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 Y-stream releases of the WMCO are 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.16. Thus, the numbering is WMCO 10.15.z. 2.1.2. Release notes for Red Hat Windows Machine Config Operator 10.16.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.16.1 were released in RHSA-2024:5749 . 2.1.2.1. Bug fixes Previously, if a Windows VM had its PowerShell ExecutionPolicy set to Restricted , the Windows Instance Config Daemon (WICD) could not run the commands on that VM that are necessary for creating Windows nodes. With this fix, the WICD now bypasses the execution policy on the VM when running PowerShell commands. As a result, the WICD can create Windows nodes on the VM as expected. ( OCPBUGS-37609 ) 2.2. Release notes for past releases of the Windows Machine Config Operator The following release notes are for versions of the Windows Machine Config Operator (WMCO). 2.2.1. Release notes for Red Hat Windows Machine Config Operator 10.16.0 This release of the WMCO provides bug fixes for running Windows compute nodes in an OpenShift Container Platform cluster. The components of the WMCO 10.16.0 were released in RHBA-2024:5014 . 2.2.1.1. New features and improvements 2.2.1.1.1. WMCO is now supported in disconnected networks The WMCO is now supported in environments with disconnected networks, which is a cluster that is intentionally impeded from reaching the internet, also known as restricted or air-gapped clusters. For more information, see Using Windows containers with a mirror registry . 2.2.1.1.2. WMCO can pull images from mirrored registries The WMCO can now use both ImageDigestMirrorSet (IDMS) and ImageTagMirrorSet (ITMS) objects to pull images from mirrored registries. For more information, see Understanding image registry repository mirroring 2.2.1.1.3. Filesystem metrics now display for Windows nodes The Filesystem metrics are now available for Windows nodes in the Utilization tile of the Node details page in the OpenShift Container Platform web console. You can query the metrics by running Prometheus Query Language (PromQL) queries. The charts previously reported No datapoints found . 2.2.1.1.4. Pod network metrics now display for the pods on Windows nodes The Network in and Network out charts are now available for Windows pods on the Pod details page in the OpenShift Container Platform web console. You can query the metrics by running PromQL queries. The charts previously reported No datapoints found . 2.2.1.1.5. Pod CPU and memory metrics now display for the pods on Windows nodes The CPU and memory usage metrics are now available for Windows pods on the Pods and Pod details pages in the OpenShift Container Platform web console. You can query the metrics by running PromQL queries. The chart previously reported No datapoints found . 2.2.1.1.6. Kubernetes upgrade The WMCO now uses Kubernetes 1.29. 2.2.1.2. Bug fixes Because the WICD service account was missing a required secret, the WMCO was unable to properly configure Windows nodes in a Nutanix cluster. With this fix, the WMCO creates a long-lived token secret for the WICD service account. As a result, the WMCO is able to configure a Windows node on Nutanix. ( OCPBUGS-22680 ) Previously, the WMCO performed a sanitization step that incorrectly replaced commas with semicolons in a user's cluster-wide proxy configuration. This behavior caused Windows to ignore the values set in the noProxy environment variable. As a consequence, the WMCO incorrectly sent traffic through the proxy for the endpoints specified in the no-proxy parameter. With this fix, the sanitization step that replaced commas with semicolons was removed. As a result, web requests from a Windows node to a cluster-internal endpoint or an endpoint that exists in the no-proxy parameter do not go through the proxy. ( OCPBUGS-24264 ) Previously, because of bad logic in the networking configuration script, the WMCO was incorrectly reading carriage returns in the containderd CNI configuration file as changes, and identified the file as modified. This bahavior caused the CNI configuration to be unnecessarily reloaded, potentially resulting in container restarts and brief network outages. With this fix, the WMCO now reloads the CNI configuration only when the CNI configuration is actually modified. ( OCPBUGS-2887 ) Previously, because of routing issues present in Windows Server 2019, under certain conditions and after more than one hour of running time, workloads on Windows Server 2019 could have experienced packet loss when communicating with other containers in the cluster. This fix enables Direct Server Return (DSR) routing within kube-proxy. As a result, DSR now causes request and response traffic to use a different network path, circumventing the bug within Windows Server 2019. ( OCPBUGS-26761 ) Previously, the kubelet on Windows nodes was unable to authenticate with private Amazon Elastic Container Registries (ECR). 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, on Azure clusters the WMCO would check if an external Cloud Controller Manager (CCM) was being used on the cluster. If a CCM was 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-31626 ) Previously, the WMCO logged error messages when a command that was run through an SSH connection to a Windows instance failed. This behavior was incorrect because some commands are expected to fail. For example, when the 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 actual errors are now logged. ( OCPBUGS-20255 ) 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-22237 ) Previously, because of a missing DNS suffix in the kubelet host name on instances that are part of a Windows AD domain controller, the cloud provider failed to find VMs by name. With this fix, the DNS suffix is now included in the host name resolution. As a result, the WMCO is able to configure and join Windows instances that are part of AD domain controller. ( OCPBUGS-34758 ) Previously, registry certificates provided to the cluster by a user were not loaded into the Windows trust store on each node. As a consequence, image pulls from a mirror registry failed, because a self-signed CA is required. With this fix, registry certificates are loaded into the Windows trust store on each node. As a result, images can be pulled from mirror registries with self-signed CAs. ( OCPBUGS-36408 ) Previously, if there were multiple service account token secrets in the WMCO namespace, scaling 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-37481 ) 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-36643 ) 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.16.0 supported platforms and Windows Server versions The following table lists the Windows Server versions that are supported by WMCO 10.16.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 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. 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 .

Commands: