This is a cache of https://docs.openshift.com/container-platform/4.10/windows_containers/understanding-windows-container-workloads.html. It is a snapshot of the page at 2024-11-27T17:04:29.395+0000.
Understanding Windows container workloads | Windows Container Support for OpenShift | OpenShift Container Platform 4.10
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Understanding Windows container workloads

Red Hat OpenShift support for Windows Containers provides built-in support for running Microsoft Windows Server containers on OpenShift Container Platform. For those that administer heterogeneous environments with a mix of Linux and Windows workloads, OpenShift Container Platform allows you to deploy Windows workloads running on Windows Server containers while also providing traditional Linux workloads hosted on Red Hat Enterprise Linux CoreOS (RHCOS) or Red Hat Enterprise Linux (RHEL).

Multi-tenancy for clusters that have Windows nodes is not supported. Hostile multi-tenant usage introduces security concerns in all Kubernetes environments. Additional security features like pod security policies, or more fine-grained role-based access control (RBAC) for nodes, make exploits more difficult. However, if you choose to run hostile multi-tenant workloads, a hypervisor is the only security option you should use. The security domain for Kubernetes encompasses the entire cluster, not an individual node. For these types of hostile multi-tenant workloads, you should use physically isolated clusters.

Windows Server Containers provide resource isolation using a shared kernel but are not intended to be used in hostile multitenancy scenarios. Scenarios that involve hostile multitenancy should use Hyper-V Isolated Containers to strongly isolate tenants.

Windows Machine Config Operator prerequisites

The following information details the supported platform versions, Windows Server versions, and networking configurations for the Windows Machine Config Operator. See the vSphere documentation for any information that is relevant to only that platform.

Because Microsoft has stopped publishing Windows Server 2019 images with Docker, Red Hat no longer supports Windows Azure for WMCO releases earlier than version 6.0.0. For WMCO 5.y.z and earlier, Windows Server 2019 images must have Docker pre-installed. WMCO 6.0.0 and later uses containerd as the runtime. You can upgrade to OpenShift Container Platform 4.11, which uses WMCO 6.0.0.

WMCO 5.1.x supported platforms and Windows Server versions

The following table lists the Windows Server versions that are supported by WMCO 5.1.1 and 5.1.0, based on the applicable platform. Windows Server versions not listed are not supported and attempting to use them will cause errors. To prevent these errors, use only an appropriate version for your platform.

Platform Supported Windows Server version

Amazon Web Services (AWS)

Windows Server 2019 (version 1809)

Microsoft Azure

Windows Server 2019 (version 1809)

VMware vSphere

Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2022 (OS Build 20348.681 or later).

Bare metal or provider agnostic

  • Windows Server 2022 Long-Term Servicing Channel (LTSC). OS Build 20348.681 or later.

  • Windows Server 2019 (version 1809)

WMCO 5.0.0 supported platforms and Windows Server versions

The following table lists the Windows Server versions that are supported by WMCO 5.0.0, based on the applicable platform. Windows Server versions not listed are not supported and attempting to use them will cause errors. To prevent these errors, use only the appropriate version for your platform.

Platform Supported Windows Server version

Amazon Web Services (AWS)

Windows Server 2019 (version 1809)

VMware vSphere

Windows Server 2022 Long-Term Servicing Channel (LTSC). OS Build 20348.681 or later.

Bare metal or provider agnostic

Windows Server 2019 (version 1809)

Supported networking

Hybrid networking with OVN-Kubernetes is the only supported networking configuration. See the additional resources below for more information on this functionality. The following tables outline the type of networking configuration and Windows Server versions to use based on your platform. You must specify the network configuration when you install the cluster. Be aware that OpenShift SDN networking is the default network for OpenShift Container Platform clusters. However, OpenShift SDN is not supported by WMCO.

Table 1. Platform networking support
Platform Supported networking

Amazon Web Services (AWS)

Hybrid networking with OVN-Kubernetes

Microsoft Azure

Hybrid networking with OVN-Kubernetes

VMware vSphere

Hybrid networking with OVN-Kubernetes with a custom VXLAN port

bare metal

Hybrid networking with OVN-Kubernetes
Table 2. WMCO 5.1.0 Hybrid OVN-Kubernetes Windows Server support
Hybrid networking with OVN-Kubernetes Supported Windows Server version

Default VXLAN port

Windows Server 2019 (version 1809)

Custom VXLAN port

Windows Server 2022 Long-Term Servicing Channel (LTSC). OS Build 20348.681 or later
Table 3. WMCO 5.0.0 Hybrid OVN-Kubernetes Windows Server support
Hybrid networking with OVN-Kubernetes Supported Windows Server version

Default VXLAN port

Windows Server 2019 (version 1809)

Custom VXLAN port

Windows Server 2022 Long-Term Servicing Channel (LTSC). OS Build 20348.681 or later
Additional resources

Windows workload management

To run Windows workloads in your cluster, you must first install the Windows Machine Config Operator (WMCO). The WMCO is a Linux-based Operator that runs on Linux-based control plane and compute nodes. The WMCO orchestrates the process of deploying and managing Windows workloads on a cluster.

WMCO workflow
Figure 1. WMCO design

Before deploying Windows workloads, you must create a Windows compute node and have it join the cluster. The Windows node hosts the Windows workloads in a cluster, and can run alongside other Linux-based compute nodes. You can create a Windows compute node by creating a Windows machine set to host Windows Server compute machines. You must apply a Windows-specific label to the machine set that specifies a Windows OS image that has the Docker-formatted container runtime add-on enabled.

Currently, the Docker-formatted container runtime is used in Windows nodes. Kubernetes is deprecating Docker as a container runtime; you can reference the Kubernetes documentation for more information in Docker deprecation. Containerd will be the new supported container runtime for Windows nodes in a future release of Kubernetes.

The WMCO watches for machines with the Windows label. After a Windows machine set is detected and its respective machines are provisioned, the WMCO configures the underlying Windows virtual machine (VM) so that it can join the cluster as a compute node.

Mixed Windows and Linux workloads
Figure 2. Mixed Windows and Linux workloads

The WMCO expects a predetermined secret in its namespace containing a private key that is used to interact with the Windows instance. WMCO checks for this secret during boot up time and creates a user data secret which you must reference in the Windows MachineSet object that you created. Then the WMCO populates the user data secret with a public key that corresponds to the private key. With this data in place, the cluster can connect to the Windows VM using an SSH connection.

After the cluster establishes a connection with the Windows VM, you can manage the Windows node using similar practices as you would a Linux-based node.

The OpenShift Container Platform web console provides most of the same monitoring capabilities for Windows nodes that are available for Linux nodes. However, the ability to monitor workload graphs for pods running on Windows nodes is not available at this time.

Scheduling Windows workloads to a Windows node can be done with typical pod scheduling practices like taints, tolerations, and node selectors; alternatively, you can differentiate your Windows workloads from Linux workloads and other Windows-versioned workloads by using a RuntimeClass object.

Windows node services

The following Windows-specific services are installed on each Windows node:

Service Description

kubelet

Registers the Windows node and manages its status.

Container Network Interface (CNI) plugins

Exposes networking for Windows nodes.

Windows Machine Config Bootstrapper (WMCB)

Configures the kubelet and CNI plugins.

Windows Exporter

Exports Prometheus metrics from Windows nodes

Kubernetes Cloud Controller Manager (CCM)

Interacts with the underlying Azure cloud platform.

hybrid-overlay

Creates the OpenShift Container Platform Host Network Service (HNS).

kube-proxy

Maintains network rules on nodes allowing outside communication.

Known limitations

Note the following limitations when working with Windows nodes managed by the WMCO (Windows nodes):

  • The following OpenShift Container Platform features are not supported on Windows nodes:

    • Image builds

    • OpenShift Pipelines

    • OpenShift Service Mesh

    • OpenShift monitoring of user-defined projects

    • OpenShift Serverless

    • Horizontal Pod Autoscaling

    • Vertical Pod Autoscaling

  • The following Red Hat features are not supported on Windows nodes:

  • Windows nodes do not support pulling container images from private registries. You can use images from public registries or pre-pull the images.

  • Windows nodes do not support workloads created by using deployment configs. You can use a deployment or other method to deploy workloads.

  • Windows nodes are not supported in clusters that use a cluster-wide proxy. This is because the WMCO is not able to route traffic through the proxy connection for the workloads.

  • Windows nodes are not supported in clusters that are in a disconnected environment.

  • Red Hat OpenShift support for Windows Containers does not support adding Windows nodes to a cluster through a trunk port. The only supported networking configuration for adding Windows nodes is through an access port that carries traffic for the VLAN.

  • Red Hat OpenShift support for Windows Containers supports only in-tree storage drivers for all cloud providers.

  • Kubernetes has identified the following node feature limitations :

    • Huge pages are not supported for Windows containers.

    • Privileged containers are not supported for Windows containers.

    • Pod termination grace periods require the containerd container runtime to be installed on the Windows node.

  • Kubernetes has identified several API compatibility issues.