OpenShift cluster(s)🔗

You can configure one or more OpenShift clusters that will be layed down on the specified infrastructure, or which already exist.

Dependent on the cloud platform on which the OpenShift cluster will be provisioned, different installation methods apply. For IBM Cloud, Terraform is used, whereas for vSphere the IPI installer is used. On AWS (ROSA), the rosa CLI is used to create and modify ROSA clusters. Each of the different platforms have slightly different properties for the openshift objects.

openshift🔗

For OpenShift, there are 5 flavours:

• Existing OpenShift
• OpenShift on IBM Cloud
• OpenShift on AWS - ROSA
• OpenShift on AWS - self-managed
• OpenShift on Microsoft Azure (ARO)
• OpenShift on vSphere

Every OpenShift cluster definition of a few mandatory properties that control which version of OpenShift is installed, the number and flavour of control plane and compute nodes and the underlying infrastructure, dependent on the cloud platform on which it is provisioned. Storage is a mandatory element for every openshift definition. For a list of supported storage types per cloud platform, refer to Supported storage types.

Additionally, one can configure Upstream DNS Servers and OpenShift logging.

The Multicloud Object Gateway (MCG) supports access to s3-compatible object storage via an underpinning block/file storage class, through the Noobaa operator. Some Cloud Pak for Data services such as Watson Assistant need object storage to run. MCG does not need to be installed if OpenShift Data Foundation (fka OCS) is also installed as the operator includes Noobaa.

OpenShift on IBM Cloud (ROKS)🔗

VPC-based OpenShift cluster on IBM Cloud, using the Red Hat OpenShift Kubernetes Services (ROKS).

openshift:
- name: sample
  managed: True
  ocp_version: 4.8
  compute_flavour: bx2.16x64
  compute_nodes: 3
  cloud_native_toolkit: False
  oadp: False
  infrastructure:
    type: vpc
    vpc_name: sample
    subnets:
    - sample-subnet-zone-1
    - sample-subnet-zone-2
    - sample-subnet-zone-3
    cos_name: sample-cos
    private_only: False
    deny_node_ports: False
  upstream_dns:
  - name: sample-dns
     zones:
     - example.com
     dns_servers:
     - 172.31.2.73:53
  mcg:
    install: True
    storage_type: storage-class
    storage_class: managed-nfs-storage
  openshift_storage:
  - storage_name: nfs-storage
    storage_type: nfs
    nfs_server_name: sample-nfs
  - storage_name: ocs-storage
    storage_type: ocs
    ocs_storage_label: ocs
    ocs_storage_size_gb: 500
    ocs_version: 4.8.0
  - storage_name: pwx-storage
    storage_type: pwx 
    pwx_etcd_location: {{ ibm_cloud_region }}
    pwx_storage_size_gb: 200 
    pwx_storage_iops: 10 
    pwx_storage_profile: "10iops-tier"
    stork_version: 2.6.2
    portworx_version: 2.7.2

Property explanation OpenShift clusters on IBM Cloud (ROKS)🔗

The managed attribute indicates whether the ROKS cluster is managed by the Cloud Pak Deployer. If set to False, the deployer will not provision the ROKS cluster but expects it to already be available in the VPC. You can still use the deployer to create the VPC, the subnets, NFS servers and other infrastructure, but first run it without an openshift element. Once the VPC has been created, manually create an OpenShift cluster in the VPC and then add the openshift element with managed set to False. If you intend to use OpenShift Container Storage, you must also activate the add-on and create the OcsCluster custom resource.

openshift_storage[] - OpenShift storage definitions🔗

OpenShift on vSphere🔗

openshift:
- name: sample
  domain_name: example.com
  vsphere_name: sample
  ocp_version: 4.8
  control_plane_nodes: 3
  control_plane_vm_definition: control-plane
  compute_nodes: 3
  compute_vm_definition: compute
  api_vip: 10.99.92.51
  ingress_vip: 10.99.92.52
  cloud_native_toolkit: False
  oadp: False
  infrastructure:
    openshift_cluster_network_cidr: 10.128.0.0/14
  upstream_dns:
  - name: sample-dns
     zones:
     - example.com
     dns_servers:
     - 172.31.2.73:53
  mcg:
    install: True
    storage_type: storage-class
    storage_class: thin
  openshift_storage:
  - storage_name: nfs-storage
    storage_type: nfs
    nfs_server_name: sample-nfs
  - storage_name: ocs-storage
    storage_type: ocs
    ocs_storage_label: ocs
    ocs_storage_size_gb: 512
    ocs_dynamic_storage_class: thin

Property explanation OpenShift clusters on vSphere🔗

openshift_storage[] - OpenShift storage definitions🔗

OpenShift on AWS - self-managed🔗

nfs_server:
- name: sample-elastic
  infrastructure:
    aws_region: eu-west-1

openshift:
- name: sample
  ocp_version: 4.10.34
  domain_name: cp-deployer.eu
  compute_flavour: m5.4xlarge
  compute_nodes: 3
  cloud_native_toolkit: False
  oadp: False
  infrastructure:
    type: self-managed
    aws_region: eu-central-1
    multi_zone: True
    credentials_mode: Manual
    private_only: True
    machine_cidr: 10.2.1.0/24
    openshift_cluster_network_cidr: 10.128.0.0/14
    subnet_ids:
    - subnet-06bbef28f585a0dd3
    - subnet-0ea5ac344c0fbadf5
    hosted_zone_id: Z08291873MCIC4TMIK4UP
    ami_id: ami-09249dd86b1933dd5
  mcg:
    install: True
    storage_type: storage-class
    storage_class: gp3-csi
  openshift_storage:
  - storage_name: ocs-storage
    storage_type: ocs
    ocs_storage_label: ocs
    ocs_storage_size_gb: 512
  - storage_name: sample-elastic
    storage_type: aws-elastic

Property explanation OpenShift clusters on AWS (self-managed)🔗

When deploying the OpenShift cluster within an existing VPC, you must specify the machine_cidr that covers all subnets and the subnet IDs within the VPC. For example:

    machine_cidr: 10.243.0.0/24
    subnets_ids:
    - subnet-0e63f662bb1842e8a
    - subnet-0673351cd49877269
    - subnet-00b007a7c2677cdbc
    - subnet-02b676f92c83f4422
    - subnet-0f1b03a02973508ed
    - subnet-027ca7cc695ce8515

openshift_storage[] - OpenShift storage definitions🔗

OpenShift on AWS - ROSA🔗

nfs_server:
- name: sample-elastic
  infrastructure:
    aws_region: eu-west-1

openshift:
- name: sample
  ocp_version: 4.10.34
  compute_flavour: m5.4xlarge
  compute_nodes: 3
  cloud_native_toolkit: False
  oadp: False
  infrastructure:
    type: rosa
    aws_region: eu-central-1
    multi_zone: True
    use_sts: False
    credentials_mode: Manual
  upstream_dns:
  - name: sample-dns
     zones:
     - example.com
     dns_servers:
     - 172.31.2.73:53
  mcg:
    install: True
    storage_type: storage-class
    storage_class: gp3-csi
  openshift_storage:
  - storage_name: ocs-storage
    storage_type: ocs
    ocs_storage_label: ocs
    ocs_storage_size_gb: 512
  - storage_name: sample-elastic
    storage_type: aws-elastic

Property explanation OpenShift clusters on AWS (ROSA)🔗

When deploying the OpenShift cluster within an existing VPC, you must specify the machine_cidr that covers all subnets and the subnet IDs within the VPC. For example:

    machine_cidr: 10.243.0.0/24
    subnets_ids:
    - subnet-0e63f662bb1842e8a
    - subnet-0673351cd49877269
    - subnet-00b007a7c2677cdbc
    - subnet-02b676f92c83f4422
    - subnet-0f1b03a02973508ed
    - subnet-027ca7cc695ce8515

openshift_storage[] - OpenShift storage definitions🔗

OpenShift on Microsoft Azure (ARO)🔗

openshift:
- name: sample
  azure_name: sample
  domain_name: example.com
  ocp_version: 4.10.54
  cloud_native_toolkit: False
  oadp: False
  network:
    pod_cidr: "10.128.0.0/14"
    service_cidr: "172.30.0.0/16"
  openshift_storage:
  - storage_name: ocs-storage
    storage_type: ocs
    ocs_storage_label: ocs
    ocs_storage_size_gb: 512
    ocs_dynamic_storage_class: managed-premium

Property explanation for OpenShift cluster on Microsoft Azure (ARO)🔗

openshift_storage[] - OpenShift storage definitions🔗

Existing OpenShift🔗

When using the Cloud Pak Deployer on an existing OpenShift cluster, the scripts assume that the cluster is already operational and that any storage classes have been pre-created. The deployer accesses the cluster through a vault secret with the kubeconfig information; the name of the secret is <name>-kubeconfig.

openshift:
- name: sample
  ocp_version: 4.8
  cluster_name: sample
  domain_name: example.com
  cloud_native_toolkit: False
  oadp: False
  infrastructure:
    type: standard
    processor_architecture: amd64
  upstream_dns:
  - name: sample-dns
     zones:
     - example.com
     dns_servers:
     - 172.31.2.73:53
  gpu:
    install: False
  mcg:
    install: True
    storage_type: storage-class
    storage_class: managed-nfs-storage
  openshift_storage:
  - storage_name: nfs-storage
    storage_type: nfs
    # ocp_storage_class_file: managed-nfs-storage
    # ocp_storage_class_block: managed-nfs-storage

Property explanation for existing OpenShift clusters🔗

infastructure.type - Type of infrastructure🔗

When deploying on existing OpenShift, the underlying infrastructure can pose some restrictions on capabilities available. For example, Red Hat OpenShift on IBM Cloud (aka ROKS) does not include the Machine Config Operator and ROSA on AWS does not allow to set labels for Machine Config Pools. This means that node settings required for Cloud Pak for Data must be applied in a non-standard manner.

The following values are allowed for infrastructure.type:

• detect (default): The deployer will attempt to detect the underlying cloud infrastructure. This is done by retrieving the existing storage classes and then inferring the cloud type.
• standard: The deployer will assume a standard OpenShift cluster with no further restrictions. This is the fallback value for detect if the underlying infra cannot be detected.
• aws-self-managed: A self-managed OpenShift cluster on AWS. No restrictions.
• aws-rosa: Managed Red Hat OpenShift on AWS. Some restrictions with regards to Machine Config Pools apply.
• azure-aro: Managed Red Hat OpenShift on Azure. No known restrictions.
• vsphere: OpenShift on vSphere. No known restrictions.

openshift_storage[] - OpenShift storage definitions🔗

Supported storage types🔗

An openshift definition always includes the type(s) of storage that it will provide. When the OpenShift cluster is provisioned by the deployer, the necessary infrastructure and storage class(es) are also configured. In case an existing OpenShift cluster is referenced by the configuration, the storage classes are expected to exist already.

The table below indicates which storage classes are supported by the Cloud Pak Deployer per cloud infrastructure.

• (1) An existing NFS server can be specified so that the deployer configures the managed-nfs-storage storage class. The deployer will not provision or change the NFS server itself.
• (2) If you specify a custom storage type, you must specify the storage class to be used for block (RWO) and file (RWX) storage.
• (3) Specifying this storage type means that Elastic File Storage (EFS) and Elastic Block Storage (EBS) storage classes will be used. For EFS, an nfs_server object is required to define the "file server" storage on AWS.