Skip to content

Latest commit

 

History

History
106 lines (85 loc) · 3.91 KB

customization.md

File metadata and controls

106 lines (85 loc) · 3.91 KB
Raw

GCP Platform Customization

Beyond the platform-agnostic install-config.yaml properties, the installer supports additional, GCP-specific properties.

  • projectID (required string): The project where the cluster should be created.
  • region (required string): The GCP region where the cluster should be created.
  • network (optional string): The name of an existing GCP VPC where the cluster infrastructure should be provisioned.
  • controlPlaneSubnet (optional string): The name of an existing GCP subnet which should be used by the cluster control plane.
  • computeSubnet (optional string): The name of an existing GCP subnet which should be used by the cluster nodes.
  • defaultMachinePlatform (optional object): Default GCP-specific machine pool properties which apply to machine pools that do not define their own GCP-specific properties.

Machine pools

  • type (optional string): The GCP machine type.
  • zones (optional array of strings): The availability zones used for machines in the pool.

Installing to Existing Networks & Subnetworks

The installer can use an existing VPC and subnets when provisioning an OpenShift cluster. If one of network, controlPlaneSubnet, or computeSubnet is specified, all must be specified (see example below). Furthermore, each of the networks must belong to the project specified by projectID, and the subnets must belong to the specified cluster region. The installer will use these existing networks when creating infrastructure such as VM instances, load balancers, firewall rules, and DNS zones.

Cluster Isolation

In a scenario where multiple clusters are installed to the same VPC network, the installer maintains cluster isolation by using firewall rules which specify allowed sources and destinations through network tags. By tagging each Compute Engine VM instance with a unique cluster id and creating corresponding firewall rules, the installer ensures that a cluster's control plane is only accessible by its own member nodes.

By design, possible inter-cluster access is limited to:

  • The API, which is globally available with an external publishing strategy or available throughout the network in an internal publishing strategy
  • Debugging tools; i.e. ports on VM instances are open to the machineCidr for SSH & ICMP

Examples

Some example install-config.yaml are shown below. For examples of platform-agnostic configuration fragments, see here.

Minimal

An example minimal GCP install config is:

apiVersion: v1
baseDomain: example.com
metadata:
  name: example-cluster
platform:
  gcp:
    project: example-project
    region: us-east1
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

Custom machine pools

An example GCP install config with custom machine pools:

apiVersion: v1
baseDomain: example.com
compute:
- name: worker
  platform: 
    gcp:
      type: n2-standard-2
      zones:
      - us-central1-a
      - us-central1-c
  replicas: 3
controlPlane:
  name: master
  platform:
    gcp:
      type: n2-standard-4
      zones:
      - us-central1-a
      - us-central1-c
  replicas: 3
metadata:
  name: example-cluster
platform:
  gcp:
    projectID: openshift-dev-installer
    region: us-central1
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

Pre-existing Networks & Subnets

An example GCP install config utilizing an existing network and subnets:

apiVersion: v1
baseDomain: example.com
metadata:
  name: example-cluster
platform:
  gcp:
    projectID: example-project
    region: us-east1
    computeSubnet: example-worker-subnet
    controlPlaneSubnet: example-controlplane-subnet
    network: example-network
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...