Creating a machine set on GCP

You can create a different machine set to serve a specific purpose in your OKD cluster on Google Cloud Platform (GCP). For example, you might create infrastructure machine sets and related machines so that you can move supporting workloads to the new machines.

This process is not applicable for clusters with manually provisioned machines. You can use the advanced machine management and scaling capabilities only in clusters where the Machine API is operational.

Machine API overview

The Machine API is a combination of primary resources that are based on the upstream Cluster API project and custom OKD resources.

For OKD 4.10 clusters, the Machine API performs all node host provisioning management actions after the cluster installation finishes. Because of this system, OKD 4.10 offers an elastic, dynamic provisioning method on top of public or private cloud infrastructure.

The two primary resources are:

Machines

A fundamental unit that describes the host for a node. A machine has a providerSpec specification, which describes the types of compute nodes that are offered for different cloud platforms. For example, a machine type for a worker node on Amazon Web Services (AWS) might define a specific machine type and required metadata.

Machine sets

MachineSet resources are groups of machines. Machine sets are to machines as replica sets are to pods. If you need more machines or must scale them down, you change the replicas field on the machine set to meet your compute need.

The following custom resources add more capabilities to your cluster:

Machine autoscaler

The MachineAutoscaler resource automatically scales machines in a cloud. You can set the minimum and maximum scaling boundaries for nodes in a specified machine set, and the machine autoscaler maintains that range of nodes. The MachineAutoscaler object takes effect after a ClusterAutoscaler object exists. Both ClusterAutoscaler and MachineAutoscaler resources are made available by the ClusterAutoscalerOperator object.

Cluster autoscaler

This resource is based on the upstream cluster autoscaler project. In the OKD implementation, it is integrated with the Machine API by extending the machine set API. You can set cluster-wide scaling limits for resources such as cores, nodes, memory, GPU, and so on. You can set the priority so that the cluster prioritizes pods so that new nodes are not brought online for less important pods. You can also set the scaling policy so that you can scale up nodes but not scale them down.

Machine health check

The MachineHealthCheck resource detects when a machine is unhealthy, deletes it, and, on supported platforms, makes a new machine.

In OKD version 3.11, you could not roll out a multi-zone architecture easily because the cluster did not manage machine provisioning. Beginning with OKD version 4.1, this process is easier. Each machine set is scoped to a single zone, so the installation program sends out machine sets across availability zones on your behalf. And then because your compute is dynamic, and in the face of a zone failure, you always have a zone for when you must rebalance your machines. In global Azure regions that do not have multiple availability zones, you can use availability sets to ensure high availability. The autoscaler provides best-effort balancing over the life of a cluster.

Sample YAML for a machine set custom resource on GCP

This sample YAML defines a machine set that runs in Google Cloud Platform (GCP) and creates nodes that are labeled with node-role.kubernetes.io/<role>: "".

In this sample, <infrastructure_id> is the infrastructure ID label that is based on the cluster ID that you set when you provisioned the cluster, and <role> is the node label to add.

  1. apiVersion: machine.openshift.io/v1beta1
  2. kind: MachineSet
  3. metadata:
  4. labels:
  5. machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
  6. name: <infrastructure_id>-w-a (1)
  7. namespace: openshift-machine-api
  8. spec:
  9. replicas: 1
  10. selector:
  11. matchLabels:
  12. machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
  13. machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a (1)
  14. template:
  15. metadata:
  16. creationTimestamp: null
  17. labels:
  18. machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
  19. machine.openshift.io/cluster-api-machine-role: <role> (2)
  20. machine.openshift.io/cluster-api-machine-type: <role> (2)
  21. machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a (1)
  22. spec:
  23. metadata:
  24. labels:
  25. node-role.kubernetes.io/<role>: "" (2)
  26. providerSpec:
  27. value:
  28. apiVersion: gcpprovider.openshift.io/v1beta1
  29. canIPForward: false
  30. credentialsSecret:
  31. name: gcp-cloud-credentials
  32. deletionProtection: false
  33. disks:
  34. - autoDelete: true
  35. boot: true
  36. image: <path_to_image> (3)
  37. labels: null
  38. sizeGb: 128
  39. type: pd-ssd
  40. kind: GCPMachineProviderSpec
  41. machineType: n1-standard-4
  42. metadata:
  43. creationTimestamp: null
  44. networkInterfaces:
  45. - network: <infrastructure_id>-network (1)
  46. subnetwork: <infrastructure_id>-worker-subnet (1)
  47. projectID: <project_name> (4)
  48. region: us-central1
  49. serviceAccounts:
  50. - email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com (1) (4)
  51. scopes:
  52. - https://www.googleapis.com/auth/cloud-platform
  53. tags:
  54. - <infrastructure_id>-worker (1)
  55. userDataSecret:
  56. name: worker-user-data
  57. zone: us-central1-a
1Specify the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. If you have the OpenShift CLI installed, you can obtain the infrastructure ID by running the following command:
  1. $ oc get -o jsonpath=’{.status.infrastructureName}{“\n”}’ infrastructure cluster
2Specify the node label to add.
3Specify the path to the image that is used in current machine sets. If you have the OpenShift CLI installed, you can obtain the path to the image by running the following command:
  1. $ oc -n openshift-machine-api \
  2. -o jsonpath=’{.spec.template.spec.providerSpec.value.disks[0].image}{“\n”}’ \
  3. get machineset/<infrastructure_id>-worker-a
4Specify the name of the GCP project that you use for your cluster.

Creating a machine set

In addition to the ones created by the installation program, you can create your own machine sets to dynamically manage the machine compute resources for specific workloads of your choice.

Prerequisites

  • Deploy an OKD 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 machine set custom resource (CR) sample and is named <file_name>.yaml.

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

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

      1. $ oc get machinesets -n openshift-machine-api

      Example output

      1. NAME DESIRED CURRENT READY AVAILABLE AGE
      2. agl030519-vplxk-worker-us-east-1a 1 1 1 1 55m
      3. agl030519-vplxk-worker-us-east-1b 1 1 1 1 55m
      4. agl030519-vplxk-worker-us-east-1c 1 1 1 1 55m
      5. agl030519-vplxk-worker-us-east-1d 0 0 55m
      6. agl030519-vplxk-worker-us-east-1e 0 0 55m
      7. agl030519-vplxk-worker-us-east-1f 0 0 55m
    2. Check values of a specific machine set:

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

      Example output

      1. ...
      2. template:
      3. metadata:
      4. labels:
      5. machine.openshift.io/cluster-api-cluster: agl030519-vplxk (1)
      6. machine.openshift.io/cluster-api-machine-role: worker (2)
      7. machine.openshift.io/cluster-api-machine-type: worker
      8. machine.openshift.io/cluster-api-machineset: agl030519-vplxk-worker-us-east-1a
      1The cluster ID.
      2A default node label.
  2. Create the new MachineSet CR:

    1. $ oc create -f <file_name>.yaml
  3. View the list of machine sets:

    1. $ oc get machineset -n openshift-machine-api

    Example output

    1. NAME DESIRED CURRENT READY AVAILABLE AGE
    2. agl030519-vplxk-infra-us-east-1a 1 1 1 1 11m
    3. agl030519-vplxk-worker-us-east-1a 1 1 1 1 55m
    4. agl030519-vplxk-worker-us-east-1b 1 1 1 1 55m
    5. agl030519-vplxk-worker-us-east-1c 1 1 1 1 55m
    6. agl030519-vplxk-worker-us-east-1d 0 0 55m
    7. agl030519-vplxk-worker-us-east-1e 0 0 55m
    8. agl030519-vplxk-worker-us-east-1f 0 0 55m

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

Machine sets that deploy machines as preemptible VM instances

You can save on costs by creating a machine set running on GCP that deploys machines as non-guaranteed preemptible VM instances. Preemptible VM instances utilize excess Compute Engine capacity and are less expensive than normal instances. You can use preemptible VM instances for workloads that can tolerate interruptions, such as batch or stateless, horizontally scalable workloads.

It is strongly recommended that control plane machines are not created on preemptible VM instances due to the increased likelihood of the instance being terminated. Manual intervention is required to replace a terminated control plane node.

GCP Compute Engine can terminate a preemptible VM instance at any time. Compute Engine sends a preemption notice to the user indicating that an interruption will occur in 30 seconds. OKD begins to remove the workloads from the affected instances when Compute Engine issues the preemption notice. An ACPI G3 Mechanical Off signal is sent to the operating system after 30 seconds if the instance is not stopped. The preemptible VM instance is then transitioned to a TERMINATED state by Compute Engine.

Interruptions can occur when using preemptible VM instances for the following reasons:

  • There is a system or maintenance event

  • The supply of preemptible VM instances decreases

  • The instance reaches the end of the allotted 24-hour period for preemptible VM instances

When GCP terminates an instance, a termination handler running on the preemptible VM instance node deletes the machine resource. To satisfy the machine set replicas quantity, the machine set creates a machine that requests a preemptible VM instance.

Creating preemptible VM instances by using machine sets

You can launch a preemptible VM instance on GCP by adding preemptible to your machine set YAML file.

Procedure

  • Add the following line under the providerSpec field:

    1. providerSpec:
    2. value:
    3. preemptible: true

    If preemptible is set to true, the machine is labelled as an interruptable-instance after the instance is launched.

Enabling customer-managed encryption keys for a machine set

Google Cloud Platform (GCP) Compute Engine allows users to supply an encryption key to encrypt data on disks at rest. The key is used to encrypt the data encryption key, not to encrypt the customer’s data. By default, Compute Engine encrypts this data by using Compute Engine keys.

You can enable encryption with a customer-managed key by using the Machine API. You must first create a KMS key and assign the correct permissions to a service account. The KMS key name, key ring name, and location are required to allow a service account to use your key.

If you do not want to use a dedicated service account for the KMS encryption, the Compute Engine default service account is used instead. You must grant the default service account permission to access the keys if you do not use a dedicated service account. The Compute Engine default service account name follows the service-<project_number>@compute-system.iam.gserviceaccount.com pattern.

Procedure

  1. Run the following command with your KMS key name, key ring name, and location to allow a specific service account to use your KMS key and to grant the service account the correct IAM role:

    1. gcloud kms keys add-iam-policy-binding <key_name> \
    2. --keyring <key_ring_name> \
    3. --location <key_ring_location> \
    4. --member "serviceAccount:service-<project_number>@compute-system.iam.gserviceaccount.com” \
    5. --role roles/cloudkms.cryptoKeyEncrypterDecrypter
  2. Configure the encryption key under the providerSpec field in your machine set YAML file. For example:

    1. providerSpec:
    2. value:
    3. # ...
    4. disks:
    5. - type:
    6. # ...
    7. encryptionKey:
    8. kmsKey:
    9. name: machine-encryption-key (1)
    10. keyRing: openshift-encrpytion-ring (2)
    11. location: global (3)
    12. projectID: openshift-gcp-project (4)
    13. kmsKeyServiceAccount: openshift-service-account@openshift-gcp-project.iam.gserviceaccount.com (5)
    1The name of the customer-managed encryption key that is used for the disk encryption.
    2The name of the KMS key ring that the KMS key belongs to.
    3The GCP location in which the KMS key ring exists.
    4Optional: The ID of the project in which the KMS key ring exists. If a project ID is not set, the machine set projectID in which the machine set was created is used.
    5Optional: The service account that is used for the encryption request for the given KMS key. If a service account is not set, the Compute Engine default service account is used.

    After a new machine is created by using the updated providerSpec object configuration, the disk encryption key is encrypted with the KMS key.

Enabling GPU support for a machine set

Google Cloud Platform (GCP) Compute Engine enables users to add GPUs to VM instances. Workloads that benefit from access to GPU resources can perform better on compute machines with this feature enabled. OKD on GCP supports NVIDIA GPU models in the A2 and N1 machine series.

Table 1. Supported GPU configurations
Model nameGPU typeMachine types [1]

NVIDIA A100

nvidia-tesla-a100

  • a2-highgpu-1g

  • a2-highgpu-2g

  • a2-highgpu-4g

  • a2-highgpu-8g

  • a2-megagpu-16g

NVIDIA K80

nvidia-tesla-k80

  • n1-standard-1

  • n1-standard-2

  • n1-standard-4

  • n1-standard-8

  • n1-standard-16

  • n1-standard-32

  • n1-standard-64

  • n1-standard-96

  • n1-highmem-2

  • n1-highmem-4

  • n1-highmem-8

  • n1-highmem-16

  • n1-highmem-32

  • n1-highmem-64

  • n1-highmem-96

  • n1-highcpu-2

  • n1-highcpu-4

  • n1-highcpu-8

  • n1-highcpu-16

  • n1-highcpu-32

  • n1-highcpu-64

  • n1-highcpu-96

NVIDIA P100

nvidia-tesla-p100

NVIDIA P4

nvidia-tesla-p4

NVIDIA T4

nvidia-tesla-t4

NVIDIA V100

nvidia-tesla-v100

  1. For more information about machine types, including specifications, compatibility, regional availability, and limitations, see the GCP Compute Engine documentation about N1 machine series, A2 machine series, and GPU regions and zones availability.

You can define which supported GPU to use for an instance by using the Machine API.

You can configure machines in the N1 machine series to deploy with one of the supported GPU types. Machines in the A2 machine series come with associated GPUs, and cannot use guest accelerators.

GPUs for graphics workloads are not supported.

Procedure

  1. In a text editor, open the YAML file for an existing machine set or create a new one.

  2. Specify a GPU configuration under the providerSpec field in your machine set YAML file. See the following examples of valid configurations:

    Example configuration for the A2 machine series:

    1. providerSpec:
    2. value:
    3. machineType: a2-highgpu-1g (1)
    4. onHostMaintenance: Terminate (2)
    5. restartPolicy: Always (3)
    1Specify the machine type. Ensure that the machine type is included in the A2 machine series.
    2When using GPU support, you must set onHostMaintenance to Terminate.
    3Specify the restart policy for machines deployed by the machine set. Allowed values are Always or Never.

    Example configuration for the N1 machine series:

    1. providerSpec:
    2. value:
    3. gpus:
    4. - count: 1 (1)
    5. type: nvidia-tesla-p100 (2)
    6. machineType: n1-standard-1 (3)
    7. onHostMaintenance: Terminate (4)
    8. restartPolicy: Always (5)
    1Specify the number of GPUs to attach to the machine.
    2Specify the type of GPUs to attach to the machine. Ensure that the machine type and GPU type are compatible.
    3Specify the machine type. Ensure that the machine type and GPU type are compatible.
    4When using GPU support, you must set onHostMaintenance to Terminate.
    5Specify the restart policy for machines deployed by the machine set. Allowed values are Always or Never.