Skip to content

OSDOCS CQA WINC-1: Windows Workload Management and Basics I #113245

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mburke5678 merged 1 commit into from
Jun 12, 2026
Merged

OSDOCS CQA WINC-1: Windows Workload Management and Basics I #113245

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 19 additions & 9 deletions modules/creating-runtimeclass.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,13 @@
[id="creating-runtimeclass_{context}"]
= Creating a RuntimeClass object to encapsulate scheduling mechanisms

Using a `RuntimeClass` object simplifies the use of scheduling mechanisms like taints and tolerations; you deploy a runtime class that encapsulates your taints and tolerations and then apply it to your pods to schedule them to the appropriate node. Creating a runtime class is also necessary in clusters that support multiple operating system variants.
// Wording taken from Windows pod placement module
[role="_abstract"]
To deploy Windows workloads, you must create a `RuntimeClass` object to map your Windows pods to a base Windows OS variant.

Using a `RuntimeClass` object simplifies the use of scheduling mechanisms like taints and tolerations; you deploy a runtime class that encapsulates your taints and tolerations and then apply it to your pods to schedule them to the appropriate node.

Creating a runtime class is also necessary in clusters that support multiple operating system variants.

.Procedure

Expand All @@ -17,14 +23,14 @@ Using a `RuntimeClass` object simplifies the use of scheduling mechanisms like t
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: windows2025 <1>
name: windows2025
handler: 'runhcs-wcow-process'
scheduling:
nodeSelector: <2>
nodeSelector:
kubernetes.io/os: 'windows'
kubernetes.io/arch: 'amd64'
node.kubernetes.io/windows-build: '10.0.26100'
tolerations: <3>
tolerations:
- effect: NoSchedule
key: os
operator: Equal
Expand All @@ -34,12 +40,14 @@ scheduling:
operator: Equal
value: "Windows"
----
<1> Specify the `RuntimeClass` object name, which is defined in the pods you want to be managed by this runtime class.
<2> Specify labels that must be present on nodes that support this runtime class. Pods using this runtime class can only be scheduled to a node matched by this selector. The node selector of the runtime class is merged with the existing node selector of the pod. Any conflicts prevent the pod from being scheduled to the node.
where:

`metadata.name`:: Specifies the `RuntimeClass` object name, which is defined in the pods you want to be managed by this runtime class.
`scheduling.nodeSelector`:: Specifies labels that must be present on nodes that support this runtime class. Pods using this runtime class can only be scheduled to a node matched by this selector. The node selector of the runtime class is merged with the existing node selector of the pod. Any conflicts prevent the pod from being scheduled to the node.
* For Windows 2025, specify the `node.kubernetes.io/windows-build: '10.0.26100'` label.
* For Windows 2022, specify the `node.kubernetes.io/windows-build: '10.0.20348'` label.
* For Windows 2019, specify the `node.kubernetes.io/windows-build: '10.0.17763'` label.
<3> Specify tolerations to append to pods, excluding duplicates, running with this runtime class during admission. This combines the set of nodes tolerated by the pod and the runtime class.
`scheduling.tolerations`:: Specifies tolerations to append to pods, excluding duplicates, running with this runtime class during admission. This combines the set of nodes tolerated by the pod and the runtime class.

. Create the `RuntimeClass` object:
+
Expand All @@ -64,7 +72,9 @@ kind: Pod
metadata:
name: my-windows-pod
spec:
runtimeClassName: windows2025 <1>
runtimeClassName: windows2025
# ...
----
<1> Specify the runtime class to manage the scheduling of your pod.
where:

`spec.runtimeClassName`:: Specifies the runtime class to manage the scheduling of your pod.
3 changes: 2 additions & 1 deletion modules/deleting-wmco-namespace.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@
[id="deleting-wmco-namespace_{context}"]
= Deleting the Windows Machine Config Operator namespace

You can delete the namespace that was generated for the Windows Machine Config Operator (WMCO) by default.
[role="_abstract"]
If you want to disable the capability to run Windows container workloads, after you uninstall the Windows Machine Config Operator (WMCO), you can delete the namespace that was generated by default for the WMCO.

.Prerequisites

Expand Down
3 changes: 2 additions & 1 deletion modules/machineset-manually-scaling.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
[id="machineset-manually-scaling_{context}"]
= Scaling a compute machine set manually

[role="_abstract"]
To add or remove an instance of a machine in a compute machine set, you can manually scale the compute machine set.

This guidance is relevant to fully automated, installer-provisioned infrastructure installations. Customized, user-provisioned infrastructure installations do not have compute machine sets.
Expand Down Expand Up @@ -88,4 +89,4 @@ You can skip draining the node by annotating `machine.openshift.io/exclude-node-
[source,terminal]
----
$ oc get machines.machine.openshift.io
----
----
17 changes: 10 additions & 7 deletions modules/sample-windows-workload-deployment.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@
[id="sample-windows-workload-deployment_{context}"]
= Sample Windows container workload deployment

You can deploy Windows container workloads to your cluster once you have a Windows compute node available.
[role="_abstract"]
You can deploy Windows container workloads to your cluster after you have a Windows compute node available.

[NOTE]
====
Expand Down Expand Up @@ -54,10 +55,10 @@ spec:
spec:
containers:
- name: windowswebserver
image: mcr.microsoft.com/windows/servercore:ltsc2025 <1>
image: mcr.microsoft.com/windows/servercore:ltsc2025
imagePullPolicy: IfNotPresent
command:
- powershell.exe <2>
- powershell.exe
- -command
- $listener = New-Object System.Net.HttpListener; $listener.Prefixes.Add('http://*:80/'); $listener.Start();Write-Host('Listening at http://*:80/'); while ($listener.IsListening) { $context = $listener.GetContext(); $response = $context.Response; $content='<html><body><H1>Red Hat OpenShift + Windows Container Workloads</H1></body></html>'; $buffer = [System.Text.Encoding]::UTF8.GetBytes($content); $response.ContentLength64 = $buffer.Length; $response.OutputStream.Write($buffer, 0, $buffer.Length); $response.Close(); };
securityContext:
Expand All @@ -66,13 +67,15 @@ spec:
runAsUserName: "ContainerAdministrator"
os:
name: "windows"
runtimeClassName: windows2025 <3>
runtimeClassName: windows2025
----
<1> Specify the container image to use: `mcr.microsoft.com/powershell:<tag>` or `mcr.microsoft.com/windows/servercore:<tag>`. The container image must match the Windows version running on the node.
where:

`spec.template.spec.containers.image`:: Specifies the container image to use: `mcr.microsoft.com/powershell:<tag>` or `mcr.microsoft.com/windows/servercore:<tag>`. The container image must match the Windows version running on the node.
* For Windows 2025, use the `ltsc2025` tag.
* For Windows 2022, use the `ltsc2022` tag.
* For Windows 2019, use the `ltsc2019` tag.
<2> Specify the commands to execute on the container.
`spec.template.spec.containers.command`:: Specifies the commands to execute on the container.
* For the `mcr.microsoft.com/powershell:<tag>` container image, you must define the command as `pwsh.exe`.
* For the `mcr.microsoft.com/windows/servercore:<tag>` container image, you must define the command as `powershell.exe`.
<3> Specify the runtime class you created for the Windows operating system variant on your cluster.
`spec.template.spec.runtimeClassName`:: Specifies the runtime class you created for the Windows operating system variant on your cluster.
3 changes: 2 additions & 1 deletion modules/uninstalling-wmco.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@
[id="uninstalling-wmco_{context}"]
= Uninstalling the Windows Machine Config Operator

You can uninstall the Windows Machine Config Operator (WMCO) from your cluster.
[role="_abstract"]
If you want to disable the capability to run Windows container workloads, you can uninstall the Windows Machine Config Operator (WMCO) from your cluster.

.Prerequisites

Expand Down
11 changes: 7 additions & 4 deletions modules/windows-pod-placement.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,18 +6,21 @@
[id="windows-pod-placement_{context}"]
= Windows pod placement

Before deploying your Windows workloads to the cluster, you must configure your Windows node scheduling so pods are assigned correctly. Since you have a machine hosting your Windows node, it is managed the same as a Linux-based node. Likewise, scheduling a Windows pod to the appropriate Windows node is completed similarly, using mechanisms like taints, tolerations, and node selectors.
[role="_abstract"]
Before deploying your Windows workloads to the cluster, you must configure your Windows node scheduling so pods are assigned correctly.

The machine hosting your Windows node is managed the same as a Linux-based node. Likewise, scheduling a Windows pod to the appropriate Windows node is completed similarly, using mechanisms like taints, tolerations, and node selectors.

With multiple operating systems, and the ability to run multiple Windows OS variants in the same cluster, you must map your Windows pods to a base Windows OS variant by using a `RuntimeClass` object. For example, if you have multiple Windows nodes running on different Windows Server container versions, the cluster could schedule your Windows pods to an incompatible Windows OS variant. You must have `RuntimeClass` objects configured for each Windows OS variant on your cluster. Using a `RuntimeClass` object is also recommended if you have only one Windows OS variant available in your cluster.

For more information, see Microsoft's documentation on link:https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/update-containers#host-and-container-version-compatibility[Host and container version compatibility, Microsoft Windows documentation].
For more information, see "Host and container version compatibility" in the Microsoft Windows documentation, which is linked in the "Additional resources" section.

Also, it is recommended that you set the `spec.os.name.windows` parameter in your workload pods. The Windows Machine Config Operator (WMCO) uses this field to authoritatively identify the pod operating system for validation and is used to enforce Windows-specific pod security context constraints (SCCs). Currently, this parameter has no effect on pod scheduling. For more information about this parameter, see the link:https://kubernetes.io/docs/concepts/workloads/pods/#pod-os[Kubernetes Pods documentation].
Also, it is recommended that you set the `spec.os.name.windows` parameter in your workload pods. The Windows Machine Config Operator (WMCO) uses this field to authoritatively identify the pod operating system for validation and is used to enforce Windows-specific pod security context constraints (SCCs). Currently, this parameter has no effect on pod scheduling. For more information about this parameter, see the Kubernetes Pod OS documentation.

[IMPORTANT]
====
The container base image must be the same Windows OS version and build number that is running on the node where the conainer is to be scheduled.

Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see link:https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11-21H2[Windows container version compatibility, Microsoft Windows documentation].
Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see Windows container version compatibility in the Microsoft Windows documentation.

@lahinson lahinson Jun 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see Windows container version compatibility in the Microsoft Windows documentation.
Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see Windows container version compatibility in the Microsoft Windows documentation, which is linked in the "Additional resources" section.

====

5 changes: 4 additions & 1 deletion modules/windows-upgrades-eus.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,10 @@
[id="wmco-upgrades-eus_{context}"]
= Windows Machine Config Operator Control Plane Only update

{product-title} and Windows Machine Config Operator (WMCO) support updating from one EUS version to another EUS version of {product-title}, in a process called a *Control Plane Only* update. After upgrading the cluster, the Windows nodes are updated from the starting EUS version to the new EUS version while keeping the Windows workloads in a healthy state with no disruptions.
[role="_abstract"]
You can use the *Control Plane Only* process to update the {product-title} from one EUS version to another EUS version of {product-title}. After you update the cluster, the Windows nodes are updated the new EUS version.

During the update, the Windows workloads are kept in a healthy state with no disruptions.

[IMPORTANT]
====
Expand Down
7 changes: 5 additions & 2 deletions modules/wmco-supported-csi-drivers.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,9 +6,12 @@
[id="wmco-supported-csi-drivers_{context}"]
= Support for Windows CSI drivers

{productwinc} installs link:https://github.com/kubernetes-csi/csi-proxy[CSI Proxy] on all Windows nodes in the cluster. CSI Proxy is a plug-in that enables CSI drivers to perform storage operations on the node.
[role="_abstract"]
You can use the CSI PROXY plug-in to perform storage operations on the nodes in your cluster.

To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of link:https://kubernetes-csi.github.io/docs/drivers.html#production-drivers[production drivers] in the Kubernetes CSI Developer Documentation.
{productwinc} installs CSI Proxy, which is a plug-in that enables CSI drivers for performing storage operations, on all Windows nodes in the cluster. For more information, see the CSI Proxy link in the "Additional resources" section.

To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of production drivers in the Kubernetes CSI Developer Documentation by using the link in the "Additional resources" section.

@lahinson lahinson Jun 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of production drivers in the Kubernetes CSI Developer Documentation by using the link in the "Additional resources" section.
To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of production drivers in the Kubernetes CSI Developer Documentation, which is linked in the "Additional resources" section.


[NOTE]
====
Expand Down
1 change: 1 addition & 0 deletions modules/wmco-upgrades-eus-using-cli.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@
[id="wmco-upgrades-eus-using-cli_{context}"]
= WMCO Control Plane Only update by using the CLI

[role="_abstract"]
You can use the {oc-first} to perform a Control Plane Only update of the Windows Machine Config Operator (WMCO).

.Prerequisites
Expand Down
1 change: 1 addition & 0 deletions modules/wmco-upgrades-eus-using-web-console.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@
[id="wmco-upgrades-eus-using-web-console_{context}"]
= WMCO Control Plane Only update by using the web console

[role="_abstract"]
You can use the {product-title} web console to perform a Control Plane Only update of the Windows Machine Config Operator (WMCO).

.Prerequisites
Expand Down
5 changes: 4 additions & 1 deletion modules/wmco-upgrades.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,10 @@
[id="wmco-upgrades_{context}"]
= Windows Machine Config Operator updates

When a new version of the Windows Machine Config Operator (WMCO) is released that is compatible with the current cluster version, the Operator is updated based on the update channel and subscription approval strategy it was installed with when using the Operator Lifecycle Manager (OLM). The WMCO update results in the Kubernetes components in the Windows machine being updated.
[role="_abstract"]
When a new version of the Windows Machine Config Operator (WMCO) is released that is compatible with the current cluster version, the Operator is updated based on the update channel and subscription approval strategy it was installed with when using the Operator Lifecycle Manager (OLM).

The WMCO update results in the Kubernetes components in the Windows machine being updated.

[NOTE]
====
Expand Down
1 change: 1 addition & 0 deletions windows_containers/disabling-windows-container-workloads.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]

toc::[]

[role="_abstract"]
You can disable the capability to run Windows container workloads by uninstalling the Windows Machine Config Operator (WMCO) and deleting the namespace that was added by default when you installed the WMCO.

include::modules/uninstalling-wmco.adoc[leveloffset=+1]
Expand Down
25 changes: 15 additions & 10 deletions windows_containers/scheduling-windows-workloads.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[]

toc::[]

You can schedule Windows workloads to Windows compute nodes.
[role="_abstract"]
You can use the Windows Machine Config Operator (WMCO) to schedule Windows workloads to Windows compute nodes.


== Prerequisites
Expand All @@ -17,20 +18,24 @@ You can schedule Windows workloads to Windows compute nodes.

include::modules/windows-pod-placement.adoc[leveloffset=+1]

include::modules/creating-runtimeclass.adoc[leveloffset=+1]

[role="_additional-resources"]
=== Additional resources
include::modules/sample-windows-workload-deployment.adoc[leveloffset=+1]

include::modules/wmco-supported-csi-drivers.adoc[leveloffset=+1]

include::modules/machineset-manually-scaling.adoc[leveloffset=+1]

[role="_additional-resources"]
[id="additional-resources_{context}"]
== Additional resources
* link:https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/update-containers#host-and-container-version-compatibility[Host and container version compatibility (Microsoft Windows documentation)]
* link:https://kubernetes.io/docs/concepts/workloads/pods/#pod-os[Pod OS (Kubernetes documentation)]
* link:https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11-21H2[Windows container version compatibility (Microsoft Windows documentation)]
* link:https://kubernetes-csi.github.io/docs/drivers.html#production-drivers[Production Drivers (Kubernetes CSI Developer Documentation)]
* xref:../nodes/scheduling/nodes-scheduler-about.adoc#nodes-scheduler-about[Controlling pod placement using the scheduler]
ifndef::openshift-dedicated,openshift-rosa[]
* xref:../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[Controlling pod placement using node taints]
endif::openshift-dedicated,openshift-rosa[]
* xref:../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors]

include::modules/creating-runtimeclass.adoc[leveloffset=+1]

include::modules/sample-windows-workload-deployment.adoc[leveloffset=+1]

include::modules/wmco-supported-csi-drivers.adoc[leveloffset=+1]

include::modules/machineset-manually-scaling.adoc[leveloffset=+1]
17 changes: 6 additions & 11 deletions windows_containers/windows-node-upgrades.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]

toc::[]

[role="_abstract"]
You can ensure your Windows nodes have the latest updates by updating the Windows Machine Config Operator (WMCO).

You can update the WMCO in any of the following scenarios:
Expand All @@ -16,23 +17,17 @@ You can update the WMCO in any of the following scenarios:

include::modules/wmco-upgrades.adoc[leveloffset=+1]

[role="_additional-resources"]
.Additional resources
* xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators].

include::modules/windows-upgrades-eus.adoc[leveloffset=+1]

include::modules/wmco-upgrades-eus-using-web-console.adoc[leveloffset=+2]

[role="_additional-resources"]
.Additional resources
* xref:../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update]
* xref:../windows_containers/enabling-windows-container-workloads.adoc#installing-wmco-using-web-console_enabling-windows-container-workloads[Installing the Windows Machine Config Operator using the web console]

include::modules/wmco-upgrades-eus-using-cli.adoc[leveloffset=+2]

[role="_additional-resources"]
.Additional resources
* xref:../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operator-from-a-cluster-using-cli_olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster using the CLI]
[id="additional-resources_{context}"]
== Additional resources
* xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators]
* xref:../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update]
* xref:../windows_containers/enabling-windows-container-workloads.adoc#installing-wmco-using-cli_enabling-windows-container-workloads[Installing the Windows Machine Config Operator using the CLI]
* xref:../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operator-from-a-cluster-using-cli_olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster using the CLI]