Promote IdentifyOS to Beta

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -128,7 +128,8 @@ different Kubernetes components.
 | `HonorPVReclaimPolicy` | `false` | Alpha | 1.23 | |
 | `HPAContainerMetrics` | `false` | Alpha | 1.20 | |
 | `HPAScaleToZero` | `false` | Alpha | 1.16 | |
-| `IdentifyPodOS` | `false` | Alpha | 1.23 | |
+| `IdentifyPodOS` | `false` | Alpha | 1.23 | 1.23 |
+| `IdentifyPodOS` | `true` | Beta | 1.24 | |
 | `InTreePluginAWSUnregister` | `false` | Alpha | 1.21 | |
 | `InTreePluginAzureDiskUnregister` | `false` | Alpha | 1.21 | |
 | `InTreePluginAzureFileUnregister` | `false` | Alpha | 1.21 | |

content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md

@@ -154,12 +154,18 @@ section refers to several key workload enablers and how they map to Windows.
   * Named pipe host mounts
   * Resource limits
   * OS field: 
-              {{< feature-state for_k8s_version="v1.23" state="alpha" >}}
+
-               `.spec.os.name` should be set to `windows` to indicate that the current Pod uses Windows containers.
+    The `.spec.os.name` field should be set to `windows` to indicate that the current Pod uses Windows containers.
-               `IdentifyPodOS` feature gate needs to be enabled for this field to be recognized and used by control plane
+    The `IdentifyPodOS` feature gate needs to be enabled for this field to be recognized and used by control plane
     components and kubelet.
+
     {{< note >}}
-              If the `IdentifyPodOS` feature gate is enabled and you set the `.spec.os.name` field to `windows`, you must not set the following fields in the `.spec` of that Pod:
+    Starting from 1.24, the `IdentifyPodOS` feature gate is in Beta stage and defaults to be enabled.
+    {{< /note >}}
+
+    If the `IdentifyPodOS` feature gate is enabled and you set the `.spec.os.name` field to `windows`,
+    you must not set the following fields in the `.spec` of that Pod:
+
     * `spec.hostPID`
     * `spec.hostIPC`
     * `spec.securityContext.seLinuxOptions`
@@ -181,8 +187,10 @@ section refers to several key workload enablers and how they map to Windows.
     * `spec.containers[*].securityContext.runAsUser`
     * `spec.containers[*].securityContext.runAsGroup`
 
-            Note: In this table, wildcards (*) indicate all elements in a list. For example, spec.containers[*].securityContext refers to the Security Context object for all defined containers. If not, Pod API validation would fail causing admission failures.
+    In the above list, wildcards (`*`) indicate all elements in a list.
-            {{< /note >}}
+    For example, `spec.containers[*].securityContext` refers to the SecurityContext object
+    for all containers. If any of these fields is specified, the Pod will
+    not be admited by the API server.
 
 * [Workload resources](/docs/concepts/workloads/controllers/) including:
   * ReplicaSet

content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md

@@ -160,21 +160,28 @@ Users today need to use some combination of taints and node selectors in order t
 keep Linux and Windows workloads on their respective OS-specific nodes. 
 This likely imposes a burden only on Windows users. The recommended approach is outlined below, 
 with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
- {{< note >}}
+
+
 If the `IdentifyPodOS` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is
 enabled, you can (and should) set `.spec.os.name` for a Pod to indicate the operating system
 that the containers in that Pod are designed for. For Pods that run Linux containers, set
 `.spec.os.name` to `linux`. For Pods that run Windows containers, set `.spec.os.name`
 to Windows.
 
+{{< note >}}
+Starting from 1.24, the `IdentifyPodOS` feature is in Beta stage and defaults to be enabled.
+{{< /note >}}
+
 The scheduler does not use the value of `.spec.os.name` when assigning Pods to nodes. You should
 use normal Kubernetes mechanisms for
 [assigning pods to nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
 to ensure that the control plane for your cluster places pods onto nodes that are running the
 appropriate operating system.
- no effect on the scheduling of the Windows pods, so taints and tolerations and node selectors are still required
+
+The `.spec.os.name` value has no effect on the scheduling of the Windows pods,
+so taints and tolerations and node selectors are still required
  to ensure that the Windows pods land onto appropriate Windows nodes.
- {{< /note >}}
+
 ### Ensuring OS-specific workloads land on the appropriate container host
 
 Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations.