From cc387ca5654858fa46e1217be16a0177ffeab9c1 Mon Sep 17 00:00:00 2001 From: Michael Burke Date: Fri, 12 Jun 2026 14:15:07 -0400 Subject: [PATCH] CQA WINC-1: Windows Workload Management and Basics II --- modules/configuring-secret-for-wmco.adoc | 13 ++++---- modules/installing-wmco-using-cli.adoc | 29 ++++++++++-------- .../installing-wmco-using-web-console.adoc | 1 + modules/windows-node-services.adoc | 3 +- modules/windows-workload-management.adoc | 5 +++- modules/wmco-cluster-wide-proxy.adoc | 7 +++-- modules/wmco-configure-debug-logging.adoc | 21 ++++++++----- modules/wmco-disconnected-cluster.adoc | 3 +- .../enabling-windows-container-workloads.adoc | 30 +++++-------------- .../removing-windows-nodes.adoc | 1 + ...rstanding-windows-container-workloads.adoc | 18 ++++++----- 11 files changed, 72 insertions(+), 59 deletions(-) diff --git a/modules/configuring-secret-for-wmco.adoc b/modules/configuring-secret-for-wmco.adoc index fd928da5f408..ca15253895ac 100644 --- a/modules/configuring-secret-for-wmco.adoc +++ b/modules/configuring-secret-for-wmco.adoc @@ -6,7 +6,10 @@ [id="configuring-secret-for-wmco_{context}"] = 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). +[role="_abstract"] +Before you can use the Windows Machine Config Operator (WMCO), you must create a secret in the WMCO namespace that contains your private key. + +This secret is required to allow the WMCO to communicate with the Windows virtual machine (VM). It is recommended to use a different private key than the one used when installing the cluster. .Prerequisites @@ -24,9 +27,7 @@ include::snippets/wmco-key-ascii-encoding.adoc[] [source,terminal] ---- $ oc create secret generic cloud-private-key --from-file=private-key.pem=${HOME}/.ssh/ \ - -n openshift-windows-machine-config-operator <1> + -n openshift-windows-machine-config-operator ---- - -<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. ++ +You must create the private key in the WMCO namespace, like `openshift-windows-machine-config-operator`. diff --git a/modules/installing-wmco-using-cli.adoc b/modules/installing-wmco-using-cli.adoc index a2910898b1ea..b7877d5ddaa6 100644 --- a/modules/installing-wmco-using-cli.adoc +++ b/modules/installing-wmco-using-cli.adoc @@ -6,6 +6,7 @@ [id="installing-wmco-using-cli_{context}"] = Installing the Windows Machine Config Operator using the CLI +[role="_abstract"] You can use the OpenShift CLI (`oc`) to install the Windows Machine Config Operator (WMCO). [NOTE] @@ -24,12 +25,14 @@ Dual NIC is not supported on WMCO-managed Windows instances. apiVersion: v1 kind: Namespace metadata: - name: openshift-windows-machine-config-operator <1> + name: openshift-windows-machine-config-operator labels: - openshift.io/cluster-monitoring: "true" <2> + openshift.io/cluster-monitoring: "true" ---- -<1> It is recommended to deploy the WMCO in the `openshift-windows-machine-config-operator` namespace. -<2> This label is required for enabling cluster monitoring for the WMCO. +where + +`metadata.name`:: Specifies the namespace to create to secret. It is recommended to deploy the WMCO in the `openshift-windows-machine-config-operator` namespace. +`metadata.labels`:: Specifies the label required for enabling cluster monitoring for the WMCO. .. Create the namespace: + @@ -87,16 +90,18 @@ metadata: name: windows-machine-config-operator namespace: openshift-windows-machine-config-operator spec: - channel: "stable" <1> - installPlanApproval: "Automatic" <2> + channel: "stable" + installPlanApproval: "Automatic" name: "windows-machine-config-operator" - source: "redhat-operators" <3> - sourceNamespace: "openshift-marketplace" <4> + source: "redhat-operators" + sourceNamespace: "openshift-marketplace" ---- -<1> Specify `stable` as the channel. -<2> Set an approval strategy. You can set `Automatic` or `Manual`. -<3> Specify the `redhat-operators` catalog source, which contains the `windows-machine-config-operator` package manifests. If your {product-title} is installed on a restricted network, also known as a disconnected cluster, specify the name of the `CatalogSource` object you created when you configured the Operator LifeCycle Manager (OLM). -<4> Namespace of the catalog source. Use `openshift-marketplace` for the default software catalog sources. +where: + +`spec.channel`:: Specifies `stable` as the channel. +`spec.installPlanApproval`:: Specifies an approval strategy. You can set `Automatic` or `Manual`. +`spec.source`:: Specifies the `redhat-operators` catalog source, which contains the `windows-machine-config-operator` package manifests. If your {product-title} is installed on a restricted network, also known as a disconnected cluster, specify the name of the `CatalogSource` object you created when you configured the Operator LifeCycle Manager (OLM). +`spec.sourceNamespace`:: Specifies the namespace of the catalog source. Use `openshift-marketplace` for the default software catalog sources. .. Create the subscription: + diff --git a/modules/installing-wmco-using-web-console.adoc b/modules/installing-wmco-using-web-console.adoc index e3a499d319aa..ab24969d9476 100644 --- a/modules/installing-wmco-using-web-console.adoc +++ b/modules/installing-wmco-using-web-console.adoc @@ -6,6 +6,7 @@ [id="installing-wmco-using-web-console_{context}"] = Installing the Windows Machine Config Operator using the web console +[role="_abstract"] You can use the {product-title} web console to install the Windows Machine Config Operator (WMCO). [NOTE] diff --git a/modules/windows-node-services.adoc b/modules/windows-node-services.adoc index 80645ccc7c29..02d26b13f910 100644 --- a/modules/windows-node-services.adoc +++ b/modules/windows-node-services.adoc @@ -6,7 +6,8 @@ [id="windows-node-services_{context}"] = Windows node services -The following Windows-specific services are installed on each Windows node: +[role="_abstract"] +By default, the installation process installs several of Windows-specific services on each Windows node. [cols="1,2",options="header"] |=== diff --git a/modules/windows-workload-management.adoc b/modules/windows-workload-management.adoc index 2f931e78be1b..ef6d90a93269 100644 --- a/modules/windows-workload-management.adoc +++ b/modules/windows-workload-management.adoc @@ -6,7 +6,10 @@ [id="windows-workload-management_{context}"] = Windows workload management -To run Windows workloads in your cluster, you must first install the Windows Machine Config Operator (WMCO). The WMCO is a Linux-based Operator that runs on Linux-based control plane and compute nodes. The WMCO orchestrates the process of deploying and managing Windows workloads on a cluster. +[role="_abstract"] +To run Windows workloads in your cluster, you must first install the Windows Machine Config Operator (WMCO). + +The WMCO is a Linux-based Operator that runs on Linux-based control plane and compute nodes. The WMCO orchestrates the process of deploying and managing Windows workloads on a cluster. .WMCO design image::wmco-design.png[WMCO workflow] diff --git a/modules/wmco-cluster-wide-proxy.adoc b/modules/wmco-cluster-wide-proxy.adoc index f43b56d5ce64..98378304a2e1 100644 --- a/modules/wmco-cluster-wide-proxy.adoc +++ b/modules/wmco-cluster-wide-proxy.adoc @@ -6,9 +6,10 @@ [id="wmco-cluster-wide-proxy_{context}"] = 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. +[role="_abstract"] +You can add Windows nodes and run workloads in a proxy-enabled cluster because 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 +This allows 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. [NOTE] @@ -19,3 +20,5 @@ 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. + +For more information on the cluster-wide proxy, see "Configuring the cluster-wide proxy". diff --git a/modules/wmco-configure-debug-logging.adoc b/modules/wmco-configure-debug-logging.adoc index 030c718907f7..418d9eee91b8 100644 --- a/modules/wmco-configure-debug-logging.adoc +++ b/modules/wmco-configure-debug-logging.adoc @@ -2,11 +2,14 @@ // // windows_containers/enabling-windows-container-workloads.adoc -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: PROCEDURE [id="wmco-configure-debug-logging_{context}"] = Configuring debug-level logging for the Windows Machine Config Operator -By default, the Windows Machine Config Operator (WMCO) is configured to use the `info` log level. You can change the log level to `debug` by editing the WMCO `Subscription` object. +[role="_abstract"] +You can edit the WMCO `Subscription` object to change the Windows Machine Config Operator (WMCO) log level to `debug` if you need more verbose output. + +By default, the Windows Machine Config Operator (WMCO) is configured to use the `info` log level. .Procedure @@ -31,10 +34,14 @@ spec: # ... config: env: - - name: ARGS <1> - value: --debugLogging <2> + - name: ARGS + value: --debugLogging ---- -<1> Defines a list of environment variables that must exist in all containers in the pod. -<2> Specifies the `debug` level of verbosity for log messages. - +where: ++ +-- +`spec.config.env.name`:: Specifies a list of environment variables that must exist in all containers in the pod. +`spec.config.env.value`:: Specifies the `debug` level of verbosity for log messages. +-- ++ You can revert to the default `info` log level by removing the `name` and `value` parameters that you added. diff --git a/modules/wmco-disconnected-cluster.adoc b/modules/wmco-disconnected-cluster.adoc index 19e857035ceb..957d7361b9cd 100644 --- a/modules/wmco-disconnected-cluster.adoc +++ b/modules/wmco-disconnected-cluster.adoc @@ -6,7 +6,8 @@ [id="wmco-disconnected-cluster_{context}"] = Using Windows containers with a mirror registry -The Windows Machine Config Operator (WMCO) can pull images from a registry mirror rather than from a public registry by using an `ImageDigestMirrorSet` (IDMS) or `ImageTagMirrorSet` (ITMS) object to configure your cluster to pull images from the mirror registry. +[role="_abstract"] +When using the Windows Machine Config Operator (WMCO), you can pull images from a registry mirror rather than from a public registry by using an `ImageDigestMirrorSet` (IDMS) or `ImageTagMirrorSet` (ITMS) object to configure your cluster to pull images from the mirror registry. A mirror registry has the following benefits: diff --git a/windows_containers/enabling-windows-container-workloads.adoc b/windows_containers/enabling-windows-container-workloads.adoc index c098f4da71f8..93b67fa23b08 100644 --- a/windows_containers/enabling-windows-container-workloads.adoc +++ b/windows_containers/enabling-windows-container-workloads.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] Before adding Windows workloads to your cluster, you must install the Windows Machine Config Operator (WMCO), which is available in the {product-title} software catalog. The WMCO orchestrates the process of deploying and managing Windows workloads on a cluster. [NOTE] @@ -25,7 +26,7 @@ Dual NIC is not supported on WMCO-managed Windows instances. ** Any installer-provisioned infrastructure ** A user-provisioned infrastructure with the `platform: none` field set in your `install-config.yaml` file -* You have configured hybrid networking with OVN-Kubernetes for your cluster. For more information, see xref:../networking/ovn_kubernetes_network_provider/configuring-hybrid-networking.adoc#configuring-hybrid-ovnkubernetes[Configuring hybrid networking]. +* You have configured hybrid networking with OVN-Kubernetes for your cluster. For more information, see "Configuring hybrid networking". * You are running an {product-title} cluster version 4.6.8 or later. @@ -36,10 +37,6 @@ Windows instances deployed by the WMCO are configured with the containerd contai For the comprehensive prerequisites for the Windows Machine Config Operator, see "Windows Machine Config Operator prerequisites". -[role="_additional-resources"] -.Additional resources -* xref:../windows_containers/wmco_rn/windows-containers-release-notes-prereqs.adoc#windows-containers-release-notes-prereqs[Windows Machine Config Operator prerequisites] - [id="installing-the-wmco"] == Installing the Windows Machine Config Operator @@ -60,33 +57,22 @@ include::modules/wmco-configure-debug-logging.adoc[leveloffset=+1] include::modules/wmco-cluster-wide-proxy.adoc[leveloffset=+1] -[role="_additional-resources"] -.Additional resources -* xref:../networking/configuring_network_settings/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[Configuring the cluster-wide proxy]. - include::modules/wmco-disconnected-cluster.adoc[leveloffset=+1] -[role="_additional-resources"] -.Additional resources -* xref:../disconnected/index.adoc#installing-mirroring-disconnected-about[About disconnected installation mirroring] - include::modules/images-configuration-registry-mirror.adoc[leveloffset=+2] include::modules/images-configuration-registry-mirror-configuring.adoc[leveloffset=+2] -[role="_additional-resources"] -.Additional resources -* xref:../windows_containers/enabling-windows-container-workloads.adoc#wmco-disconnected-cluster_enabling-windows-container-workloads[Using Windows containers with a mirror registry] - include::modules/nodes-nodes-rebooting-gracefully.adoc[leveloffset=+1] [role="_additional-resources"] -.Additional resources +== Additional resources +* xref:../windows_containers/wmco_rn/windows-containers-release-notes-prereqs.adoc#windows-containers-release-notes-prereqs[Windows Machine Config Operator prerequisites] +* xref:../networking/ovn_kubernetes_network_provider/configuring-hybrid-networking.adoc#configuring-hybrid-ovnkubernetes[Configuring hybrid networking] +* xref:../networking/configuring_network_settings/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[Configuring the cluster-wide proxy] +* xref:../disconnected/index.adoc#installing-mirroring-disconnected-about[About disconnected installation mirroring] +* xref:../windows_containers/enabling-windows-container-workloads.adoc#wmco-disconnected-cluster_enabling-windows-container-workloads[Using Windows containers with a mirror registry] * xref:../nodes/nodes/nodes-nodes-rebooting.adoc#nodes-nodes-rebooting-gracefully_nodes-nodes-rebooting[Rebooting a {product-title} node gracefully] * xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[Backing up etcd data] - -[role="_additional-resources"] -== Additional resources - * xref:../installing/installing_azure/ipi/installing-azure-default.adoc#ssh-agent-using_installing-azure-default[Generating a key pair for cluster node SSH access] * xref:../operators/admin/olm-adding-operators-to-cluster.adoc#olm-adding-operators-to-a-cluster[Adding Operators to a cluster] diff --git a/windows_containers/removing-windows-nodes.adoc b/windows_containers/removing-windows-nodes.adoc index f6997984de44..0dbd1a7c5890 100644 --- a/windows_containers/removing-windows-nodes.adoc +++ b/windows_containers/removing-windows-nodes.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] You can remove a Windows node by deleting its host Windows machine. include::modules/machine-delete.adoc[leveloffset=+1] diff --git a/windows_containers/understanding-windows-container-workloads.adoc b/windows_containers/understanding-windows-container-workloads.adoc index d67ad341d9cc..863cffdb3644 100644 --- a/windows_containers/understanding-windows-container-workloads.adoc +++ b/windows_containers/understanding-windows-container-workloads.adoc @@ -6,23 +6,27 @@ include::_attributes/common-attributes.adoc[] toc::[] -{productwinc} provides built-in support for running Microsoft Windows Server containers on {product-title}. For those that administer heterogeneous environments with a mix of Linux and Windows workloads, {product-title} allows you to deploy Windows workloads running on Windows Server containers while also providing traditional Linux workloads hosted on {op-system-first} or {op-system-base-full}. +[role="_abstract"] +You can use the Windows Machine Config Operator (WMCO) to run Microsoft Windows Server containers on {product-title}. + +For those that administer heterogeneous environments with a mix of Linux and Windows workloads, {product-title} allows you to deploy Windows workloads running on Windows Server containers while also providing traditional Linux workloads hosted on {op-system-first} or {op-system-base-full}. [NOTE] ==== Multi-tenancy for clusters that have Windows nodes is not supported. Clusters are considered _multi-tenant_ when multiple workloads operate on shared infrastructure and resources. If one or more workloads running on an infrastructure cannot be trusted, the multi-tenant environment is considered _hostile_. -Hostile multi-tenant clusters introduce security concerns in all Kubernetes environments. Additional security features like link:https://kubernetes.io/docs/concepts/policy/pod-security-policy/[pod security policies], or more fine-grained role-based access control (RBAC) for nodes, make exploiting your environment more difficult. However, if you choose to run hostile multi-tenant workloads, a hypervisor is the only security option you should use. The security domain for Kubernetes encompasses the entire cluster, not an individual node. For these types of hostile multi-tenant workloads, you should use physically isolated clusters. +Hostile multi-tenant clusters introduce security concerns in all Kubernetes environments. Additional security features like pod security policies, or more fine-grained role-based access control (RBAC) for nodes, make exploiting your environment more difficult. However, if you choose to run hostile multi-tenant workloads, a hypervisor is the only security option you should use. The security domain for Kubernetes encompasses the entire cluster, not an individual node. For these types of hostile multi-tenant workloads, you should use physically isolated clusters. Windows Server Containers provide resource isolation using a shared kernel but are not intended to be used in hostile multitenancy scenarios. ==== -[role="_additional-resources"] -.Additional resources -* See xref:../networking/ovn_kubernetes_network_provider/configuring-hybrid-networking.adoc#configuring-hybrid-ovnkubernetes_configuring-hybrid-networking[Configuring hybrid networking with OVN-Kubernetes] - include::modules/windows-workload-management.adoc[leveloffset=+1] include::modules/windows-node-services.adoc[leveloffset=+1] -//modules/windows-linux-containers-differences.adoc[leveloffset=+1] +[role="_additional-resources"] +[id="additional-resources_{context}"] +== Additional resources + +* link:https://kubernetes.io/docs/concepts/policy/pod-security-policy/[Pod Security Policies] +* xref:../networking/ovn_kubernetes_network_provider/configuring-hybrid-networking.adoc#configuring-hybrid-ovnkubernetes_configuring-hybrid-networking[Configuring hybrid networking with OVN-Kubernetes]