vania-janet/multiturn-rag-retrieval-data huggingface dataset:
ID Name Number Type Router
1519999 vlan 1355 private bcr02a.dal10
1519898 vlan 1357 private bcr02a.dal10
1518787 vlan 1252 public fcr02a.dal10
1518888 vlan 1254 public fcr02a.dal10

If a public and private VLAN already exist, note the matching routers. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match. In the example output, any private VLAN can be used with any public VLAN because the routers all include 02a.dal10.
7. Create your standard cluster.

ibmcloud oc cluster create classic --zone <zone> --flavor <flavor> --hardware <shared_or_dedicated> --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID> --workers <number> [--operating-system (REDHAT_7_64|REDHAT_8_64)] --name <cluster_name> --version <major.minor.patch>_openshift --public-service-endpoint [--private-service-endpoint] [--pod-subnet] [--service-subnet] [--disable-disk-encrypt] [--sm-group GROUP] [--sm-instance INSTANCE]

--zone <zone>
: Specify the IBM Cloud zone ID that you chose earlier and that you want to use to create your cluster.

--flavor <flavor>
: Specify the flavor for your worker node that you chose earlier.

--hardware <shared_or_dedicated>
: Specify with the level of hardware isolation for your worker node. Use dedicated to have available physical resources dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared.
Optionally set up [automated deployments with the API](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_api_install). As you work with your cluster, refer to the [IBM Cloud Kubernetes Service API reference](https://containers.cloud.ibm.com/global/swagger-global-api//) and [Community Kubernetes API reference](https://kubernetes.io/docs/reference/).



3. Cluster deployment:



1. [Create the cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters).
2. After the cluster is ready, [access your cluster](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster).
3. Spread your cluster across availability zones by [adding worker nodes and zones to your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workers).



4. User access:



1. Make sure that your authorized cluster users can now also access the cluster by planning your user access strategy.
2. [Pick the correct access policy and role for your users](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewaccess_roles).
3. [Understand access roles for individual or groups of users in IBM Cloud IAM](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewiam_individuals_groups).
4. [Choose the scope of user access to cluster instances, Red Hat OpenShift project, or resource groups](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewresource_groups).
5.
The zone name for the default worker pool. To see available zones, run ibmcloud oc zones --provider vpc-gen2.



3. In the CLI, navigate to your Terraform directory.

cd <terraform_directory>
4. Run the commands to initialize and plan your Terraform actions. Review the plan output to make sure the correct actions are performed.

terraform init

terraform plan
5. Apply the Terraform files to create the cluster. Then, navigate to the IBM Cloud console to check that the cluster is provisioning.

terraform apply
ibmcloud oc cluster create classic --name cloud_pak_cluster --version 4.11_openshift --zone dal10 --flavor b3c.4x16 --hardware dedicated --workers 3 --entitlement cloud_pak --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID> [--operating-system (REDHAT_7_64|REDHAT_8_64)]

For a complete list of available RHEL versions and which cluster versions they are compatible with, see [Available Red Hat OpenShift versions](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsopenshift_versions_available).

ibmcloud oc cluster create classic --name my_cluster --zone dal10 --flavor b3c.4x16 --version 4.9.28_openshift --operating-system REDHAT_8_64

For a classic multizone cluster, after you created the cluster in a [multizone metro](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-mz), [add zones](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersadd_zone):

ibmcloud oc zone add classic --zone <zone> --cluster <cluster_name_or_ID> --worker-pool <pool_name> --private-vlan <private_VLAN_ID> --public-vlan <public_VLAN_ID>





 Creating a single-zone classic cluster with Terraform 

Terraform on IBM Cloud enables predictable and consistent provisioning of IBM Cloud platform infrastructure and resources, including classic clusters. To create a classic cluster with Terraform, you first create a Terraform configuration file that declares the type of cluster resource you want to create. Then, you apply the Terraform configuration file.
Each worker node in the worker pool then is encrypted by the KMS provider that you manage. Each worker pool in your cluster can use the same KMS instance and root key, the same KMS instance with different root keys, or different instances.



* Creating a cluster: Only the default worker pool's nodes are encrypted. After you create the cluster, if you create more worker pools, you must enable encryption in each pool separately. For more information, see [Creating clusters](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2&interface=ui) or the [CLI reference documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_cluster-create-vpc-gen2).



* UI: From the [cluster creation page](https://cloud.ibm.com/kubernetes/catalog/create), make sure to include the KMS instance, Root key and optionally, if the KMS instance resides in a different account, the KMS account fields.
* CLI: Make sure to include the --kms-instance-id, --crk fields and also the optional--kms-account-id field if the KMS instance resides in an account different from the clusters account, such as in the following VPC example.

ibmcloud oc cluster create vpc-gen2 --name <cluster_name> --zone <vpc_zone> --vpc-id <vpc_ID> --subnet-id <vpc_subnet> --flavor <flavor> --workers <number_of_workers_per_zone> --kms-account-id <kms_account_ID> --kms-instance-id <kms_instance_ID> --crk <kms_root_key_ID>
ibmcloud ks cluster create classic [--hardware HARDWARE] --zone ZONE --flavor FLAVOR --name NAME [--operating-system UBUNTU_20_64|UBUNTU_18_64] [--version MAJOR.MINOR.PATCH] [--no-subnet] [--sm-group GROUP] [--sm-instance INSTANCE] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--private-only] [--gateway-enabled] [--private-service-endpoint] [--public-service-endpoint] [--workers WORKER] [--disable-disk-encrypt] [--pod-subnet SUBNET] [--service-subnet SUBNET] [--skip-advance-permissions-check] [-q]

To create a VPC cluster, use the [ibmcloud ks cluster create vpc-gen2 command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_cluster-create-vpc-gen2) instead.

Minimum required permissions
: Administrator platform access role for IBM Cloud Kubernetes Service at the account level
: Administrator platform access role for IBM Cloud Container Registry at the account level
: Super User role for IBM Cloud infrastructure

Command options:

--hardware HARDWARE
: The level of hardware isolation for your worker node. Use dedicated so that available physical resources are dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. For bare metal flavors, specify dedicated.

--zone ZONE
: The zone where you want to create the cluster. This value is required for standard clusters.
: Review available [classic](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) or [VPC](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-vpc) zones.
You can start with one zone, and then add the two other zones to your cluster later for high availability. To see the zone names for your location, run ibmcloud sat location get --location <location_name_or_ID> and look for the Host Zones field. If you don't specify a zone name, the zone name that is alphabetically first is chosen.

The following example creates a Satellite cluster with the REDHAT_8_64 operating system.

ibmcloud sat cluster create satellite --name mysatcluster --location my-location --pull-secret <secret> --operating-system REDHAT_8_64 --version 4.11_openshift -hl cpu=4 -hl memory=16265432 --workers 3 --zone myzone1

The following example creates a Satellite cluster running Red Hat OpenShift on IBM Cloud version 4.9.23_openshift and RHCOS hosts.

ibmcloud sat cluster create satellite --name mysatcluster-coreos --location my-location --version 4.9.23_openshift --operating-system RHCOS --workers 6





 ibmcloud oc cluster master satellite-service-endpoint allowlist add 

Satellite

Add a subnet to a Satellite cluster's service endpoint allowlist. Authorized requests to the cluster master that originate from the subnet are permitted through the Satellite service endpoint. The allowlist must be [enabled](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicluster-master-sat-allowlist-enable) for the restrictions to apply. This command can be used only with Satellite clusters that are CoreOS-enabled.

ibmcloud oc cluster master satellite-service-endpoint allowlist add --cluster CLUSTER --subnet SUBNET [--subnet SUBNET ...] [-q]

Minimum required permissions: IBM Cloud IAM Editor platform access role for Satellite.

Command options:

-c, --cluster CLUSTER
: Required. The name or ID of the cluster.

--subnet SUBNET
To get a secret group ID, see the [Secrets Manager CLI reference](https://cloud.ibm.com/docs/secrets-manager-cli-plugin?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-cli-secret-groups-command).

--sm-instance INSTANCE
: The CRN of the Secrets Manager instance. To get the CRN of an instance, run [ibmcloud oc ingress instance ls --cluster CLUSTER](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_ingress_instance_ls).

--workers COUNT
: Required when --host-label is specified or if you want to [automatically assign hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-assigning-hostshost-autoassign). Specify the number of worker nodes per zone in the default worker pool. The default value is 0. If you do not specify a value, workers do not automatically assign and you must instead [manually assign](https://cloud.ibm.com/docs/satellite?topic=satellite-assigning-hostshost-assign-manual) workers to your Satellite resources.

--zone ZONE
: Optional. The name of the zone to create the default worker pool in. You can start with one zone, and then add the two other zones to your cluster later for high availability. To see the zone names for your location, run ibmcloud sat location get --location <location_name_or_ID> and look for the Host Zones field. If you don't specify a zone name, the zone name that is alphabetically first is chosen.

The following example creates a Satellite cluster with the REDHAT_8_64 operating system.
Learning path for administrators 

Following a curated learning path through Red Hat® OpenShift® on IBM Cloud® to create a cluster, manage the cluster's resources and lifecycle, and use the powerful tools of Red Hat OpenShift on IBM Cloud to secure, manage, and monitor your cluster workloads.



 Plan your environment 

Start by designing a cluster for maximum availability and capacity for your workloads.



1. Environment strategy:



1. Define your [Kubernetes strategy](https://cloud.ibm.com/docs/openshift?topic=openshift-strategy) for the cluster, such as deciding how many clusters to create for your environments.
2. Plan your [security strategy](https://cloud.ibm.com/docs/openshift?topic=openshift-securitynetwork_segmentation), such as ensuring network segmentation and workload isolation.



2. Cluster setup: After you plan your environment, plan the setup for a specific cluster.



1. Choose a [supported infrastructure provider](https://cloud.ibm.com/docs/openshift?topic=openshift-infrastructure_providers).
2. Plan your [cluster network setup](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_clusters).
3. Plan your cluster for [high availability](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clusters).
4. Plan your [worker node setup](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodes).





Looking for serverless? Try [Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started).





 Create a cluster 

Create a cluster with infrastructure, network, and availability setups that are customized to your use case and cloud environment.



1.
: [Administrator platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for IBM Cloud Kubernetes Service at the account level.
: [Writer or Manager service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for IBM Cloud Kubernetes Service.
: [Administrator platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for IBM Cloud Container Registry at the account level.

Command options:

--name NAME
: Required: The name for the cluster. The name must start with a letter, can contain letters, numbers, periods (.), and hyphen (-), and must be 35 characters or fewer. Use a name that is unique across regions. The cluster name and the region in which the cluster is deployed form the fully qualified domain name for the Ingress subdomain. To ensure that the Ingress subdomain is unique within a region, the cluster name might be truncated and appended with a random value within the Ingress domain name.

--zone ZONE
: Required: Select a zone to deploy the initial cluster worker pool in. If you create the cluster in a multizone metro, you can add a zone to the worker pool later. To list available VPC zones, run ibmcloud oc zone ls --provider vpc-gen2.

When you select a zone that is located outside your country, keep in mind that you might require legal authorization before data can be physically stored in a foreign country.

--vpc-id VPC_ID
: Required: The ID of the VPC in which to create the cluster and worker nodes. To list available IDs, run ibmcloud oc vpcs.

--subnet-id VPC_SUBNET_ID
: Required: The VPC subnet to assign the cluster. To list available VPC subnets, run ibmcloud oc subnets --provider vpc-gen2.
For more information, see [Creating Red Hat OpenShift clusters in Satellite](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusterssatcluster-create-cli).

ibmcloud oc cluster create satellite --location LOCATION --name NAME --version VERSION [--enable-config-admin] [--host-label LABEL ...] [--infrastructure-topology TOPOLOGY] [--operating-system SYSTEM] [--pod-subnet SUBNET] [--pod-network-interface-selection METHOD] [--pull-secret SECRET] [-q] [--service-subnet SUBNET] [--sm-group GROUP] [--sm-instance INSTANCE] [--workers COUNT] [--zone ZONE]

Minimum required permissions: IBM Cloud IAM Administrator platform access role for Satellite.

Command options:

--location LOCATION
: Required. Enter the ID or name of the location where you want to create the cluster. To retrieve the location ID or name, run ibmcloud sat location ls.

--name NAME
: Required. Enter a name for your cluster. The name must start with a letter, can contain letters, numbers, and hyphen (-), and must be 35 characters or fewer.

--version VERSION
: Required. Enter the Red Hat OpenShift on IBM Cloud version that you want to run in your cluster. For a list of supported versions, run ibmcloud oc versions.

--enable-admin-config
: Optional. Grant the Satellite Config service accounts access to the cluster admin role to manage Kubernetes resources. If you don't grant Satellite Config access, you can't later use the Satellite Config functionality to view or deploy Kubernetes resources for your clusters. If you want to enable access later, you can [create custom RBAC roles for Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfigcustom-access-cluster-wide).
: Optional: Do not show the message of the day or update reminders.

--yaml
: Optional: Prints the command output in YAML format.



 Example cluster config command 

ibmcloud oc cluster config --cluster my_cluster







 ibmcloud oc cluster create classic 

Classic infrastructure

Create a cluster with worker nodes on classic infrastructure.

Red Hat OpenShift on IBM Cloud clusters are created with a public only or both a public and private service endpoint. Public service endpoints can't be disabled, and therefore, you can't convert a public Red Hat OpenShift cluster to a private one. If you want your cluster to remain private, see [Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_vpc_basicsvpc-pgw).

ibmcloud oc cluster create classic [--hardware HARDWARE] --zone ZONE --flavor FLAVOR --name NAME [--operating-system (REDHAT_7_64|REDHAT_8_64)] [--version MAJOR.MINOR.PATCH] [--no-subnet] [--sm-group GROUP] [--sm-instance INSTANCE] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--private-service-endpoint] [--public-service-endpoint] --workers WORKER [--disable-disk-encrypt] [--pod-subnet SUBNET] [--service-subnet SUBNET] [--skip-advance-permissions-check] [--entitlement cloud_pak]

To create a VPC cluster, use the [ibmcloud oc cluster create vpc-gen2 command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_cluster-create-vpc-gen2) instead.

Minimum required permissions
: Administrator platform access role for IBM Cloud Kubernetes Service at the account level
: Administrator platform access role for IBM Cloud Container Registry at the account level
: Super User role for IBM Cloud infrastructure
To list available KMS instances, run ibmcloud oc kms instance ls. If you include this option, you must also include the --crk option. Before you can use KMS encryption, you must create a KMS instance and set up the required service authorization in IAM. See [Managing encryption](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionworker-encryption) for the worker nodes in your cluster.

--crk <root_key>
: Optional: Include the ID of the root key in the KMS instance to use to encrypt the local disk on the worker nodes in the default worker pool. To list available root keys, run ibmcloud oc kms crk ls --instance-id. If you include this option, you must also include the --kms-instance option. Before you can use KMS encryption, you must create a KMS instance and set up the required service authorization in IAM. See [Managing encryption](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionworker-encryption) for the worker nodes in your cluster.

--secondary-storage STORAGE
: Optional. The storage option for the flavor. For example, 900gb.5iops-tier. When you add a secondary disk, that disk is used for the container runtime, while the primary disk is used for the operating system. To view the storage options for a flavor, run the ibmcloud oc flavor get --flavor FLAVOR --zone ZONE --provider vpc-gen2 command. To view a list of VPC worker node flavors, see [VPC flavors](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-flavors&interface=ui)
5. Verify that the creation of the cluster was requested. It can take a few minutes for the worker node machines to be ordered, and for the cluster to be set up and provisioned in your account.

ibmcloud oc cluster ls
See the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_pool_create) for command details.

ibmcloud oc worker-pool create classic --name <worker_pool_name> --cluster <cluster_name_or_ID> --flavor <flavor> --size-per-zone <number_of_workers_per_zone>

For VPC clusters. See the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_worker_pool_create_vpc_gen2) for command details.

ibmcloud oc worker-pool create vpc-gen2 --name <worker_pool_name> --cluster <cluster_name_or_ID> --flavor <flavor> --size-per-zone <number_of_workers_per_zone>
3. Verify that the worker pool is created.

ibmcloud oc worker-pool ls --cluster <cluster_name_or_ID>
4. Add a zone to your worker pool. When you add a zone, the number of worker nodes you specified with the --size-per-zone option are added to the zone. These worker nodes run the RHEL 8 operating system.



* [Adding a zone to a worker pool in a classic cluster](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_zone)
* [Adding a zone to a worker pool in a VPC cluster](https://cloud.ibm.com/docs/containers?topic=containers-add_workersvpc_add_zone)



5. Verify that worker nodes are available in your new worker pool. In the output, check the number in the Workers column for the worker pool.

ibmcloud oc worker-pool ls --cluster <cluster_name_or-ID>
6.
ibmcloud ks cluster create vpc-gen2 --name <cluster-name> --zone <zone> --vpc-id <vpc-id> --subnet-id <subnet-id> --cluster-security-group cluster --cluster-security-group <group-id-1> --cluster-security-group <group-id-2> --cluster-security-group <group-id-3>

The following security groups are applied:



* kube-<cluster-id>
* Up to four of your own additional security groups, for a maximum of five total security groups.







 If you only want your own security groups 

Your own security groups

When you create the cluster, specify up to five security groups that you own. You must include a separate --cluster-security-group option for each individual security group you want to add.

Example command to create a VPC cluster with only your own security groups:

ibmcloud ks cluster create vpc-gen2 --name <cluster-name> --zone <zone> --vpc-id <vpc-id> --subnet-id <subnet-id> --cluster-security-group <group-id-1> --cluster-security-group <group-id-2> --cluster-security-group <group-id-3>

Up to five of your own security groups are applied to the workers on the cluster.







 Adding security groups to worker pools at worker pool create time 

By default, the security groups applied to a worker pool are the same security groups that are indicated at cluster create time. However, you can specify additional security groups to apply to a worker pool. If you apply additional security groups to the worker pool, then the security group applied to the workers on the cluster is a combination of the [security groups applied at cluster create](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=uivpc-sg-cluster) and the security groups applied to the worker pool.

A maximum of five security groups can be applied to a worker, including the security groups applied by default.