SupportConsoleDevelopersStart a trialContact

Chapter 6. Creating Windows machine sets

6.1. Creating a Windows machine set on AWS
Copy link

You can use a MachineSet custom resource (CR) to add a Windows compute node to your Amazon Web Services cluster, where you can run Windows container workloads.

For example, you might create infrastructure Windows machine sets and related machines so that you can move supporting Windows workloads to the new Windows machines. For more information about machine sets, see "Overview of machine management" in the Additional resources section.

6.1.1. Prerequisites
Copy link

  • You installed the Windows Machine Config Operator (WMCO) using Operator Lifecycle Manager (OLM).

  • You are using a supported Windows Server as the operating system image.

    Use one of the following aws commands, as appropriate for your Windows Server release, to query valid AMI images:

    Example Windows Server 2025 command

    $ aws ec2 describe-images --region <aws_region_name> --filters "Name=name,Values=Windows_Server-2025*English*Core*Base*" "Name=is-public,Values=true" --query "reverse(sort_by(Images, &CreationDate))[*].{name: Name, id: ImageId}" --output table

    Example Windows Server 2022 command

    $ aws ec2 describe-images --region <aws_region_name> --filters "Name=name,Values=Windows_Server-2022*English*Core*Base*" "Name=is-public,Values=true" --query "reverse(sort_by(Images, &CreationDate))[*].{name: Name, id: ImageId}" --output table

    Example Windows Server 2019 command

    $ aws ec2 describe-images --region <aws_region_name> --filters "Name=name,Values=Windows_Server-2019*English*Core*Base*" "Name=is-public,Values=true" --query "reverse(sort_by(Images, &CreationDate))[*].{name: Name, id: ImageId}" --output table

    where:

    <aws_region_name>
    Specifies the name of your AWS region.
  • For disconnected clusters, the Windows AMI must have the EC2LaunchV2 agent version 2.0.2107 or later installed. For more information, see "Install the latest version of EC2Launch v2 (AWS documentation)" in the Additional references section.

You can add Windows nodes to an Amazon Web Services (AWS) cluster by defining a Windows MachineSet object that the Windows Machine Config Operator (WMCO) can react upon.

The following example is a YAML file for creating a MachineSet object for AWS. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-windows-worker-<zone>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
        machine.openshift.io/os-id: Windows
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
      providerSpec:
        value:
          ami:
            id: <windows_container_ami>
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile
          instanceType: m5a.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone>
            region: <region>
          securityGroups:
          - filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-node
          - filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-lb
          subnet:
            filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-subnet-private-<zone>
          tags:
            - name: kubernetes.io/cluster/<infrastructure_id>
              value: owned
          userDataSecret:
            name: windows-user-data
            namespace: openshift-machine-api

where:

metadata.labels

For the machine.openshift.io/cluster-api-cluster label, replace <infrastructure_id> with the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. You can obtain the infrastructure ID by running the following command: 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
metadata.name
Replace the infrastructure ID, worker label, and zone.
spec.selector.matchLabels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Replace the infrastructure ID, worker label, and zone.
spec.template.metadata.labels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Replace the infrastructure ID, worker label, and zone.
  • machine.openshift.io/os-id: Windows. When set to Windows, configures the compute machine set as a Windows machine.
spec.template.spec.metadata.labels
When set to node-role.kubernetes.io/worker, configures the node as a compute machine.
spec.template.spec.providerSpec

Specify the following parameters:

  • value.ami.id. Specify the AMI ID of a supported Windows image with a container runtime installed.

    Note

    For disconnected clusters, the Windows AMI must have the EC2LaunchV2 agent version 2.0.2107 or later installed. For more information, see the Install the latest version of EC2Launch v2 (AWS documentation).

  • value.iamInstanceProfile.id. Replace the infrastructure ID.
  • value.placement.availabilityZone. Specifies the AWS zone, such as us-east-1a.
  • value.placement.region. Specifies the AWS region, such as us-east-1.
  • value.securityGroups.filters.values. Replace the infrastructure ID.
  • value.subnet.filters.values. Replace the infrastructure ID and zone.
  • value.tags.name. Replace the infrastructure ID.
  • value.userDataSecret.name. Specifies the name of the secret in the user data YAML file that is in the openshift-machine-api namespace. Use the value that installation program populates in the default compute machine set.

6.1.3. Creating a compute machine set
Copy link

To dynamically manage machine compute resources, you can create your own compute machine sets in addition to the compute machine sets created by the installation program. Use the OpenShift Container Platform CLI to automate node provisioning.

Prerequisites

  • Deploy an OpenShift Container Platform cluster.
  • Install the OpenShift CLI (oc).
  • Log in to oc as a user with cluster-admin permission.
  • In disconnected environments, the image specified in the MachineSet custom resource (CR) must have the OpenSSH server v0.0.1.0 installed.

Procedure

  1. Create a new YAML file that contains the compute machine set custom resource (CR) sample and is named <file_name>.yaml.

    Ensure that you set the <clusterID> and <role> parameter values.

  2. Optional: If you are not sure which value to set for a specific field, you can check an existing compute machine set from your cluster.

    1. To list the compute machine sets in your cluster, run the following command: 

      $ oc get machinesets -n openshift-machine-api

      The following is example output: 

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. To view values of a specific compute machine set custom resource (CR), run the following command: 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      The following is example output: 

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-<role>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
        ...

      where:

      metadata.labels.machine.openshift.io/cluster-api-cluster
      Specifies the cluster infrastructure ID.
      metadata.labels.name

      Specifies a default node label.

      Note

      For clusters that have user-provisioned infrastructure, a compute machine set can only create worker and infra type machines.

      spec.template.metadata.spec.providerSpec
      Specifies the values of the compute machine set CR. The values are platform-specific. For more information about <providerSpec> parameters in the CR, see the sample compute machine set CR configuration for your provider.

  3. Create a MachineSet CR by running the following command: 

    $ oc create -f <file_name>.yaml

Verification

  • View the list of compute machine sets by running the following command: 

    $ oc get machineset -n openshift-machine-api

    The following is example output: 

    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    When the new compute machine set is available, the DESIRED and CURRENT values match. If the compute machine set is not available, wait a few minutes and run the command again.

6.2. Creating a Windows machine set on Azure
Copy link

You can use a MachineSet custom resource (CR) to add a Windows compute node to your Microsoft Azure cluster, where you can run Windows container workloads.

For example, you might create infrastructure Windows machine sets and related machines so that you can move supporting Windows workloads to the new Windows machines. For more information about machine sets, see "Overview of machine management".

6.2.1. Prerequisites
Copy link

  • You installed the Windows Machine Config Operator (WMCO) using Operator Lifecycle Manager (OLM).
  • You are using a supported Windows Server as the operating system image.

You can add Windows nodes to an Microsoft Azure cluster by defining a Windows MachineSet object that the Windows Machine Config Operator (WMCO) can react upon.

The following example is a YAML file for creating a MachineSet object for Azure. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <windows_machine_set_name>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
        machine.openshift.io/os-id: Windows
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: WindowsServer
            publisher: MicrosoftWindowsServer
            resourceID: ""
            sku: 2022-datacenter
            version: latest
          kind: AzureMachineProviderSpec
          location: <location>
          networkResourceGroup: <infrastructure_id>-rg
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Windows
          publicIP: false
          resourceGroup: <infrastructure_id>-rg
          subnet: <infrastructure_id>-worker-subnet
          userDataSecret:
            name: windows-user-data
            namespace: openshift-machine-api
          vmSize: Standard_D2s_v3
          vnet: <infrastructure_id>-vnet
          zone: "<zone>"

where:

metadata.labels

For the machine.openshift.io/cluster-api-cluster label, replace <infrastructure_id> with the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. You can obtain the infrastructure ID by running the following command: 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
metadata.name
Replace <windows_machine_set_name> with the Windows compute machine set name. Windows machine names on Azure cannot be more than 15 characters long. Therefore, the compute machine set name cannot be more than 9 characters long, due to the way machine names are generated from it.
spec.selector.matchLabels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Replace the Windows compute machine set name.
spec.template.metadata.labels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Replace the Windows compute machine set name.
  • machine.openshift.io/os-id: Windows. When set to Windows, configures the compute machine set as a Windows machine.
spec.template.spec.metadata.labels
When set to node-role.kubernetes.io/worker, configures the node as a compute machine.
spec.template.spec.providerSpec

Specify the following parameters:

  • value.image. Specifies a WindowsServer image offering that defines the 2022-datacenter SKU.
  • value.location. Specifies the Azure region, such as centralus.
  • value.networkResourceGroup. Replace the infrastructure ID.
  • value.resourceGroup. Replace the infrastructure ID.
  • value.userDataSecret.name. Specifies the name of the secret in the user data YAML file that is in the openshift-machine-api namespace. Use the value that installation program populates in the default compute machine set.
  • value.zone. Specifies the zone within your region to place machines on. Be sure that your region supports the zone that you specify.

6.2.3. Creating a compute machine set
Copy link

To dynamically manage machine compute resources, you can create your own compute machine sets in addition to the compute machine sets created by the installation program. Use the OpenShift Container Platform CLI to automate node provisioning.

Prerequisites

  • Deploy an OpenShift Container Platform cluster.
  • Install the OpenShift CLI (oc).
  • Log in to oc as a user with cluster-admin permission.
  • In disconnected environments, the image specified in the MachineSet custom resource (CR) must have the OpenSSH server v0.0.1.0 installed.

Procedure

  1. Create a new YAML file that contains the compute machine set custom resource (CR) sample and is named <file_name>.yaml.

    Ensure that you set the <clusterID> and <role> parameter values.

  2. Optional: If you are not sure which value to set for a specific field, you can check an existing compute machine set from your cluster.

    1. To list the compute machine sets in your cluster, run the following command: 

      $ oc get machinesets -n openshift-machine-api

      The following is example output: 

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. To view values of a specific compute machine set custom resource (CR), run the following command: 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      The following is example output: 

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-<role>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
        ...

      where:

      metadata.labels.machine.openshift.io/cluster-api-cluster
      Specifies the cluster infrastructure ID.
      metadata.labels.name

      Specifies a default node label.

      Note

      For clusters that have user-provisioned infrastructure, a compute machine set can only create worker and infra type machines.

      spec.template.metadata.spec.providerSpec
      Specifies the values of the compute machine set CR. The values are platform-specific. For more information about <providerSpec> parameters in the CR, see the sample compute machine set CR configuration for your provider.

  3. Create a MachineSet CR by running the following command: 

    $ oc create -f <file_name>.yaml

Verification

  • View the list of compute machine sets by running the following command: 

    $ oc get machineset -n openshift-machine-api

    The following is example output: 

    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    When the new compute machine set is available, the DESIRED and CURRENT values match. If the compute machine set is not available, wait a few minutes and run the command again.

You can use a MachineSet custom resource (CR) to add a Windows compute node to your Google Cloud cluster, where you can run Windows container workloads.

For example, you might create infrastructure Windows machine sets and related machines so that you can move supporting Windows workloads to the new Windows machines. For more information about machine sets, see "Overview of machine management".

6.3.1. Prerequisites
Copy link

  • You installed the Windows Machine Config Operator (WMCO) using Operator Lifecycle Manager (OLM).
  • You are using a supported Windows Server as the operating system image.

You can add Windows nodes to a Google Cloud cluster by defining a Windows MachineSet object that the Windows Machine Config Operator (WMCO) can react upon.

The following example is a YAML file for creating a MachineSet object for Google Cloud. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-windows-worker-<zone_suffix>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone_suffix>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone_suffix>
        machine.openshift.io/os-id: Windows
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <windows_server_image>
            sizeGb: 128
            type: pd-ssd
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
          networkInterfaces:
          - network: <infrastructure_id>-network
            subnetwork: <infrastructure_id>-worker-subnet
          projectID: <project_id>
          region: <region>
          serviceAccounts:
          - email: <infrastructure_id>-w@<project_id>.iam.gserviceaccount.com
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
          - <infrastructure_id>-worker
          userDataSecret:
            name: windows-user-data
          zone: <zone>

where:

metadata.labels

For the machine.openshift.io/cluster-api-cluster label, replace <infrastructure_id> with the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. You can obtain the infrastructure ID by running the following command: 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
metadata.name
Replace the infrastructure ID, worker label, and zone suffix, such as a.
spec.selector.matchLabels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Replace the infrastructure ID, worker label, and zone suffix.
spec.template.metadata.labels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Replace the infrastructure ID, worker label, and zone suffix.
  • machine.openshift.io/os-id: Windows. When set to Windows, configures the compute machine set as a Windows machine.
spec.template.spec.metadata.labels
When set to node-role.kubernetes.io/worker, configures the node as a compute machine.
spec.template.spec.providerSpec

Specify the following parameters:

  • value.disks.image. Specifies the full path to an image of a supported version of Windows Server.
  • value.networkInterfaces.network. Replace the infrastructure ID.
  • value.networkInterfaces.subnetwork. Replace the infrastructure ID.
  • value.projectID. Specifies the Google Cloud project that this cluster was created in.
  • value.region. Specifies the Google Cloud region, such as us-central1.
  • value.userDataSecret.name. Specifies the name of the secret in the user data YAML file that is in the openshift-machine-api namespace. Use the value that installation program populates in the default compute machine set.
  • value.zone. Specifies the zone within the chosen region, such as us-central1-a.

6.3.3. Creating a compute machine set
Copy link

To dynamically manage machine compute resources, you can create your own compute machine sets in addition to the compute machine sets created by the installation program. Use the OpenShift Container Platform CLI to automate node provisioning.

Prerequisites

  • Deploy an OpenShift Container Platform cluster.
  • Install the OpenShift CLI (oc).
  • Log in to oc as a user with cluster-admin permission.

Procedure

  1. Create a new YAML file that contains the compute machine set custom resource (CR) sample and is named <file_name>.yaml.

    Ensure that you set the <clusterID> and <role> parameter values.

  2. Optional: If you are not sure which value to set for a specific field, you can check an existing compute machine set from your cluster.

    1. To list the compute machine sets in your cluster, run the following command: 

      $ oc get machinesets -n openshift-machine-api

      The following is example output: 

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. To view values of a specific compute machine set custom resource (CR), run the following command: 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      The following is example output: 

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-<role>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
        ...

      where:

      metadata.labels.machine.openshift.io/cluster-api-cluster
      Specifies the cluster infrastructure ID.
      metadata.labels.name

      Specifies a default node label.

      Note

      For clusters that have user-provisioned infrastructure, a compute machine set can only create worker and infra type machines.

      spec.template.metadata.spec.providerSpec
      Specifies the values of the compute machine set CR. The values are platform-specific. For more information about <providerSpec> parameters in the CR, see the sample compute machine set CR configuration for your provider.

  3. Create a MachineSet CR by running the following command: 

    $ oc create -f <file_name>.yaml

Verification

  • View the list of compute machine sets by running the following command: 

    $ oc get machineset -n openshift-machine-api

    The following is example output: 

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    When the new compute machine set is available, the DESIRED and CURRENT values match. If the compute machine set is not available, wait a few minutes and run the command again.

You can use a MachineSet custom resource (CR) to add a Windows compute node to your Nutanix cluster, where you can run Windows container workloads.

For example, you might create infrastructure Windows machine sets and related machines so that you can move supporting Windows workloads to the new Windows machines. For more information about machine sets, see "Overview of machine management".

6.4.1. Prerequisites
Copy link

  • You installed the Windows Machine Config Operator (WMCO) using Operator Lifecycle Manager (OLM).
  • You are using a supported Windows Server as the operating system image.
  • You added a new DNS entry for the internal API server URL, api-int.<cluster_name>.<base_domain>, that points to the external API server URL, api.<cluster_name>.<base_domain>. This can be a CNAME or an additional A record.

You can define a Windows MachineSet object running on Nutanix by creating a YAML file similar to the following example that the Windows Machine Config Operator (WMCO) can react upon. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-windows-worker-<zone>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
        machine.openshift.io/os-id: Windows
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          bootType: ""
          categories: null
          cluster:
            type: uuid
            uuid: <cluster_uuid>
          credentialsSecret:
            name: nutanix-credentials
          image:
            name: <image_id>
            type: name
          kind: NutanixMachineProviderConfig
          memorySize: 16Gi
          project:
            type: ""
          subnets:
          - type: uuid
            uuid: <subnet_uuid>
          systemDiskSize: 120Gi
          userDataSecret:
            name: windows-user-data
          vcpuSockets: 4
          vcpusPerSocket: 1

where:

metadata.labels.machine.openshift.io/cluster-api-cluster

Replace <infrastructure_id> with the infrastructure ID. You can obtain the infrastructure ID by running the following command: 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
metadata.name
Replace the infrastructure ID, worker label, and zone.
spec.selector.matchLabels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Replace the infrastructure ID, worker label, and zone.
spec.template.metadata.labels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Replace the infrastructure ID, worker label, and zone.
  • machine.openshift.io/os-id: Windows. When set to Windows, configures the compute machine set as a Windows machine.
spec.template.spec.metadata.labels
When set to node-role.kubernetes.io/worker, configures the node as a compute machine.
spec.template.spec.providerSpec

Specify the following parameters:

  • value.bootType. Specifies the boot type that the compute machines use. Valid values are Legacy, SecureBoot, or UEFI. The default is Legacy. For more information about boot types, see "Understanding UEFI, Secure Boot, and TPM in the Virtualized Environment (Nutanix documentaiton)" in the Additional resources section.

    Note

    You must use the Legacy boot type in OpenShift Container Platform 4.22.

  • value.cluster. Specifies a Nutanix Prism Element cluster configuration. In this example, the cluster type is uuid, so there is a uuid stanza. Replace <cluster_uuid> with the cluster UUID.
  • value.credentialsSecret.name. Specifies the secret name for the cluster. Do not change this value.

  • value.image. Specifies the image to use. Replace <image_id> with an image from an existing default compute machine set for the cluster, one of the following options:

    • nutanix-windows-server-2022 for Windows Server 2022
    • nutanix-windows-server-2025 for Windows Server 2025
  • value.kind. Specifies the cloud provider platform type. Do not change this value.
  • value.memorySize. Specifies the amount of memory for the cluster in Gi.
  • value.subnets. Specifies a subnet configuration. In this example, the subnet type is uuid, so there is a uuid stanza. Replace <subnet_uuid> with the subnet UUID.
  • value.systemDiskSize. Specifies the size of the system disk in Gi.
  • value.userDataSecret.name. Specifies the name of the secret in the user data YAML file that is in the openshift-machine-api namespace. Use the value that installation program populates in the default compute machine set.
  • value.vcpuSockets. Specifies the number of vCPU sockets.
  • value.vcpusPerSocket. Specifies the number of vCPUs per socket.

6.4.3. Creating a compute machine set
Copy link

To dynamically manage machine compute resources, you can create your own compute machine sets in addition to the compute machine sets created by the installation program. Use the OpenShift Container Platform CLI to automate node provisioning.

Prerequisites

  • Deploy an OpenShift Container Platform cluster.
  • Install the OpenShift CLI (oc).
  • Log in to oc as a user with cluster-admin permission.

Procedure

  1. Create a new YAML file that contains the compute machine set custom resource (CR) sample and is named <file_name>.yaml.

    Ensure that you set the <clusterID> and <role> parameter values.

  2. Optional: If you are not sure which value to set for a specific field, you can check an existing compute machine set from your cluster.

    1. To list the compute machine sets in your cluster, run the following command: 

      $ oc get machinesets -n openshift-machine-api

      The following is example output: 

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. To view values of a specific compute machine set custom resource (CR), run the following command: 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      The following is example output: 

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-<role>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
        ...

      where:

      metadata.labels.machine.openshift.io/cluster-api-cluster
      Specifies the cluster infrastructure ID.
      metadata.labels.name

      Specifies a default node label.

      Note

      For clusters that have user-provisioned infrastructure, a compute machine set can only create worker and infra type machines.

      spec.template.metadata.spec.providerSpec
      Specifies the values of the compute machine set CR. The values are platform-specific. For more information about <providerSpec> parameters in the CR, see the sample compute machine set CR configuration for your provider.

  3. Create a MachineSet CR by running the following command: 

    $ oc create -f <file_name>.yaml

Verification

  • View the list of compute machine sets by running the following command: 

    $ oc get machineset -n openshift-machine-api

    The following is example output: 

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    When the new compute machine set is available, the DESIRED and CURRENT values match. If the compute machine set is not available, wait a few minutes and run the command again.

6.5. Creating a Windows machine set on vSphere
Copy link

You can use a MachineSet custom resource (CR) to add a Windows compute node to your VMware vSphere cluster, where you can run Windows container workloads.

For example, you might create infrastructure Windows machine sets and related machines so that you can move supporting Windows workloads to the new Windows machines. For more information about machine sets, see "Overview of machine management" in the Additional resources section.

6.5.1. Prerequisites
Copy link

  • You installed the Windows Machine Config Operator (WMCO) using Operator Lifecycle Manager (OLM).
  • You are using a supported Windows Server as the operating system image.
  • You must prepare your vSphere environment for Windows container workloads by creating the vSphere Windows VM golden image. See "Creating the vSphere Windows VM golden image" in this section.
  • You must enable communication with the internal API server for the WMCO. See "Enabling communication with the internal API server for the WMCO on vSphere" in this section.

You must prepare your vSphere environment for Windows container workloads by creating the vSphere Windows VM golden image.

Prerequisites

  • You have created a private/public key pair, which is used to configure key-based authentication in the OpenSSH server. The private key must be configured in the Windows Machine Config Operator (WMCO) namespace so that the WMCO can communicate with the Windows VM.

    If you created the key pair on a Red Hat Enterprise Linux (RHEL) system, before you can use the public key on a Windows system, make sure the public key is saved using ASCII encoding. For example, the following PowerShell command copies a public key, encoding it for the ASCII character set: 

    C:\> echo "ssh-rsa <ssh_pub_key>" | Out-File <ssh_key_path> -Encoding ascii

    where:

    <ssh_pub_key>
    Specifies the SSH public key used to access the cluster.
    <ssh_key_path>
    Specifies the path to the SSH public key.

    See the "Configuring a secret for the Windows Machine Config Operator" section for more details.

Note

You must use Microsoft PowerShell commands in several cases when creating your Windows VM. PowerShell commands in this guide are distinguished by the PS C:\> prefix.

Procedure

  1. Select a compatible Windows Server version. Currently, the Windows Machine Config Operator (WMCO) stable version supports the following versions:

  2. Create a new VM in the vSphere client using the VM golden image with a compatible Windows Server version. For more information about compatible versions, see the "Windows Machine Config Operator prerequisites" section of the "Red Hat OpenShift support for Windows Containers release notes."

    Important

    The virtual hardware version for your VM must meet the infrastructure requirements for OpenShift Container Platform. For more information, see the "VMware vSphere infrastructure requirements" section in the OpenShift Container Platform documentation. Also, you can refer to VMware’s documentation on virtual machine hardware versions.

  3. Install and configure VMware Tools version 11.0.6 or greater on the Windows VM. See the VMware Tools documentation for more information.

  4. After installing VMware Tools on the Windows VM, verify the following:

    1. The C:\ProgramData\VMware\VMware Tools\tools.conf file exists with the following entry: 

      exclude-nics=

      If the tools.conf file does not exist, create it with the exclude-nics option uncommented and set as an empty value.

      This entry ensures the cloned vNIC generated on the Windows VM by the hybrid-overlay is not ignored.

    2. The Windows VM has a valid IP address in vCenter: 

      C:\> ipconfig

    3. The VMTools Windows service is running: 

      PS C:\> Get-Service -Name VMTools | Select Status, StartType
  5. Install and configure the OpenSSH Server on the Windows VM. See Microsoft’s documentation on installing OpenSSH for more details.

  6. Set up SSH access for an administrative user. See Microsoft’s documentation on the Administrative user to do this.

    Important

    The public key used in the instructions must correspond to the private key you create later in the WMCO namespace that holds your secret. See the "Configuring a secret for the Windows Machine Config Operator" section for more details.

  7. You must create a new firewall rule in the Windows VM that allows incoming connections for container logs. Run the following PowerShell command to create the firewall rule on TCP port 10250: 

    PS C:\> New-NetFirewallRule -DisplayName "ContainerLogsPort" -LocalPort 10250 -Enabled True -Direction Inbound -Protocol TCP -Action Allow -EdgeTraversalPolicy Allow
  8. Clone the Windows VM so it is a reusable image. Follow the VMware documentation on how to clone an existing virtual machine for more details.

  9. In the cloned Windows VM, run the Windows Sysprep tool: 

    C:\> C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown /unattend:<path_to_unattend.xml>

    Replace <path_to_unattend.xml> with the path to your unattend.xml file.

    Note

    There is a limit on how many times you can run the sysprep command on a Windows image. Consult Microsoft’s documentation for more information.

    An example unattend.xml is provided, which maintains all the changes needed for the WMCO. You must modify this example; it cannot be used directly.

    Example unattend.xml

    <?xml version="1.0" encoding="UTF-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
   <settings pass="specialize">
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <InputLocale>0409:00000409</InputLocale>
         <SystemLocale>en-US</SystemLocale>
         <UILanguage>en-US</UILanguage>
         <UILanguageFallback>en-US</UILanguageFallback>
         <UserLocale>en-US</UserLocale>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Security-SPP-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <SkipAutoActivation>true</SkipAutoActivation>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-SQMApi" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <CEIPEnabled>0</CEIPEnabled>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <ComputerName>winhost</ComputerName>
      </component>
   </settings>
   <settings pass="oobeSystem">
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <AutoLogon>
            <Enabled>false</Enabled>
         </AutoLogon>
         <OOBE>
            <HideEULAPage>true</HideEULAPage>
            <HideLocalAccountScreen>true</HideLocalAccountScreen>
            <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
            <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
            <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
            <NetworkLocation>Work</NetworkLocation>
            <ProtectYourPC>1</ProtectYourPC>
            <SkipMachineOOBE>true</SkipMachineOOBE>
            <SkipUserOOBE>true</SkipUserOOBE>
         </OOBE>
         <RegisteredOrganization>Organization</RegisteredOrganization>
         <RegisteredOwner>Owner</RegisteredOwner>
         <DisableAutoDaylightTimeSet>false</DisableAutoDaylightTimeSet>
         <TimeZone>Eastern Standard Time</TimeZone>
         <UserAccounts>
            <AdministratorPassword>
               <Value>MyPassword</Value>
               <PlainText>true</PlainText>
            </AdministratorPassword>
         </UserAccounts>
      </component>
   </settings>
</unattend>

    where:

    <ComputerName>
    Replace the winhost placeholder with a computer name, which must follow the Kubernetes' names specification. These specifications also apply to Guest OS customization performed on the resulting template while creating new VMs. For more information, see "Object Names and IDs specification (Kubernetes documentation)".
    <AutoLogon>.<Enabled>
    When false, automatic logon is disabled to avoid the security issue of leaving an open terminal with Administrator privileges at boot. This is the default value and must not be changed.
    <UserAccounts>.<AdministratorPassword>.<Value>

    Replace the MyPassword placeholder with the password for the Administrator account. This prevents the built-in Administrator account from having a blank password by default. Follow Microsoft’s best practices for choosing a password. For more information on Microsoft’s best practices, see "Password must meet complexity requirements (Microsoft documentation)".

    After the Sysprep tool has completed, the Windows VM will power off. You must not use or power on this VM anymore.

  10. Convert the Windows VM to a template in vCenter. For more information, see "vSphere Virtual Machine Administration (vSphere documentation)".

You must enable communication with the internal API server so that your Windows virtual machine (VM) can download the Ignition config files, and the kubelet on the configured VM can only communicate with the internal API server.

The Windows Machine Config Operator (WMCO) can download the Ignition config files from the internal API server endpoint only after communication with the server is enabled.

Prerequisites

  • You have installed a cluster on vSphere.

Procedure

  • Add a new DNS entry for api-int.<cluster_name>.<base_domain> that points to the external API server URL api.<cluster_name>.<base_domain>. This can be a CNAME or an additional A record.

    Note

    The external API endpoint was already created as part of the initial cluster installation on vSphere.

You can define a Windows MachineSet object running on VMware vSphere by creating a YAML file similar to the following example, which the Windows Machine Config Operator (WMCO) can react upon. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <windows_machine_set_name>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
        machine.openshift.io/os-id: Windows
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
      providerSpec:
        value:
          apiVersion: vsphereprovider.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          diskGiB: 128
          kind: VSphereMachineProviderSpec
          memoryMiB: 16384
          network:
            devices:
            - networkName: "<vm_network_name>"
          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <windows_vm_template_name>
          userDataSecret:
            name: windows-user-data
          workspace:
             datacenter: <vcenter_data_center_name>
             datastore: <vcenter_datastore_name>
             folder: <vcenter_vm_folder_path>
             resourcePool: <vsphere_resource_pool>
             server: <vcenter_server_ip>

where:

metadata.labels

For the machine.openshift.io/cluster-api-cluster label, replace <infrastructure_id> with the infrastructure ID. You can obtain the infrastructure ID by running the following command: Specify the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. You can obtain the infrastructure ID by running the following command: 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
metadata.name
Replace the infrastructure ID, worker label, and zone.
spec.selector.matchLabels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Specify the Windows compute machine set name. The compute machine set name cannot be more than 9 characters long, due to the way machine names are generated in vSphere.
spec.template.metadata.labels

Replace the parameters for the following labels:

  • machine.openshift.io/cluster-api-cluster. Replace the infrastructure ID.
  • machine.openshift.io/cluster-api-machineset. Specify the Windows compute machine set name. The compute machine set name cannot be more than 9 characters long, due to the way machine names are generated in vSphere.
  • machine.openshift.io/os-id: Windows. When set to Windows, configures the compute machine set as a Windows machine.
spec.template.spec.metadata.labels
When set to node-role.kubernetes.io/worker, configures the node as a compute machine.
spec.template.spec.providerSpec

Specify the following parameters:

  • value.diskGiB. Specifies the size of the vSphere Virtual Machine Disk (VMDK).

    Note

    This parameter does not set the size of the Windows partition. You can resize the Windows partition by using the unattend.xml file or by creating the vSphere Windows virtual machine (VM) golden image with the required disk size.

  • value.network.devices.networkName. Specifies the vSphere VM network to deploy the compute machine set to. This VM network must be where other Linux compute machines reside in the cluster.

  • value.template. Specifies the full path of the Windows vSphere VM template to use, such as golden-images/windows-server-template. The name must be unique.

    Important

    Do not specify the original VM template. The VM template must remain off and must be cloned for new Windows machines. Starting the VM template configures the VM template as a VM on the platform, which prevents it from being used as a template that compute machine sets can apply configurations to.

  • value.userDataSecret.name. The windows-user-data is created by the WMCO when the first Windows machine is configured. After that, the windows-user-data is available for all subsequent compute machine sets to consume.
  • value.workspace.datacenter. Specifies the vCenter data center to deploy the compute machine set on.
  • value.workspace.datastore. Specifies the vCenter datastore to deploy the compute machine set on.
  • value.workspace.folder. Specifies the path to the vSphere VM folder in vCenter, such as /dc1/vm/user-inst-5ddjd.
  • value.workspace.resourcePool. Specifies the vSphere resource pool for your Windows VMs. This parameter is optional.
  • value.workspace.server. Specifies the vCenter server IP or fully qualified domain name. This parameter is optional.

6.5.5. Creating a compute machine set
Copy link

To dynamically manage machine compute resources, you can create your own compute machine sets in addition to the compute machine sets created by the installation program. Use the OpenShift Container Platform CLI to automate node provisioning.

Prerequisites

  • Deploy an OpenShift Container Platform cluster.
  • Install the OpenShift CLI (oc).
  • Log in to oc as a user with cluster-admin permission.
  • In disconnected environments, the image specified in the MachineSet custom resource (CR) must have the OpenSSH server v0.0.1.0 installed.

Procedure

  1. Create a new YAML file that contains the compute machine set custom resource (CR) sample and is named <file_name>.yaml.

    Ensure that you set the <clusterID> and <role> parameter values.

  2. Optional: If you are not sure which value to set for a specific field, you can check an existing compute machine set from your cluster.

    1. To list the compute machine sets in your cluster, run the following command: 

      $ oc get machinesets -n openshift-machine-api

      The following is example output: 

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. To view values of a specific compute machine set custom resource (CR), run the following command: 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      The following is example output: 

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-<role>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
        ...

      where:

      metadata.labels.machine.openshift.io/cluster-api-cluster
      Specifies the cluster infrastructure ID.
      metadata.labels.name

      Specifies a default node label.

      Note

      For clusters that have user-provisioned infrastructure, a compute machine set can only create worker and infra type machines.

      spec.template.metadata.spec.providerSpec
      Specifies the values of the compute machine set CR. The values are platform-specific. For more information about <providerSpec> parameters in the CR, see the sample compute machine set CR configuration for your provider.

  3. Create a MachineSet CR by running the following command: 

    $ oc create -f <file_name>.yaml

Verification

  • View the list of compute machine sets by running the following command: 

    $ oc get machineset -n openshift-machine-api

    The following is example output: 

    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    When the new compute machine set is available, the DESIRED and CURRENT values match. If the compute machine set is not available, wait a few minutes and run the command again.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

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.

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 Documentation

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

Legal Notice

Theme

© 2026 Red HatBack to top