Chapter 5. Enabling Windows container workloads
Before adding Windows workloads to your cluster, you must install the Windows Machine Config Operator (WMCO), which is available in the OpenShift Container Platform OperatorHub. The WMCO orchestrates the process of deploying and managing Windows workloads on a cluster.
Dual NIC is not supported on WMCO-managed Windows instances.
Prerequisites
-
You have access to an OpenShift Container Platform cluster using an account with
cluster-admin
permissions. -
You have installed the OpenShift CLI (
oc
). -
You have installed your cluster using installer-provisioned infrastructure, or using user-provisioned infrastructure with the
platform: none
field set in yourinstall-config.yaml
file. - You have configured hybrid networking with OVN-Kubernetes for your cluster. For more information, see Configuring hybrid networking.
- You are running an OpenShift Container Platform cluster version 4.6.8 or later.
Windows instances deployed by the WMCO are configured with the containerd container runtime. Because WMCO installs and manages the runtime, it is recommanded that you do not manually install containerd on nodes.
Additional resources
- For the comprehensive prerequisites for the Windows Machine Config Operator, see Windows Machine Config Operator prerequisites.
5.1. Installing the Windows Machine Config Operator
You can install the Windows Machine Config Operator using either the web console or OpenShift CLI (oc
).
- The WMCO is not supported in clusters that use a cluster-wide proxy because the WMCO is not able to route traffic through the proxy connection for the workloads.
-
Due to a limitation within the Windows operating system,
clusterNetwork
CIDR addresses of class E, such as240.0.0.0
, are not compatible with Windows nodes.
5.1.1. Installing the Windows Machine Config Operator using the web console
You can use the OpenShift Container Platform web console to install the Windows Machine Config Operator (WMCO).
Dual NIC is not supported on WMCO-managed Windows instances.
Procedure
-
From the Administrator perspective in the OpenShift Container Platform web console, navigate to the Operators
OperatorHub page. -
Use the Filter by keyword box to search for
Windows Machine Config Operator
in the catalog. Click the Windows Machine Config Operator tile. - Review the information about the Operator and click Install.
On the Install Operator page:
- Select the stable channel as the Update Channel. The stable channel enables the latest stable release of the WMCO to be installed.
- The Installation Mode is preconfigured because the WMCO must be available in a single namespace only.
-
Choose the Installed Namespace for the WMCO. The default Operator recommended namespace is
openshift-windows-machine-config-operator
. - Click the Enable Operator recommended cluster monitoring on the Namespace checkbox to enable cluster monitoring for the WMCO.
Select an Approval Strategy.
- The Automatic strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
- The Manual strategy requires a user with appropriate credentials to approve the Operator update.
Click Install. The WMCO is now listed on the Installed Operators page.
NoteThe WMCO is installed automatically into the namespace you defined, like
openshift-windows-machine-config-operator
.- Verify that the Status shows Succeeded to confirm successful installation of the WMCO.
5.1.2. Installing the Windows Machine Config Operator using the CLI
You can use the OpenShift CLI (oc
) to install the Windows Machine Config Operator (WMCO).
Dual NIC is not supported on WMCO-managed Windows instances.
Procedure
Create a namespace for the WMCO.
Create a
Namespace
object YAML file for the WMCO. For example,wmco-namespace.yaml
:apiVersion: v1 kind: Namespace metadata: name: openshift-windows-machine-config-operator 1 labels: openshift.io/cluster-monitoring: "true" 2
Create the namespace:
$ oc create -f <file-name>.yaml
For example:
$ oc create -f wmco-namespace.yaml
Create the Operator group for the WMCO.
Create an
OperatorGroup
object YAML file. For example,wmco-og.yaml
:apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: windows-machine-config-operator namespace: openshift-windows-machine-config-operator spec: targetNamespaces: - openshift-windows-machine-config-operator
Create the Operator group:
$ oc create -f <file-name>.yaml
For example:
$ oc create -f wmco-og.yaml
Subscribe the namespace to the WMCO.
Create a
Subscription
object YAML file. For example,wmco-sub.yaml
:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: windows-machine-config-operator namespace: openshift-windows-machine-config-operator spec: channel: "stable" 1 installPlanApproval: "Automatic" 2 name: "windows-machine-config-operator" source: "redhat-operators" 3 sourceNamespace: "openshift-marketplace" 4
- 1
- Specify
stable
as the channel. - 2
- Set an approval strategy. You can set
Automatic
orManual
. - 3
- Specify the
redhat-operators
catalog source, which contains thewindows-machine-config-operator
package manifests. If your OpenShift Container Platform is installed on a restricted network, also known as a disconnected cluster, specify the name of theCatalogSource
object you created when you configured the Operator LifeCycle Manager (OLM). - 4
- Namespace of the catalog source. Use
openshift-marketplace
for the default OperatorHub catalog sources.
Create the subscription:
$ oc create -f <file-name>.yaml
For example:
$ oc create -f wmco-sub.yaml
The WMCO is now installed to the
openshift-windows-machine-config-operator
.
Verify the WMCO installation:
$ oc get csv -n openshift-windows-machine-config-operator
Example output
NAME DISPLAY VERSION REPLACES PHASE windows-machine-config-operator.2.0.0 Windows Machine Config Operator 2.0.0 Succeeded
5.2. Configuring a secret for the Windows Machine Config Operator
To run the Windows Machine Config Operator (WMCO), you must create a secret in the WMCO namespace containing a private key. This is required to allow the WMCO to communicate with the Windows virtual machine (VM).
Prerequisites
- You installed the Windows Machine Config Operator (WMCO) using Operator Lifecycle Manager (OLM).
- You created a PEM-encoded file containing an RSA key.
Procedure
Define the secret required to access the Windows VMs:
$ oc create secret generic cloud-private-key --from-file=private-key.pem=${HOME}/.ssh/<key> \ -n openshift-windows-machine-config-operator 1
- 1
- You must create the private key in the WMCO namespace, like
openshift-windows-machine-config-operator
.
It is recommended to use a different private key than the one used when installing the cluster.
5.3. Using Windows containers in a proxy-enabled cluster
The Windows Machine Config Operator (WMCO) can consume and use a cluster-wide egress proxy configuration when making external requests outside the cluster’s internal network.
This allows you to add Windows nodes and run workloads in a proxy-enabled cluster, allowing your Windows nodes to pull images from registries that are secured behind your proxy server or to make requests to off-cluster services and services that use a custom public key infrastructure.
The cluster-wide proxy affects system components only, not user workloads.
In proxy-enabled clusters, the WMCO is aware of the NO_PROXY
, HTTP_PROXY
, and HTTPS_PROXY
values that are set for the cluster. The WMCO periodically checks whether the proxy environment variables have changed. If there is a discrepancy, the WMCO reconciles and updates the proxy environment variables on the Windows instances.
Windows workloads created on Windows nodes in proxy-enabled clusters do not inherit proxy settings from the node by default, the same as with Linux nodes. Also, by default PowerShell sessions do not inherit proxy settings on Windows nodes in proxy-enabled clusters.
Additional resources
5.4. Rebooting a node gracefully
The Windows Machine Config Operator (WMCO) minimizes node reboots whenever possible. However, certain operations and updates require a reboot to ensure that changes are applied correctly and securely. To safely reboot your Windows nodes, use the graceful reboot process. For information on gracefully rebooting a standard OpenShift Container Platform node, see "Rebooting a node gracefully" in the Nodes documentation.
Before rebooting a node, it is recommended to backup etcd data to avoid any data loss on the node.
For single-node OpenShift clusters that require users to perform the oc login
command rather than having the certificates in kubeconfig
file to manage the cluster, the oc adm
commands might not be available after cordoning and draining the node. This is because the openshift-oauth-apiserver
pod is not running due to the cordon. You can use SSH to access the nodes as indicated in the following procedure.
In a single-node OpenShift cluster, pods cannot be rescheduled when cordoning and draining. However, doing so gives the pods, especially your workload pods, time to properly stop and release associated resources.
Procedure
To perform a graceful restart of a node:
Mark the node as unschedulable:
$ oc adm cordon <node1>
Drain the node to remove all the running pods:
$ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force
You might receive errors that pods associated with custom pod disruption budgets (PDB) cannot be evicted.
Example error
error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
In this case, run the drain command again, adding the
disable-eviction
flag, which bypasses the PDB checks:$ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction
SSH into the Windows node and enter PowerShell by running the following command:
C:\> powershell
Restart the node by running the following command:
C:\> Restart-Computer -Force
Windows nodes on Amazon Web Services (AWS) do not return to
READY
state after a graceful reboot due to an inconsistency with the EC2 instance metadata routes and the Host Network Service (HNS) networks.After the reboot, SSH into any Windows node on AWS and add the route by running the following command in a shell prompt:
C:\> route add 169.254.169.254 mask 255.255.255.0 <gateway_ip>
where:
169.254.169.254
- Specifies the address of the EC2 instance metadata endpoint.
255.255.255.255
- Specifies the network mask of the EC2 instance metadata endpoint.
<gateway_ip>
Specifies the corresponding IP address of the gateway in the Windows instance, which you can find by running the following command:
C:\> ipconfig | findstr /C:"Default Gateway"
After the reboot is complete, mark the node as schedulable by running the following command:
$ oc adm uncordon <node1>
Verify that the node is ready:
$ oc get node <node1>
Example output
NAME STATUS ROLES AGE VERSION <node1> Ready worker 6d22h v1.18.3+b0068a8
Additional resources