vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Configuring VPC subnets 

Virtual Private Cloud

Change the pool of available portable public or private IP addresses by adding subnets to your Red Hat® OpenShift® on IBM Cloud® VPC cluster.

The content on this page is specific to VPC clusters. For information about classic clusters, see [Configuring subnets and IP addresses for classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-subnets).



 Overview of VPC networking in Red Hat OpenShift on IBM Cloud 

Understand the basic concepts of VPC networking in Red Hat OpenShift on IBM Cloud clusters.



 Subnets 

Before you create a VPC cluster for the first time, you must [create a VPC subnet](https://cloud.ibm.com/vpc/provision/network) in each zone where you want to deploy worker nodes. A VPC subnet is a specified private IP address range (CIDR block) and configures a group of worker nodes and pods as if they are attached to the same physical wire.

When you create a cluster, you can specify only one existing VPC subnet for each zone. Each worker node that you add in a cluster is deployed with a private IP address from the VPC subnet in that zone. After the worker node is provisioned, the worker node IP address persists after a reboot operation, but the worker node IP address changes after replace and update operations.

Do not delete the subnets that you attach to your cluster during cluster creation or when you add worker nodes in a zone. If you delete a VPC subnet that your cluster used, any load balancers that use IP addresses from the subnet might experience issues, and you might be unable to create new load balancers.



 How many IP addresses do I need for my VPC subnet? 

When you [create your VPC subnet](https://cloud.ibm.com/vpc/provision/network), make sure to create a subnet with enough IP addresses for your cluster, such as 256. You can't change the number of IP addresses that a VPC subnet has later.

Keep in mind the following IP address reservations.
OpenVPN Operator image v1.0.12 v1.1.0 Updated image for [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971). 
 Red Hat OpenShift on IBM Cloud toolkit 4.4.0+20201210 4.4.0+20210112 See the [Red Hat OpenShift on IBM Cloud toolkit release notes](https://github.com/openshift/ibm-roks-toolkit/releases/tag/v4.4.0+20210112). 







 Change log for worker node fix pack 4.4.31_1530_openshift, released 18 January 2021 

The following table shows the changes that are in the worker node fix pack 4.4.31_1530_openshift. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 4.4.31_1528_openshift

 Component Previous Current Description 

 RHEL 7 Packages N/A N/A Updated worker node image with package updates. 







 Change log for master fix pack 4.4.31_1529_openshift, released 6 January 2021 

The following table shows the changes that are in the master fix pack patch update 4.4.31_1529_openshift. Master patch updates are applied automatically.



Changes since version 4.4.29_1527_openshift

 Component Previous Current Description 

 IBM Calico extension 538 556 Updated image to include the ip command. 
 IBM Cloud Block Storage driver and plug-in 1.17.2 v2.0.0 Updated to use the universal base image (UBI), to use Go version 1.15.5, to run with a least privileged security context, and to improve logging. Updated image to implement additional IBM security controls. 
 IBM Cloud Controller Manager v1.17.15-1 v1.17.16-1 Updated to support the Kubernetes 1.17.16 release.
-c, --cluster CLUSTER
: Required: The name or ID of the cluster where the worker pool exists.

-p, --worker-pool WORKER_POOL
: Required: The name of the worker node pool that you want to see zones for.

--output json
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.



 Example worker-pool zones command 

ibmcloud oc worker-pool zones --cluster my_cluster --worker-pool pool1









 zone commands 



 ibmcloud oc zone add classic 

Classic infrastructure

After you create a classic cluster or worker pool, you can add a zone. When you add a zone, worker nodes are added to the new zone to match the number of workers per zone that you specified for the worker pool. You can add more than one zone only if your cluster is in a multizone metro.

To add a zone to worker pools in a VPC cluster, use the [ibmcloud oc zone add vpc-gen2 command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_zone-add-vpc-gen2).

ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER [--worker-pool WORKER_POOL] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--output json] [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

--zone ZONE
: Required: The zone that you want to add. The zone must be a [multizone-capable zone](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-mz) within the cluster's region.

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

-p, --worker-pool WORKER_POOL
curl -X GET "https://containers.cloud.ibm.com/v2/storage/getAttachment?cluster=<cluster_ID>&worker=<worker_ID>&volumeAttachmentID=<volume_attachment_ID>" --header "X-Auth-Resource-Group-ID: <resource_group_ID>" --header "Authorization: <IAM_token>"

IAM_token
: The IAM OAuth token for your current session. You can retrieve this value by running ibmcloud iam oauth-tokens.

cluster_ID
: The unique ID that is assigned to your cluster. You can retrieve this ID by running ibmcloud ks cluster ls.

worker_ID
: The unique ID that is assigned to the worker node where you want to attach your volume. You can retrieve this value by running ibmcloud ks worker ls -c <cluster_name>.

volume_ID
: The unique ID that is assigned to your Block Storage for Classic volume. You can retrieve a list of your Block Storage for Classic volumes by running ibmcloud is volumes.

volume_attachment_ID
: The unique ID that is assigned to your volume attachment. You can retrieve this ID by running ibmcloud is volume <volume_ID>.









 VPC: Attaching raw Block Storage for VPC to VPC worker nodes by using the CLI 

You can use the Kubernetes Service CLI to attach and detach raw, unformatted Block Storage for Classic to a worker node in your VPC cluster.

You can attach a volume to one worker node only. Make sure that the volume is in the same zone as the worker node for the attachment to succeed.

The instructions in this topic are available for VPC worker nodes only. If you want to attach raw, unformatted block storage to a classic worker node, you must install the [IBM Cloud Block Storage attacher plug-in](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesblock_storage_attacher).

Before you begin:

[Log in to your account. If applicable, target the appropriate resource group.
After a few minutes, you can check the Events section in the output of the following command to see activity on the Autorecovery deployment.

kubectl -n kube-system describe deployment ibm-worker-recovery
7. If you don't see activity on the Autorecovery deployment, you can check the Helm deployment by running the tests that are in the Autorecovery chart definition.

helm test ibm-worker-recovery -n kube-system





 Understanding the configmap components 

Review the following information on the individual components of health checks.



* name: The configuration name ibm-worker-recovery-checks is a constant and can't be changed.
* namespace: The kube-system namespace is a constant and can't be changed.
* checknode.json: Defines a Kubernetes API node check that checks whether each worker node is in the Ready state. The check for a specific worker node counts as a failure if the worker node is not in the Ready state. The check in the example YAML runs every 3 minutes. If it fails three consecutive times, the worker node is reloaded. This action is equivalent to running ibmcloud ks worker reload. The node check is enabled until you set the Enabled field to false or remove the check. Note that reloading is supported only for worker nodes on classic infrastructure.
* checkpod.json: Defines a Kubernetes API pod check that checks the total percentage of NotReady pods on a worker node based on the total pods that are assigned to that worker node. The check for a specific worker node counts as a failure if the total percentage of NotReady pods is greater than the defined PodFailureThresholdPercent. The check in the example YAML runs every 3 minutes. If it fails three consecutive times, the worker node is reloaded. This action is equivalent to running ibmcloud ks worker reload. For example, the default PodFailureThresholdPercent is 50%. If the percentage of NotReady pods is greater than 50% three consecutive times, the worker node is reloaded. The check runs on all namespaces by default.
(https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



To create an edge node worker pool,



1. [Create a worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_pool) that spans all zones in your cluster and has at least two workers per zone if you use NLBs or 3 or more workers per zone if you use ALBs. In the ibmcloud ks worker-pool create command, include the --label dedicated=edge option to label all worker nodes in the pool. All worker nodes in this pool, including any worker nodes that you add later, are labeled as edge nodes.

If you want to use an existing worker pool, the pool must span all zones in your cluster and have at least two worker nodes per zone. You can label the worker pool with dedicated=edge by using the [ibmcloud ks worker-pool label set command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_pool_label_set).

To ensure that ALB pods are always scheduled to edge worker nodes if they are present and not scheduled to non-edge worker nodes, you must create or use an existing worker pool that has at least three edge worker nodes per zone. During the update of an ALB pod, a new ALB pod rolls out to replace an existing ALB pod. However, ALB pods have anti-affinity rules that don't permit a pod to deploy to a worker node where another ALB pod already exists. If you have only two edge nodes per zone, both ALB pod replicas already exist on those edge nodes, so the new ALB pod must be scheduled on a non-edge worker node. When three edge nodes are present in a zone, the new ALB pod can be scheduled to the third edge node. Then, the old ALB pod is removed.
2. Verify that the worker pool and worker nodes have the dedicated=edge label.



* To check the worker pool
When you specify the number of workers (--size-per-zone) and flavor (--flavor), make sure to specify only the number and size of worker nodes that you are entitled to use in [IBM Passport Advantage](https://www.ibm.com/software/passportadvantage/index.html). After creation, your worker pool does not charge you the Red Hat OpenShift license fee for your entitled worker nodes. Do not exceed your entitlement. Keep in mind that your OpenShift Container Platform entitlements can be used with other cloud providers or in other environments. To avoid billing issues later, make sure that you use only what you are entitled to use. For example, you might have an entitlement for the OCP licenses for two worker nodes of 4 CPU and 16 GB memory, and you create this worker pool with two worker nodes of 4 CPU and 16 GB memory. You used your entire entitlement, and you can't use the same entitlement for other worker pools, cloud providers, or environments.

-q
: Optional: Do not show the message of the day or update reminders.

--output json
: Optional: Prints the command output in JSON format.



 Example worker-pool create classic command 

ibmcloud oc worker-pool create classic --name my_pool --cluster my_cluster --flavor b3c.4x16 --size-per-zone 6







 ibmcloud oc worker-pool create vpc-gen2 

Virtual Private Cloud

Add a worker pool to a VPC cluster. No worker nodes are created until you [add zones](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_zone-add-vpc-gen2) to the worker pool.
kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7 169.xx.xxx.xxx 10.xxx.xx.xxx u3c.2x4.encrypted normal Ready dal10 1.26.6_1526

Every worker node is assigned a unique worker node ID and domain name that must not be changed manually after the cluster is created. If you change the ID or domain name, the Kubernetes master cannot manage your cluster.
10. Optional: If you created your cluster in a [multizone metro location](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz), you can [spread the default worker pool across zones](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_zone) to increase the cluster's availability.
11. After your cluster is created, you can [begin working with your cluster by configuring your CLI session](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster).



Your cluster is ready for your workloads! You might also want to [add a tag to your cluster](https://cloud.ibm.com/docs/containers?topic=containers-add_workerscluster_tags), such as the team or billing department that uses the cluster, to help manage IBM Cloud resources. For more ideas of what to do with your cluster, review the [Next steps](https://cloud.ibm.com/docs/containers?topic=containers-clustersnext_steps).





 Example commands to create classic clusters 

Classic cluster, shared virtual machine

ibmcloud ks cluster create classic --name my_cluster --zone dal10 --flavor b3c.4x16 --hardware shared --workers 3 --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID>

Classic cluster, bare metal
You can use worker pools to spread worker nodes evenly across zones and build a balanced cluster. Balanced clusters are more available and resilient to failures. If a worker node is removed from a zone, you can rebalance the worker pool and automatically provision new worker nodes to that zone. Worker pools are also used to install Kubernetes version updates to all your worker nodes.

If you created clusters before multizone clusters became available, your worker nodes are still stand-alone and not automatically grouped into worker pools. You must update these clusters to use worker pools. If not updated, you can't change your single zone cluster to a multizone cluster.

Review the following image to see how your cluster setup changes when you move from stand-alone worker nodes to worker pools.

Zoom

![Update your cluster from stand-alone worker nodes to worker pools](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_cluster_migrate.png)

Figure 1. Update your cluster from stand-alone worker nodes to worker pools

Before you begin:



* Ensure that you have the [Operator or Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the cluster.
* [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



To update stand-alone worker nodes to worker pools:



1. List existing stand-alone worker nodes in your cluster and note the ID, the Machine Type, and Private IP.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>
2. Create a worker pool and decide on the flavor and the number of worker nodes that you want to add to the pool.
Unsupported version: The version is unsupported. IBM only provides support to upgrade to a supported release. The version is unsupported. Unsupported clusters are not provided with security and patch updates and are not supported by IBM Cloud Support. Although your cluster and apps might continue to run for a time, you can no longer create, reload, or take other corrective actions on your cluster master or worker nodes when an issue occurs. You can still delete the cluster or worker nodes, or update the cluster to the next version. Review the potential impacts and immediately [update the cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-updateupdate) to continue receiving important security updates and support. If the cluster master runs two or more versions behind the oldest supported version, you can no longer apply updates and must delete the cluster and create a new one.
5. Archived: The version is unsupported with no upgrade path. IBM provides no support. IBM reserves the right to shut down the control planes for such clusters.



IBM provides bi-weekly worker node fix packs. IBM's goal is to remediate detected, legitimate vulnerabilities within a timeframe appropriate for the risks they represent. To ensure the quality and stability of the release, fix packs might be delayed.

For Red Hat OpenShift, fix packs are applied to the latest minor release and patch for the targeted operating system. - For RHEL8 that is 8.7. - For RHEL7 (deprecated) that is 7.9.

To keep your nodes secure, you must install worker node fix packs as soon as possible. You can subscribe to notifications to be alerted when a new update is available.





 Archive 

Unsupported clusters are not provided with security and patch updates and are not supported by IBM Cloud Support. Although your cluster and apps might continue to run for a time, you can no longer create, reload, or take other corrective actions on your cluster master or worker nodes when an issue occurs. You can still delete the cluster or worker nodes, or update the cluster to the next version.
If multiple app instances are deployed in the cluster, the router sends the requests between the app pods.
4. When the app returns a response packet, it uses the IP address of the worker node where the router that forwarded the client request exists. The router then sends the response packet through the load balancer service to the client.







 Traffic flow in a classic multizone cluster 

The following diagram shows how a router directs network traffic from the internet to an app in a multizone, classic cluster.

Zoom

![Expose an app in a multizone Red Hat OpenShift cluster by using a router](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/roks-router-multi.png)

Figure 1. Expose an app in a multizone cluster by using a router



1. A request to your app uses the route hostname that you set up for your app.
2. A DNS service resolves the route subdomain to the portable public IP address of a router service that was reported as healthy by the multizone load balancer (MZLB). The MZLB continuously checks the portable public IP addresses of the services that expose the router in each zone in your cluster. Requests are handled by the router services in various zones in a round-robin cycle.
3. Based on the resolved IP address of the router service, the router receives the request.
4. The router forwards the request to the private IP address of the app pod over the private network. The source IP address of the request package is changed to the public IP address of the worker node where the router pod runs. Each router sends requests to the app instances in its own zone and to app instances in other zones. Additionally, if multiple app instances are deployed in one zone, the router alternates requests between app pods.
5. When the app returns a response packet, it uses the IP address of the worker node where the router that forwarded the client request exists.
(https://cloud.ibm.com/docs/containers?topic=containers-access_cluster).
3. Check which infrastructure account the region that your cluster is in currently uses to provision clusters. Replace REGION with the IBM Cloud region that the cluster is in.

ibmcloud ks credential get --region REGION

If you see a message similar to the following, then the account uses the default, linked infrastructure account.

No credentials set for resource group <resource group>.: The user credentials could not be found.
4. Check which infrastructure account was used to provision the cluster.



1. In the Worker Nodes tab, select a worker node and note its ID.
2. Open the menu ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) and click Classic Infrastructure.
3. From the infrastructure navigation pane, click Devices > Device List.
4. Search for the worker node ID that you previously noted.
5. If you don't find the worker node ID, the worker node is not provisioned into this infrastructure account. Switch to a different infrastructure account and try again.



5. Compare the infrastructure accounts.



* If the worker nodes are in the linked infrastructure account: Use the ibmcloud ks credential unset[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_unset) to resume using the default infrastructure credentials that are linked with your Pay-As-You-Go account.
* If the worker nodes are in a different infrastructure account: Use the ibmcloud ks credential set[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_set) to change your infrastructure credentials to the account that the cluster worker nodes are provisioned in, which you found in the previous step.

If you no longer have access to the infrastructure credentials, you can open an IBM Cloud support case to determine an email address for the administrator of the other infrastructure account.
For more information about available bare metal flavors and how bare metal is different from virtual machines, see [Physical machines (bare metal)](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesbm).





 What is the smallest size cluster that I can make? 

Your cluster must have at least 2 worker nodes to run default Kubernetes and OpenShift Container Platform components. You can't have a cluster with 0 worker nodes, and you can't power off or suspend billing for your worker nodes. Additionally, the type of cluster and the number of worker pools that you have can impact the size of your cluster.



* Single zone clusters: [Create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters) with 2 worker nodes in the default worker pool.
* Multizone clusters: You must [create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters) with 1 worker node per zone in the worker pool. Later, you can [remove zones](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_zone_rm) from the worker pool or [remove individual worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_rm) so that your cluster size reduces to the minimum size of 2.
* Worker pools: For any type of cluster, each worker pool must always have at least 1 worker node. For the smallest size cluster possible, you can have only 1 worker pool.



Keep in mind that some services such as Ingress might require multiple worker nodes for high availability, and you might not be able to run these services or your apps in the smallest size cluster possible.

Classic clusters only: Initially, you can create a classic cluster with only 1 worker node. This operation is allowed for multizone clusters, so that you are not forced to create 2 worker nodes per zone. If you have a single zone cluster, resize the worker pool to 2.