1. Documentation
    2. history bug_report picture_as_pdf
×

Red Hat OpenShift support for Windows Containers release notes

About Red Hat OpenShift support for Windows Containers

Windows Container Support for OpenShift Container Platform enables running Windows compute nodes in an OpenShift Container Platform cluster. Running Windows workloads is possible by using the Red Hat Windows Machine Config Operator (WMCO) to install and manage Windows nodes. With Windows nodes available, you can run Windows container workloads in OpenShift Container Platform.

These release notes track the development of the WMCO, which provides all Windows container workload capabilities in OpenShift Container Platform.

Getting support

Windows Container Support for OpenShift Container Platform is provided and available as an optional, installable component. Windows Container Support for Red Hat OpenShift is not part of the OpenShift Container Platform subscription. It requires an additional Red Hat subscription and is supported according to the Scope of coverage and Service level agreements.

You must have this separate subscription to receive support for Windows Container Support for Red Hat OpenShift. Without this additional Red Hat subscription, deploying Windows container workloads in production clusters is not supported. You can request support through the Red Hat Customer Portal.

For more information, see the Red Hat OpenShift Container Platform Life Cycle Policy document for Red Hat OpenShift support for Windows Containers.

Release notes for Red Hat Windows Machine Config Operator 9.0.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 9.0.1 were released in RHSA-2024:1203.

Bug fixes

  • Previously, because of a lack of synchronization between Windows machine set nodes and Bring-Your-Own-Host (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-22984)

  • 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-24748)

  • 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-27046)

  • Previously, because the WMCO performed an erroneous sanitization step that replaced commas with semicolons in the cluster-wide proxy configuration, Windows would ignore the endpoints specified in the noProxy parameter. As a consequence, traffic was being incorrectly sent through those proxies. With this fix, the sanitization step was removed. As a result, a web request from a Windows node to a cluster-internal endpoint or an endpoint that exists in the noProxy parameter does not go through the proxy. (OCPBUGS-27240)

  • 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-28226)

Release notes for Red Hat Windows Machine Config Operator 9.0.0

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 9.0.0 were released in RHSA-2023:1372.

New features and improvements

Support cluster-wide proxy on Windows containers

Clusters that use a cluster-wide proxy now support WMCO. Starting with OpenShift Container Platform version 4.14, WMCO can consume and use a global egress proxy configuration when making external requests outside the cluster’s internal network. For more information, see Configuring the cluster-wide proxy.

Support Windows Containers on Nutanix

Clusters installed on Nutanix now support Windows Server 2022 nodes. You can create a Windows machine set on Nutanix to host Windows Server 2022 compute nodes. For more information, see Creating a Windows machine set on Nutanix.

New scheduling priority class

WMCO now supports the windows-priorityclass kubelet parameter, which ensures that running pods do not deplete the kubelet of CPU cycles. By default, the windows-priorityclass parameter is set to ABOVE_NORMAL_PRIORITY_CLASS. It is not recommended to change this setting. For more information on this parameter, see CPU management in the Kubernetes documentation.

CSI Proxy support for Windows Containers

WMCO now supports the use of persistent storage for Windows workloads, without the use of in-tree storage drivers, by running the CSI Proxy service on each Windows node. Windows pods on each node now have access to storage through persistent volume claims.

With CSI proxy running on a cluster’s Windows nodes, you can deploy the Container Storage Interface (CSI) storage drivers of your choice as a Windows daemon set. For more information on CSI Proxy, see CSI Windows Support (with CSI Proxy) in the Kubernetes documentation. For information on CSI, see Configuring CSI volumes in the OpenShift Container Platform documentation.

Notable technical changes

SSH password authentication is disabled for all Windows Machine nodes

SSH password authentication is now disabled by default for all Windows nodes. The nodes now reject SSH connections that do not use public key authentication. This change is required by Red Hat Enterprise Linux CoreOS (RHCOS).

Bug fixes

  • Previously, on an Azure Windows Server 2019 platform that does not have the Azure container service installed, WMCO would fail to deploy Windows instances and would display the following error message:

    Install-WindowsFeature : Win32 internal error "Access is denied" 0x5 occurred while reading the console output buffer

    The failure occurred because the Microsoft Install-WindowsFeature cmdlet displays a progress bar that cannot be sent over an SSH connection. This fix hides the progress bar. As a result, Windows instances can be deployed as nodes. (OCPBUGS-13244)

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 (WMCO). See the vSphere documentation for any information that is relevant to only that platform.

WMCO 9.y supported platforms and Windows Server versions

The following table lists the Windows Server versions that are supported by WMCO 9.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

  • 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

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.

The WMCO does not support OVN-Kubernetes without hybrid networking or OpenShift SDN.
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

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

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

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