$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
You can change the configuration of your Google Cloud Platform (GCP) control plane machines and enable features by updating values in the control plane machine set. When you save an update to the control plane machine set, the Control Plane Machine Set Operator updates the control plane machines according to your configured update strategy.
The following example YAML snippets show provider specification and failure domain configurations for a GCP cluster.
When you create a control plane machine set for an existing cluster, the provider specification must match the providerSpec
configuration in the control plane machine custom resource (CR) that is created by the installation program. You can omit any field that is set in the failure domain section of the CR.
In the following example, you can obtain some of the values for your cluster by using the OpenShift CLI.
The <cluster_id>
string is 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:
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
The <path_to_image>
string is the path to the image that was used to create the disk. If you have the OpenShift CLI installed, you can obtain the path to the image by running the following command:
$ oc -n openshift-machine-api \
-o jsonpath='{.spec.template.machines_v1beta1_machine_openshift_io.spec.providerSpec.value.disks[0].image}{"\n"}' \
get ControlPlaneMachineSet/cluster
providerSpec
valuesapiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
name: cluster
namespace: openshift-machine-api
spec:
# ...
template:
# ...
spec:
providerSpec:
value:
apiVersion: machine.openshift.io/v1beta1
canIPForward: false
credentialsSecret:
name: gcp-cloud-credentials (1)
deletionProtection: false
disks:
- autoDelete: true
boot: true
image: <path_to_image> (2)
labels: null
sizeGb: 200
type: pd-ssd
kind: GCPMachineProviderSpec (3)
machineType: e2-standard-4
metadata:
creationTimestamp: null
metadataServiceOptions: {}
networkInterfaces:
- network: <cluster_id>-network
subnetwork: <cluster_id>-master-subnet
projectID: <project_name> (4)
region: <region> (5)
serviceAccounts:
- email: <cluster_id>-m@<project_name>.iam.gserviceaccount.com
scopes:
- https://www.googleapis.com/auth/cloud-platform
shieldedInstanceConfig: {}
tags:
- <cluster_id>-master
targetPools:
- <cluster_id>-api
userDataSecret:
name: master-user-data (6)
zone: "" (7)
1 | Specifies the secret name for the cluster. Do not change this value. |
2 | Specifies the path to the image that was used to create the disk.
To use a GCP Marketplace image, specify the offer to use:
|
3 | Specifies the cloud provider platform type. Do not change this value. |
4 | Specifies the name of the GCP project that you use for your cluster. |
5 | Specifies the GCP region for the cluster. |
6 | Specifies the control plane user data secret. Do not change this value. |
7 | This parameter is configured in the failure domain, and is shown with an empty value here. If a value specified for this parameter differs from the value in the failure domain, the Operator overwrites it with the value in the failure domain. |
The control plane machine set concept of a failure domain is analogous to the existing GCP concept of a zone. The ControlPlaneMachineSet
CR spreads control plane machines across multiple failure domains when possible.
When configuring GCP failure domains in the control plane machine set, you must specify the zone name to use.
apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
name: cluster
namespace: openshift-machine-api
spec:
# ...
template:
# ...
machines_v1beta1_machine_openshift_io:
failureDomains:
gcp:
- zone: <gcp_zone_a> (1)
- zone: <gcp_zone_b> (2)
- zone: <gcp_zone_c>
- zone: <gcp_zone_d>
platform: GCP (3)
# ...
1 | Specifies a GCP zone for the first failure domain. |
2 | Specifies an additional failure domain. Further failure domains are added the same way. |
3 | Specifies the cloud provider platform name. Do not change this value. |
You can enable features by updating values in the control plane machine set.
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.
In a text editor, open the YAML file for an existing machine set or create a new one.
Edit the following line under the providerSpec
field:
apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
...
spec:
template:
spec:
providerSpec:
value:
disks:
type: pd-ssd (1)
1 | Control plane nodes must use the pd-ssd disk type. |
Using the Google Cloud console, review the details for a machine deployed by the machine set and verify that the Type
field matches the configured disk type.
By editing the machine set YAML file, you can configure the Confidential VM options that a machine set uses for machines that it deploys.
For more information about Confidential VM features, functions, and compatibility, see the GCP Compute Engine documentation about Confidential VM.
Confidential VMs are currently not supported on 64-bit ARM architectures. |
OKD 4.17 does not support some Confidential Compute features, such as Confidential VMs with AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP). |
In a text editor, open the YAML file for an existing machine set or create a new one.
Edit the following section under the providerSpec
field:
apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
...
spec:
template:
spec:
providerSpec:
value:
confidentialCompute: Enabled (1)
onHostMaintenance: Terminate (2)
machineType: n2d-standard-8 (3)
...
1 | Specify whether Confidential VM is enabled. Valid values are Disabled or Enabled . |
2 | Specify the behavior of the VM during a host maintenance event, such as a hardware or software update. For a machine that uses Confidential VM, this value must be set to Terminate , which stops the VM. Confidential VM does not support live VM migration. |
3 | Specify a machine type that supports Confidential VM. Confidential VM supports the N2D and C2D series of machine types. |
On the Google Cloud console, review the details for a machine deployed by the machine set and verify that the Confidential VM options match the values that you configured.
By editing the machine set YAML file, you can configure the Shielded VM options that a machine set uses for machines that it deploys.
For more information about Shielded VM features and functionality, see the GCP Compute Engine documentation about Shielded VM.
In a text editor, open the YAML file for an existing machine set or create a new one.
Edit the following section under the providerSpec
field:
apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
template:
spec:
providerSpec:
value:
shieldedInstanceConfig: (1)
integrityMonitoring: Enabled (2)
secureBoot: Disabled (3)
virtualizedTrustedPlatformModule: Enabled (4)
# ...
1 | In this section, specify any Shielded VM options that you want. | ||
2 | Specify whether integrity monitoring is enabled. Valid values are Disabled or Enabled .
|
||
3 | Specify whether UEFI Secure Boot is enabled. Valid values are Disabled or Enabled . |
||
4 | Specify whether vTPM is enabled. Valid values are Disabled or Enabled . |
Using the Google Cloud console, review the details for a machine deployed by the machine set and verify that the Shielded VM options match the values that you configured.
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 in clusters that use 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 |
To allow a specific service account to use your KMS key and to grant the service account the correct IAM role, run the following command with your KMS key name, key ring name, and location:
$ 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 providerSpec
field in your machine set YAML file. For example:
apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
...
spec:
template:
spec:
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 projectID in 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. |
When a new machine is created by using the updated providerSpec
object configuration, the disk encryption key is encrypted with the KMS key.