Chapter 8. Using Bring-Your-Own-Host (BYOH) Windows instances as nodes
Bring-Your-Own-Host (BYOH) allows for users to repurpose Windows Server VMs and bring them to OpenShift Container Platform. BYOH Windows instances benefit users looking to mitigate major disruptions in the event that a Windows server goes offline.
8.1. Configuring a BYOH Windows instance
Creating a BYOH Windows instance requires creating a config map in the Windows Machine Config Operator (WMCO) namespace.
Prerequisites
Any Windows instances that are to be attached to the cluster as a node must fulfill the following requirements:
- The instance must be on the same network as the Linux worker nodes in the cluster.
- Port 22 must be open and running an SSH server.
-
The default shell for the SSH server must be the Windows Command shell, or
cmd.exe
. - Port 10250 must be open for log collection.
- An administrator user is present with the private key used in the secret set as an authorized SSH key.
-
If you are creating a BYOH Windows instance for an installer-provisioned infrastructure (IPI) AWS cluster, you must add a tag to the AWS instance that matches the
spec.template.spec.value.tag
value in the machine set for your worker nodes. For example,kubernetes.io/cluster/<cluster_id>: owned
orkubernetes.io/cluster/<cluster_id>: shared
. - If you are creating a BYOH Windows instance on vSphere, communication with the internal API server must be enabled.
The hostname of the instance must follow the RFC 1123 DNS label requirements, which include the following standards:
- Contains only lowercase alphanumeric characters or '-'.
- Starts with an alphanumeric character.
- Ends with an alphanumeric character.
Windows instances deployed by the WMCO are configured with the containerd container runtime. Because the WMCO installs and manages the runtime, it is recommended that you not manually install containerd on nodes.
Procedure
Create a ConfigMap named
windows-instances
in the WMCO namespace that describes the Windows instances to be added.NoteFormat each entry in the config map’s data section by using the address as the key while formatting the value as
username=<username>
.Example config map
kind: ConfigMap apiVersion: v1 metadata: name: windows-instances namespace: openshift-windows-machine-config-operator data: 10.1.42.1: |- 1 username=Administrator 2 instance.example.com: |- username=core
- 1
- The address that the WMCO uses to reach the instance over SSH, either a DNS name or an IPv4 address. A DNS PTR record must exist for this address. It is recommended that you use a DNS name with your BYOH instance if your organization uses DHCP to assign IP addresses. If not, you need to update the
windows-instances
ConfigMap whenever the instance is assigned a new IP address. - 2
- The name of the administrator user created in the prerequisites.
8.2. Removing BYOH Windows instances
You can remove BYOH instances attached to the cluster by deleting the instance’s entry in the config map. Deleting an instance reverts that instance back to its state prior to adding to the cluster. Any logs and container runtime artifacts are not added to these instances.
For an instance to be cleanly removed, it must be accessible with the current private key provided to WMCO. For example, to remove the 10.1.42.1
instance from the previous example, the config map would be changed to the following:
kind: ConfigMap apiVersion: v1 metadata: name: windows-instances namespace: openshift-windows-machine-config-operator data: instance.example.com: |- username=core
Deleting windows-instances
is viewed as a request to deconstruct all Windows instances added as nodes.