This is a cache of https://docs.okd.io/latest/machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-gcp.html. It is a snapshot of the page at 2024-11-26T18:54:37.787+0000.
Control plane configuration options for Google Cloud Platform - Managing control plane machines | Machine management | OKD 4
  1. Documentation
×

Control plane configuration options for Google Cloud Platform

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.

Sample YAML for configuring Google Cloud Platform clusters

The following example YAML snippets show provider specification and failure domain configurations for a GCP cluster.

Sample GCP provider specification

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.

Values obtained by using the OpenShift CLI

In the following example, you can obtain some of the values for your cluster by using the OpenShift CLI.

Infrastructure ID

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
Image path

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
Sample GCP providerSpec values
apiVersion: 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: (6)
            - 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 (7)
            zone: "" (8)
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:

  • OKD: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-413-x86-64-202305021736

  • OpenShift Platform Plus: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-413-x86-64-202305021736

  • OpenShift Kubernetes Engine: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-413-x86-64-202305021736
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 a single service account. Multiple service accounts are not supported.
7 Specifies the control plane user data secret. Do not change this value.
8 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.

Sample GCP failure domain configuration

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.

Sample GCP failure domain values
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.

Enabling Google Cloud Platform features for control plane machines

You can enable features by updating values in the control plane machine set.

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

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

  2. 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.
Verification

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

Configuring Confidential VM by using machine sets

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 does not support some Confidential Compute features, such as Confidential VMs with AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP).
Procedure

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

  2. 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.
Verification

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

Configuring Shielded VM options by using machine sets

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.

Procedure

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

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

    When integrity monitoring is enabled, you must not disable virtual trusted platform module (vTPM).
    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.
Verification

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

Additional resources

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 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 service-<project_number>@compute-system.iam.gserviceaccount.com pattern.
Procedure

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

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