Search

Chapter 8. Using Bring-Your-Own-Host (BYOH) Windows instances as nodes

download PDF

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

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

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

    Note

    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.

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.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.