vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Cluster health image v1.3.12 v1.3.13 Updated Go dependencies, golangci-lint, gosec, and to Go version 1.19.3. Updated base image version to 116. 
 etcd v3.4.18 v3.4.21 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.21). 
 Gateway-enabled cluster controller 1823 1902 Go module updates. 
 IBM Calico extension 1096 1213 Updated image to fix the following CVEs: [CVE-2020-35525](https://nvd.nist.gov/vuln/detail/CVE-2020-35525), [CVE-2020-35527](https://nvd.nist.gov/vuln/detail/CVE-2020-35527), [CVE-2022-3515](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3515), [CVE-2022-37434](https://nvd.nist.gov/vuln/detail/CVE-2022-37434), [CVE-2022-2509](https://nvd.nist.gov/vuln/detail/CVE-2022-2509), [CVE-2022-32149](https://nvd.nist.gov/vuln/detail/CVE-2022-32149). 
 IBM Cloud Block Storage driver and plug-in v2.3.1 v2.3.3 Updated universal base image (UBI) to version 8.7-923 to resolve CVEs. 
 IBM Cloud Controller Manager v1.23.13-1 v1.23.13-5 Key rotation and updated Go dependencies. 
 IBM Cloud File Storage for Classic plug-in and monitor 416 420 Updated universal base image (UBI) to version 8.7-923 to resolve CVEs.
Cluster health image v1.3.12 v1.3.13 Updated Go dependencies, golangci-lint, gosec, and to Go version 1.19.3. Updated base image version to 116. 
 etcd v3.4.18 v3.4.21 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.21). 
 Gateway-enabled cluster controller 1823 1902 Go module updates. 
 IBM Calico extension 1096 1213 Updated image to fix the following CVEs: [CVE-2020-35525](https://nvd.nist.gov/vuln/detail/CVE-2020-35525), [CVE-2020-35527](https://nvd.nist.gov/vuln/detail/CVE-2020-35527), [CVE-2022-3515](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3515), [CVE-2022-37434](https://nvd.nist.gov/vuln/detail/CVE-2022-37434), [CVE-2022-2509](https://nvd.nist.gov/vuln/detail/CVE-2022-2509), [CVE-2022-32149](https://nvd.nist.gov/vuln/detail/CVE-2022-32149). 
 IBM Cloud Block Storage driver and plug-in v2.3.1 v2.3.3 Updated universal base image (UBI) to version 8.7-923 to resolve CVEs. 
 IBM Cloud Controller Manager v1.21.14-6 v1.21.14-10 Key rotation and updated Go dependencies. 
 IBM Cloud File Storage for Classic plug-in and monitor 416 420 Updated universal base image (UBI) to version 8.7-923 to resolve CVEs.
Complete the following steps to verify that the privileged-psp-user cluster role binding uses the default configuration. This ensures that all service accounts and users are authorized to use the ibm-restricted-psp through the privileged-psp-user cluster role binding.

Your upgrade to 1.25 fails if the cluster role binding does not have the default role and subjects exactly as shown in the following example.



1. Get the details privileged-psp-user cluster role binding.

kubectl get clusterrolebinding privileged-psp-user -o yaml
2. Review the role and subjects in the output. If the output is different than the following example, do not upgrade to 1.25. If your privileged-psp-user cluster role binding matches the following example, you can continue with the upgrade.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: "2022-10-06T20:12:36Z"
name: privileged-psp-user
resourceVersion: "151862"
uid: 15014736-94d2-4cba-a3a8-92dd36de453b
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ibm-privileged-psp-user
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:masters
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:nodes
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:authenticated
Show more







 Step 3: Verify the restricted-psp-user cluster role binding uses the default configuration 

Complete the following steps to verify that the restricted-psp-user cluster role binding uses the default configuration.
Cluster health image v1.3.15 v1.3.16 Updated Go dependencies and to Go version 1.19.6. Updated universal base image (UBI) to resolve CVEs. 
 etcd v3.5.6 v3.5.7 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.5.7). 
 Gateway-enabled cluster controller 1902 1987 Updated armada-utils to version v1.9.35 
 IBM Calico extension 1305-amd64 1308-amd64 Updated universal base image (UBI) to resolve [CVE-2022-47629](https://nvd.nist.gov/vuln/detail/CVE-2022-47629). 
 IBM Cloud Block Storage driver and plug-in v2.3.6 v2.3.7 Updated universal base image (UBI) to resolve CVEs. 
 IBM Cloud Controller Manager v1.24.10-2 v1.24.10-10 Updated Go dependencies. Updated k8s.io/utils digest to a5ecb01. Updated vpcctl to v0.10.0. 
 IBM Cloud File Storage for Classic plug-in and monitor 425 427 Updated universal base image (UBI) to resolve CVEs. 
 Key Management Service provider v2.5.13 v2.6.3 Updated Go dependencies and to Go version 1.19.6. 
 Load balancer and Load balancer monitor for IBM Cloud Provider 2325 2383 Updated to armada-utils version 1.9.35.
Creating your own Ingress domain 

When you create a standard cluster, an Ingress subdomain is registered by default for your cluster in the format <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. Additionally, you can create your own domain registered with IBM Cloud's internal domain provider, or a domain registered with an external provider. Currently, IBM Cloud supports external domains registered with IBM Cloud Internet Services, Akamai, or Cloudflare.

This functionality is available in beta and is subject to change.



 Setting up domains with the IBM Cloud internal provider 

IBM Cloud provides a managed, internal provider that you can use to create your own domains. You can use the ibmcloud ks ingress domain create command to create a new domain, or you can specify an existing domain that you want to add to your cluster. When you create a domain with the internal provider, you specify a subdomain name, such as exampledomain. The new domain is named in the format exampledomain.<zone>.containers.appdomain.cloud.

The IBM Cloud internal provider runs on Akamai, but is separate from and should not be confused with an external Akamai domain that you create on your own. When you get the details of a domain, you may see the provider type listed as akamai or akamai-ext. The akamai provider type refers to the internal IBM Cloud domain provider, and akamai-ext refers to the external Akamai provider that you directly register the domain with.

ibmcloud ks ingress domain create --cluster CLUSTER [--is-default] [--domain DOMAIN] [--hostname HOSTNAME] [--ip IP] [--output OUTPUT] [-q] [--secret-namespace NAMESPACE]

-c, --cluster CLUSTER
: Required. The name or ID of the cluster where you want to create the domain.

--is-default
: Optional. Include this option to set the relevant domain as the default domain for the cluster.

--domain DOMAIN
: The domain to create or add to your cluster.
To get your cluster ID, run ibmcloud oc cluster ls.<br> * For "namespace": Enter a Kubernetes namespace in your cluster. To list the namespaces in your cluster, run oc get namespaces.<br><br><br><br>To assign the access policy to all namespaces in a cluster, remove the entire {"name": "namespace", "value": "<namespace_name"} entry. 



3. Apply the IBM Cloud IAM policy to an individual user.



* For individual users

ibmcloud iam user-policy-create <user@email.com> --file <filepath>/policy.json



4. If you assigned only service access roles to users, the users must be given the cluster master URL to open the Red Hat OpenShift web console from their browser at https://<master_URL>/console instead of the IBM Cloud console. Otherwise, [give the users the platform Viewer role](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users_cli_platform).
5. Optional: After a couple minutes, verify that the user is added to the corresponding [RBAC role binding or cluster role binding](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-rbac).



Users must run the ibmcloud ks cluster config command for their role changes to take effect.







 Understanding RBAC permissions 

RBAC roles and cluster roles define a set of permissions for how users can interact with Kubernetes resources in your cluster.

With IBM Cloud IAM, you can automatically manage RBAC from IBM Cloud, by assigning users [service access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users). You might want a deeper understanding of RBAC to customize access for resources within your cluster, like service accounts.



 What are the types of RBAC roles?
A service provides connectivity between your app pods and other services in the cluster without exposing the actual private IP address of each pod. Services are assigned an in-cluster IP address, the clusterIP, that is accessible inside the cluster only. This IP address is tied to the service for its entire lifespan and does not change while the service exists. Services are assigned an IP from one of the 65,000 IPs in the 172.21.0.0/16 range.

To avoid conflicts, don't use this IP range on any nodes that communicate with your worker nodes. A DNS lookup entry is also created for the service and stored in the kube-dns component of the cluster. The DNS entry contains the name of the service, the namespace where the service was created, and the link to the assigned in-cluster IP address.

If you plan to connect your cluster to on-premises networks through IBM Cloud or a VPN service, you might have subnet conflicts with the 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](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clipod-subnet) 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.

To provide basic load balancing of all TCP and UDP network traffic for services, a local Kubernetes network proxy, kube-proxy, runs as a daemon on each worker node in the kube-system namespace. kube-proxy uses Iptables rules, a Linux kernel feature, to direct requests to the pod behind a service equally, independent of pods' in-cluster IP addresses and the worker node that they are deployed to.

For example, apps inside the cluster can access a pod behind a cluster service by using the service's in-cluster IP or by sending a request to the name of the service. When you use the name of the service, kube-proxy looks up the name in the cluster DNS provider and routes the request to the in-cluster IP address of the service.
For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on.
: The subnet that you choose must be within one of the following ranges:



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. The service subnet is in the 172.21.0.0/16 range by default.

--service-subnet SUBNET
: All services that are deployed to the cluster are assigned a private IP address in the 172.21.0.0/16 range by default. If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your services.
: The subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger. The subnet that you choose must be within one of the following ranges:



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. The pod subnet is in the 172.30.0.0/16 range by default.

--skip-advance-permissions-check
: Optional: Skip [the check for infrastructure permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliinfra_permissions_get) before creating the cluster.
Compliance to industry standards varies depending on the infrastructure provider of the cluster, such as classic or VPC.<br> * Monitor, isolate, and recover the cluster master.<br> * Provide highly available replicas of the Kubernetes master API server, etcd, scheduler, and controller manager components to protect against a master outage.<br> * Provide options for cluster network connectivity, such as public and private cloud service endpoints.<br> * Provide options for compute isolation, such as dedicated virtual machines or bare metal.<br> * Integrate Kubernetes role-based access control (RBAC) with IBM Cloud Identity and Access Management (IAM).<br><br><br> <br><br> * Set up and maintain security and regulation compliance for your apps and data. For example, choose how to set up your [cluster network](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_clusters), [protect sensitive information](https://cloud.ibm.com/docs/openshift?topic=openshift-encryption) such as with IBM Key Protect encryption, and configure further [security settings](https://cloud.ibm.com/docs/openshift?topic=openshift-securitysecurity) to meet your workload's security and compliance needs. If applicable, configure your [firewall](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall).<br><br><br>
1518888 vlan 1254 public fcr02a.dal10



* To create a cluster in which you can run internet-facing workloads, check to see whether a public and private VLAN exist. If a public and private VLAN already exist, note the matching routers. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match. In the example output, any private VLAN can be used with any public VLAN because the routers all include 02a.dal10.
* To create a cluster that extends your on-premises data center on the private network only or provides limited public access through a gateway appliance, check to see whether a private VLAN exists. If you have a private VLAN, note the ID.



7. Create your standard cluster.



* To create a cluster in which you can run internet-facing workloads:

ibmcloud ks cluster create classic --zone <zone> --flavor <flavor> --hardware <shared_or_dedicated> --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID> --workers <number> --name <cluster_name> --version <major.minor.patch> [--public-service-endpoint] [--private-service-endpoint] [--pod-subnet] [--service-subnet] [--disable-disk-encrypt]
* To create a cluster with private network connectivity only, such as to extend your on-premises data center:
Add-ClusterResource -Name $port -ResourceType "Distributed Network Name" -Group $ag
Get-ClusterResource -Name $port | Set-ClusterParameter -Name DnsName -Value $dns
Start-ClusterResource -Name $port
$Dep = Get-ClusterResourceDependency -Resource $ag
if ( $Dep.DependencyExpression -match 's((.))s' ) {$DepStr = "$($Matches.1) or [$port]"} else {$DepStr = "[$port]"}
Set-ClusterResourceDependency -Resource $ag -Dependency "$DepStr"
Stop-ClusterResource -Name $ag
Start-ClusterResource -Name $ag

Use the following command to allow TCP 6789 through the Windows firewall:

New-NetFirewallRule -DisplayName 'SQL-dnnlsnr-6789-Inbound' -Profile Domain -Direction Inbound -Action Allow -Protocol TCP -LocalPort 6789
To secure your cluster network or connect to an on-prem data center, you can configure one of the following options:<br><br><br><br> * [strongSwan IPSec VPN Service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnvpn-setup)<br> * [IBM Cloud® Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl)<br> * [Virtual Router Appliance (VRA)](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnvyatta)<br> * [Fortigate Security Appliance (FSA)](https://cloud.ibm.com/docs/vmwaresolutions/services?topic=vmwaresolutions-fsa_considerations)<br><br><br> 
 IBM Cloud storage Supported persistent storage solutions, such as IBM Cloud File Storage for Classic, IBM Cloud Block Storage, or IBM Cloud Object Storage are integrated as Kubernetes flex drivers and can be set up by using Helm charts. The storage documentation for each solution includes instructions to install and manage storage. For more information about choosing a persistent storage solution, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-plan). 
 Cluster autoscaler With the ibm-iks-cluster-autoscaler plug-in, you can scale the worker pools in your cluster automatically to increase or decrease the number of worker nodes in the worker pool based on the sizing requests of your scheduled workloads. For more information, see [Scaling clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpc).
For example, when you create an IBM Cloud Satellite cluster, the cluster is accessible through a URL that consists one of the subdomains for your location and a port, such as https://pacfd8bdae2d04696301d-6b64a6ccc9c596bf59a86625d8fa2202-ce00.us-east.satellite.appdomain.cloud:32200. When you access your cluster, such as by using the ibmcloud oc cluster config --cluster <cluster_name_or_ID> --admin command or by getting a login token from the Red Hat OpenShift web console, this URL is automatically used for your connection to the cluster master. Note that if you use hosts that have private network connectivity only for your location, you must be connected to your hosts' private network, such as through VPN access, to connect to your cluster and access the Red Hat OpenShift web console.

For more information about connecting to services that run in your Satellite location by using the cluster service URL, see the documentation for that service, such as the [Red Hat OpenShift on IBM Cloud documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat).





 IBM private network access with Satellite Link 

If you have a resource on the IBM private network that requires access to your Satellite location, you can [create a location endpoint in Satellite Link](https://cloud.ibm.com/docs/satellite?topic=satellite-link-cloud-createlink-location).





 Application workloads that run in clusters 

To make your apps available, see the options for [Exposing apps in Satellite clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-sat-expose-apps).







 IBM Cloud access to your Satellite location 

Default Satellite Link endpoints are created for your location's control plane cluster and for any other Satellite-enabled services that you run in your location. These default Satellite Link endpoints are accessible only from within the IBM Cloud private network.
Example output for VPC clusters:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
router-private-ingress-controller LoadBalancer 172.21.57.132 1234abcd-us-south.lb.appdomain.cloud 80/TCP,443/TCP,1940/TCP 3m
4. Register the service's external IP address or VPC hostname with the domain you previously chose.



* Custom domain: Work with your DNS provider to add the router-private-ingress-controller service's external IP address as an A record (classic clusters) or VPC hostname as a CNAME (VPC clusters) that maps to your custom domain.
* IBM-provided domain: Create a DNS entry for the router-private-ingress-controller service's VPC hostname. When you run the following command, the subdomain that you specified in the private-ingress-controller.yaml file is automatically generated, and is registered with the router-private-ingress-controller service. A TLS secret for the domain is automatically generated in the project that you specify where your app runs. The secret name follows a truncated format of the subdomain, such as mycluster-a1b2cdef345678g9hi012j3kl4567890-i003.

ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <VPC_hostname> --type private --secret-namespace <project>









 Step 4: Create the Ingress resource 

Ingress resources define the routing rules that the Ingress controller uses to route traffic to your app service.



1. Define an Ingress resource configuration file that uses the IBM-provided domain or your custom domain to route incoming network traffic to the services that you created earlier.

apiVersion: networking.k8s.io/v1 For 4.5 or earlier, use networking.k8s.io/v1beta1 instead
kind: Ingress
metadata:
name: myingressresource
spec:
tls:
- hosts:
Deploying third-party router in gateway cluster 

When you deploy a vCenter Server instance in your IBM Cloud classic infrastructure, you might optionally deploy a gateway cluster. This cluster can host a third-party router or firewall. You are able to control which VLANs are routed through the router or firewall running on it.

The gateway cluster must not be mixed with NSX-T edge cluster, which consists of NSX-T edge transport nodes. The gateway cluster provides compute capacity for third-party router or firewalls, and VLAN routing can be controlled by the [gateway appliance configuration](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-managing-vlans-and-gateway-appliances) in IBM Cloud classic network.

Zoom

![Deploying third-party router in third-party router or firewall in gateway cluster](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-nsx-t-edge-services-cluster.svg)

Figure 1. Deploying third-party router in third-party router or firewall in gateway cluster

This architecture pattern deployment is summarized as follows:



1. You can optionally deploy a gateway cluster to host your own routing or firewall device. This cluster is attached to both IBM Cloud private and public networks through transit networks.
2. The third-party device can route assigned VLANs through it. You can choose the VLANs to be routed through it on IBM Cloud portal. You must configure the required VLAN interfaces and IP addresses to the devices as well as firewall zones, rules, and policies.
3. If you route your management VLAN through the firewall, you can also secure your management workloads, such as vCenter and NSX-T managers. Ensure that you allow the traffic for your management.
4. Your workload T0 is attached to IBM Cloud private network.
: If your cluster is on a public VLAN, a portable public IP address is used. Most clusters are on a public VLAN.
: If your cluster is on a private VLAN only, a portable private IP address is used.

Example configuration file to create a private NLB 1.0 service that uses a specified IP address on private VLAN 2234945:

apiVersion: v1
kind: Service
metadata:
name: myloadbalancer
annotations:
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
spec:
type: LoadBalancer
selector:
app: nginx
ports:
- protocol: TCP
port: 8080
targetPort: 8080 Optional. By default, the targetPort is set to match the port value unless specified otherwise.
loadBalancerIP: 172.21.xxx.xxx
Show more
3. Optional: Make your NLB service available to only a limited range of IP addresses by specifying the IPs in the spec.loadBalancerSourceRanges field. loadBalancerSourceRanges is implemented by kube-proxy in your cluster via Iptables rules on worker nodes. For more information, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/).
4. Create the service in your cluster.

oc apply -f myloadbalancer.yaml



3. Verify that the NLB service was created successfully. It might take a few minutes for the service to be created and for the app to be available.

oc describe service myloadbalancer

Example CLI output:

NAME: myloadbalancer
Namespace: default
Labels: <none>
Selector: app=liberty
Type: LoadBalancer
Location: dal10
IP: 172.21.xxx.xxx