vania-janet/multiturn-rag-retrieval-data huggingface dataset:
: Optional: Do not show the message of the day or update reminders.



 Example worker-pool resize command 

ibmcloud oc worker-pool resize --cluster my_cluster --worker-pool my_pool --size-per-zone 3







 ibmcloud oc worker-pool rm 

Virtual Private Cloud

Classic infrastructure

Remove a worker pool from your cluster. All worker nodes in the pool are deleted. Your pods are rescheduled when you delete. To avoid downtime, be sure that you have enough workers to run your workload.

ibmcloud oc worker-pool rm --worker-pool WORKER_POOL --cluster CLUSTER [-q] [-f]

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

Command options:

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

-c, --cluster CLUSTER
: Required: The name or ID of the cluster that you want to remove the worker pool from.

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

-f
: Optional: Force the command to run with no user prompts.



 Example worker-pool rm command 

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







 ibmcloud oc worker-pool taint 

Set or remove Kubernetes taints for all the worker nodes in a worker pool. After you set up taints, pods without a matching toleration can't run on the worker pool. You might use taints to dedicate your worker pool exclusively for a certain type of workload, such as for networking edge nodes or the cluster autoscaler. For more information about how taints and tolerations work, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).



 ibmcloud oc worker-pool taint set 

Virtual Private Cloud

Classic infrastructure
If you try to set the context for your cluster by running ibmcloud oc cluster config, the command fails.

oc get secrets --all-namespaces

Example output

Unable to connect to the server: dial tcp 169.48.110.250:32346: i/o timeout
7. For clusters that run Red Hat OpenShift version 4.5 or later, check that your cluster is in a warning state. Your cluster remains in this state and is unusable until you enable your root key again.

ibmcloud oc cluster get -c <cluster_name_or_ID>
8. In your KMS instance, [enable the root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-disable-keys) so that your cluster returns to a normal state and becomes usable again.







 Managing encryption for the worker nodes in your cluster 

You can manage the encryption of the local disks in your worker nodes by using a [key management service (KMS) provider](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms) such as [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial). The way that you manage encryption for worker nodes depends on the infrastructure provider.



 Classic worker nodes 

Classic infrastructure: Classic worker nodes have two disks, and you can manage encryption for the second disk.



* The primary disk has the kernel images to boot your worker node. This disk is unencrypted.
* The secondary disk has the container file system and locally pulled images. This disk is AES 256-bit encrypted with an IBM-managed LUKS encryption key that is unique to the worker node and stored as a Kubernetes secret in your cluster. When you reload or update your worker nodes, the LUKS keys are rotated.







 VPC worker nodes
When you create a classic cluster, the cluster's worker nodes are connected automatically to a private VLAN and a public VLAN. A VLAN configures a group of worker nodes and pods as if they were attached to the same physical wire and provides a channel for connectivity among the workers.

You can't create classic Red Hat OpenShift on IBM Cloud clusters that are connected to a private VLAN only. Your worker nodes must be connected to both public and private VLANs.



 VLAN connections for worker nodes 

All worker nodes must be connected to a private VLAN so that each worker node can send information to and receive information from other worker nodes. The private VLAN provides private subnets that are used to assign private IP addresses to your worker nodes and private app services. Your worker nodes also must be connected to a public VLAN. The public VLAN provides public subnets that are used to assign public IP addresses to your worker nodes and public app services. However, if you need to secure your apps from the public network interface, several options are available to secure your cluster such as creating [Calico network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policies) or isolating external network workloads to [edge worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-edge).

The first time that you create a cluster in a zone, a public VLAN and a private VLAN in that zone are automatically provisioned for you in your IBM Cloud infrastructure account. For every subsequent cluster that you create in that zone, you can specify the VLAN pair that you want to use. You can reuse the same public and private VLANs that were created for you because multiple clusters can share VLANs.

For more information about VLANs, subnets, and IP addresses, see [Overview of networking in Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-subnetsbasics).

Need to create your cluster by using custom subnets?
Using reservations to reduce classic worker node costs 

When you have consistent computing needs over time of at least one year, create a reservation to reduce the costs of worker nodes in your IBM Cloud® Kubernetes Service clusters. With a reservation, you reserve virtual worker node instances in a contract for a fixed, predictable, and lower price than regular instances.

Reservations are available only for classic infrastructure worker nodes in multizone regions (MZRs). Also note that you can't enable the cluster autoscaler add-on on worker pools that use reservations.

Reservations are available only for allowlisted accounts. For more information, see [Requesting access to allowlisted features](https://cloud.ibm.com/docs/containers?topic=containers-get-helpallowlist-access-request).



 Understanding reservations 

A reservation is a type of IBM Cloud resource that you set up to describe the flavor, location, and other details of worker nodes that you want to purchase. Then, you create contracts for the reservation, which are agreements to pay a certain amount each month for a certain number of worker nodes for 1 or 3 year terms.

Review the following diagram for an example scenario of how you might set up your reservation and contracts to use across clusters.

Zoom

![Overview of reservations for IBM Cloud Kubernetes Service.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/reservations-ov.png)

Figure 1. An example scenario of using a reservation for worker nodes in your clusters.

Reservation: The reservation contains details such as the container platform, worker node flavor, location, and infrastructure provider.

Contract: The example reservation has two contracts for different terms. One contract is for 10 worker nodes across 3 years. The other contract is for 5 worker nodes across 1 year. Therefore, the total capacity of the reservation is 15 worker nodes.

Clusters: Each cluster is in the same multizone region as the reservation, but can be in a different resource group. Reserved worker nodes from different reservations can be used in different clusters.
You can check the new rates in the pricing estimate when you create a cluster or worker pool in the console. The OCP licenses are no longer a separate line item in the estimate, but instead are in the cost of the worker nodes.







 OCP licenses from Cloud Pak entitlements 

When you purchase products such as IBM Cloud Paks, your purchase might include OCP licenses. When you create a cluster or worker pool, you can choose to apply your entitlement to cover the cost of the OCP licenses.

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.







 Public bandwidth 

Bandwidth refers to the public data transfer of inbound and outbound network traffic, both to and from IBM Cloud resources in data centers around the globe.

Classic clusters: Public bandwidth is charged per GB. You can review your current bandwidth summary by logging into the [IBM Cloud console](https://cloud.ibm.com/), from the menu ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/icons/icon_hamburger.svg) selecting Classic Infrastructure, and then selecting the Network > Bandwidth > Summary page.

Review the following factors that impact public bandwidth charges:



* Location: As with worker nodes, charges vary depending on the zone that your resources are deployed in.
* Pay-As-You-Go for VM: Because VMs are billed at an hourly rate, your VM worker node machines have a Pay-As-You-Go allocation of outbound networking based on GB usage.
[Create a configmap](https://cloud.ibm.com/docs/containers?topic=containers-updateworker-up-configmap) to control the maximum number of worker nodes that can be unavailable at a time in your cluster. When you update your worker nodes, the ConfigMap helps prevent downtime for your apps as the apps are rescheduled orderly onto available worker nodes.
6. Update all the worker nodes in your cluster to pick up the private cloud service endpoint configuration.

By issuing the update command, the worker nodes are reloaded to pick up the service endpoint configuration. If no worker update is available, you must [reload the worker nodes manually](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli). If you reload, be sure to cordon, drain, and manage the order to control the maximum number of worker nodes that are unavailable at a time.

ibmcloud oc worker update --cluster <cluster_name_or_ID> --worker <worker1,worker2>
7. If the cluster is in an environment behind a firewall:



* [Allow your authorized cluster users to run kubectl commands to access the master through the private cloud service endpoint.](https://cloud.ibm.com/docs/openshift?topic=openshift-firewall)
* [Allow outbound network traffic to the private IPs](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_outbound) for infrastructure resources and for the IBM Cloud services that you plan to use.









 Setting up the public cloud service endpoint 

Enable the public cloud service endpoint for your cluster.

Your cluster must have a public cloud service endpoint on classic infrastructure. For a cluster with only a private cloud service endpoint, create a VPC cluster instead.

The public cloud service endpoint makes your Kubernetes master publicly accessible. Your worker nodes and your authorized cluster users can securely communicate with the Kubernetes master over the public network.
Configuring VPC subnets 

Virtual Private Cloud

Change the pool of available portable public or private IP addresses by adding subnets to your IBM Cloud® Kubernetes Service 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/containers?topic=containers-subnets).



 Overview of VPC networking in IBM Cloud Kubernetes Service 

Understand the basic concepts of VPC networking in IBM Cloud Kubernetes Service 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.
An Ingress controller is deployed by default to your cluster, which enable Routes to be used by external clients. The Ingress controller uses the service selector to find the service and the endpoints that back the service. You can configure the service selector to direct traffic through one Route to multiple services. You can also create either unsecured or secured Routes by using the TLS certificate that is assigned by the Ingress controller for your hostname. Note that the Ingress controller supports only the HTTP and HTTPS protocols.

[NodePort](https://cloud.ibm.com/docs/openshift?topic=openshift-nodeport)
: When you expose apps with a NodePort service, a NodePort in the range of 30000 - 32767 and an internal cluster IP address is assigned to the service. To access the service from outside the cluster, you use the public or private IP address of any worker node and the NodePort in the format <IP_address>:<nodeport>. However, the public and private IP addresses of the worker node are not permanent. When a worker node is removed or re-created, a new public and a new private IP address are assigned to the worker node. NodePorts are ideal for testing public or private access or providing access for only a short amount of time.

LoadBalancer
: The LoadBalancer service type is implemented differently depending on your cluster's infrastructure provider.



* Classic clusters: [Network load balancer (NLB)](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer). Every standard cluster is provisioned with four portable public and four portable private IP addresses that you can use to create a layer 4 TCP/UDP network load balancer (NLB) for your app. You can customize your NLB by exposing any port that your app requires. The portable public and private IP addresses that are assigned to the NLB are permanent and don't change when a worker node is re-created in the cluster. If you create public NLBs, you can create a subdomain for your app that registers the public NLB IP addresses with a DNS entry.
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 oc 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 oc 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/openshift?topic=openshift-utilitiesblock_storage_attacher).

Before you begin:
Then, [create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_create) that uses this new VLAN.

Do the IP addresses for my worker nodes change?
: Your worker node is assigned an IP address on the public or private VLANs that your cluster uses. After the worker node is provisioned, the worker node IP address persists across reboot and update operations, but the worker node IP address changes after a replace operation. Additionally, the private IP address of the worker node is used for the worker node identity in most kubectl commands. If you change the VLANs that the worker pool uses, new worker nodes that are provisioned in that pool use the new VLANs for their IP addresses. Existing worker node IP addresses don't change, but you can choose to remove the worker nodes that use the old VLANs.

Can I specify subnets for pods and services in my cluster?
: If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods, and a custom subnet CIDR to provide the private IP addresses for services.

To specify custom pod and service subnets during cluster creation, use the --pod-subnet and --service-subnet options in the ibmcloud ks cluster create CLI command.



 Pods 

Default range
: All services that are deployed to the cluster are assigned a private IP address in the 172.30.0.0/16 range by default.

Size requirements
: When you specify a custom subnet, consider the size of the cluster that you plan to create and the number of worker nodes that you might add in the future. The subnet must have a CIDR of at least /23, which provides enough pod IPs for a maximum of four worker nodes in a cluster. For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on.

Range requirements
If you need a new VLAN, order one by [contacting IBM Cloud support](https://cloud.ibm.com/docs/vlans?topic=vlans-ordering-premium-vlansordering-premium-vlans). Then, [create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_create) that uses this new VLAN.

Do the IP addresses for my worker nodes change?
: Your worker node is assigned an IP address on the public or private VLANs that your cluster uses. After the worker node is provisioned, the worker node IP address persists across reboot and update operations, but the worker node IP address changes after a replace operation. Additionally, the private IP address of the worker node is used for the worker node identity in most oc commands. If you change the VLANs that the worker pool uses, new worker nodes that are provisioned in that pool use the new VLANs for their IP addresses. Existing worker node IP addresses don't change, but you can choose to remove the worker nodes that use the old VLANs.

Can I specify subnets for pods and services in my cluster?
: If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods, and a custom subnet CIDR to provide the private IP addresses for services.

To specify custom pod and service subnets during cluster creation, use the --pod-subnet and --service-subnet options in the ibmcloud oc cluster create CLI command.



 Pods 

Default range
: All services that are deployed to the cluster are assigned a private IP address in the 172.30.0.0/16 range by default.

Size requirements
: When you specify a custom subnet, consider the size of the cluster that you plan to create and the number of worker nodes that you might add in the future.
Can I use security groups to manage my cluster's network traffic? 

Classic clusters: IBM Cloud [security groups](https://cloud.ibm.com/docs/security-groups?topic=security-groups-about-ibm-security-groupsabout-ibm-security-groups) are applied to the network interface of a single virtual server to filter traffic at the hypervisor level. If you want to manage traffic for each worker node, you can use security groups. When you create a security group, you must allow the VRRP protocol, which IBM Cloud Kubernetes Service uses to manage NLB IP addresses. To uniformly manage traffic for your cluster across all your worker nodes, use [Calico and Kubernetes policies](https://cloud.ibm.com/docs/containers?topic=containers-network_policies).

VPC clusters: VPC security groups are applied to the network interface of a single virtual server to filter traffic at the hypervisor level. You can add inbound and outbound rules to the default security group for your cluster to manage inbound and outbound traffic to a VPC cluster. For more information about the security groups, including the default settings, see [Controlling traffic with VPC security groups](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=ui).

Because the worker nodes of your VPC cluster exist in a service account and are not listed in the VPC infrastructure dashboard, you can't create a security group and apply it to your worker node instances. You can only modify existing security groups that are created for you.





 How can I secure the source IP within the cluster? 

In version 2.0 NLBs, the source IP address of the client request is preserved by default. However, in version 1.0 NLBs and in all Ingress ALBs, the source IP address of the client request is not preserved. When a client request to your app is sent to your cluster, the request is routed to a pod for the NLB 1.0 or ALB. If no app pod exists on the same worker node as the load balancer service pod, the NLB or ALB forwards the request to an app pod on a different worker node.