vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name annotation is supported only on cluster versions 4.11 and later.

VPC load balancer names are formatted as kube-<cluster_ID>-<kubernetes_lb_service_UID> by default. When a cluster is deleted, this name format specifies the associated load balancers that are then also deleted. To make sure that your load balancer is not deleted when you delete a cluster, include the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name annotation in your LoadBalancer service definition to give your load balancer a unique name. The load balancer name must be unique within your VPC, and can include only lowercase alphanumeric characters and dashes (-). The annotation can be applied to all VPC load balancer types.

You are responsible for deleting persistent VPC load balancers when they are no longer needed. To delete a persistent VPC load balancer, delete the Kubernetes LoadBalancer service definition that the VPC load balancer is associated with.





 Moving a VPC load balancer from one cluster to another 

[Persistent VPC load balancers](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_persist) can be detached from one VPC cluster and then attached to another. The new cluster must be within the same VPC as the original cluster.



 Detaching a VPC load balancer from a cluster 

VPC load balancers are linked to the Kubernetes LoadBalancer service definition that they were created with.
* UI
* CLI
* API







 Viewing Block Storage for VPC volumes 

View details about a Block Storage for VPC volume or summary information about all volumes.



 Viewing information about Block Storage for VPC volumes in the UI 

List all Block Storage for VPC volumes and view details for a single volume. View attached Block Storage for VPC volume details in instance details. View all snapshots that were created from the Block Storage for VPC volume.



 Viewing information about all Block Storage for VPC volumes in the UI 

Go to the list of Block Storage for VPC volumes. In [IBM Cloud console)](https://cloud.ibm.com/login), go to the menu ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > VPC Infrastructure > Storage > Block storage volumes.

By default, Block Storage for VPC volumes display for all resource groups in your region. In the list of all Block Storage for VPC volumes, you see the following information.



Table 1. Details about all volumes

 Field Description 

 Region The region where these volumes are located, for example, US South. Click the down arrow to see volumes in a different region in which you have an account.) 
 Name Click the name of the volume to see individual volume details. 
 Status Status of the volume, which functions as the default filter for all rows. For more information about volume statuses, see [Block Storage for VPC volume statuses](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-block-storagestatus). 
 Location Availability zone in your region, inherited from the VPC (for example, US South 1). 
 Size Size of the volume you specified, in GBs. 
 Attachment type Data, for a secondary volume attached to an instance, boot when attached as a boot volume, or blank for an unattached volume. 
 Health Health monitors the overall health of the volume, such as I/O performance and data consistency. Volume health statuses are OK or degraded. Volumes in a degraded state have degraded performance, capacity, or experience connection problems.
Give your cluster a unique name, such as mycluster-free.
4. Select a resource group to create the cluster in, such as default.
5. In the Summary pane, review the order summary and then click Create. A worker pool is created that contains one worker node in the default resource group.



The worker node can take a few minutes to provision, but you can see the progress in the Worker nodes tab. When the status reaches Ready, you can start working with your cluster by [deploying your first app](https://cloud.ibm.com/docs/containers?topic=containers-getting-starteddeploy-app)!





 Creating a VPC cluster in the IBM Cloud console 

Create a standard VPC cluster by using the IBM Cloud console. For more detailed information about your cluster customization options, see [Creating a standard VPC cluster](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2&interface=ui).

VPC clusters can be created as standard clusters only, and as such incur costs. Be sure to review the order summary at the end of this tutorial to review the costs for your cluster. To keep your costs to a minimum, set up your cluster as a single zone cluster with one worker node only.



1. Create a Virtual Private Cloud (VPC) on generation 2 compute.



1. Navigate to the [VPC create console](https://cloud.ibm.com/vpc/provision/vpc).
2. Give the VPC a name and select a resource group to deploy the VPC into.
3. Give the VPC subnet a name and select the location where you want to create the cluster.
4. Attach a public gateway to your subnet so that you can access public endpoints from your cluster. This public gateway is used later on to access container images from Docker Hub.
5. Click Create virtual private cloud.



2. From the [IBM Cloud Kubernetes Service dashboard](https://cloud.ibm.com/kubernetes/clusters), click Create cluster.
* [VPC Gen 2 flavors](https://cloud.ibm.com/docs/containers?topic=containers-vpc-flavors)*



* VPC: For more information about network performance caps for virtual machines, see [VPC profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles). The network speeds refer to the speeds of the worker node network interfaces. The maximum speed available to your worker nodes is 25Gbps. Because IP in IP encapsulation is required for traffic between pods that are on different subnets, data transfer speeds between pods on different subnets might be slower, about half the compute profile network speed. Overall network speeds for apps that you deploy to your cluster depend on the worker node size and application's architecture.







 Physical machines (bare metal) 

You can provision your worker node as a single-tenant physical server, also referred to as bare metal.

Physical machines are available for classic clusters only and are not supported in VPC clusters.



 Planning considerations for bare metal 

How is bare metal different than VMs?
: Bare metal gives you direct access to the physical resources on the machine, such as the memory or CPU. This setup eliminates the virtual machine hypervisor that allocates physical resources to virtual machines that run on the host. Instead, all a bare metal machine's resources are dedicated exclusively to the worker, so you don't need to worry about "noisy neighbors" sharing resources or slowing down performance. Physical flavors have more local storage than virtual, and some have RAID to increase data availability. Local storage on the worker node is for short-term processing only, and the primary and auxiliary disks are wiped when you update or reload the worker node. For persistent storage solutions, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-plan).

Because you have full control over the isolation and resource consumption for your workloads, you can use bare metal machines to achieve HIPAA and PCI compliance for your environment.

Bare metal seems awesome! What's stopping me from ordering one immediately?
VPC clusters: Why do I see VPC load balancer health status failures? 

Virtual Private Cloud

  What’s happening 

In the [Load balancers for VPC dashboard](https://cloud.ibm.com/vpc-ext/network/loadBalancers), you view the details of the VPC load balancer that exposes your cluster's Ingress controller.

Although traffic to your apps is flowing correctly in your cluster, the Health status of the VPC load balancer shows that at most 2 instances (worker nodes) are Passing, while all other instances are Failing. For example, if you have 4 worker nodes in your cluster, the health status shows 2/4.

  Why it’s happening 

In VPC clusters, a VPC load balancer that exposes the Ingress controller is automatically created outside of your cluster. In the configuration for the load balancer, externalTrafficPolicy is set to Local, which offers better routing performance than Cluster.

This externalTrafficPolicy: Local setting indicates that when the VPC load balancer receives a request to your app service's node port, the load balancer forwards the traffic only to Ingress controller pods that are also on the same worker node as the app service's node port.

By default in the OpenShift Container Platform Ingress controller, only 2 Ingress controller pods are deployed to your cluster, so only 2 worker nodes have Ingress controller pods. Because the VPC load balancer forwards traffic only to worker nodes that contain Ingress controller pods, the load balancer's health check only reports the 2 worker nodes that have the Ingress controller pods as Passing, and the other worker nodes as Failing. For this reason, the failures are expected, and don't indicate that your VPC load balancer is unable to forward traffic to your cluster.
* [Preventing app workloads from running on edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgeedge_workloads)
* [Deploying the Sysdig agent on edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgesysdig-edge)







 Controlling traffic in VPC clusters with ACLs, security groups, and network policies 

[Overview of network security options](https://cloud.ibm.com/docs/containers?topic=containers-vpc-network-policyvpc-network-policy)



* [Comparison of network security options](https://cloud.ibm.com/docs/containers?topic=containers-vpc-network-policycomparison)
* [Access control lists (ACLs) or security groups?](https://cloud.ibm.com/docs/containers?topic=containers-vpc-network-policyacl-sg-compare)



[Controlling traffic with VPC security groups](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-security-group)



* [VPC security groups](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-security-groups-details)



* [Security groups applied to cluster workers](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-sg-cluster-workers)
* [Security groups applied to VPE gateways and VPC ALBs](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-sg-vpe-alb)



* [Viewing VPC security groups in the CLI](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupvpc-sg-cli)
[IBM Cloud bare metal server network interfaces and Distributed PortGroups with NSX-T](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vpc-ryo-diagrams-vpc-hosts-vmk-tep.svg)

Figure 3. IBM Cloud bare metal server network interfaces and Distributed PortGroups with NSX-T

When provisioning a host, make sure you provision the required VLAN interfaces for each, and that the PCI interface allowed VLANs lists include the used VLAN IDs.

As VMkernel adapters do not need to move between hosts, they are provisioned with Allow Float set to false.







 Related links 



* [IBM Cloud VPC getting started](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started)
* [IBM Cloud VPC Bare Metal Servers](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-for-bare-metal-servers)
* [IBM Cloud VPC RYO VMware reference architecture](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vpc-ryo-arch-overview)
* [IBM Cloud Direct Link overview](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl)
* [IBM Cloud Transit Gateway overview](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-started)
* [IBM Cloud VPC VPN overview](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-overview)
* [VPC IaaS endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpcinfrastructure-as-a-service-iaas-endpoints)
* VPC clusters: A Load Balancer for VPC is automatically created in your VPC for your cluster. For cost information, see [Pricing for Load Balancer for VPC](https://cloud.ibm.com/vpc-ext/provision/vs).







 Default storage for images 

To store images in the internal registry, Red Hat OpenShift on IBM Cloud creates a storage instance that varies by infrastructure provider.



* Classic clusters: A classic IBM Cloud File Storage for Classic volume is automatically created for you. Your file storage volume is provisioned with an ibmc-file-gold storage class of 100 GB capacity at 10 IOPS/GB, and billed at an hourly rate. If you need more image storage capacity, you can [update the volume size](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_internal_registry), which modifies the cost.
* VPC clusters: A bucket in an existing IBM Cloud Object Storage instance is created for you. For more information, see [Billing and pricing in the Object Storage documentation](https://www.ibm.com/cloud/object-storage).







 Storage for apps 

When you provision storage, you can choose the storage type and storage class that is correct for your use case. Charges vary depending on the type of storage, the location, and the specs of the storage instance. Some storage solutions, such as file and block storage offer hourly and monthly rates that you can choose from.

To choose the correct storage solution, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-plan). For more information, see:



* [File Storage for Classic](https://www.ibm.com/products/file-storage)
* [Block Storage for Classic](https://www.ibm.com/products/block-storage)
* [File Storage for VPC](https://www.ibm.com/products/file-storage)
* [Block Storage for VPC](https://www.ibm.com/products/block-storage)
In the diagram above the end user is accessing the applications. The applications are leveraging shared microservices. The company has separate DevOps teams that own application1, application2 and shared. A networking team focuses on connectivity and network security. The DevOps teams manage Virtual Service Instances, VSIs, used to implement the services they create and support.





 Concrete Architecture 

The following architecture implements the isolation and connectivity requirements set by the company. Notice that application1, shared, and application2 are VPCs. The single zone and subnet in each VPC can be expanded to a more detailed multi zone implementation over time.

Zoom

![Architecture of the tutorial](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution59-vpc-tg-dns-iam/architecture.png)

Architecture of the tutorial







 Before you begin 

This tutorial requires:



* IBM Cloud CLI with these plugins:



* Transit Gateway (tg)
* IBM Cloud VPC (vpc-infrastructure)
* DNS Services (dns)



* git to clone source code repository.
* terraform CLI to run the Terraform commands.



You will find instructions to download and install these tools for your operating environment in the [Getting started with solution tutorials](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-tutorials) guide.

In addition:



* Check for user permissions. Be sure that your user account has sufficient permissions to create and manage VPC resources, create a IBM Cloud® Transit Gateway and create a IBM Cloud® Transit Gateway services. See the list of [required permissions](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources) for VPC. You will also need the ability to create resource groups and IAM resources like access groups, policies, service IDs, ...
* [VPC cluster with a public cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-about-roks4architecture-vpc_public)
* [VPC cluster with a private cloud service endpoint only](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-about-roks4architecture-vpc_private)



* [How can I customize routing?](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-about-roks4custom-routing)
* [How can I enable TLS certificates?](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-about-roks4certs)



[Planning your Ingress setup](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-roks4ingress-roks4)



* [Planning networking for single or multiple projects](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-roks4multiple_projects)



* [All apps are in one project](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-roks4one-project)
* [Apps are in multiple projects](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-roks4multi-project)
* [Multiple domains within a project](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-roks4multi-domains-project)





[Configuring Ingress](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-configureingress-configure)
kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7 169.xx.xxx.xxx 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal10 1.26.6_1526

Every worker node is assigned a unique worker node ID and domain name that must not be changed manually after the cluster is created. If you change the ID or domain name, the Kubernetes master cannot manage your cluster.



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





 Example commands to create VPC clusters 

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.

ibmcloud ks cluster create vpc-gen2 --name my_cluster --zone us-east-1 --vpc-id <VPC_ID> --subnet-id <VPC_SUBNET_ID> --flavor bx2.4x16 --workers 3

For a VPC multizone cluster, after you created the cluster in a [multizone metro](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-vpc), [add zones](https://cloud.ibm.com/docs/containers?topic=containers-add_workersvpc_add_zone).
To see flavors that are available in a VPC zone, run ibmcloud ks flavors --zone <vpc_zone> --provider vpc-gen2.

--vpc-id VPC_ID
: Optional: Specify the ID of the VPC in which to create the worker pool's worker nodes. The value must match the VPC ID that the cluster is in. To list the cluster's VPC ID, run ibmcloud ks cluster get -c <cluster_name_or_ID>. If this option is not provided, then the worker pool defaults to the VPC ID of existing worker pools in the cluster.

-l, --label KEY1=VALUE1
: Optional: Apply key-value labels to each worker node in the worker pool. To specify multiple labels, use multiple options, such as -l key1=value1 -l key2=value2.

--kms-account-id ID
: Optional: The ID of the account that contains the KMS instance you want to use for local disk or secret encryption.

--kms-instance KMS_INSTANCE_ID
: Optional: Include the ID of a key management service (KMS) instance to use to encrypt the local disk on the worker nodes in the default worker pool. To list available KMS instances, run ibmcloud ks kms instance ls. If you include this option, you must also include the --crk option. For more information including steps to create, see [Managing encryption for the worker nodes in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-encryptionworker-encryption).

--crk ROOT_KEY
: Optional: Include the ID of the root key in the KMS instance to use to encrypt the local disk on the worker nodes in this worker pool. To list available root keys, run ibmcloud ks kms crk ls --instance-id. If you include this option, you must also include the --kms-instance option. Before you can use KMS encryption, you must create a KMS instance and set up the required service authorization in IAM.
To delete a persistent VPC load balancer, delete the Kubernetes LoadBalancer service definition that the VPC load balancer is associated with.





 Moving a VPC load balancer from one cluster to another 

[Persistent VPC load balancers](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaasvpc_lb_persist) can be detached from one VPC cluster and then attached to another. The new cluster must be within the same VPC as the original cluster.



 Detaching a VPC load balancer from a cluster 

VPC load balancers are linked to the Kubernetes LoadBalancer service definition that they were created with. To detach a persistent VPC load balancer from a cluster, you must break the link with the LoadBalancer service by [renaming the VPC load balancer](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-referenceload-balancer-update), or by removing the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name annotation from the original LoadBalancer service definition. You can also detach a persistent VPC load balancer from a cluster by [deleting the cluster](https://cloud.ibm.com/docs/containers?topic=containers-remove).

If you remove the annotation, the original LoadBalancer service reverts and creates a non-persistent VPC load balancer in the original cluster. This non-persistent VPC load balancer follows the kube-<cluster_ID>-<kubernetes_lb_service_UID> naming convention.





 Attaching a VPC load balancer to a cluster 

After a persistent VPC load balancer is detached from a cluster, you can attach to a different cluster by creating a new Kubernetes LoadBalancer service definition that references the VPC load balancer, or by updating an existing Kubernetes LoadBalancer service that exists on the new cluster.
For example, when you create a Kubernetes LoadBalancer service in your cluster, a load balancer for VPC is automatically created in your VPC outside of your cluster. The VPC load balancer is multizonal and routes requests for your app through the private NodePorts that are automatically opened on your worker nodes. For VPC ALBs, a [security group](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group), named in the form of kube-<vpc-id>, is automatically attached to your ALB instance.

The kube-<vpc-id> security group that is attached to your VPC ALB is the same security group used for the private VPE gateway that communicates with the Kubernetes master. Do not modify this security group, as doing so might result in disruptions to the network connectivity between the cluster and the Kubernetes master. Instead, you can [remove the security group from the VPC ALB](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-remove) and [replace it with a security group](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-add) that you create and manage.

For more information, see [Planning private external load balancing](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningprivate_access).





 Public traffic to cluster apps 

To make your apps accessible from the public internet, you can use public networking services. Even though your worker nodes are connected to private VPC subnets only, the VPC load balancer that is created for public networking services can route public requests to your app on the private network by providing your app a public URL. When an app is publicly exposed, anyone that has the public URL can send a request to your app.