vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Note that you must enable classic access when you create the VPC, and you can't convert an existing VPC to use classic access. Additionally, you can set up classic infrastructure access for only one VPC per region, and you can't set up more than one VPC with classic infrastructure access in a region.
* To get started with IBM Cloud Transit Gateway, see the [Transit Gateway documentation](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-started). You can connect multiple VPCs to classic infrastructure, such as using IBM Cloud Transit Gateway to manage access between your VPCs in multiple regions to resources in your IBM Cloud classic infrastructure.









 External communication to apps that run on worker nodes 

Allow private or public traffic requests from outside the cluster to your apps that run on worker nodes.





 Private traffic to cluster apps 

When you deploy an app in your cluster, you might want to make the app accessible to only users and services that are on the same private network as your cluster. Private load balancing is ideal for making your app available to requests from outside the cluster without exposing the app to the general public. You can also use private load balancing to test access, request routing, and other configurations for your app before you later expose your app to the public with public network services.

To allow private network traffic requests from outside the cluster to your apps, you can use private Kubernetes networking services, such as creating [LoadBalancer services](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas). 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.
If you expose apps in your cluster with URLs, such as the Ingress subdomain or Red Hat OpenShift routes, ensure that the URLs are 130 characters or fewer. 
 Network speeds [VPC profile network speeds](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles) refer to the speeds of the worker node 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. 
 NodePort You can access an app through a NodePort only if you are connected to your private VPC network, such as through a VPN connection. To access an app from the internet, you must use a VPC load balancer or Ingress service instead. 
 Pod network VPC access control lists (ACLs) filter incoming and outgoing traffic for your cluster at the subnet level, and security groups filter incoming and outgoing traffic for your cluster at the worker nodes level. To control traffic within the cluster at the pod-to-pod level, you can't use VPC security groups or ACLs. Instead, use [Calico](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policies) and [Kubernetes network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-kube-policies), which can control the pod-level network traffic that uses IP in IP encapsulation. 
 Public gateway If the public service endpoint is enabled, you must attach a public gateway to each VPC subnet so that your worker nodes can communicate on the public network. Default Red Hat OpenShift components, such as the web console and OperatorHub, require public network access. 
 Service endpoints When you create your VPC cluster in the IBM Cloud console, your cluster has both a public and a private cloud service endpoint.
Check that outbound traffic to the cluster workers is allowed to the NodePort range 30,000 - 32,767 on whichever protocols the ALB is using.
* If the VPC load balancer is listed and you have not modified the kube-<vpc-id> security group attached to it, the DNS entry might still be registering. When a VPC load balancer is created, the hostname is registered through a public DNS. Sometimes, it can take several minutes for this DNS entry to be replicated to the specific DNS that your client is using. You can either wait for the hostname to be registered in your DNS, or access the VPC load balancer directly by using one of its IP addresses. To find the VPC load balancer IP addresses, run ibmcloud is lb <LB_ID> and look for the Public IPs field. If after several minutes you can't reach the load balancer, it might be offline due to provisioning or connection issues. [Open an IBM Cloud support case](https://cloud.ibm.com/unifiedsupport/cases/add). For the type, select Technical. For the category, select Network in the VPC section. In the description, include your cluster ID and the VPC load balancer ID.
Use the IBM Cloud console to create a VPC subnet for your cluster and optionally attach a public gateway to the subnet.



1. From the [VPC subnet dashboard](https://cloud.ibm.com/vpc/network/subnets), click Create.
2. Enter a name for your subnet and select the name of the VPC that you created.
3. Select the location and zone where you want to create the subnet.
4. Specify the number of IP addresses to create.



* VPC subnets provide IP addresses for your worker nodes and load balancer services in the cluster, so [create a VPC subnet with enough IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsvpc_basics_subnets), such as 256. You can't change the number of IPs that a VPC subnet has later.
* If you enter a specific IP range and running Red Hat OpenShift 4.7 or earlier., don't use the following reserved ranges: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, and 172.20.0.0/16.



5. To run default Red Hat OpenShift components such as the web console or OperatorHub, and to allow your cluster to access public endpoints such as a public URL of another app or an IBM Cloud service that supports public cloud service endpoints only, you must attach a public gateway to your subnet.
6. Click Create subnet.
7.
* Connect to your VPC private network, such as through a [VPC VPN connection](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-vpnaas).
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* To view VPC NLBs, install the infrastructure-service plug-in. The prefix for running commands is ibmcloud is.

ibmcloud plugin install infrastructure-service





* When cluster nodes are reloaded or when a cluster master update includes a new keepalived image, the load balancer virtual IP is moved to the network interface of a new node. When this occurs, any long-lasting connections to your load balancer must be re-established. Consider including retry logic in your application so that attempts to re-establish the connection are made quickly.



To enable your app to receive private network requests,



1. Create a VPC subnet that is dedicated to your VPC NLB. This subnet must exist in the same VPC and location as your cluster, but can't be attached to your cluster or any worker nodes.



1. From the [VPC subnet dashboard](https://cloud.ibm.com/vpc/network/subnets), click New subnet.
2. Enter a name for your subnet.
3. Select the location where your cluster exists and the zone where you want to create the VPC NLB.
4. Select the name of the VPC where your cluster exists.
5. Specify the number of IP addresses to create. Because this subnet is dedicated to the VPC NLB, you might choose a smaller size, such as 16. You can't change the number of IPs that a VPC subnet has later. If you enter a specific IP range, don't use the following reserved ranges: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, and 172.20.0.0/16.
Verify that the VPC NLB is created successfully in your VPC. In the output, verify that the VPC NLB has an Operating Status of online and a Provision Status of active.

Persistent VPC NLB names have a format kube-<cluster_ID>-<kubernetes_lb_service_UID>. To see your cluster ID, run ibmcloud oc cluster get --cluster <cluster_name>. To see the Kubernetes LoadBalancer service UID, run oc get svc myloadbalancer -o yaml and look for the metadata.uid field in the output. The dashes (-) are removed from the Kubernetes LoadBalancer service UID in the VPC NLB name.

ibmcloud is load-balancers

In the following example CLI output, the VPC NLB that is named kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e is created for the Kubernetes LoadBalancer service:

ID Name Created Host Name Is Public Listeners Operating Status Pools Private IPs Provision Status Public IPs Subnets Resource Group
06496f64-a689-4693-ba23-320959b7b677 kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e 8 minutes ago 1234abcd-us-south.lb.appdomain.cloud no 95482dcf-6b9b-4c6a-be54-04d3c46cf017 online 717f2122-5431-403c-b21d-630a12fc3a5a 10.XXX.XXX.XXX active - c6540331-1c1c-40f4-9c35-aa42a98fe0d9 00809211b934565df546a95f86160f62
8.
The cluster name and the region in which the cluster is deployed form the fully qualified domain name for the Ingress subdomain. To ensure that the Ingress subdomain is unique within a region, the cluster name might be truncated and appended with a random value within the Ingress domain name.

--zone <zone>
: Specify the IBM Cloud zone where you want to create your cluster. Make sure that you use a zone that matches the metro city location that you selected when you created your VPC and that you have an existing VPC subnet for that zone. For example, if you created your VPC in the Dallas metro city, your zone must be set to us-south-1, us-south-2, or us-south-3. To list available VPC cluster zones, run ibmcloud ks zone ls --provider vpc-gen2. Note that when you select a zone outside of your country, you might require legal authorization before data can be physically stored in a foreign country.

--vpc-id <vpc_ID>
: Enter the ID of the VPC that you created earlier. To retrieve the ID of your VPC, run ibmcloud ks vpcs.

--subnet-id <subnet_ID>
: Enter the ID of the VPC subnet that you created earlier. When you create a VPC cluster from the CLI, you can initially create your cluster in one zone with one subnet only. To create a multizone cluster, [add more zones with the subnets](https://cloud.ibm.com/docs/containers?topic=containers-add_workers) that you created earlier to your cluster after the cluster is created. To list the IDs of your subnets in all resource groups, run ibmcloud ks subnets --provider vpc-gen2 --vpc-id &lt,VPC_ID> --zone <subnet_zone>.

--flavor <worker_flavor>
: Enter the worker node flavor that you want to use. The flavor determines the amount of virtual CPU, memory, and disk space that is set up in each worker node and made available to your apps.
To check the VPE gateway for your cluster in the VPC infrastructure console, open the [Virtual private endpoint gateways for VPC dashboard](https://cloud.ibm.com/vpc-ext/network/endpointGateways) and look for the VPE gateway in the format iks-<cluster_ID>.



* If the gateway for your cluster is not listed, continue to the next step.
* If the gateway for your cluster is listed but its status is not Stable, [open a support case](https://cloud.ibm.com/docs/openshift?topic=openshift-get-helphelp-support). In the case details, include the cluster ID.
* If the gateway for your cluster is listed and its status is Stable, you might have firewall or security group rules that are blocking worker node communication to the cluster master. [Configure your security group rules to allow outgoing traffic to the appropriate ports and IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group).



2. Refresh the cluster master. If the VPE gateway does not exist in your VPC, it is created, and connectivity to the reserved IP addresses on the subnets that your worker nodes are connected to is re-established. After you refresh the cluster, wait a few minutes to allow the operation to complete.

ibmcloud oc cluster master refresh -c <cluster_name_or_ID>
3. Verify that the VPE gateway for your cluster is created by opening the [Virtual private endpoint gateways for VPC dashboard](https://cloud.ibm.com/vpc-ext/network/endpointGateways) and looking for the VPE gateway in the format iks-<cluster_ID>.
4. If you still can't manage worker nodes after the cluster master is refreshed, replace the worker nodes that you can't access.



1. List all worker nodes in your cluster and note the name of the worker node that you want to replace.

oc get nodes
Publicly expose an app in a multizone VPC cluster by using Ingress



1. A user sends a request to your app by accessing your app's URL. This URL is the Ingress subdomain for your cluster for your exposed app appended with the Ingress resource path, such as mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.
2. A DNS service resolves the route subdomain to the VPC load balancer hostname that is assigned to the Ingress controller. In VPC clusters, the external IP addresses are floating, and are kept behind a VPC-assigned hostname.
3. The VPC load balancer resolves the VPC hostname to an available IP address in a zone for the Ingress controller that was reported as healthy. The VPC load balancer continuously checks the external IP addresses for the Ingress controller in each zone in your cluster.
4. Based on the resolved IP address, the VPC load balancer sends the request to an Ingress controller.
5. The Ingress controller checks the routing rules that are implemented by the Ingress controller for the myapp path. If a matching rule is found, the request is proxied according to the rules that you defined in the IngressController and the Route resource to the pod where the app is deployed. The source IP address of the packet is changed to the IP address of the worker node where the Ingress controller pod runs. If multiple app instances are deployed in the cluster, the Ingress controller load balances the requests between the app pods across all zones.
6. When the app returns a response packet, it uses the IP address of the worker node where the Ingress controller service that forwarded the request exists. The VPC load balancer then sends the response packet to the client.







 VPC cluster with a private cloud service endpoint only 

When you create a multizone VPC cluster with the private cloud service endpoint only, a private Ingress controller is created by default. Only clients that are connected to your private VPC network can access apps that are exposed by a private Ingress controller.
vpc_worker_dns_domain IBM Cloud DNS Services domain name to be used for the compute cluster, for example, "test.example.corp". No dnsworker.com 
 vpn_enabled Set the value as true to deploy a VPN gateway for VPC in the cluster. No false 
 vpn_peer_address The peer public IP address to which the VPN is connected. No _NOT_SET_ 
 vpn_peer_cidrs Comma-separated list of peer CIDRs (for example, 192.168.0.0/24) to which the VPN is connected. No _NOT_SET_ 
 vpn_preshared_key The pre-shared key for the VPN No _NOT_SET_ 
 windows_image_name Name of the custom image that you want to use to create Windows® virtual server instances in your IBM Cloud account to deploy the IBM Spectrum Symphony cluster. By default, the solution uses a base image with additional software packages, which are mentioned [here](https://cloud.ibm.com/docs/hpc-spectrum-symphonycreate-custom-image). If you want to include your application-specific binary files, follow the instructions in [Planning for custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images) to create your own custom image and use that to build the IBM Spectrum Symphony cluster through this offering. No hpcc-sym731-win2016-10oct22-v1 
 windows_worker_node Set to true to deploy Windows® worker nodes in the cluster. By default, the cluster deploys Linux® worker nodes. If the variable is set to true, the values of both worker_node_min_count and worker_node_max_count should be equal because the current implementation doesn't support dynamic creation of worker nodes through Host Factory. No false 
 worker_node_instance_type Specify the virtual server instance or bare metal server profile type name to be used to create the worker nodes for the Spectrum Symphony cluster based on worker_node_type.
To make an app publicly available to the internet in a VPC cluster, choose an app exposure method that uses routes, VPC load balancers, or setting up Ingress. The following table describes each possible method, why you might use it, and how to set it up. For basic information about the networking services that are listed, see [Understanding Kubernetes service types](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningexternal).

You can't use multiple app exposure methods for one app.



Characteristics of public app exposure methods

 Name Load-balancing method Use case Implementation 

 Route HTTP(S) load balancing that exposes the app with a subdomain and uses custom routing rules Implement custom routing rules and SSL termination for multiple apps. Choose this method to remain Red Hat OpenShift-native; for example, you can use the Red Hat OpenShift web console to create and manage routes. [Create a route](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroutes-public-classic) by using the default public Ingress controller in clusters with a public cloud service endpoint, or [create a route](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroutes-public-vpc-privse) by using a custom public Ingress controller in clusters with a private cloud service endpoint only. 
 VPC load balancer Basic load balancing that exposes the app with a hostname. Quickly expose one app to the public with a VPC load balancer-assigned hostname. [Create a public LoadBalancer service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas) in your cluster. A multizonal VPC load balancer is automatically created in your VPC that assigns a hostname to your LoadBalancerservice for your app. 
 Ingress HTTP(S) load balancing that exposes the app with a subdomain and uses custom routing rules. Implement custom routing rules and SSL termination for multiple apps.
To make an app available over a private network only in a VPC cluster, choose a load balancing deployment pattern based on your cluster's service endpoint setup: public and private cloud service endpoint, or private cloud service endpoint only. For each service endpoint setup, the following table describes each possible app exposure method, why you might use it, and how to set it up.



Private network deployment patterns for a VPC cluster

 Name Load-balancing method Use case Implementation 

 Route HTTP(S) load balancing that exposes the app with a subdomain and uses custom routing rules Implement custom routing rules and SSL termination for multiple apps. Choose this method to remain Red Hat OpenShift-native; for example, you can use the Red Hat OpenShift web console to create and manage routes. [Create an Ingress controller by using the default private Ingress controller in clusters with a private cloud service endpoint only](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesprivate-routes-setup-43), or [create a route by using a custom private Ingress controller in clusters with a public cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroutes-private-vpc-privse). 
 NodePort Port on a worker node that exposes the app on the worker's private IP address Test private access to one app or provide access for only a short amount of time. [Create a private NodePort service](https://cloud.ibm.com/docs/openshift?topic=openshift-nodeport). 
 VPC load balancer Basic load balancing that exposes the app with a private hostname Quickly expose one app to a private network with a VPC load balancer-assigned private hostname. [Create a private LoadBalancer service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas) in your cluster. A multizonal VPC load balancer is automatically created in your VPC that assigns a hostname to your LoadBalancer service for your app.
If you created a subdomain for a public VPC ALB, open a web browser and enter the URL to access your app through the subdomain such as the example www.your-custom-domain.com. If you created a subdomain for a private VPC ALB, you must be [connected to your private VPC network](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-onprem-example) to test access to your subdomain.



To use the TLS certificate to access your app via HTTPS, ensure that you defined an HTTPS port in your [Kubernetes LoadBalancer service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaassetup_vpc_ks_vpc_lb). You can verify that requests are correctly routing through the HTTPS port by running curl -v --insecure https://<domain>. A connection error indicates that no HTTPS port is open on the service. Also, ensure that TLS connections can be terminated by your app. You can verify that your app terminates TLS properly by running curl -v https://<domain>. A certificate error indicates that your app is not properly terminating TLS connections.







 Persistent VPC load balancers 

By default, VPC load balancers are deleted when the cluster they are associated with is deleted. However, when you create a LoadBalancer service definition, you can make your load balancer persistent so that it remains available even after your cluster is deleted. A persistent VPC load balancer can be applied to a different cluster after its previous cluster is deleted.

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.