This is a cache of https://docs.okd.io/4.10/windows_containers/byoh-windows-instance.html. It is a snapshot of the page at 2024-11-21T22:12:40.865+0000.
Using Bring-Your-Own-Host Windows instances as nodes | Windows Container Support for OpenShift | OKD 4.10
  1. Documentation
×

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 OKD. BYOH Windows instances benefit users looking to mitigate major disruptions in the event that a Windows server goes offline.

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 Docker container runtime must be installed on the instance.

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

Procedure

  1. Create a configmap named windows-instances in the WMCO namespace that describes the Windows instances to be added.

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

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.