Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
×

Understanding Windows container workloads

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

Multi-tenancy for clusters that have Windows nodes is not supported. Clusters are considered multi-tenant when multiple workloads operate on shared infrastructure and resources. If one or more workloads running on an infrastructure cannot be trusted, the multi-tenant environment is considered hostile.

Hostile multi-tenant clusters introduce 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 exploiting your environment 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.
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 compute machine set to host Windows Server compute machines. You must apply a Windows-specific label to the compute machine set that specifies a Windows OS image.

The WMCO watches for machines with the Windows label. After a Windows compute 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 OKD 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 Instance Config Daemon (WICD)

Maintains the state of all services running on the Windows instance to ensure the instance functions as a worker node.

Windows Exporter

Exports Prometheus metrics from Windows nodes

Kubernetes Cloud Controller Manager (CCM)

Interacts with the underlying Azure cloud platform.

hybrid-overlay

Creates the OKD Host Network Service (HNS).

kube-proxy

Maintains network rules on nodes allowing outside communication.

containerd container runtime

Manages the complete container lifecycle.

CSI Proxy

Enables CSI drivers to perform storage operations on the node, which allows containerized CSI drivers to run on Windows nodes.