vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* UI
* CLI







 Controlling traffic with VPC security groups 

Virtual Private Cloud

VPC clusters use various security groups to protect cluster components. These security groups are automatically created and attached to cluster workers, load balancers, and cluster-related VPE gateways. You can modify or replace these security groups to meet your specific requirements, however, any modifications must be made according to these guidelines to avoid network connectivity disruptions.



 VPC security groups 

Default behavior
: Virtual Private Cloud security groups filter traffic at the hypervisor level. Security group rules are not applied in a particular order. However, requests to your worker nodes are only permitted if the request matches one of the rules that you specify. When you allow traffic in one direction by creating an inbound or outbound rule, responses are also permitted in the opposite direction. Security groups are additive, meaning that if your worker nodes are attached to more than one security group, all rules included in the security groups are applied to the worker nodes. Newer cluster versions might have more rules in the kube-clusterID security group than older cluster versions. Security group rules are added to improve the security of the service and do not break functionality.

Limitations
: Because the worker nodes of your VPC cluster exist in a service account and aren't 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 the existing security group.

If you modify the default VPC security groups, you must, at minimum, include the required [inbound](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=uimin-outbound-rules-sg-workers) and [outbound](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=uimin-inbound-rules-sg-workers) rules so that your cluster works properly.



 Security groups applied to cluster workers 

Do not modify the rules in thekube-<cluster-ID> security group as doing so might cause disruptions in network connectivity between the workers of the cluster and the control cluster.
VPC clusters: Why does a Kubernetes LoadBalancer service fail with no IPs? 

Infrastructure provider: VPC

 What’s happening 

You exposed your app by creating a Kubernetes LoadBalancer service in your VPC cluster.

When you run oc describe svc <kubernetes_lb_service_name>, you see a warning message in the Events section similar to one of the following:

The subnet with ID(s) '<subnet_id>' has insufficient available ipv4 addresses.

 Why it’s happening 

When you create a Kubernetes LoadBalancer service in your cluster, a VPC load balancer is automatically created in your VPC.

The VPC load balancer puts a floating IP address for your Kubernetes LoadBalancer service behind a hostname that you can access your app through.

In VPC clusters, both worker nodes and services are assigned IP addresses from the same subnets. Traffic routing is enabled between subnets, so when all IP addresses in a subnet for a zone are used by worker nodes or services, you can still create new worker nodes or services in that zone because they use IP addresses from subnets in other zones. However, if all IP addresses on all subnets are in use, a new Kubernetes LoadBalancer service can't be successfully provisioned.

 How to fix it 

After you create a VPC subnet, you can't resize it or change its IP range.

Instead, you must create a larger VPC subnet in one or more zones where you have worker nodes. Then you create a new worker pool using the larger subnets.



1. [Create a new VPC subnet](https://cloud.ibm.com/vpc/provision/network) in the same VPC and in one or more zones where your cluster has worker nodes. Make sure that you create a subnet that can support both the number of worker nodes and services that you plan to create in your cluster. The default CIDR size of each VPC subnet is /24, which can support up to 253 worker nodes and services.
Available regions and zones for deploying VPC resources and a mapping of those to city locations and data centers can be found in [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations). While any of the available regions can be used, resources are provisioned only in a single availability zone within the selected region.
* What permissions do I need in order to create a cluster using the offering?

Instructions for setting the appropriate permissions for IBM Cloud services that are used by the offering to create a cluster can be found in [Granting user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources), [Managing user access for Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-access), [Assigning access to Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-assign-access), and [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).
* How do I SSH among nodes?

The IBM Spectrum Scale solution consists of two separate clusters (storage and compute). The SSH key parameter that is provided through Schematics (storage_cluster_key_pair and compute_cluster_key_pair) can be used to log in to the respective cluster nodes. You can log in to any node only through the bastion host by using the following command:

ssh -J ubuntu@<IP_address_bastion_host> vpcuser@<IP-address-of-nodes>

Although all of the nodes of each cluster have passwordless SSH set up among them, due to security constraints, you can't directly log in to a node from one cluster to another cluster.
* How many compute and storage nodes can I deploy in my Spectrum Scale cluster through this offering?
VPC clusters: Why does a Kubernetes LoadBalancer service fail with no IPs? 

Infrastructure provider: VPC

 What’s happening 

You exposed your app by creating a Kubernetes LoadBalancer service in your VPC cluster.

When you run kubectl describe svc <kubernetes_lb_service_name>, you see a warning message in the Events section similar to one of the following:

The subnet with ID(s) '<subnet_id>' has insufficient available ipv4 addresses.

 Why it’s happening 

When you create a Kubernetes LoadBalancer service in your cluster, a VPC load balancer is automatically created in your VPC.

The VPC load balancer puts a floating IP address for your Kubernetes LoadBalancer service behind a hostname that you can access your app through.

In VPC clusters, both worker nodes and services are assigned IP addresses from the same subnets. Traffic routing is enabled between subnets, so when all IP addresses in a subnet for a zone are used by worker nodes or services, you can still create new worker nodes or services in that zone because they use IP addresses from subnets in other zones. However, if all IP addresses on all subnets are in use, a new Kubernetes LoadBalancer service can't be successfully provisioned.

 How to fix it 

After you create a VPC subnet, you can't resize it or change its IP range.

Instead, you must create a larger VPC subnet in one or more zones where you have worker nodes. Then you create a new worker pool using the larger subnets.



1. [Create a new VPC subnet](https://cloud.ibm.com/vpc/provision/network) in the same VPC and in one or more zones where your cluster has worker nodes. Make sure that you create a subnet that can support both the number of worker nodes and services that you plan to create in your cluster. The default CIDR size of each VPC subnet is /24, which can support up to 253 worker nodes and services.
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. 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.

Subnets provide a channel for connectivity among the worker nodes within the cluster. Additionally, any system that is connected to any of the private subnets in the same VPC can communicate with workers. For example, all subnets in one VPC can communicate through private layer 3 routing with a built-in VPC router. If you have multiple clusters that must communicate with each other, you can create the clusters in the same VPC. However, if your clusters don't need to communicate, you can achieve better network segmentation by creating the clusters in separate VPCs. You can also create [access control lists (ACLs)](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-acls) for your VPC subnets to mediate traffic on the private network. ACLs consist of inbound and outbound rules that define which ingress and egress is permitted for each VPC subnet.

If your worker nodes must access a public endpoint outside of the cluster, you can enable a public gateway on the VPC subnet that the worker nodes are deployed to. A public gateway can be attached to or detached from a subnet at any time.

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

Subnets provide a channel for connectivity among the worker nodes within the cluster. Additionally, any system that is connected to any of the private subnets in the same VPC can communicate with workers. For example, all subnets in one VPC can communicate through private layer 3 routing with a built-in VPC router. If you have multiple clusters that must communicate with each other, you can create the clusters in the same VPC. However, if your clusters don't need to communicate, you can achieve better network segmentation by creating the clusters in separate VPCs. You can also create [access control lists (ACLs)](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-acls) for your VPC subnets to mediate traffic on the private network. ACLs consist of inbound and outbound rules that define which ingress and egress is permitted for each VPC subnet.

When you create a VPC cluster and enable both the public and private cloud service endpoints during cluster creation, the public cloud service endpoint is used by default for access to components such as the Red Hat OpenShift web console for your cluster. In order for console pods to establish a secure, public connection over the internet through the public service endpoint, you must enable a public gateway on each VPC subnet that your worker nodes are deployed to.
* UI
* CLI







 Controlling traffic with VPC security groups 

Virtual Private Cloud

VPC clusters use various security groups to protect cluster components. These security groups are automatically created and attached to cluster workers, load balancers, and cluster-related VPE gateways. You can modify or replace these security groups to meet your specific requirements, however, any modifications must be made according to these guidelines to avoid network connectivity disruptions.



 VPC security groups 

Default behavior
: Virtual Private Cloud security groups filter traffic at the hypervisor level. Security group rules are not applied in a particular order. However, requests to your worker nodes are only permitted if the request matches one of the rules that you specify. When you allow traffic in one direction by creating an inbound or outbound rule, responses are also permitted in the opposite direction. Security groups are additive, meaning that if your worker nodes are attached to more than one security group, all rules included in the security groups are applied to the worker nodes. Newer cluster versions might have more rules in the kube-clusterID security group than older cluster versions. Security group rules are added to improve the security of the service and do not break functionality.

Limitations
: Because the worker nodes of your VPC cluster exist in a service account and aren't 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 the existing security group.

If you modify the default VPC security groups, you must, at minimum, include the required [inbound](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupmin-outbound-rules-sg-workers) and [outbound](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupmin-inbound-rules-sg-workers) rules so that your cluster works properly.



 Security groups applied to cluster workers 

Do not modify the rules in thekube-<cluster-ID> security group as doing so might cause disruptions in network connectivity between the workers of the cluster and the control cluster.
For supported regions, see [Creating a VPC in a different region](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-in-a-different-region). The cluster's resource group can differ from the VPC resource group.

VPC Gen 2 cluster flavors with instance storage are available for allowlisted accounts. To get added to the allowlist, [open a case](https://cloud.ibm.com/unifiedsupport/cases/form) with support.

Free clusters are not available in VPC.

ibmcloud ks cluster create vpc-gen2 --name NAME --zone ZONE --vpc-id VPC_ID --subnet-id VPC_SUBNET_ID --flavor WORKER_FLAVOR [--cluster-security-group GROUP_ID] [--operating-system UBUNTU_20_64|UBUNTU_18_64] [--version MAJOR.MINOR.PATCH] [--workers NUMBER_WORKERS_PER_ZONE] [--disable-public-service-endpoint] [--pod-subnet SUBNET] [--service-subnet SUBNET] [--kms-account-id ID] [--kms-instance KMS_INSTANCE_ID] [--crk ROOT_KEY_ID] [--sm-group GROUP] [--sm-instance INSTANCE] [-q] [--secondary-storage STORAGE]

Minimum required permissions
: [Administrator platform access role for VPC Infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started).
: [Administrator platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for IBM Cloud Kubernetes Service at the account level.
: [Writer or Manager service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for IBM Cloud Kubernetes Service.
* Image tags: v.3.0.0
* The vpc-block-csi-driver is now available for both managed clusters and unmanaged clusters.
* No functional changes in this release.









 Archive 

Find an overview of Block Storage for VPC add-ons that are unsupported in IBM Cloud Kubernetes Service.



 Version 2.0.3 

Review the changes in version 2.0.3 of the Block Storage for VPC add-on.

Version 2.0.3 is unsupported.



 Change log for patch update 2.0.3_471, released 26 January 2021 

Review the changes in version 2.0.3_471 of the Block Storage for VPC add-on.



* Image tags: v.2.0.9
* Supported cluster versions: 1.15 - 1.20
* Updated he openssl, openssl-libs, gnutls packages to fix [CVE-2020-1971](https://nvd.nist.gov/vuln/detail/CVE-2020-1971) and [CVE-2020-24659](https://nvd.nist.gov/vuln/detail/CVE-2020-24659).







 Change log for patch update 2.0.3_464, released 10 December 2020 

Review the changes in version 2.0.3_464 of the Block Storage for VPC add-on.



* Image tags: v2.0.8
* New!: Metro storage classes with the volumeBindingMode:WaitForFirstConsumer specification.
* Resources that are deployed by the add-on now contain a label which links the source code URL and the build URL.
* The v2.0.8 image is signed.
* Updates the Go version from 1.15.2 to 1.15.5.







 Change log for patch update 2.0.3_404, released 25 November 2020 

Review the changes in version 2.0.3_404 of the Block Storage for VPC add-on.



* Image tags: v2.0.7
* Fixes vulnerability scan issues.
* Image tags: v.3.0.0
* The vpc-block-csi-driver is now available for both managed clusters and unmanaged clusters.
* No functional changes in this release.









 Archive 

Find an overview of Block Storage for VPC add-ons that are unsupported in IBM Cloud Kubernetes Service.



 Version 2.0.3 

Review the changes in version 2.0.3 of the Block Storage for VPC add-on.

Version 2.0.3 is unsupported.



 Change log for patch update 2.0.3_471, released 26 January 2021 

Review the changes in version 2.0.3_471 of the Block Storage for VPC add-on.



* Image tags: v.2.0.9
* Supported cluster versions: 4.3 - 4.6
* Updated he openssl, openssl-libs, gnutls packages to fix [CVE-2020-1971](https://nvd.nist.gov/vuln/detail/CVE-2020-1971) and [CVE-2020-24659](https://nvd.nist.gov/vuln/detail/CVE-2020-24659).







 Change log for patch update 2.0.3_464, released 10 December 2020 

Review the changes in version 2.0.3_464 of the Block Storage for VPC add-on.



* Image tags: v2.0.8
* New!: Metro storage classes with the volumeBindingMode:WaitForFirstConsumer specification.
* Resources that are deployed by the add-on now contain a label which links the source code URL and the build URL.
* The v2.0.8 image is signed.
* Updates the Go version from 1.15.2 to 1.15.5.







 Change log for patch update 2.0.3_404, released 25 November 2020 

Review the changes in version 2.0.3_404 of the Block Storage for VPC add-on.



* Image tags: v2.0.7
* Fixes vulnerability scan issues.
Architecture and dependencies of the service 

Review sample cluster architectures and the components that are created in your [classic](https://cloud.ibm.com/docs/containers?topic=containers-service-archarchitecture_classic) or [VPC](https://cloud.ibm.com/docs/containers?topic=containers-service-archarchitecture_vpc) cluster.



 Classic cluster 

The following architectural overviews are specific to the classic infrastructure provider. For an architectural overview for the VPC infrastructure provider, see [VPC cluster architecture](https://cloud.ibm.com/docs/containers?topic=containers-service-archarchitecture_vpc).



 Non-VRF or VRF-enabled account with public cloud service endpoint only 

The following image shows the components of your cluster and how they interact in a non-VRF or VRF-enabled account when only the [public cloud service endpoint is enabled](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsworkeruser-master).

Zoom

![IBM Cloud Kubernetes Service architecture when only the public cloud service endpoint is enabled](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_org_ov_public_se.png)

Figure 1. Cluster architecture when only the public cloud service endpoint is enabled





 VRF-enabled account with private and public cloud service endpoints 

The following image shows the components of your cluster and how they interact in a VRF-enabled account when the [public and private cloud service endpoints are enabled](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsworkeruser-master).

Zoom

!
Additionally, any system that is connected to any of the private subnets in the same VPC can communicate with workers. For example, all subnets in one VPC can communicate through private layer 3 routing with a built-in VPC router.

If you have multiple clusters that must communicate with each other, you can create the clusters in the same VPC. However, if your clusters don't need to communicate, you can achieve better network segmentation by creating the clusters in separate VPCs. You can also create [access control lists (ACLs)](https://cloud.ibm.com/docs/containers?topic=containers-vpc-network-policy) for your VPC subnets to mediate traffic on the private network. ACLs consist of inbound and outbound rules that define which ingress and egress is permitted for each VPC subnet.





 VPC networking limitations 

When you create VPC subnets for your clusters, keep in mind the following features and limitations.



* The default CIDR size of each VPC subnet is /24, which can support up to 253 worker nodes. If you plan to deploy more than 250 worker nodes per zone in one cluster, consider creating a subnet of a larger size.
* After you create a VPC subnet, you can't resize it or change its IP range.
* Multiple clusters in the same VPC can share VPC subnets. However, custom pod and service subnets can't be shared between multiple clusters.
* 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.
* Within one VPC, you can create only one public gateway per zone, but that public gateway can be attached to multiple subnets within the zone.
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). 
 Apps and container platform You can choose to create [community Kubernetes or Red Hat OpenShift clusters](https://cloud.ibm.com/docs/containers?topic=containers-faqscontainer_platforms) to manage your containerized apps. Your app build processes don't differ because of the infrastructure provider, but how you expose the app does. For more information, see [Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning). 
 App networking All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range and are routed between worker nodes on the worker node private IP address of the private VPC subnet. To expose the app on the public network, you can create a Kubernetes LoadBalancer service, which provisions a VPC load balancer and public hostname address for your worker nodes. For more information, see [Exposing apps with VPC load balancers](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas). 
 Storage For persistent storage, use [block](https://cloud.ibm.com/docs/containers?topic=containers-vpc-block). For the number of volumes that can be attached per worker node, see [Volume attachment limits](https://cloud.ibm.com/docs/vpc?topic=vpc-attaching-block-storagevol-attach-limits). The storage class limits the volume size to 20TB and IOPS capacity to 20,000. For non-persistent storage, secondary storage on the local worker node is not available.