1. Documentation
×

Installing a cluster on OpenStack with customizations

Prerequisites

Resource guidelines for installing OKD on OpenStack

To support an OKD installation, your OpenStack quota must meet the following requirements:

Table 1. Recommended resources for a default OKD cluster on OpenStack
Resource Value

Floating IP addresses

3

Ports

15

Routers

1

Subnets

1

RAM

88 GB

vCPUs

22

Volume storage

275 GB

Instances

7

Security groups

3

Security group rules

60

Server groups

2 - plus 1 for each additional availability zone in each machine pool

A cluster might function with fewer than recommended resources, but its performance is not guaranteed.

If OpenStack object storage (Swift) is available and operated by a user account with the swiftoperator role, it is used as the default backend for the OKD image registry. In this case, the volume storage requirement is 175 GB. Swift space requirements vary depending on the size of the image registry.
By default, your security group and security group rule quotas might be low. If you encounter problems, run openstack quota set --secgroups 3 --secgroup-rules 60 <project> as an administrator to increase them.

An OKD deployment comprises control plane machines, compute machines, and a bootstrap machine.

Control plane machines

By default, the OKD installation process creates three control plane machines.

Each machine requires:

  • An instance from the OpenStack quota

  • A port from the OpenStack quota

  • A flavor with at least 16 GB memory and 4 vCPUs

  • At least 100 GB storage space from the OpenStack quota

Compute machines

By default, the OKD installation process creates three compute machines.

Each machine requires:

  • An instance from the OpenStack quota

  • A port from the OpenStack quota

  • A flavor with at least 8 GB memory and 2 vCPUs

  • At least 100 GB storage space from the OpenStack quota

Compute machines host the applications that you run on OKD; aim to run as many as you can.

Bootstrap machine

During installation, a bootstrap machine is temporarily provisioned to stand up the control plane. After the production control plane is ready, the bootstrap machine is deprovisioned.

The bootstrap machine requires:

  • An instance from the OpenStack quota

  • A port from the OpenStack quota

  • A flavor with at least 16 GB memory and 4 vCPUs

  • At least 100 GB storage space from the OpenStack quota

Enabling Swift on OpenStack

Swift is operated by a user account with the swiftoperator role. Add the role to an account before you run the installation program.

If the OpenStack object storage service, commonly known as Swift, is available, OKD uses it as the image registry storage. If it is unavailable, the installation program relies on the OpenStack block storage service, commonly known as Cinder.

If Swift is present and you want to use it, you must enable access to it. If it is not present, or if you do not want to use it, skip this section.

OpenStack 17 sets the rgw_max_attr_size parameter of Ceph RGW to 256 characters. This setting causes issues with uploading container images to the OKD registry. You must set the value of rgw_max_attr_size to at least 1024 characters.

Before installation, check if your OpenStack deployment is affected by this problem. If it is, reconfigure Ceph RGW.
Prerequisites

  • You have a OpenStack administrator account on the target environment.

  • The Swift service is installed.

  • On Ceph RGW, the account in url option is enabled.

Procedure

To enable Swift on OpenStack:

  1. As an administrator in the OpenStack CLI, add the swiftoperator role to the account that will access Swift:

    $ openstack role add --user <user> --project <project> swiftoperator

Your OpenStack deployment can now use Swift for the image registry.

Configuring an image registry with custom storage on clusters that run on OpenStack

After you install a cluster on OpenStack, you can use a Cinder volume that is in a specific availability zone for registry storage.

Procedure

  1. Create a YAML file that specifies the storage class and availability zone to use. For example:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: custom-csi-storageclass
provisioner: cinder.csi.openstack.org
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  availability: <availability_zone_name>

    OKD does not verify the existence of the availability zone you choose. Verify the name of the availability zone before you apply the configuration.

  2. From a command line, apply the configuration:

    $ oc apply -f <storage_class_file_name>
    Example output
    storageclass.storage.k8s.io/custom-csi-storageclass created

  3. Create a YAML file that specifies a persistent volume claim (PVC) that uses your storage class and the openshift-image-registry namespace. For example:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pvc-imageregistry
  namespace: openshift-image-registry (1)
  annotations:
    imageregistry.openshift.io: "true"
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 100Gi (2)
  storageClassName: <your_custom_storage_class> (3)
    1 Enter the namespace openshift-image-registry. This namespace allows the Cluster Image Registry Operator to consume the PVC.
    2 Optional: Adjust the volume size.
    3 Enter the name of the storage class that you created.

  4. From a command line, apply the configuration:

    $ oc apply -f <pvc_file_name>
    Example output
    persistentvolumeclaim/csi-pvc-imageregistry created

  5. Replace the original persistent volume claim in the image registry configuration with the new claim:

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --type 'json' -p='[{"op": "replace", "path": "/spec/storage/pvc/claim", "value": "csi-pvc-imageregistry"}]'
    Example output
    config.imageregistry.operator.openshift.io/cluster patched

    Over the next several minutes, the configuration is updated.

Verification

To confirm that the registry is using the resources that you defined:

  1. Verify that the PVC claim value is identical to the name that you provided in your PVC definition:

    $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml
    Example output
    ...
status:
    ...
    managementState: Managed
    pvc:
      claim: csi-pvc-imageregistry
...

  2. Verify that the status of the PVC is Bound:

    $ oc get pvc -n openshift-image-registry csi-pvc-imageregistry
    Example output
    NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS             AGE
csi-pvc-imageregistry  Bound    pvc-72a8f9c9-f462-11e8-b6b6-fa163e18b7b5   100Gi      RWO            custom-csi-storageclass  11m

Verifying external network access

The OKD installation process requires external network access. You must provide an external network value to it, or deployment fails. Before you begin the process, verify that a network with the external router type exists in OpenStack.

Prerequisites
Procedure

  1. Using the OpenStack CLI, verify the name and ID of the 'External' network:

    $ openstack network list --long -c ID -c Name -c "Router Type"
    Example output
    +--------------------------------------+----------------+-------------+
| ID                                   | Name           | Router Type |
+--------------------------------------+----------------+-------------+
| 148a8023-62a7-4672-b018-003462f8d7dc | public_network | External    |
+--------------------------------------+----------------+-------------+

A network with an external router type appears in the network list. If at least one does not, see Creating a default floating IP network and Creating a default provider network.

If the external network’s CIDR range overlaps one of the default network ranges, you must change the matching network ranges in the install-config.yaml file before you start the installation process.

The default network ranges are:

Network Range

machineNetwork

10.0.0.0/16

serviceNetwork

172.30.0.0/16

clusterNetwork

10.128.0.0/14
If the installation program finds multiple networks with the same name, it sets one of them at random. To avoid this behavior, create unique names for resources in OpenStack.

If the Neutron trunk service plugin is enabled, a trunk port is created by default. For more information, see Neutron trunk port.

Defining parameters for the installation program

The OKD installation program relies on a file that is called clouds.yaml. The file describes OpenStack configuration parameters, including the project name, log in information, and authorization service URLs.

Procedure

  1. Create the clouds.yaml file:

    • If your OpenStack distribution includes the Horizon web UI, generate a clouds.yaml file in it.

      Remember to add a password to the auth field. You can also keep secrets in a separate file from clouds.yaml. OKD does not support application credentials.

    • If your OpenStack distribution does not include the Horizon web UI, or you do not want to use Horizon, create the file yourself. For detailed information about clouds.yaml, see Config files in the OpenStack documentation.

      clouds:
  shiftstack:
    auth:
      auth_url: http://10.10.14.42:5000/v3
      project_name: shiftstack
      username: <username>
      password: <password>
      user_domain_name: Default
      project_domain_name: Default
  dev-env:
    region_name: RegionOne
    auth:
      username: <username>
      password: <password>
      project_name: 'devonly'
      auth_url: 'https://10.10.14.22:5001/v2.0'

  2. If your OpenStack installation uses self-signed certificate authority (CA) certificates for endpoint authentication:

    1. Copy the certificate authority file to your machine.

    2. Add the cacerts key to the clouds.yaml file. The value must be an absolute, non-root-accessible path to the CA certificate:

      clouds:
  shiftstack:
    ...
    cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"

      After you run the installer with a custom CA certificate, you can update the certificate by editing the value of the ca-cert.pem key in the cloud-provider-config keymap. On a command line, run:

      $ oc edit configmap -n openshift-config cloud-provider-config

  3. Place the clouds.yaml file in one of the following locations:

    1. The value of the OS_CLIENT_CONFIG_FILE environment variable

    2. The current directory

    3. A Unix-specific user configuration directory, for example ~/.config/openstack/clouds.yaml

    4. A Unix-specific site configuration directory, for example /etc/openstack/clouds.yaml

      The installation program searches for clouds.yaml in that order.

Setting cloud provider options

Optionally, you can edit the cloud provider configuration for your cluster. The cloud provider configuration controls how OKD interacts with OpenStack.

For a complete list of cloud provider configuration parameters, see the "OpenStack cloud configuration reference guide" page in the "Installing on OpenStack" documentation.

Procedure

  1. If you have not already generated manifest files for your cluster, generate them by running the following command:

    $ openshift-install --dir <destination_directory> create manifests

  2. In a text editor, open the cloud-provider configuration manifest file. For example:

    $ vi openshift/manifests/cloud-provider-config.yaml

  3. Modify the options based on the cloud configuration specification.

    Configuring Octavia for load balancing is a common case for clusters that do not use Kuryr. For example:

    #...
[LoadBalancer]
use-octavia=true (1)
lb-provider = "amphora" (2)
floating-network-id="d3deb660-4190-40a3-91f1-37326fe6ec4a" (3)
create-monitor = True (4)
monitor-delay = 10s (5)
monitor-timeout = 10s (6)
monitor-max-retries = 1 (7)
#...
    1 This property enables Octavia integration.
    2 This property sets the Octavia provider that your load balancer uses. It accepts "ovn" or "amphora" as values. If you choose to use OVN, you must also set lb-method to SOURCE_IP_PORT.
    3 This property is required if you want to use multiple external networks with your cluster. The cloud provider creates floating IP addresses on the network that is specified here.
    4 This property controls whether the cloud provider creates health monitors for Octavia load balancers. Set the value to True to create health monitors. As of OpenStack 16.1 and 16.2, this feature is only available for the Amphora provider.
    5 This property sets the frequency with which endpoints are monitored. The value must be in the time.ParseDuration() format. This property is required if the value of the create-monitor property is True.
    6 This property sets the time that monitoring requests are open before timing out. The value must be in the time.ParseDuration() format. This property is required if the value of the create-monitor property is True.
    7 This property defines how many successful monitoring requests are required before a load balancer is marked as online. The value must be an integer. This property is required if the value of the create-monitor property is True.

    Prior to saving your changes, verify that the file is structured correctly. Clusters might fail if properties are not placed in the appropriate section.

    You must set the value of the create-monitor property to True if you use services that have the value of the .spec.externalTrafficPolicy property set to Local. The OVN Octavia provider in OpenStack 16.1 and 16.2 does not support health monitors. Therefore, services that have ETP parameter values set to Local might not respond when the lb-provider value is set to "ovn".

    For installations that use Kuryr, Kuryr handles relevant services. There is no need to configure Octavia load balancing in the cloud provider.

  4. Save the changes to the file and proceed with installation.

    You can update your cloud provider configuration after you run the installer. On a command line, run:

    $ oc edit configmap -n openshift-config cloud-provider-config

    After you save your changes, your cluster will take some time to reconfigure itself. The process is complete if none of your nodes have a SchedulingDisabled status.

External load balancers that use pre-defined floating IP addresses

Commonly, OpenStack deployments disallow non-administrator users from creating specific floating IP addresses. If such a policy is in place and you use a floating IP address in your service specification, the cloud provider will fail to handle IP address assignment to load balancers.

If you use an external cloud provider, you can avoid this problem by pre-creating a floating IP address and specifying it in your service specification. The in-tree cloud provider does not support this method.

Alternatively, you can modify the OpenStack Networking service (Neutron) to allow non-administrator users to create specific floating IP addresses.

Additional resources

Obtaining the installation program

Before you install OKD, download the installation file on a local computer.

Prerequisites

  • You have a computer that runs Linux or macOS, with 500 MB of local disk space.

Procedure

  1. Download installer from https://github.com/openshift/okd/releases

    The installation program creates several files on the computer that you use to install your cluster. You must keep the installation program and the files that the installation program creates after you finish installing the cluster. Both files are required to delete the cluster.

    Deleting the files created by the installation program does not remove your cluster, even if the cluster failed during installation. To remove your cluster, complete the OKD uninstallation procedures for your specific cloud provider.

  2. Extract the installation program. For example, on a computer that uses a Linux operating system, run the following command:

    $ tar -xvf openshift-install-linux.tar.gz

  3. Download your installation pull secret from the Red Hat OpenShift Cluster Manager. This pull secret allows you to authenticate with the services that are provided by the included authorities, including Quay.io, which serves the container images for OKD components.

    Using a pull secret from the Red Hat OpenShift Cluster Manager is not required. You can use a pull secret for another private registry. Or, if you do not need the cluster to pull images from a private registry, you can use {"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}} as the pull secret when prompted during the installation.

    If you do not use the pull secret from the Red Hat OpenShift Cluster Manager:

    • Red Hat Operators are not available.

    • The Telemetry and Insights operators do not send data to Red Hat.

    • Content from the Red Hat Container Catalog registry, such as image streams and Operators, are not available.

Creating the installation configuration file

You can customize the OKD cluster you install on OpenStack.

Prerequisites

  • Obtain the OKD installation program and the pull secret for your cluster.

  • Obtain service principal permissions at the subscription level.

Procedure

  1. Create the install-config.yaml file.

    1. Change to the directory that contains the installation program and run the following command:

      $ ./openshift-install create install-config --dir <installation_directory> (1)
      1 For <installation_directory>, specify the directory name to store the files that the installation program creates.

      When specifying the directory:

      • Verify that the directory has the execute permission. This permission is required to run Terraform binaries under the installation directory.

      • Use an empty directory. Some installation assets, such as bootstrap X.509 certificates, have short expiration intervals, therefore you must not reuse an installation directory. If you want to reuse individual files from another cluster installation, you can copy them into your directory. However, the file names for the installation assets might change between releases. Use caution when copying installation files from an earlier OKD version.

    2. At the prompts, provide the configuration details for your cloud:

      1. Optional: Select an SSH key to use to access your cluster machines.

        For production OKD clusters on which you want to perform installation debugging or disaster recovery, specify an SSH key that your ssh-agent process uses.

      2. Select openstack as the platform to target.

      3. Specify the OpenStack external network name to use for installing the cluster.

      4. Specify the floating IP address to use for external access to the OpenShift API.

      5. Specify a OpenStack flavor with at least 16 GB RAM to use for control plane nodes and 8 GB RAM for compute nodes.

      6. Select the base domain to deploy the cluster to. All DNS records will be sub-domains of this base and will also include the cluster name.

      7. Enter a name for your cluster. The name must be 14 or fewer characters long.

      8. Paste the pull secret from the Red Hat OpenShift Cluster Manager. This field is optional.

  2. Modify the install-config.yaml file. You can find more information about the available parameters in the "Installation configuration parameters" section.

  3. Back up the install-config.yaml file so that you can use it to install multiple clusters.

    The install-config.yaml file is consumed during the installation process. If you want to reuse the file, you must back it up now.
Additional resources

See Installation configuration parameters section for more information about the available parameters.

Configuring the cluster-wide proxy during installation

Production environments can deny direct access to the internet and instead have an HTTP or HTTPS proxy available. You can configure a new OKD cluster to use a proxy by configuring the proxy settings in the install-config.yaml file.

Prerequisites

  • You have an existing install-config.yaml file.

  • You reviewed the sites that your cluster requires access to and determined whether any of them need to bypass the proxy. By default, all cluster egress traffic is proxied, including calls to hosting cloud provider APIs. You added sites to the Proxy object’s spec.noProxy field to bypass the proxy if necessary.

    The Proxy object status.noProxy field is populated with the values of the networking.machineNetwork[].cidr, networking.clusterNetwork[].cidr, and networking.serviceNetwork[] fields from your installation configuration.

    For installations on Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and OpenStack, the Proxy object status.noProxy field is also populated with the instance metadata endpoint (169.254.169.254).
Procedure

  1. Edit your install-config.yaml file and add the proxy settings. For example:

    apiVersion: v1
baseDomain: my.domain.com
proxy:
  httpProxy: http://<username>:<pswd>@<ip>:<port> (1)
  httpsProxy: https://<username>:<pswd>@<ip>:<port> (2)
  noProxy: example.com (3)
additionalTrustBundle: | (4)
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
    1 A proxy URL to use for creating HTTP connections outside the cluster. The URL scheme must be http.
    2 A proxy URL to use for creating HTTPS connections outside the cluster.
    3 A comma-separated list of destination domain names, IP addresses, or other network CIDRs to exclude from proxying. Preface a domain with . to match subdomains only. For example, .y.com matches x.y.com, but not y.com. Use * to bypass the proxy for all destinations.
    4 If provided, the installation program generates a config map that is named user-ca-bundle in the openshift-config namespace that contains one or more additional CA certificates that are required for proxying HTTPS connections. The Cluster Network Operator then creates a trusted-ca-bundle config map that merges these contents with the Fedora CoreOS (FCOS) trust bundle, and this config map is referenced in the trustedCA field of the Proxy object. The additionalTrustBundle field is required unless the proxy’s identity certificate is signed by an authority from the FCOS trust bundle.

    The installation program does not support the proxy readinessEndpoints field.

    If the installer times out, restart and then complete the deployment by using the wait-for command of the installer. For example:

    $ ./openshift-install wait-for install-complete --log-level debug

  2. Save the file and reference it when installing OKD.

The installation program creates a cluster-wide proxy that is named cluster that uses the proxy settings in the provided install-config.yaml file. If no proxy settings are provided, a cluster Proxy object is still created, but it will have a nil spec.

Only the Proxy object named cluster is supported, and no additional proxies can be created.

Installation configuration parameters

Before you deploy an OKD cluster, you provide parameter values to describe your account on the cloud platform that hosts your cluster and optionally customize your cluster’s platform. When you create the install-config.yaml installation configuration file, you provide values for the required parameters through the command line. If you customize your cluster, you can modify the install-config.yaml file to provide more details about the platform.

After installation, you cannot modify these parameters in the install-config.yaml file.

Required configuration parameters

Required installation configuration parameters are described in the following table:

Table 2. Required parameters
Parameter Description Values

apiVersion

The API version for the install-config.yaml content. The current version is v1. The installer may also support older API versions.

String

baseDomain

The base domain of your cloud provider. The base domain is used to create routes to your OKD cluster components. The full DNS name for your cluster is a combination of the baseDomain and metadata.name parameter values that uses the <metadata.name>.<baseDomain> format.

A fully-qualified domain or subdomain name, such as example.com.

metadata

Kubernetes resource ObjectMeta, from which only the name parameter is consumed.

Object

metadata.name

The name of the cluster. DNS records for the cluster are all subdomains of {{.metadata.name}}.{{.baseDomain}}.

String of lowercase letters, hyphens (-), and periods (.), such as dev. The string must be 14 characters or fewer long.

platform

The configuration for the specific platform upon which to perform the installation: alibabacloud, aws, baremetal, azure, gcp, ibmcloud, nutanix, openstack, ovirt, vsphere, or {}. For additional information about platform.<platform> parameters, consult the table for your specific platform that follows.

Object

Network configuration parameters

You can customize your installation configuration based on the requirements of your existing network infrastructure. For example, you can expand the IP address block for the cluster network or provide different IP address blocks than the defaults.

Only IPv4 addresses are supported.

Globalnet is not supported with Red Hat OpenShift Data Foundation disaster recovery solutions. For regional disaster recovery scenarios, ensure that you use a nonoverlapping range of private IP addresses for the cluster and service networks in each cluster.
Table 3. Network parameters
Parameter Description Values

networking

The configuration for the cluster network.

Object

You cannot modify parameters specified by the networking object after installation.

networking.networkType

The cluster network provider Container Network Interface (CNI) cluster network provider to install.

Either OpenShiftSDN or OVNKubernetes. The default value is OVNKubernetes.

networking.clusterNetwork

The IP address blocks for pods.

The default value is 10.128.0.0/14 with a host prefix of /23.

If you specify multiple IP address blocks, the blocks must not overlap.

An array of objects. For example:

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23

networking.clusterNetwork.cidr

Required if you use networking.clusterNetwork. An IP address block.

An IPv4 network.

An IP address block in Classless Inter-Domain Routing (CIDR) notation. The prefix length for an IPv4 block is between 0 and 32.

networking.clusterNetwork.hostPrefix

The subnet prefix length to assign to each individual node. For example, if hostPrefix is set to 23 then each node is assigned a /23 subnet out of the given cidr. A hostPrefix value of 23 provides 510 (2^(32 - 23) - 2) pod IP addresses.

A subnet prefix.

The default value is 23.

networking.serviceNetwork

The IP address block for services. The default value is 172.30.0.0/16.

The OpenShift SDN and OVN-Kubernetes network providers support only a single IP address block for the service network.

An array with an IP address block in CIDR format. For example:

networking:
  serviceNetwork:
   - 172.30.0.0/16

networking.machineNetwork

The IP address blocks for machines.

If you specify multiple IP address blocks, the blocks must not overlap.

An array of objects. For example:

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16

networking.machineNetwork.cidr

Required if you use networking.machineNetwork. An IP address block. The default value is 10.0.0.0/16 for all platforms other than libvirt. For libvirt, the default value is 192.168.126.0/24.

An IP network block in CIDR notation.

For example, 10.0.0.0/16.

Set the networking.machineNetwork to match the CIDR that the preferred NIC resides in.

Optional configuration parameters

Optional installation configuration parameters are described in the following table:

Table 4. Optional parameters
Parameter Description Values

additionalTrustBundle

A PEM-encoded X.509 certificate bundle that is added to the nodes' trusted certificate store. This trust bundle may also be used when a proxy has been configured.

String

capabilities

Controls the installation of optional core cluster components. You can reduce the footprint of your OKD cluster by disabling optional components.

String array

capabilities.baselineCapabilitySet

Selects an initial set of optional capabilities to enable. Valid values are None, v4.11 and vCurrent. v4.11 enables the baremetal Operator, the marketplace Operator, and the openshift-samples content. vCurrent installs the recommended set of capabilities for the current version of OKD. The default value is vCurrent.

String

capabilities.additionalEnabledCapabilities

Extends the set of optional capabilities beyond what you specify in baselineCapabilitySet. Valid values are baremetal, marketplace and openshift-samples. You may specify multiple capabilities in this parameter.

String array

cgroupsV2

Enables Linux control groups version 2 (cgroups v2) on specific nodes in your cluster. The OKD process for enabling cgroups v2 disables all cgroup version 1 controllers and hierarchies. The OKD cgroups version 2 feature is in Developer Preview and is not supported by Red Hat at this time.

true

compute

The configuration for the machines that comprise the compute nodes.

Array of MachinePool objects.

compute.architecture

Determines the instruction set architecture of the machines in the pool. Currently, clusters with varied architectures are not supported. All pools must specify the same architecture. Valid values are amd64 (the default).

String

compute.hyperthreading

Whether to enable or disable simultaneous multithreading, or hyperthreading, on compute machines. By default, simultaneous multithreading is enabled to increase the performance of your machines' cores.

If you disable simultaneous multithreading, ensure that your capacity planning accounts for the dramatically decreased machine performance.

Enabled or Disabled

compute.name

Required if you use compute. The name of the machine pool.

worker

compute.platform

Required if you use compute. Use this parameter to specify the cloud provider to host the worker machines. This parameter value must match the controlPlane.platform parameter value.

alibabacloud, aws, azure, gcp, ibmcloud, nutanix, openstack, ovirt, vsphere, or {}

compute.replicas

The number of compute machines, which are also known as worker machines, to provision.

A positive integer greater than or equal to 2. The default value is 3.

controlPlane

The configuration for the machines that comprise the control plane.

Array of MachinePool objects.

controlPlane.architecture

Determines the instruction set architecture of the machines in the pool. Currently, clusters with varied architectures are not supported. All pools must specify the same architecture. Valid values are amd64 (the default).

String