Change:
{{< feature-state state="stable" for_k8s_version="v1.25" >}} You should set the `.spec.os.name` field to either `windows` or `linux` to indicate the OS on <del> which you want the pod to run. These two are the only operating systems supported for now by Kubernetes. In future, this list may be expanded. In Kubernetes v{{< skew currentVersion >}}, the value you set for this field has no effect on {{< glossary_tooltip text="scheduling" term_id="kube-scheduler" >}} of the pods. Setting the `.spec.os.name` helps to identify the pod OS authoritatively and is used for validation. The kubelet refuses to run a Pod where you have specified a Pod OS, if this isn't the same as the operating system for the node where that kubelet is running. </del> <ins> which you want the pod to run. These two are the only operating systems supported for now by Kubernetes. In the future, this list may be expanded. In Kubernetes v{{< skew currentVersion >}}, the value of `.spec.os.name` does not affect how the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} picks a Pod to run a node. In any cluster where there is more than one operating system for running nodes, you should set the [kubernetes.io/os](/docs/reference/labels-annotations-taints/#kubernetes-io-os) label correctly on each node, and define pods with a `nodeSelector` based on the operating system label, the kube-scheduler assigns your pod to a node based on other criteria and may or may not succeed in picking a suitable node placement where the node OS is right for the containers in that Pod. </ins> The [Pod security standards](/docs/concepts/security/pod-security-standards/) also use this <del> field to avoid enforcing policies that aren't relevant to that operating system. </del> <ins> field to avoid enforcing policies that aren't relevant to the operating system. </ins> ### Pods and controllers

Discussion:
While reading the documentation about the OS spec for it states: Pod OS FEATURE STATE: Kubernetes v1.25 [stable] You should set the field to either windows or linux to indicate the OS on which you want the pod to run. These two are the only operating systems supported for now by Kubernetes. In future, this list may be expanded. In Kubernetes v1.26, the value you set for this field has no effect on of the pods. Setting the helps to identify the pod OS authoratitively and is used for validation. The kubelet refuses to run a Pod where you have specified a Pod OS, if this isn't the same as the operating system for the node where that kubelet is running. The also use this field to avoid enforcing policies that aren't relevant to that operating system. The second paragraph mentions 1.26 doesn't take this field into consideration to schedule the pod but later in the same paragraph it states kubelet will take this field in consideration to schedule the pod (assigning the pod to a matching OS node). Am I reading it incorrectly or the paragraph should read "In Kubernetes v1.25, the vaule you set for this field has no effect on scheduling" ?
is correct, but perhaps misleading. How about changing the order round: Kubernetes v1.26 uses the value of to validate Pods (the kubelet checks that the Pod OS matches the operating system that the kubelet is running on). If you create (or try to create a Pod) in a namespace that uses Pod security admission, the control plane also uses the value of to work out what restrictions to verify and / or enforce. In Kubernetes v1.26, the value of does not affect how the picks a Pod to run a node. In any cluster where there is more than one operating system for nodes, you should set the  label correctly on each nodes, and define Pods with a than matches the correct operating system. If you set anddo not specify a based on the operating system label, the scheduler assigns your pod to a node based on other criteria and may or may not succeed in picking a suitable node placement where the node OS is right for the containers in that Pod. ? We could link to a task page that explains how to assign Linux Pods to Linux nodes, and Windows Pods to Windows nodes (if we had such a task page).

/sig node
/language en
Hi by your message I understand that: Kubelet will fail to run a pod with a non matching in the node that is running (as if a Linux pod is assigned to a Windows Node for example) Kube-Scheduler will not take into account to define in which node to run a pod (unless a label is specified) so it would potentially scheduling a Linux pod in a Windows node. Am I getting it right? if so I believe your message is great to be a replacement of the one in the current documentation. Just there is a missing space in this paragraph (getting a bit picky sorry ) If you set not specify a nodeSelector based on the operating system label, the scheduler assigns your pod to a node based on other criteria and may or may not succeed in picking a suitable node placement where the node OS is right for the containers in that Pod.
This could warrant a PR since the fix is clear. /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This could warrant a PR since the fix is clear. /help </details
/triage accepted
/assign
Also see /retitle Pod OS spec description is not clear
/assign