Chapter 2. Release notes

2.1. Red Hat OpenShift support for Windows Containers release notes

The release notes for Red Hat OpenShift for Windows Containers tracks the development of the Windows Machine Config Operator (WMCO), which provides all Windows container workload capabilities in OpenShift Container Platform.

2.1.1. Windows Machine Config Operator numbering

Starting with this release, y-stream releases of the WMCO will be in step with OpenShift Container Platform, with only z-stream releases between OpenShift Container Platform releases. The WMCO numbering reflects the associated OpenShift Container Platform version in the y-stream position. For example, the current release of WMCO is associated with OpenShift Container Platform version 4.15. Thus, the numbering is WMCO 10.15.z.

2.1.2. Release notes for Red Hat Windows Machine Config Operator 10.15.3

This release of the WMCO provides new features and bug fixes for running Windows compute nodes in an OpenShift Container Platform cluster. The components of the WMCO 10.15.3 were released in RHSA-2024:5745.

2.1.2.1. Bug fixes

Previously, after rotating the kube-apiserver-to-kubelet-client-ca certificate, the contents of the kubetl-ca.crt file on Windows nodes was not populated correctly. With this fix, after certificate rotation, the kubetl-ca.crt file contains the correct certificates. (OCPBUGS-33875)
Previously, if reverse DNS lookup failed due to an error, such as the reverse DNS lookup services being unavailable, the WMCO would not fall back to using the VM hostname to determine if a certificate signing requests (CSR) should be approved. As a consequence, Bring-Your-Own-Host (BYOH) Windows nodes configured with an IP address would not become available. With this fix, BYOH nodes are properly added if reverse DNS is not available. (OCPBUGS-37533)
Previously, if there were multiple service account token secrets in the WMCO namespace, the scaling of Windows nodes would fail. With this fix, the WMCO uses only the secret it creates, ignoring any other service account token secrets in the WMCO namespace. As a result, Windows nodes scale properly. (OCPBUGS-38485)

2.2. Release notes for past releases of the Windows Machine Config Operator

The following release notes are for previous versions of the Windows Machine Config Operator (WMCO).

2.2.1. Release notes for Red Hat Windows Machine Config Operator 10.15.2

This release of the WMCO provides new features and bug fixes for running Windows compute nodes in an OpenShift Container Platform cluster. The components of the WMCO 10.15.2 were released in RHBA-2024:2704.

2.2.1.1. Bug fixes

Previously, on Azure clusters the WMCO would check if an external Cloud Controller Manager (CCM) was being used on the cluster. CCM use is the default. If a CCM is being used, the Operator would adjust configuration logic accordingly. Because the status condition that the WMCO used to check for the CCM was removed, the WMCO proceeded as if a CCM was not in use. This fix removes the check. As a result, the WMCO always configures the required logic on Azure clusters. (OCPBUGS-31704)
Previously, the kubelet was unable to authenticate with private Elastic Container Registries (ECR) registries. Because of this error, the kubelet was not able to pull images from these registries. With this fix, the kubelet is able to pull images from these registries as expected. (OCPBUGS-26602)
Previously, the WMCO was logging error messages when any commands being run through an SSH connection to a Windows instance failed. This was incorrect behavior because some commands are expected to fail. For example, when WMCO reboots a node the Operator runs PowerShell commands on the instance until they fail, meaning the SSH connection rebooted as expected. With this fix, only actualy errors are now logged. (OCPBUGS-20255)

2.2.2. Release notes for Red Hat Windows Machine Config Operator 10.15.1

This release of the WMCO provides new features and bug fixes for running Windows compute nodes in an OpenShift Container Platform cluster. The components of the WMCO 10.15.1 were released in RHBA-2024:1191.

Due to an internal issue, the planned WMCO 10.15.0 could not be released. Multiple bug and security fixes, described below, were included in WMCO 10.15.0. These fixes are included in WMCO 10.15.1. For specific details about these bug and security fixes, see the RHSA-2024:0954 errata.

2.2.2.1. New features and improvements

2.2.2.1.1. CPU and memory usage metrics are now available

CPU and memory usage metrics for Windows pods are now available in Prometheus. The metrics are shown in the OpenShift Container Platform web console on the Metrics tab for each Windows pod and can be queried by users.

2.2.2.1.2. Operator SDK upgrade

The WMCO now uses the Operator SDK version 1.32.0.

2.2.2.1.3. Kubernetes upgrade

The WMCO now uses Kubernetes 1.28.

2.2.2.2. Bug fixes

Previously, there was a flaw in the handling of multiplexed streams in the HTTP/2 protocol, which is utilized by the WMCO. A client could repeatedly make a request for a new multiplex stream and then immediately send an RST_STREAM frame to cancel those requests. This activity created additional work for the server by setting up and dismantling streams, but avoided any server-side limitations on the maximum number of active streams per connection. As a result, a denial of service occurred due to server resource consumption. This issue has been fixed. (BZ-2243296)
Previously, there was a flaw in Kubernetes, where a user who can create pods and persistent volumes on Windows nodes was able to escalate to admin privileges on those nodes. Kubernetes clusters were only affected if they were using an in-tree storage plugin for Windows nodes. This issue has been fixed. (BZ-2247163)
Previously, there was a flaw in the SSH channel integrity. By manipulating sequence numbers during the handshake, an attacker could remove the initial messages on the secure channel without causing a MAC failure. For example, an attacker could disable the ping extension and thus disable the new countermeasure in OpenSSH 9.5 against keystroke timing attacks. This issue has been fixed. (BZ-2254210)
Previously, the routes from a Windows Bring-Your-Own-Host (BYOH) VM to the metadata endpoint were being added as non-persistent routes, so the routes were removed when a VM was removed (deconfigured) or re-configured. This would cause the node to fail if configured again, as the metadata endpoint was unreachable. With this fix, the WMCO runs the AWS EC2 launch v2 service after removal or re-configuration. As a result, the routes are restored so that the VM can be configured into a node, as expected. (OCPBUGS-15988)

Previously, the WMCO did not properly wait for Windows virtual machines (VMs) to finish rebooting. This led to occasional timing issues where the WMCO would attempt to interact with a node that was in the middle of a reboot, causing WMCO to log an error and restart node configuration. Now, the WMCO waits for the instance to completely reboot. (OCPBUGS-17217)

Previously, the WMCO configuration was missing the DeleteEmptyDirData: true field, which is required for draining nodes that have emptyDir volumes attached. As a consequence, customers that had nodes with emptyDir volumes would see the following error in the logs: cannot delete Pods with local storage. With this fix, the DeleteEmptyDirData: true field was added to the node drain helper struct in the WMCO. As a result, customers are able to drain nodes with emptyDir volumes attached. (OCPBUGS-27300)
Previously, because of a lack of synchronization between Windows machine set nodes and BYOH instances, during an update the machine set nodes and the BYOH instances could update simultaneously. This could impact running workloads. This fix introduces a locking mechanism so that machine set nodes and BYOH instances update individually. (OCPBUGS-8996)
Previously, because of a missing secret, the WMCO could not configure proper credentials for the WICD on Nutanix clusters. As a consequence, the WMCO could not create Windows nodes. With this fix, the WMCO creates long-lived credentials for the WICD service account. As a result, the WMCO is able to configure a Windows node on Nutanix clusters. (OCPBUGS-25350)

Previously, because of bad logic in the networking configuration script, the WICD was incorrectly reading carriage returns in the CNI configuration file as changes, and identified the file as modified. This caused the CNI configuration to be unnecessarily reloaded, potentially resulting in container restarts and brief network outages. With this fix, the WICD now reloads the CNI configuration only when the CNI configuration is actually modified. (OCPBUGS-25756)

2.3. 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.

2.3.1. WMCO supported installation method

The WMCO fully supports installing Windows nodes into installer-provisioned infrastructure (IPI) clusters. This is the preferred OpenShift Container Platform installation method.

For user-provisioned infrastructure (UPI) clusters, the WMCO supports installing Windows nodes only into a UPI cluster installed with the platform: none field set in the install-config.yaml file (bare-metal or provider-agnostic) and only for the BYOH (Bring Your Own Host) use case. UPI is not supported for any other platform.

2.3.2. WMCO 10.y supported platforms and Windows Server versions

The following table lists the Windows Server versions that are supported by WMCO 10.y, 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 2022, OS Build 20348.681 or later ^[1] Windows Server 2019, version 1809
Microsoft Azure	Windows Server 2022, OS Build 20348.681 or later Windows Server 2019, version 1809
VMware vSphere	Windows Server 2022, OS Build 20348.681 or later
Google Cloud Platform (GCP)	Windows Server 2022, OS Build 20348.681 or later
Nutanix	Windows Server 2022, OS Build 20348.681 or later
Bare metal or provider agnostic	Windows Server 2022, OS Build 20348.681 or later Windows Server 2019, version 1809

For disconnected clusters, the Windows AMI must have the EC2LaunchV2 agent version 2.0.1643 or later installed. For more information, see the Install the latest version of EC2Launch v2 in the AWS documentation.

2.3.3. 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.

Note

The WMCO does not support OVN-Kubernetes without hybrid networking or OpenShift SDN.
Dual NIC is not supported on WMCO-managed Windows instances.

Table 2.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
Google Cloud Platform (GCP)	Hybrid networking with OVN-Kubernetes
Nutanix	Hybrid networking with OVN-Kubernetes
Bare metal or provider agnostic	Hybrid networking with OVN-Kubernetes

Table 2.2. Hybrid OVN-Kubernetes Windows Server support
Hybrid networking with OVN-Kubernetes	Supported Windows Server version
Default VXLAN port	Windows Server 2022, OS Build 20348.681 or later Windows Server 2019, version 1809
Custom VXLAN port	Windows Server 2022, OS Build 20348.681 or later

Additional resources

Hybrid networking

2.4. Windows Machine Config Operator 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:
- Red Hat Insights cost management
- Red Hat OpenShift Local
Dual NIC is not supported on WMCO-managed Windows instances.
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 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 does not support any Windows operating system language other than English (United States).
Due to a limitation within the Windows operating system, clusterNetwork CIDR addresses of class E, such as 240.0.0.0, are not compatible with Windows nodes.
Kubernetes has identified the following node feature limitations :
- Huge pages are not supported for Windows containers.
- Privileged containers are not supported for Windows containers.
Kubernetes has identified several API compatibility issues.