1. Documentation
×

Changing control plane configuration options for Microsoft Azure

You can update your control plane machines to reflect changes in your infrastructure or environment by editing values in the control plane machine set specification.

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. For more information, see "Updating the control plane configuration".

The following example YAML snippets show provider specification and failure domain configurations for an Azure cluster.

Sample Azure 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 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, <cluster_id> 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
Sample Azure providerSpec values
apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
      spec:
        providerSpec:
          value:
            acceleratedNetworking: true
            apiVersion: machine.openshift.io/v1beta1
            credentialsSecret:
              name: azure-cloud-credentials (1)
              namespace: openshift-machine-api
            diagnostics: {}
            image: (2)
              offer: ""
              publisher: ""
              resourceID: /resourceGroups/<cluster_id>-rg/providers/Microsoft.Compute/galleries/gallery_<cluster_id>/images/<cluster_id>-gen2/versions/412.86.20220930 (3)
              sku: ""
              version: ""
            internalLoadBalancer: <cluster_id>-internal (4)
            kind: AzureMachineProviderSpec (5)
            location: <region> (6)
            managedIdentity: <cluster_id>-identity
            metadata:
              creationTimestamp: null
              name: <cluster_id>
            networkResourceGroup: <cluster_id>-rg
            osDisk: (7)
              diskSettings: {}
              diskSizeGB: 1024
              managedDisk:
                storageAccountType: Premium_LRS
              osType: Linux
            publicIP: false
            publicLoadBalancer: <cluster_id> (8)
            resourceGroup: <cluster_id>-rg
            subnet: <cluster_id>-master-subnet (9)
            userDataSecret:
              name: master-user-data (10)
            vmSize: Standard_D8s_v3
            vnet: <cluster_id>-vnet
            zone: "1" (11)
1 Specifies the secret name for the cluster. Do not change this value.
2 Specifies the image details for your control plane machine set.
3 Specifies an image that is compatible with your instance type. The Hyper-V generation V2 images created by the installation program have a -gen2 suffix, while V1 images have the same name without the suffix.
4 Specifies the internal load balancer for the control plane. This field might not be preconfigured but is required in both the ControlPlaneMachineSet and control plane Machine CRs.
5 Specifies the cloud provider platform type. Do not change this value.
6 Specifies the region to place control plane machines on.
7 Specifies the disk configuration for the control plane.
8 Specifies the public load balancer for the control plane.

You can omit the publicLoadBalancer parameter on private OKD clusters that have user-defined outbound routing.
9 Specifies the subnet for the control plane.
10 Specifies the control plane user data secret. Do not change this value.
11 Specifies the zone configuration for clusters that use a single zone for all failure domains.

If the cluster is configured to use a different zone for each failure domain, this parameter is configured in the failure domain. If you specify this value in the provider specification when using different zones for each failure domain, the Control Plane Machine Set Operator ignores it.

Sample Azure failure domain configuration

The control plane machine set concept of a failure domain is analogous to existing Azure concept of an Azure availability zone. The ControlPlaneMachineSet CR spreads control plane machines across multiple failure domains when possible.

When configuring Azure failure domains in the control plane machine set, you must specify the availability zone name. An Azure cluster uses a single subnet that spans multiple zones.

Sample Azure 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:
        azure:
        - zone: "1" (1)
        - zone: "2"
        - zone: "3"
        platform: Azure (2)
# ...
1 Each instance of zone specifies an Azure availability zone for a failure domain.

If the cluster is configured to use a single zone for all failure domains, the zone parameter is configured in the provider specification instead of in the failure domain configuration.
2 Specifies the cloud provider platform name. Do not change this value.

Additional resources