vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Instead, you manage your worker nodes with IBM Cloud Kubernetes Service only. However, your worker nodes might be connected to other VPC infrastructure resources, such as VPC subnets or VPC Block Storage. These resources are in the VPC infrastructure dashboard and can be managed separately from there.





 What limitations do I need to be aware of? 

Kubernetes limits the maximum number of worker nodes that you can have in a cluster. Review [worker node and pod quotas](https://kubernetes.io/docs/setup/best-practices/cluster-large/) for more information.

[Reserved capacity and reserved instances](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-provisioning-reserved-capacity-and-instances) are not supported.

IBM Cloud Kubernetes Service also sets compute resource reserves that limit available compute resources on each worker node. For more information, see [worker node resource reserves](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesresource_limit_node).

Want to be sure that you always have enough worker nodes to cover your workload? Try out [the cluster autoscaler](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-classic-vpc).





 How can I check the operating system that my worker nodes run? 

When you create a worker pool, you choose the flavor, which describes the operating system along with the compute resources of the worker nodes. Supported operating systems are Ubuntu 18.04 x86_64, 16.04 x86_64 (deprecated). To update the version of the operating system that a worker node uses, such as from Ubuntu 16 to 18, you can [replace the flavor of the worker pool](https://cloud.ibm.com/docs/containers?topic=containers-updatemachine_type).

You can also log in to your cluster to check the operating system of the worker nodes.



1. [Log in to your account. If applicable, target the appropriate resource group.
Key Management Service provider 277 v1.0.0 Updated the IBM Key Protect Go client. 
 OpenVPN client N/A N/A Fixed a problem that might cause the vpn-config secret in the kube-system namespace to be deleted during cluster master operations. 







 Change log for worker node fix pack 1.15.11_1535, released 13 April 2020 

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



Changes since version 1.15.11_1534

 Component Previous Current Description 

 HA proxy 1.8.23 1.8.25 See the [HA proxy change logs](https://www.haproxy.org/download/1.8/src/CHANGELOG). The update addresses [CVE-2020-11100](https://nvd.nist.gov/vuln/detail/CVE-2020-11100). 
 Ubuntu 18.04 packages 4.15.0-91-generic 4.15.0-96-generic Updated worker node images with package and kernel updates for [CVE-2020-8831](https://nvd.nist.gov/vuln/detail/CVE-2020-8831), [CVE-2020-8833](https://nvd.nist.gov/vuln/detail/CVE-2020-8833), [CVE-2020-11100](https://nvd.nist.gov/vuln/detail/CVE-2020-11100), and [CVE-2020-8834](https://nvd.nist.gov/vuln/detail/CVE-2020-8834).
Although this option is usually less expensive and sufficient, you might want to verify your performance and infrastructure requirements with your company policies. Virtual machines are billed hourly.
* Virtual - dedicated: Your worker nodes are hosted on infrastructure that is devoted to your account. Your physical resources are completely isolated. Virtual machines are billed hourly.



11. Optional: If the flavor that you want to use has a configurable secondary disk, you can modify the secondary disk by clicking the Edit icon ![Edit icon](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/icons/edit-tagging.svg). Select the storage disks that you want to add to your worker nodes and then click Apply. To view a list of VPC worker node flavors and their storage options, see [VPC flavors](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-flavors).
12. Set how many worker nodes to create per zone, such as 3. You must set at least 2 worker nodes. For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssmallest_cluster).
13. Enable [boot volume encryption](https://cloud.ibm.com/docs/containers?topic=containers-encryptionworker-encryption-vpc). From the drop down menus, select a key management service (KMS) instance and root key to encrypt the local disk for each worker node in the default worker pool. If you choose not to enable this option when you create your cluster, you can enable it later.
14. Configure your cluster with a private or a public and a private cloud service endpoint by setting the Master service endpoint.
Change log for worker node fix pack 1.24.4_1537, released 12 September 2022 

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



Changes since version 1.24.4_1535

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-191 4.15.0-192 Worker node kernel & package updates for [CVE-2021-33656](https://nvd.nist.gov/vuln/detail/CVE-2021-33656), [CVE-2022-35252](https://nvd.nist.gov/vuln/detail/CVE-2022-35252). 
 Kubernetes N/A N/A N/A 







 Change log for master fix pack 1.24.4_1536, released 1 September 2022 

The following table shows the changes that are in the master fix pack 1.24.4_1536. Master patch updates are applied automatically.



Changes since version 1.24.3_1531

 Component Previous Current Description 

 Cluster health image v1.3.9 v1.3.10 Updated Go dependencies and to Go version 1.18.5. 
 Gateway-enabled cluster controller 1792 1823 Updated to Go version 1.17.13. 
 GPU device plug-in and installer d8f1be0 c58c299 Enable DRM module and update Go to version 1.18.5. 
 IBM Calico extension 997 1006 Updated to Go version 1.17.13. 
 IBM Cloud Block Storage driver and plug-in v2.2.8 v2.2.9 Updated to Go version 1.18.5. 
 IBM Cloud Controller Manager v1.24.2-8 v1.24.4-1 Updated vpcctl binary to version 3367. Updated to support the Kubernetes 1.24.4 release. 
 IBM Cloud File Storage for Classic plug-in and monitor 412 414 Updated to Go version 1.18.5.
OpenVPN client 2.4.6-r3-IKS-116 2.4.6-r3-IKS-301 Updated image to implement additional IBM security controls. 
 OpenVPN server 2.4.6-r3-IKS-222 2.4.6-r3-IKS-301 Updated image to implement additional IBM security controls. 







 Change log for worker node fix pack 1.19.4_1529, released 11 December 2020 

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



Changes since version 1.19.4_1528

 Component Previous Current Description 

 Ubuntu 18.04 bare metal kernel 4.15.0-126-generic 4.15.0-123-generic Bare metal worker nodes: Reverted the kernel version for bare metal worker nodes while Canonical addresses issues with the previous version that prevented worker nodes from being reloaded or updated. 







 Change log for worker node fix pack 1.19.4_1528, released 7 December 2020 

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



Changes since version 1.19.4_1527

 Component Previous Current Description 

 Containerd v1.4.1 v1.4.3 See the [containerd release notes](https://github.com/containerd/containerd/releases/tag/v1.4.3). The update resolves CVE-2020–15257 (see the [IBM security bulletin](https://www.ibm.com/support/pages/node/6387878)). 
 HA proxy 1.8.26-384f42 db4e6d Added provenance labels for source tracking.
For more information, see [Intel Hyper-Threading Technology](https://cloud.ibm.com/docs/vpc?topic=vpc-profilesvpc-intel-hyper-threading). 
 Security Clusters on shared hardware run in an isolated environment in the public cloud. Clusters on dedicated hosts do not run in a shared environment, instead only your clusters are present on your hosts. Network access control lists protect the subnets that provide the floating IPs for your worker nodes. For more information, see the [VPC documentation](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vpc). 
 High availability The master includes three replicas for high availability. Further, if you create your cluster in a multizone metro, the master replicas are spread across zones and you can also spread your worker pools across zones. For more information, see [High availability for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-ha). 
 Reservations Reservations aren't available for VPC. 
 Cluster administration VPC clusters can't be reloaded or updated. Instead, use the [worker replace --update CLI](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_worker_replace) or [API operation](https://containers.cloud.ibm.com/global/swagger-global-api//beta/replaceWorker) to replace worker nodes that are outdated or in a troubled state. 
 Cluster networking Unlike classic infrastructure, the worker nodes of your VPC cluster are attached to VPC subnets and assigned private IP addresses. The worker nodes are not connected to the public network, which instead is accessed through a public gateway, floating IP, or VPN gateway. For more information, see [Overview of VPC networking in IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc_basics).
* The vpc provider is designed to support multiple VPC subproviders. The supported VPC subprovider is vpc-gen2, which corresponds to a VPC cluster for Generation 2 compute resources.
* Provider-specific requests have a path parameter in the URL, such as v2/vpc/createCluster. Some APIs are only available to a particular provider, such as GET vlan for classic or GET vpcs for VPC.
* Provider-neutral requests can include a provider-specific body parameter that you specify, usually in JSON, such as {"provider": "vpc"}, if you want to return responses for only the specified provider.



GET responses
: v1 API: The GET method for a collection of resources (such as GET v1/clusters) returns the same details for each resource in the list as a GET method for an individual resource (such as GET v1/clusters/{idOrName}).
: v2 API: To return responses faster, the v2 GET method for a collection of resources (such as GET v2/clusters) returns only a subset of information that is detailed in a GET method for an individual resource (such as GET v2/clusters/{idOrName}). Some list responses include a providers property to identify whether the returned item applies to classic or VPC infrastructure. For example, the GET zones list returns some results such as mon01 that are available only in the classic infrastructure provider, while other results such as us-south-01 are available only in the VPC infrastructure provider.

Cluster, worker node, and worker-pool responses
: v1 API: Responses include only information that is specific to the classic infrastructure provider, such as the VLANs in GET cluster and worker responses.
: v2 API: The information that is returned varies depending on the infrastructure provider. For such provider-specific responses, you can specify the provider in your request. For example, VPC clusters don't return VLAN information since they don't have VLANs. Instead, they return subnet and CIDR network information.





 Automating cluster deployments with the API
* Multiple clusters in the same VPC can share subnets.
* VPC subnets are bound to a single zone and can't span multiple zones or regions.
* After you create a subnet, you can't move it to a different zone, region, or VPC.
* If you have worker nodes that are attached to an existing subnet in a zone, you can't change the subnet for that zone in the cluster.
* The 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, and 172.20.0.0/16 ranges are prohibited if you are using Kubernetes 1.20 or earlier .







 Worker-to-master and user-to-master communication using Virtual private endpoints or cloud service endpoints 

IBM Cloud Kubernetes Service uses different types of service endpoints to establish a connection from authorized cluster users and worker nodes to the Kubernetes master. Authorized cluster users communicate with the Kubernetes master through cloud service endpoints. Depending on your cluster version, worker nodes communicate with the Kubernetes master through cloud service endpoints or VPC virtual private endpoints.

Before you create a cluster, you must enable your account to use service endpoints. To enable service endpoints, run ibmcloud account update --service-endpoint-enable true.

In VPC clusters in IBM Cloud Kubernetes Service, you can't disable the private cloud service endpoint or set up a cluster with the public cloud service endpoint only.





 Worker-to-master communication in VPC clusters 

Worker node communication to the Kubernetes master is established differently based on your cluster version.



* Worker node communication to the Kubernetes master is established over the [VPC virtual private endpoint (VPE)](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc_basics_vpe). If the public cloud service endpoint is also enabled, worker-to-master traffic is established half over the public endpoint and half over the VPE for protection from potential outages of the public or private network.
Create a VPC called myvpc and note the ID in the output. VPCs provide an isolated environment for your workloads to run within the public cloud. You can use the same VPC for multiple clusters, such as if you plan to have different clusters host separate microservices that need to communicate with each other. If you want to separate your clusters, such as for different departments, you can create a VPC for each cluster.

ibmcloud is vpc-create myvpc
2. Create a subnet for your VPC, and note its ID. Consider the following information when you create the VPC subnet:



* Zones: You must have one VPC subnet for each zone in your cluster. The available zones depend on the metro location that you created the VPC in. To list available zones in the region, run ibmcloud is zones.
* IP addresses: VPC subnets provide private IP addresses for your worker nodes and load balancer services in your cluster, so make sure to [create a subnet with enough IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc_basics_subnets), such as 256. You can't change the number of IP addresses that a VPC subnet has later.
* Public gateways: You don't need to attach a public gateway to complete this tutorial. Instead, you can keep your worker nodes isolated from public access by using VPC load balancers to expose workloads securely. You might attach a public gateway if your worker nodes need to access a public URL. For more information, see [Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters).



ibmcloud is subnet-create mysubnet1 <vpc_ID> --zone us-south-1 --ipv4-address-count 256



3. Create a cluster in your VPC in the same zone as the subnet. By default, your cluster is created with a public and a private cloud service endpoint.
Kubernetes Service security group kube-<vpc-id> <br><br> * Automatically created and attached to any cluster-related VPE gateways in the VPC.<br> * Automatically created and attached to each VPC ALB that is created in the VPC.<br> * Allows traffic necessary for the cluster infrastructure to function.<br><br><br> 









 Viewing VPC security groups in the CLI 

Follow the steps to view details about the VPC security groups.



1. List your clusters and note the ID of the cluster that you are working in.

To check what VPC a cluster is in, run ibmcloud ks cluster get --cluster <cluster_name_or_id> and check the VPC ID in the output.

ibmcloud ks cluster ls --provider vpc-gen2
2. List the security groups attached to the VPC that your cluster is in. The VPC security group is assigned a randomly generated name, such as trench-hexagon-matriarch-flower. The VPC cluster security group is named in the format of kube-<cluster-ID>. The Kubernetes Service security group is named in the format of kube-<vpc-ID>.

ibmcloud is sgs | grep <vpc_name>

Example output.

ID Name Rules Network interfaces VPC Resource group

r006-111aa1aa-1a1a-1a11-1111-a111aaa1a11a trench-hexagon-matriarch-flower 4 0 my-vpc default
r006-222aa2aa-2a2a-2a22-2222-a222aaa2a22a kube-a111a11a11aa1aa11a11 4 0 my-vpc default
r006-333aa3aa-3a3a-3a33-3333-a333aaa3a33a kube-r006-111a11aa-aaa1-1a1a-aa11-1a1a111aa11 4 0 my-vpc default
3. Get the details of a security group.
Understanding network basics of VPC clusters 

When you create your cluster, you must choose a networking setup so that certain cluster components can communicate with each other and with networks or services outside of the cluster.



* [Worker-to-worker communication](https://cloud.ibm.com/docs/containers?topic=containers-plan_vpc_basicsvpc-worker-worker): All worker nodes must be able to communicate with each other on the private network through VPC subnets.
* [Worker-to-master and user-to-master communication](https://cloud.ibm.com/docs/containers?topic=containers-plan_vpc_basicsvpc-workeruser-master): Your worker nodes and your authorized cluster users can communicate with the Kubernetes master securely over virtual private endpoints or cloud service endpoints.
* [Worker communication to other services or networks](https://cloud.ibm.com/docs/containers?topic=containers-plan_vpc_basicsvpc-worker-services-onprem): Allow your worker nodes to securely communicate with other IBM Cloud services, such as IBM Cloud® Container Registry, to on-premises networks, to other VPCs, or to classic infrastructure resources.
* [External communication to apps that run on worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-plan_vpc_basicsvpc-external-workers): Allow public or private requests into the cluster as well as requests out of the cluster to a public endpoint.





 Worker-to-worker communication using VPC 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 specify an 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.
: v2 API: Same as v1; see [Using an API key to log in to clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_api_key).

Supported APIs by infrastructure type
: v1 API: classic
: v2 API: vpc and classic



* The vpc provider is designed to support multiple VPC subproviders. The supported VPC subprovider is vpc-gen2, which corresponds to a VPC cluster for Generation 2 compute resources.
* Provider-specific requests have a path parameter in the URL, such as v2/vpc/createCluster. Some APIs are only available to a particular provider, such as GET vlan for classic or GET vpcs for VPC.
* Provider-neutral requests can include a provider-specific body parameter that you specify, usually in JSON, such as {"provider": "vpc"}, if you want to return responses for only the specified provider.



GET responses
: v1 API: The GET method for a collection of resources (such as GET v1/clusters) returns the same details for each resource in the list as a GET method for an individual resource (such as GET v1/clusters/{idOrName}).
: v2 API: To return responses faster, the v2 GET method for a collection of resources (such as GET v2/clusters) returns only a subset of information that is detailed in a GET method for an individual resource (such as GET v2/clusters/{idOrName}). Some list responses include a providers property to identify whether the returned item applies to classic or VPC infrastructure. For example, the GET zones list returns some results such as mon01 that are available only in the classic infrastructure provider, while other results such as us-south-01 are available only in the VPC infrastructure provider.

Cluster, worker node, and worker-pool responses
: v1 API: Responses include only information that is specific to the classic infrastructure provider, such as the VLANs in GET cluster and worker responses.
: v2 API: The information that is returned varies depending on the infrastructure provider.
--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.

--version 4.11_openshift
: VPC clusters are supported for Red Hat OpenShift version 4 only.

--flavor FLAVOR
: Choose a flavor for your worker nodes. You can deploy your worker nodes as virtual machines on shared or dedicated hardware. To see flavors that are available in a zone, run ibmcloud oc flavors --zone <vpc_zone> --provider vpc-gen2.

--cluster-security-group GROUP_ID
: Optional. Specify additional security group IDs to apply to all workers on the cluster. You must include a separate --cluster-security-group option for each individual security group you want to add. To apply the IBM-created kube-clusterID, use --cluster-security-group cluster. If no value is specified, only the kube-clusterID and the default VPC security group are applied. A maximum of five security groups can be applied to workers, including the default security groups. Note that the VPC security group is only applied if no other security groups are specified. For more information, see [Adding VPC security groups to clusters and worker pools during create time](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-sg-cluster). The security groups applied to a cluster cannot be changed once the cluster is created. You can [change the rules of the security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupvpc-sg-create-rules) that are applied to the cluster, but you cannot add or remove security groups at the cluster level.