vania-janet/multiturn-rag-retrieval-data huggingface dataset:
When you assign the Super User infrastructure role to the admin or functional ID that sets the API key or whose infrastructure credentials are set, other users within the account share the API key or credentials for performing infrastructure actions. You can then control which infrastructure actions the users can perform by assigning the appropriate [IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms). You don't need to edit the user's IBM Cloud infrastructure permissions.

Classic infrastructure permissions apply only to classic clusters. For VPC clusters, see [Granting user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources).

For compliance, security, or billing reasons, you might not want to give the Super User infrastructure role to the user who sets the API key or whose credentials are set with the ibmcloud oc credential set command. However, if this user doesn't have the Super User role, then infrastructure-related actions, such as creating a cluster or reloading a worker node, can fail. Instead of using IBM Cloud IAM platform access roles to control users' infrastructure access, you must set specific IBM Cloud infrastructure permissions for users.

For example, if your account is not VRF-enabled, your IBM Cloud infrastructure account owner must turn on VLAN spanning. The account owner can also assign a user the Network > Manage Network VLAN Spanning permission so that the user can enable VLAN spanning. For more information, see [VLAN spanning for cross-VLAN communication](https://cloud.ibm.com/docs/openshift?topic=openshift-subnetsbasics_segmentation).



 Assigning infrastructure access through the console 

Classic infrastructure permissions apply only to classic clusters. For VPC clusters, see [Granting user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources).

Before you begin:
Setting up VPC VPN connectivity 

This VPN information is specific to VPC clusters. For VPN information for classic clusters, see [Setting up VPN connectivity](https://cloud.ibm.com/docs/openshift?topic=openshift-vpn).

Securely connect apps and services in a VPC cluster in Red Hat® OpenShift® on IBM Cloud® to on-premises networks, other VPCs, and IBM Cloud classic infrastructure resources. You can also connect apps that are external to your cluster to an app that runs inside your cluster.

The following table compares the connection options that are available based on the type of destination that you want to connect your VPC cluster to.



Comparison of connection options based on destination type

 Destination IBM Cloud VPC VPN Transit Gateway Direct Link Classic-access VPC 

 [On-premises networks](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-vpnaasonprem) Yes Yes 
 [Other VPCs](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-vpnaasvpc-vpc) Yes Yes 
 [Classic infrastructure resources](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-vpnaasvpc-classic) Yes Yes 





 Communication with resources in on-premises data centers 

To connect your cluster with your on-premises data center, you can use the IBM Cloud® Virtual Private Cloud VPN or IBM Cloud® Direct Link.

You might have subnet conflicts with the IBM-provided default 172.30.0.0/16 range for pods and 172.21.0.0/16 range for services. You can avoid subnet conflicts when you [create a cluster from the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_cluster-create-vpc-gen2) by specifying a custom subnet CIDR for pods in the --pod-subnet option and a custom subnet CIDR for services in the --service-subnet option.
This means clusters are still visible (read-only) in the console and CLI. When this limitation is addressed, you must add new rules to protect the APIs for getting clusters and listing clusters.
* For Red Hat OpenShift on IBM Cloud clusters on VPC with a Public Service Endpoint, if you add public CBR rules to your cluster, make sure to also add the public gateway IP addresses of your VPC subnets to your CBR rules. If you don't include the public gateway IPs, your Red Hat OpenShift Console pods won't work properly because those pods need to access the Oauth port of the cluster master with the public network.
* Due to a limitation that is currently being addressed, when you create a single private CBR rule that applies to the cluster API type and specifies a single, empty network zone, the rule does not block the private service endpoint completely. Instead, the cluster is treated as if there are no CBR rules and allows all traffic. Until this limitation is resolved, you must create a private CBR rule with at least one IP, for example, 1.1.1.1/32, or another IP that you control.
* Some Red Hat OpenShift on IBM Cloud clusters that were created before 8 October 2022 are not able to enforce public CBR rules for the cluster's APIserver. To check if your cluster supports these public cluster API type CBR rules, run the ibmcloud ks cluster get -c <CLUSTER-ID> command. If either of the Service Endpoint URLs starts with the https://cXXX (where XXX is any three digit number), then the cluster does support public CBR rules. If the Service Endpoint URLs starts with https://cX (where the number after the c is a single digit), then the cluster is not able to enforce public CBR rules for the cluster's APIserver. To use public CBR rules, you must create a new cluster.
Target the resource group where you want to set the API key. If you don't target a resource group, the API key is set for the default resource group.

ibmcloud target -g <resource_group_name>
3. Set up the API key that has the user's permissions for the region.

ibmcloud oc api-key reset --region <region>
4. Verify that the API key is set up.

ibmcloud oc api-key info --cluster <cluster_name_or_ID>



2. [Create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters). To create the cluster, the API key credentials that you set up for the region and resource group are used.







 Accessing a different classic infrastructure account 

Instead of using the default linked IBM Cloud infrastructure account to order infrastructure for clusters within a region, you might want to use a different IBM Cloud infrastructure account that you already have. You can link this infrastructure account to your IBM Cloud account by using the [ibmcloud oc credential set](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_credentials_set) command. The IBM Cloud infrastructure credentials are used instead of the default Pay-As-You-Go or Subscription account's credentials that are stored for the region.

You can manually set infrastructure credentials to a different account only for classic clusters, not for VPC clusters.

The IBM Cloud infrastructure credentials that are set by the ibmcloud oc credential set command persist after your session ends. If you remove IBM Cloud infrastructure credentials that were manually set with the [ibmcloud oc credential unset --region <region>](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_credentials_unset) command, the credentials of the Pay-As-You-Go or Subscription account are used instead.
When you require a stable public IP address and more availability for your service, expose your app by using a [network load balancer (NLB) service](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer) or [Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about).





 Enabling access to an app by using a NodePort service 

Expose your app as a Kubernetes NodePort service.

Because worker nodes in VPC clusters don't have a public IP address, 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](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas) or [Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about) service instead.

If you don't already have an app ready, you can use a Kubernetes example app called [Guestbook](https://github.com/kubernetes/examples/blob/master/guestbook/all-in-one/guestbook-all-in-one.yaml).

Before you begin



* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* VPC clusters: [Allow traffic requests that are routed to NodePorts on your worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group).



To use a NodePort,



1. In the configuration file for your app, define a [service](https://kubernetes.io/docs/concepts/services-networking/service/) section.

For the Guestbook example, a front-end service section exists in the configuration file.
[Ingress service traffic in VPC clusters](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/vpc-ingress-traffic.svg)

Ingress service traffic in VPC clusters.







 Planning public external load balancing 

Publicly expose an app in your cluster to the internet.

In classic clusters, you can connect worker nodes to a public VLAN. The public VLAN determines the public IP address that is assigned to each worker node, which provides each worker node with a public network interface. Public networking services connect to this public network interface by providing your app with a public IP address and, optionally, a public URL.

In VPC clusters, your worker nodes are connected to private VPC subnets only. However, when you create public networking services, a VPC load balancer is automatically created. The VPC load balancer can route public requests to your app 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.

When an app is publicly exposed, anyone that has the public service IP address or the URL that you set up for your app can send a request to your app. For this reason, expose as few apps as possible. Expose an app to the public only when your app is ready to accept traffic from external web clients or users.

The public network interface for worker nodes is protected by [predefined Calico network policy settings](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesdefault_policy) that are configured on every worker node during cluster creation. By default, all outbound network traffic is allowed for all worker nodes. Inbound network traffic is blocked except for a few ports. These ports are opened so that IBM can monitor network traffic and automatically install security updates for the Kubernetes master, and so that connections can be established to NodePort, LoadBalancer, and Ingress services.
* In classic clusters, if you have [VRF or VLAN spanning](https://cloud.ibm.com/docs/containers?topic=containers-subnetsbasics_segmentation) enabled, any system that is connected to any of the private VLANs in the same IBM Cloud account.
* In VPC clusters:



* If you permit traffic between VPC subnets, any system in the same VPC.
* If you permit traffic between VPCs, any system that has access to the VPC that the cluster is in.







 Choosing a deployment pattern for classic clusters 

To make an app available over a private network only in classic clusters, choose a load balancing deployment pattern based on your cluster's VLAN setup:



* [Public and private VLAN setup](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningprivate_both_vlans)
* [Private VLAN only setup](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningplan_private_vlan)





 Setting up private load balancing in a public and private VLAN setup 

When your worker nodes are connected to both a public and a private VLAN, you can make your app accessible from a private network only by creating private NodePort, LoadBalancer, or Ingress services. Then, you can create Calico policies to block public traffic to the services.

[Predefined Calico network policy settings](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesdefault_policy) protect the public network interface for worker nodes and are configured on every worker node during cluster creation. By default, all outbound network traffic is allowed for all worker nodes. Inbound network traffic is blocked except for a few ports. These ports allow IBM to monitor network traffic and automatically install security updates for the Kubernetes master, and so that connections can be established to NodePort, LoadBalancer, and Ingress services.

Because the default Calico network policies allow inbound public traffic to these services, you can create Calico policies to instead block all public traffic to the services.
: Versions [1.7.1](https://cloud.ibm.com/docs/containers?topic=containers-istio-changelog171) and [1.6.9](https://cloud.ibm.com/docs/containers?topic=containers-istio-changelog169) of the Istio managed add-on are released.

VPC load balancer
: In version 1.18 and later VPC clusters, added the service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol" annotation to preserve the source IP address of requests to apps in your cluster.





 4 September 2020 

New! CIS Kubernetes Benchmark
: Added information about IBM Cloud Kubernetes Service compliance with the [Center for Internet Security (CIS) Kubernetes Benchmark](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark) 1.5 for clusters that run Kubernetes version 1.18.





 3 September 2020 

CA certificate rotation
: Added steps to [revoke existing certificate authority (CA) certificates in your cluster and issue new CA certificates](https://cloud.ibm.com/docs/containers?topic=containers-securitycert-rotate).





 2 September 2020 

Istio add-on
: [Version 1.7 of the Istio managed add-on](https://cloud.ibm.com/docs/containers?topic=containers-istio-changelogv17) is released.





 1 September 2020 

Deprecation of VPC Gen 1 compute
: Virtual Private Cloud Generation 1 is deprecated. If you did not create any VPC Gen 1 resources before 01 September 2020, you can no longer provision any VPC Gen 1 resources. If you created any VPC Gen 1 resources before 01 September 2020, you can continue to provision and use VPC Gen 1 resources until 26 February 2021, when all service for VPC Gen 1 ends and all remaining VPC Gen 1 resources are deleted.
In VPC clusters, set up a layer-4 [Network Load Balancer for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-network-load-balancers) (VPC NLB) in each zone of your cluster to serve as the external entry point for incoming requests to an app.

VPC NLBs provide several advantages, such as providing higher throughput and better performance by utilizing direct server return (DSR). With DSR, the worker node can send app response packets directly to the client IP address and skip the VPC NLB, decreasing the amount of traffic that the VPC NLB must handle. Additionally, the VPC NLB supports source IP address preservation on all client requests by default.

When you create a Kubernetes LoadBalancer service for an app in your cluster and include the service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb" annotation, a VPC NLB is created in your VPC outside of your cluster. The VPC NLB routes requests for your app through the private NodePorts that are automatically opened on your worker nodes.



* If you create a public Kubernetes LoadBalancer service, you can access your app from the internet through the external, public IP address that is assigned by the VPC NLB to the Kubernetes LoadBalancer service. Even though your worker nodes are connected to only a private VPC subnet, the VPC NLB can receive and route public requests to the service that exposes your app. Note that no public gateway is required on your VPC subnet to allow public requests to your VPC NLB. However, if your app must access a public URL, you must attach public gateways to the VPC subnets that your worker nodes are connected to.
* If you create a private Kubernetes LoadBalancer service, your app is accessible only to systems that are connected to your private subnets within the same region and VPC. If you are connected to your private VPC network, you can access your app through the external, private IP address that is assigned by the VPC NLB to the Kubernetes LoadBalancer service.
Deprecation of VPC Gen 1 compute
: Virtual Private Cloud Generation 1 is deprecated. If you did not create any VPC Gen 1 resources before 01 September 2020, you can no longer provision any VPC Gen 1 resources. If you created any VPC Gen 1 resources before 01 September 2020, you can continue to provision and use VPC Gen 1 resources until 26 February 2021, when all service for VPC Gen 1 ends and all remaining VPC Gen 1 resources are deleted. To ensure continued support, create new VPC clusters on Generation 2 compute only, and move your workloads from existing VPC Gen 1 clusters to VPC Gen 2 clusters.

Istio add-on
: [Version 1.5.10](https://cloud.ibm.com/docs/containers?topic=containers-istio-changelog1510) of the Istio managed add-on is released.







 August 2020 



 31 August 2020 

Versions
: Worker node fix pack update change log documentation is available.
: Kubernetes version [1.18.8_1526](https://cloud.ibm.com/docs/containers?topic=containers-118_changelog1188_1526), [1.17.11_1538](https://cloud.ibm.com/docs/containers?topic=containers-117_changelog11711_1538), [1.16.14_1545](https://cloud.ibm.com/docs/containers?topic=containers-116_changelog11614_1545), and [1.15.12_1551](https://cloud.ibm.com/docs/containers?topic=containers-115_changelog11512_1551).





 27 August 2020 

Observability CLI plug-in
: Added the following commands to manage your IBM Log Analysis and IBM Cloud Monitoring configurations.



* [ibmcloud ob logging agent discover](https://cloud.ibm.com/docs/containers?topic=containers-observability_clilogging_agent_discover)
* Other networking resources that you set up for the cluster, such as a VPNaaS or LBaaS autoscaling, might require additional IP addresses or have other [service limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations). For example, LBaaS autoscaling might scale up to 16 IP addresses per load balancer.







 What IP ranges can I use for my VPC subnets? 

The default IP address range for VPC subnets is 10.0.0.0 – 10.255.255.255. For a list of IP address ranges per VPC zone, see the [VPC default address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes).

If you need to create your cluster by using custom-range subnets, see the guidance for [custom address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes). However, if you use custom-range subnets for your worker nodes, you must ensure that the IP range for the worker node subnets don't overlap with your cluster's pod subnet.



* If you specified your own pod subnet in the --pod-subnet option during cluster creation, your pods are assigned IP addresses from this range.
* If you did not specify a custom pod subnet during cluster creation, your cluster uses the default pod subnet. In the first cluster that you create in a VPC, the default pod subnet is 172.17.0.0/18. In the second cluster that you create in that VPC, the default pod subnet is 172.17.64.0/18. In each subsequent cluster, the pod subnet range is the next available, non-overlapping /18 subnet.







 How do I create subnets for classic infrastructure access?
* Other networking resources that you set up for the cluster, such as a VPNaaS or LBaaS autoscaling, might require additional IP addresses or have other [service limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations). For example, LBaaS autoscaling might scale up to 16 IP addresses per load balancer.







 What IP ranges can I use for my VPC subnets? 

The default IP address range for VPC subnets is 10.0.0.0 – 10.255.255.255. For a list of IP address ranges per VPC zone, see the [VPC default address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes).

If you need to create your cluster by using custom-range subnets, see the guidance for [custom address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes). However, if you use custom-range subnets for your worker nodes, you must ensure that the IP range for the worker node subnets don't overlap with your cluster's pod subnet. The pod subnet varies depending on your subnet choices during cluster creation and your cluster's infrastructure type:



* If you specified your own pod subnet in the --pod-subnet option during cluster creation, your pods are assigned IP addresses from this range.
* If you did not specify a custom pod subnet during cluster creation, your cluster uses the default pod subnet. In the first cluster that you create in a VPC, the default pod subnet is 172.17.0.0/18. In the second cluster that you create in that VPC, the default pod subnet is 172.17.64.0/18. In each subsequent cluster, the pod subnet range is the next available, non-overlapping /18 subnet.







 How do I create subnets for classic infrastructure access?
* NAME: The name that was specified when the agent was registered. This name appears on the Private Worker integration page.
* SERVICEID: The work queue ID from which this agent processes work requests.
* AGENT: A value of OK indicates that the agent can process work requests.
* REGISTERED: A value of Succeeded indicates that the agent successfully registered with the regional private worker service.
* VERSION: A value of OK indicates whether the version of the agent is current.
* AUTH: A value of OK indicates whether the agent apikey is valid.
* CONSTRAINED: A value of false indicates that enough cluster resources are available for the agent to run tasks. A value of True specifies that the cluster is resource-constrained.
* PAUSED: A value of false indicates that the agent is operational and can run tasks. A value of true specifies that the agent is paused and cannot run any tasks. One reason that an agent might be paused is for cluster maintenance.







 How do I set my ClusterImagePolicy so that I can access Tekton images? 

Because Delivery Pipeline private workers depend on the Tekton and tekton-pipelines infrastructure, they must pull tekton-releases images from icr.io (icr.io/continuous-delivery/pipeline/). You might need to define a specific Kubernetes ClusterImagePolicy to pull images from these container registries. To add the ClusterImagePolicy type to your Kubernetes cluster, you must install several [Helm charts](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts).





 How do I self-host container images for Delivery Pipeline Private Worker? 

Security constraints might prevent you from pulling images from the icr.io/continuous-delivery/pipeline container registry. In such scenarios, complete the following steps:



1. Provision the container images on a supported container registry.
2. Install the deployment.yaml file to reference the container images in this container registry.
3. For each container image that is referenced in the regular deployment yaml file, complete the following steps:



* Docker pull the image to a local Dockerfile.