Merge pull request #32481 from tengqm/IdentifyOS-beta

Promote IdentifyPodOS to Beta
kubernetes · Mar 29, 2022 · 9f50755 · 9f50755
2 parents 55a0710 + 2536593
commit 9f50755
Show file tree

Hide file tree

Showing 3 changed files with 49 additions and 33 deletions.
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@@ -126,7 +126,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 | |

diff --git a/...ent/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/...ent/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -84,35 +84,43 @@ 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.
-               `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:
-               * `spec.hostPID`
-               * `spec.hostIPC`
-               * `spec.securityContext.seLinuxOptions`
-               * `spec.securityContext.seccompProfile`
-               * `spec.securityContext.fsGroup`
-               * `spec.securityContext.fsGroupChangePolicy`
-               * `spec.securityContext.sysctls`
-               * `spec.shareProcessNamespace`
-               * `spec.securityContext.runAsUser`
-               * `spec.securityContext.runAsGroup`
-               * `spec.securityContext.supplementalGroups`
-               * `spec.containers[*].securityContext.seLinuxOptions`
-               * `spec.containers[*].securityContext.seccompProfile`
-               * `spec.containers[*].securityContext.capabilities`
-               * `spec.containers[*].securityContext.readOnlyRootFilesystem`
-               * `spec.containers[*].securityContext.privileged`
-               * `spec.containers[*].securityContext.allowPrivilegeEscalation`
-               * `spec.containers[*].securityContext.procMount`
-               * `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.
-            {{< /note >}}
+
+    The `.spec.os.name` field should be set to `windows` to indicate that the current Pod uses Windows containers.
+    The `IdentifyPodOS` feature gate needs to be enabled for this field to be recognized and used by control plane
+    components and kubelet.
+
+    {{< note >}}
+    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`
+    * `spec.securityContext.seccompProfile`
+    * `spec.securityContext.fsGroup`
+    * `spec.securityContext.fsGroupChangePolicy`
+    * `spec.securityContext.sysctls`
+    * `spec.shareProcessNamespace`
+    * `spec.securityContext.runAsUser`
+    * `spec.securityContext.runAsGroup`
+    * `spec.securityContext.supplementalGroups`
+    * `spec.containers[*].securityContext.seLinuxOptions`
+    * `spec.containers[*].securityContext.seccompProfile`
+    * `spec.containers[*].securityContext.capabilities`
+    * `spec.containers[*].securityContext.readOnlyRootFilesystem`
+    * `spec.containers[*].securityContext.privileged`
+    * `spec.containers[*].securityContext.allowPrivilegeEscalation`
+    * `spec.containers[*].securityContext.procMount`
+    * `spec.containers[*].securityContext.runAsUser`
+    * `spec.containers[*].securityContext.runAsGroup`
+
+    In the above list, wildcards (`*`) indicate all elements in a list.
+    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

diff --git a/...t/en/docs/setup/production-environment/windows/user-guide-windows-containers.md b/...t/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.