|
| 1 | +[id="windows-containers-release-notes-4-x"] |
| 2 | += Windows Container Support for Red Hat OpenShift release notes |
| 3 | +include::modules/common-attributes.adoc[] |
| 4 | +:context: windows-containers-release-notes |
| 5 | + |
| 6 | +toc::[] |
| 7 | + |
| 8 | +[id="about-windows-containers"] |
| 9 | +== About Windows Container Support for Red Hat OpenShift |
| 10 | + |
| 11 | +Windows Container Support for Red Hat OpenShift enables running Windows compute nodes in an {product-title} 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 {product-title}. |
| 12 | + |
| 13 | +The release notes for Red Hat OpenShift for Windows Containers tracks the development of the WMCO, which provides all Windows container workload capabilities in {product-title}. |
| 14 | + |
| 15 | +[id="getting-support"] |
| 16 | +== Getting support |
| 17 | + |
| 18 | +You must have a subscription to receive support for the Red Hat WMCO. Deploying Windows container workloads in production clusters is not supported without a subscription. If you do not have a subscription, you can use the community WMCO, a distribution that lacks official support. Request support through the link:http://access.redhat.com/[Red Hat Customer Portal]. |
| 19 | + |
| 20 | +[id="wmco-4-0-0"] |
| 21 | +== Release notes for Red Hat Windows Machine Config Operator 4.0.0 |
| 22 | + |
| 23 | +This release of the WMCO provides bug fixes for running Windows compute nodes in an {product-title} cluster. The components of the WMCO 4.0.0 were released in link:https://access.redhat.com/errata/RHBA-2021:3702[RHBA-2021:3702]. |
| 24 | + |
| 25 | +[id="wmco-4-0-0-bug-fixes"] |
| 26 | +=== Bug fixes |
| 27 | + |
| 28 | +* Previously, the WMCO used the raw user-provided instance address when creating Bring-Your-Own-Host (BYOH) Windows nodes. This caused BYOH Windows instances to not join an {product-title} cluster. This bug fix ensures user-provided DNS names resolve to valid IPv4 addresses, and that the resolved value is used when creating BYOH Windows instances. Now BYOH instances with differing hostnames and DNS addresses can be configured as Windows Nodes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1995684[**BZ#1995684**]) |
| 29 | + |
| 30 | +* Previously, the WMCO performed direct comparisons using unresolved instance addresses when identifying instance-to-node associations. This caused BYOH Windows instances configured to join an {product-title} cluster to be removed. This bug fix validates DNS addresses by performing DNS lookups of entries that are added to the `windows-instances` config map. Now the WMCO can properly identify configured instance-to-node relationships, preventing any premature removals of BYOH nodes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2005126[**BZ#2005126**]) |
| 31 | + |
| 32 | +[id="wmco-4-0-0-known-issues"] |
| 33 | +=== Known issues |
| 34 | + |
| 35 | +* The file system graphs available in the web console do not display for Windows nodes. This issue is caused by changes in the file system queries, which will be fixed in a future release of WMCO. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1930347[*BZ#1930347*]) |
| 36 | + |
| 37 | +* For clusters installed on VMware vSphere, the WMCO ignored the `Deleting` phase notification event, leaving incorrect node information in the `windows-exporter` metrics endpoint. This resulted in an invalid mapping for the Prometheus metrics endpoint. This bug has been fixed; the WMCO now recognizes the `Deleting` phase notification event and maps the Prometheus metrics endpoint appropriately. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1995341[**BZ#1995341**]) |
| 38 | + |
| 39 | +* When the `RunAsUser` permission is set in the security context of a Linux-based pod, the projected files have the correct permissions set, including container user ownership. However, when the Windows equivalent `RunAsUsername` permission is set in a Windows pod, the kubelet is prevented from setting correct ownership on the files in the projected volume. This problem can get exacerbated when used in conjunction with a xref:../storage/persistent_storage/persistent-storage-hostpath.adoc#persistent-storage-using-hostpath[hostPath volume] where best practices are not followed. For example, giving a pod access to the `C:\var\lib\kubelet\pods\` folder results in that pod being able to access service account tokens from other pods. |
| 40 | ++ |
| 41 | +By default, the projected files will have the following ownership, as shown in this example Windows projected volume file: |
| 42 | ++ |
| 43 | +[source,posh] |
| 44 | +---- |
| 45 | +Path : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt |
| 46 | +Owner : BUILTIN\Administrators |
| 47 | +Group : NT AUTHORITY\SYSTEM |
| 48 | +Access : NT AUTHORITY\SYSTEM Allow FullControl |
| 49 | + BUILTIN\Administrators Allow FullControl |
| 50 | + BUILTIN\Users Allow ReadAndExecute, Synchronize |
| 51 | +Audit : |
| 52 | +Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU) |
| 53 | +---- |
| 54 | ++ |
| 55 | +This indicates all administrator users, like someone with the `ContainerAdministrator` role, have read, write, and execute access, while non-administrator users have read and execute access. |
| 56 | ++ |
| 57 | +[IMPORTANT] |
| 58 | +==== |
| 59 | +{product-title} applies the `RunAsUser` security context to all pods irrespective of its operating system. This means Windows pods automatically have the `RunAsUser` permission applied to its security context. |
| 60 | +==== |
| 61 | ++ |
| 62 | +In addition, if a Windows pod is created with a projected volume with the default `RunAsUser` permission set, the pod gets stuck in the `ContainerCreating` phase. |
| 63 | ++ |
| 64 | +To handle these issues, {product-title} forces the file permission handling in projected service account volumes set in the security context of the pod to not be honored for projected volumes on Windows (link:https://bugzilla.redhat.com/show_bug.cgi?id=1971745[BZ#1971745]). Note that this behavior for Windows pods is how file permission handling used to work for all pod types prior to {product-title} 4.7. |
| 65 | + |
| 66 | +include::modules/wmco-prerequisites.adoc[leveloffset=+1] |
| 67 | + |
| 68 | +[IMPORTANT] |
| 69 | +==== |
| 70 | +Running Windows container workloads is not supported for clusters in a restricted network or disconnected environment. |
| 71 | +==== |
| 72 | + |
| 73 | +Version 4.x of the WMCO is only compatible with {product-title} 4.9. |
0 commit comments