Promote IdentifyOS to Beta
Qiming Teng
parent
b2f72a383e
commit
2536593a39
|
|
@ -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 | |
|
||||
|
|
|
|||
|
|
@ -154,35 +154,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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue