$ oc get infrastructure cluster -o jsonpath='{.status.platform}'
×
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.
|
You can use the advanced machine management and scaling capabilities only in clusters where the Machine API is operational. Clusters with user-provisioned infrastructure require additional validation and configuration to use the Machine API. Clusters with the infrastructure platform type To view the platform type for your cluster, run the following command: |
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.
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
labels:
machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
name: <infrastructure_id>-w-a
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>-w-a
template:
metadata:
creationTimestamp: null
labels:
machine.openshift.io/cluster-api-cluster: <infrastructure_id>
machine.openshift.io/cluster-api-machine-role: <role> (2)
machine.openshift.io/cluster-api-machine-type: <role>
machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
spec:
metadata:
labels:
node-role.kubernetes.io/<role>: ""
providerSpec:
value:
apiVersion: gcpprovider.openshift.io/v1beta1
canIPForward: false
credentialsSecret:
name: gcp-cloud-credentials
deletionProtection: false
disks:
- autoDelete: true
boot: true
image: <path_to_image> (3)
labels: null
sizeGb: 128
type: pd-ssd
gcpMetadata: (4)
- key: <custom_metadata_key>
value: <custom_metadata_value>
kind: GCPMachineProviderSpec
machineType: n1-standard-4
metadata:
creationTimestamp: null
networkInterfaces:
- network: <infrastructure_id>-network
subnetwork: <infrastructure_id>-worker-subnet
projectID: <project_name> (5)
region: us-central1
serviceAccounts:
- email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com
scopes:
- https://www.googleapis.com/auth/cloud-platform
tags:
- <infrastructure_id>-worker
userDataSecret:
name: worker-user-data
zone: us-central1-a| 1 | For <infrastructure_id>, specify 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:
|
| 2 | For <node>, specify the node label to add. |
| 3 | Specify 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:
To use a GCP Marketplace image, specify the offer to use:
|
| 4 | Optional: Specify custom metadata in the form of a key:value pair. For example use cases, see the GCP documentation for setting custom metadata. |
| 5 | For <project_name>, specify the name of the GCP project that you use for your cluster. |
Creating a machine set
In addition to the compute machine sets created by the installation program, you can create your own 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
ocas a user withcluster-adminpermission.
Procedure
-
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. -
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.
-
To list the compute machine sets in your cluster, run the following command:
$ oc get machinesets -n openshift-machine-apiExample outputNAME 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 -
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 yamlExample outputapiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1) name: <infrastructure_id>-<role> (2) 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: (3) ...1 The cluster infrastructure ID. 2 A default node label. For clusters that have user-provisioned infrastructure, a compute machine set can only create
workerandinfratype machines.3 The values in the <providerSpec>section of the compute machine set CR are platform-specific. For more information about<providerSpec>parameters in the CR, see the sample compute machine set CR configuration for your provider.
-
-
Create a
MachineSetCR 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-apiExample outputNAME 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 55mWhen the new machine set is available, the
DESIREDandCURRENTvalues match. If the machine set is not available, wait a few minutes and run the command again.
Configuring persistent disk types by using machine sets
You can configure the type of persistent disk that a machine set deploys machines on by editing the machine set YAML file.
For more information about persistent disk types, compatibility, regional availability, and limitations, see the GCP Compute Engine documentation about persistent disks.
Procedure
-
In a text editor, open the YAML file for an existing machine set or create a new one.
-
Edit the following line under the
providerSpecfield:providerSpec: value: disks: type: <pd-disk-type> (1)1 Specify the disk persistent type. Valid values are pd-ssd,pd-standard, andpd-balanced. The default value ispd-standard.
Verification
-
On the Google Cloud console, review the details for a machine deployed by the machine set and verify that the
Typefield matches the configured disk type.
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.
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
providerSpecfield:providerSpec: value: preemptible: trueIf
preemptibleis set totrue, the machine is labelled as aninterruptable-instanceafter 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 |
Procedure
-
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:
gcloud kms keys add-iam-policy-binding <key_name> \ --keyring <key_ring_name> \ --location <key_ring_location> \ --member "serviceAccount:service-<project_number>@compute-system.iam.gserviceaccount.com” \ --role roles/cloudkms.cryptoKeyEncrypterDecrypter -
Configure the encryption key under the
providerSpecfield in your machine set YAML file. For example:providerSpec: value: # ... disks: - type: # ... encryptionKey: kmsKey: name: machine-encryption-key (1) keyRing: openshift-encrpytion-ring (2) location: global (3) projectID: openshift-gcp-project (4) kmsKeyServiceAccount: openshift-service-account@openshift-gcp-project.iam.gserviceaccount.com (5)1 The name of the customer-managed encryption key that is used for the disk encryption. 2 The name of the KMS key ring that the KMS key belongs to. 3 The GCP location in which the KMS key ring exists. 4 Optional: The ID of the project in which the KMS key ring exists. If a project ID is not set, the machine set projectIDin which the machine set was created is used.5 Optional: 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
providerSpecobject 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.
| Model name | GPU type | Machine types [1] |
|---|---|---|
NVIDIA A100 |
|
|
NVIDIA K80 |
|
|
NVIDIA P100 |
|
|
NVIDIA P4 |
|
|
NVIDIA T4 |
|
|
NVIDIA V100 |
|
-
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
-
In a text editor, open the YAML file for an existing machine set or create a new one.
-
Specify a GPU configuration under the
providerSpecfield in your machine set YAML file. See the following examples of valid configurations:Example configuration for the A2 machine series:providerSpec: value: machineType: a2-highgpu-1g (1) onHostMaintenance: Terminate (2) restartPolicy: Always (3)1 Specify the machine type. Ensure that the machine type is included in the A2 machine series. 2 When using GPU support, you must set onHostMaintenancetoTerminate.3 Specify the restart policy for machines deployed by the machine set. Allowed values are AlwaysorNever.Example configuration for the N1 machine series:providerSpec: value: gpus: - count: 1 (1) type: nvidia-tesla-p100 (2) machineType: n1-standard-1 (3) onHostMaintenance: Terminate (4) restartPolicy: Always (5)1 Specify the number of GPUs to attach to the machine. 2 Specify the type of GPUs to attach to the machine. Ensure that the machine type and GPU type are compatible. 3 Specify the machine type. Ensure that the machine type and GPU type are compatible. 4 When using GPU support, you must set onHostMaintenancetoTerminate.5 Specify the restart policy for machines deployed by the machine set. Allowed values are AlwaysorNever.