vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To ensure that every team has the necessary resources to deploy services and run apps in the cluster, you must set up [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) for every namespace. Resource quotas determine the deployment constraints for a namespace, such as the number of Kubernetes resources that you can deploy, and the amount of CPU and memory that can be consumed by those resources. After you set a quota, users must include resource requests and limits in their deployments.





 Organize your Kubernetes objects with labels 

To organize and select your Kubernetes resources such as pods or nodes, [use Kubernetes labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/). By default, IBM Cloud Kubernetes Service applies some labels, including arch, os, region, zone, and machine-type.

Example use cases for labels include [limiting network traffic to edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edge), [deploying an app to a GPU machine](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appgpu_app), and [restricting your app workloads](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) to run on worker nodes that meet certain flavor or SDS capabilities, such as bare metal worker nodes. To see what labels are already applied to a resource, use the kubectl get command with the --show-labels option.

To apply labels to worker nodes, [create your worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_pool) with labels or [update an existing worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersworker_pool_labels).







 How can I keep my cluster in a supported state?
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-enablecluster-scaling-customize) such as scaleDownUnneededTime, scaleDownDelayAfterAdd, scaleDownDelayAfterDelete, or scaleDownUtilizationThreshold.

Can I increase the minimum size per zone to trigger a scale up my cluster to that size?
: No, setting a minSize does not automatically trigger a scale-up. The minSize is a threshold so that the cluster autoscaler does not scale to fewer than a certain number of worker nodes per zone. If your cluster does not yet have that number per zone, the cluster autoscaler does not scale up until you have workload resource requests that require more resources. For example, if you have a worker pool with one worker node per three zones (three total worker nodes) and set the minSize to 4 per zone, the cluster autoscaler does not immediately provision an additional three worker nodes per zone (12 worker nodes total). Instead, the scale-up is triggered by resource requests. If you create a workload that requests the resources of 15 worker nodes, the cluster autoscaler scales up the worker pool to meet this request. Now, the minSize means that the cluster autoscaler does not scale down to fewer than four worker nodes per zone even if you remove the workload that requests the amount.

How is this behavior different from worker pools that are not managed by the cluster autoscaler?
: When you [create a worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersadd_pool), you specify how many worker nodes per zone it has.
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-enablecluster-scaling-customize) such as scaleDownUnneededTime, scaleDownDelayAfterAdd, scaleDownDelayAfterDelete, or scaleDownUtilizationThreshold.

Can I increase the minimum size per zone to trigger a scale up my cluster to that size?
: No, setting a minSize does not automatically trigger a scale-up. The minSize is a threshold so that the cluster autoscaler does not scale to fewer than a certain number of worker nodes per zone. If your cluster does not yet have that number per zone, the cluster autoscaler does not scale up until you have workload resource requests that require more resources. For example, if you have a worker pool with one worker node per three zones (three total worker nodes) and set the minSize to 4 per zone, the cluster autoscaler does not immediately provision an additional three worker nodes per zone (12 worker nodes total). Instead, the scale-up is triggered by resource requests. If you create a workload that requests the resources of 15 worker nodes, the cluster autoscaler scales up the worker pool to meet this request. Now, the minSize means that the cluster autoscaler does not scale down to fewer than four worker nodes per zone even if you remove the workload that requests the amount.

How is this behavior different from worker pools that are not managed by the cluster autoscaler?
: When you [create a worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_pool), you specify how many worker nodes per zone it has. The worker pool maintains that number of worker nodes until you [resize](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_pool_resize) or [rebalance](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_rebalance) it.
To expose services and apps to the public internet, you can leverage the [VPC load balancer and Ingress ALB support](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningpattern_public_vpc) to securely make your services publicly available. Ensure that only necessary services are exposed, and revisit the list of exposed apps regularly to ensure that they are still valid. 
 Limit public network egress to one subnet with a public gateway If pods on your worker nodes need to connect to a public external endpoint, you can attach a public gateway to the subnet that those worker nodes are on. You can isolate this network traffic in your cluster by attaching a public gateway to only one subnet in your cluster. Then, you can [set affinity rules](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc-restrict-gateway) to deploy app pods that require access to external endpoints to only the subnet with an attached public gateway. 



Depending on the network that you want to connect your worker nodes to, you can [choose a VPN solution](https://cloud.ibm.com/docs/containers?topic=containers-vpc-vpnaas).





 Securely expose apps with LoadBalancer and Ingress services 

You can use network load balancer (NLB) and Ingress application load balancer (ALB) networking services to connect your apps to the public internet or to external private networks. Review the following optional settings for NLBs and ALBs that you can use to meet back-end app security requirements or encrypt traffic as it moves through your cluster.





 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.
If you want to connect your worker nodes to a private VLAN only, you can use the ID of an existing private VLAN or [create a private VLAN](https://cloud.ibm.com/docs/cli/reference/ibmcloud?topic=cli-manage-classic-vlanssl_vlan_create) and use the ID during cluster creation.

To see the VLANs that are provisioned in each zone for your account, run ibmcloud ks vlan ls --zone <zone>. To see the VLANs that one cluster is provisioned on, run ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources and look for the Subnet VLANs section.

IBM Cloud infrastructure manages the VLANs that are automatically provisioned when you create your first cluster in a zone. If you let a VLAN become unused, such as by removing all worker nodes from a VLAN, IBM Cloud infrastructure reclaims the VLAN. After, if you need a new VLAN, [contact IBM Cloud support](https://cloud.ibm.com/docs/vlans?topic=vlans-ordering-premium-vlansordering-premium-vlans).

Can I change my VLAN decision later?
: You can change your VLAN setup by modifying the worker pools in your cluster. For more information, see [Changing your worker node VLAN connections](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_clusterchange-vlans).





 Subnets and IP addresses 

In addition to worker nodes and pods, subnets are also automatically provisioned onto VLANs. Subnets provide network connectivity to your cluster components by assigning IP addresses to them.

The following subnets are automatically provisioned on the default public and private VLANs.



 Public VLAN subnets 



* The primary public subnet determines the public IP addresses that are assigned to worker nodes during cluster creation. Multiple clusters on the same VLAN can share one primary public subnet.
* The portable public subnet is bound to one cluster only and provides the cluster with 8 public IP addresses.
If you want to connect your worker nodes to a private VLAN only, you can use the ID of an existing private VLAN or [create a private VLAN](https://cloud.ibm.com/docs/cli/reference/ibmcloud?topic=cli-manage-classic-vlanssl_vlan_create) and use the ID during cluster creation.

To see the VLANs that are provisioned in each zone for your account, run ibmcloud oc vlan ls --zone <zone>. To see the VLANs that one cluster is provisioned on, run ibmcloud oc cluster get --cluster <cluster_name_or_ID> --show-resources and look for the Subnet VLANs section.

IBM Cloud infrastructure manages the VLANs that are automatically provisioned when you create your first cluster in a zone. If you let a VLAN become unused, such as by removing all worker nodes from a VLAN, IBM Cloud infrastructure reclaims the VLAN. After, if you need a new VLAN, [contact IBM Cloud support](https://cloud.ibm.com/docs/vlans?topic=vlans-ordering-premium-vlansordering-premium-vlans).

Can I change my VLAN decision later?
: You can change your VLAN setup by modifying the worker pools in your cluster. For more information, see [Changing your worker node VLAN connections](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_clusterchange-vlans).





 Subnets and IP addresses 

In addition to worker nodes and pods, subnets are also automatically provisioned onto VLANs. Subnets provide network connectivity to your cluster components by assigning IP addresses to them.

The following subnets are automatically provisioned on the default public and private VLANs.



 Public VLAN subnets 



* The primary public subnet determines the public IP addresses that are assigned to worker nodes during cluster creation. Multiple clusters on the same VLAN can share one primary public subnet.
* The portable public subnet is bound to one cluster only and provides the cluster with 8 public IP addresses.
: Specify at least 2 worker nodes to include in the cluster. For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssmallest_cluster). If you create a cluster with only one worker node per zone, you might experience issues with Ingress. For high availability, create a cluster with at least two workers per zone. Every worker node is assigned a unique worker node ID and domain name that must not be manually changed after the cluster is created. Changing the ID or domain name prevents the Kubernetes master from managing your cluster.

--disable-disk-encrypt
: Worker nodes feature AES 256-bit disk encryption by default; [learn more](https://cloud.ibm.com/docs/openshift?topic=openshift-securityencrypted_disk). To disable encryption, include this option.

--pod-subnet SUBNET
: All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range by default. 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.
: When you choose a subnet size, 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.
: The subnet that you choose must be within one of the following ranges:



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/containers?topic=containers-faqssmallest_cluster). If you create a cluster with only one worker node per zone, you might experience issues with Ingress. For high availability, create a cluster with at least two workers per zone. Every worker node is assigned a unique worker node ID and domain name that must not be manually changed after the cluster is created. Changing the ID or domain name prevents the Kubernetes master from managing your cluster.

--disable-disk-encrypt
: Worker nodes feature AES 256-bit disk encryption by default; [learn more](https://cloud.ibm.com/docs/containers?topic=containers-securityencrypted_disk). To disable encryption, include this option.

--pod-subnet SUBNET
: All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range by default. 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.
: When you choose a subnet size, 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.
: The subnet that you choose must be within one of the following ranges:



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255
Application Load Balancer for VPC 

Set up a layer-7, multizone [Application Load Balancer for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-load-balancers) (VPC ALB) to serve as the external entry point for incoming requests to an app in your cluster.

Do not confuse the Application Load Balancer for VPC with IBM Cloud Kubernetes Service Ingress applications load balancers. Application Load Balancers for VPC (VPC ALBs) run outside your cluster in your VPC and are configured by Kubernetes LoadBalancer services that you create. [Ingress applications load balancers (ALBs)](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-aboutmanaged-ingress-albs) are Ingress controllers that run on worker nodes in your cluster.

By default, when you create a Kubernetes LoadBalancer service for an app in your cluster, an Application Load Balancer for VPC is created in your VPC outside of your cluster. The VPC ALB routes requests to your app through the private NodePorts that are automatically opened on your worker nodes.



* If you create a public Kubernetes LoadBalancer service, you can access your app from the internet through the hostname that is assigned by the VPC ALB to the Kubernetes LoadBalancer service in the format 1234abcd-<region>.lb.appdomain.cloud. Even though your worker nodes are connected to only a private VPC subnet, the VPC ALB can receive and route public requests to the service that exposes your app. Note that no public gateway is required on your VPC subnet to allow public requests to your VPC ALB. However, if your app must access a public URL, you must attach public gateways to the VPC subnets that your worker nodes are connected to.
* If you create a private Kubernetes LoadBalancer service, your app is accessible only to systems that are connected to your private subnets within the same region and VPC.
Application Load Balancer for VPC 

Set up a layer-7, multizone [Application Load Balancer for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-load-balancers) (VPC ALB) to serve as the external entry point for incoming requests to an app in your cluster.

Do not confuse the Application Load Balancer for VPC with Red Hat OpenShift on IBM Cloud Ingress applications load balancers. Application Load Balancers for VPC (VPC ALBs) run outside your cluster in your VPC and are configured by Kubernetes LoadBalancer services that you create. [Ingress applications load balancers (ALBs)](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-aboutmanaged-ingress-albs) are Ingress controllers that run on worker nodes in your cluster.

By default, when you create a Kubernetes LoadBalancer service for an app in your cluster, an Application Load Balancer for VPC is created in your VPC outside of your cluster. The VPC ALB routes requests to your app through the private NodePorts that are automatically opened on your worker nodes.



* If you create a public Kubernetes LoadBalancer service, you can access your app from the internet through the hostname that is assigned by the VPC ALB to the Kubernetes LoadBalancer service in the format 1234abcd-<region>.lb.appdomain.cloud. Even though your worker nodes are connected to only a private VPC subnet, the VPC ALB can receive and route public requests to the service that exposes your app. Note that no public gateway is required on your VPC subnet to allow public requests to your VPC ALB. However, if your app must access a public URL, you must attach public gateways to the VPC subnets that your worker nodes are connected to.
* If you create a private Kubernetes LoadBalancer service, your app is accessible only to systems that are connected to your private subnets within the same region and VPC.
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.



* 5 IP addresses are [reserved by VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-about-networking-for-vpcaddresses-reserved-by-the-system) from each subnet by default.
* 1 IP address from one subnet in each zone where your cluster has worker nodes is required for the [virtual private endpoints (VPE) gateway](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc_basics_vpe).
* 1 IP address is required per worker node in your cluster.
* 1 IP address is required each time that you update or replace a worker node. These IP addresses are eventually reclaimed and available for reuse.
* 2 IP addresses are used each time that you create a public or private load balancer. If you have a multizone cluster, these 2 IP addresses are spread across zones, so the subnet might not have an IP address reserved.
* Other networking resources that you set up for the cluster, such as a VPNaaS or LBaaS autoscaling, might require additional IP addresses or have other [service limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations). For example, LBaaS autoscaling might scale up to 16 IP addresses per load balancer.







 What IP ranges can I use for my VPC subnets? 

The default IP address range for VPC subnets is 10.0.0.0 – 10.255.255.255.
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.



* 5 IP addresses are [reserved by VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-about-networking-for-vpcaddresses-reserved-by-the-system) from each subnet by default.
* 1 IP address from one subnet in each zone where your cluster has worker nodes is required for the [virtual private endpoints (VPE) gateway](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsvpc_basics_vpe).
* 1 IP address is required per worker node in your cluster.
* 1 IP address is required each time that you update or replace a worker node. These IP addresses are eventually reclaimed and available for reuse.
* 2 IP addresses are used each time that you create a public or private load balancer. If you have a multizone cluster, these 2 IP addresses are spread across zones, so the subnet might not have an IP address reserved.
* Other networking resources that you set up for the cluster, such as a VPNaaS or LBaaS autoscaling, might require additional IP addresses or have other [service limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations). For example, LBaaS autoscaling might scale up to 16 IP addresses per load balancer.







 What IP ranges can I use for my VPC subnets? 

The default IP address range for VPC subnets is 10.0.0.0 – 10.255.255.255.
If you don't have a private or a public VLAN, the VLAN is automatically created for you when you add a zone to your worker pool.

ibmcloud oc vlan ls --zone <zone>
3. For each zone, review the [available flavors for worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesplanning_worker_nodes).

ibmcloud oc flavors --zone <zone>
4. Create a worker pool. For more options, see the [CLI documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_pool_create).



* The minimum number of worker nodes per zone is 2. For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssmallest_cluster).
* Include the --label option to automatically label worker nodes that are in the pool with the label key=value.
* If you provision a bare metal or dedicated VM worker pool, specify --hardware dedicated.
* The new worker nodes run the same major.minor version as the cluster master, but the latest worker node patch of that major.minor version.



ibmcloud oc worker-pool create classic --name <pool_name> --cluster <cluster_name_or_ID> --flavor <flavor> --size-per-zone <number_of_workers_per_zone_min_2> [--operating-system (REDHAT_7_64|REDHAT_8_64)] [--label key=value]
5. Verify that the worker pool is created.

ibmcloud oc worker-pool ls --cluster <cluster_name_or_ID>
6. By default, adding a worker pool creates a pool with no zones. To deploy worker nodes in a zone, you must add the zones that you previously retrieved to the worker pool.