vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If no public IP is listed, then your cluster has only private VLANs. * If you want the cluster to have only private VLANs, set up your [VLAN connection](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsprivate_clusters) and your [firewall](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_outbound). * If you created the cluster with only the private cloud service endpoint before you enabled your account for [VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) and [service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointservice-endpoint), your workers can't connect to the master. Try [setting up the public cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_clusterset-up-public-se) so that you can use your cluster until your support cases are processed to update your account. If you still want a private cloud service endpoint only cluster after your account is updated, you can then disable the public cloud service endpoint. * If you want the cluster to have a public IP, [add new worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_add) with both public and private VLANs.





 Hard reboot 

Message:

The worker did not respond to the soft reboot request. A hard reboot might be necessary.

Description and resolution:

Although you issued a reboot on your worker node, the worker node is unresponsive.
* Replace <profile-id>, <access_token>, <cluster_crn>, and <cluster_name> with the values that you previously retrieved.
* For <ns>, enter the namespace in your cluster. You can list namespaces by logging in to the cluster and running oc get ns. The Kubernetes namespace that you enter does not have to exist already. Any future namespace with this name can establish trust.

curl -L -X POST 'https://iam.cloud.ibm.com/v1/profiles/<profile-id>/links' -H 'Accept: application/json' -H 'Authorization: Bearer <access_token>' -H 'Content-Type: application/json' --data-raw '{
"name": "<link_name>",
"cr_type": "ROKS_SA",
"link": {
"crn": "<cluster_crn>",
"namespace": "<ns>",
"name": "<cluster_name>"
}
}'





3. [Assign the trusted profile to an access group](https://cloud.ibm.com/docs/account?topic=account-groupsaccess_ag_api) with access policies to the IBM Cloud services that you want your apps to have access to.



Your clusters can now establish trust with IBM Cloud IAM. Next, your developers can [configure their application pods to exchange the identity token for an IAM token to authenticate requests to IBM Cloud services](https://cloud.ibm.com/docs/openshift?topic=openshift-pod-iam-identityiam-identity-pod).





 Creating an IAM trusted profile for your cluster in the UI 

As an account administrator, create a trusted profile in IBM Cloud Identity and Access Management. For more information, see the [IAM documentation](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile&interface=ui).
ibmcloud login [--sso]
2. If the cluster is in a resource group other than default, target that resource group. To see the resource group that each cluster belongs to, run ibmcloud ks cluster ls. Note: You must have at least the [Viewer role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the resource group.

ibmcloud target -g <resource_group_name>
3. Get the name of your cluster.

ibmcloud ks cluster ls
4. Retrieve the service endpoint URLs for your cluster.



* If only the Private Service Endpoint URL is populated, get this URL. Your authorized cluster users can access the master through this endpoint on the private network.
* If both the Public Service Endpoint URL and Private Service Endpoint URL are populated, get both URLs. Your authorized cluster users can access the master through the public endpoint on the public network or the private endpoint on the private network.



ibmcloud ks cluster get --cluster <cluster_name_or_ID>

Example output

...
Public Service Endpoint URL: https://c3.<region>.containers.cloud.ibm.com:30426
Private Service Endpoint URL: https://c3-private.<region>.containers.cloud.ibm.com:31140
...
5. Allow access to the service endpoint URLs and ports that you got in the previous step. If your allowlist is IP-based, you can see which IP addresses are opened when you allow access to the service endpoint URLs by reviewing [this table](https://cloud.ibm.com/docs/containers?topic=containers-firewallmaster_ips).
6. Verify your connection.



* If the public cloud service endpoint is enabled:

curl --insecure <public_service_endpoint_URL>/version

Example command
Verify that the role or cluster role is created.



* Role:

kubectl get roles -n <namespace>
* Cluster role:

kubectl get clusterroles





2. Bind users to the role or cluster role.



1. Create a .yaml file to bind users to your role or cluster role. Note the unique URL to use for each subject's name.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: my_role_binding
namespace: default
subjects:
- kind: User
name: IAMuser1@example.com
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: team1
apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
name: <service_account_name>
namespace: <kubernetes_namespace>
roleRef:
kind: Role
name: my_role
apiGroup: rbac.authorization.k8s.io
Show more



Table 3. Understanding the YAML parameters

 Parameter Description 

 kind <br><br> * Specify RoleBinding for a namespace-specific Role or ClusterRole.<br> * Specify ClusterRoleBinding for a cluster-wide ClusterRole.<br><br><br> 
 apiVersion <br><br> * For clusters that run Kubernetes 1.8 or later, use rbac.authorization.k8s.io/v1.<br> * For earlier versions, use apiVersion: rbac.authorization.k8s.io/v1beta1.<br><br><br> 
 metadata.namespace <br><br> * For kind RoleBinding: Specify the Kubernetes namespace to which access is granted.<br> * For kind ClusterRoleBinding: Don't use the namespace field.<br><br><br> 
 metadata.name Name the role binding or cluster role binding.
In case the person leaves the team, the functional ID user remains the API key owner.
* [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



To set up the API key to access the IBM Cloud infrastructure portfolio:



1. Create an API key for the region and resource group that the cluster is in.



1. Log in to the command line with the user whose infrastructure permissions you want to use.
2. 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 ks api-key reset --region <region>
4. Verify that the API key is set up.

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



2. [Create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-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 ks credential set](https://cloud.ibm.com/docs/containers?topic=containers-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.
Controlling traffic with network policies 

Classic clusters

This network policy information is specific to classic clusters. For network policy information for VPC clusters, see [Controlling traffic with security groups](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group).

Every IBM Cloud® Kubernetes Service cluster comes with a network plug-in called Calico. Default network policies secure the public network interface of every worker node in the cluster.

You can use Calico and Kubernetes to create network policies for a cluster. With Kubernetes network policies, you can specify the network traffic that you want to allow or block to and from a pod within a cluster. To set more advanced network policies such as blocking inbound (ingress) traffic to network load balancer (NLB) services, use Calico network policies.

Kubernetes network policies
: [Kubernetes network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) specify how pods can communicate with other pods and with external endpoints. Both incoming and outgoing network traffic is allowed or blocked based on protocol, port, and source or destination IP addresses. Traffic can also be filtered based on pod and namespace labels. You can apply Kubernetes network policies by using kubectl commands or the Kubernetes APIs.

Calico network policies
: [Calico network policies](https://docs.tigera.io/calico/latest/reference/resources/networkpolicy) are a set of the Kubernetes network policies. You can apply Calico policies by using the calicoctl command line. Calico policies add the following features.



* Allow or block network traffic on specific network interfaces regardless of the Kubernetes pod source or destination IP address or CIDR.
* Allow or block network traffic for pods across namespaces.
* [Block inbound traffic to Kubernetes LoadBalancer or NodePort services](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesblock_ingress).
* Replace <profile-id>, <access_token>, <cluster_crn>, and <cluster_name> with the values that you previously retrieved.
* For <ns>, enter the namespace in your cluster. You can list namespaces by logging in to the cluster and running kubectl get ns. The Kubernetes namespace that you enter does not have to exist already. Any future namespace with this name can establish trust.

curl -L -X POST 'https://iam.cloud.ibm.com/v1/profiles/<profile-id>/links' -H 'Accept: application/json' -H 'Authorization: Bearer <access_token>' -H 'Content-Type: application/json' --data-raw '{
"name": "<link_name>",
"cr_type": "IKS_SA",
"link": {
"crn": "<cluster_crn>",
"namespace": "<ns>",
"name": "<cluster_name>"
}
}'





3. [Assign the trusted profile to an access group](https://cloud.ibm.com/docs/account?topic=account-groupsaccess_ag_api) with access policies to the IBM Cloud services that you want your apps to have access to.



Your clusters can now establish trust with IBM Cloud IAM. Next, your developers can [configure their application pods to exchange the identity token for an IAM token to authenticate requests to IBM Cloud services](https://cloud.ibm.com/docs/containers?topic=containers-pod-iam-identity&interface=uiiam-identity-pod).





 Creating an IAM trusted profile for your cluster in the UI 

As an account administrator, create a trusted profile in IBM Cloud Identity and Access Management. For more information, see the [IAM documentation](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile&interface=ui).
: If you set up [VPC security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group) or [VPC access control lists (ACLs)](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-acls) to secure your cluster network, you can now create the rules to allow the necessary traffic from the control plane IP addresses and Akamai IPv4 IP addresses to health check your routers. Previously, a quota on the number of rules per security group or ACL prevented the ability to create all necessary rules for health checks.





 10 May 2021 

New! PX-Backup is now available
: For more information, see [Backing up and restoring apps and data with PX-Backup](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_backup).

Cluster autoscaler add-on
: [Patch update 1.0.2_267](https://cloud.ibm.com/docs/openshift?topic=openshift-ca_changelog) of the cluster autoscaler add-on is available.

IBM Cloud Object Storage plug-in
: [Version 2.0.9](https://cloud.ibm.com/docs/openshift?topic=openshift-cos_plugin_changelog) of the IBM Cloud Object Storage plug-in is available.

Worker node versions
oc get svc router-external-default -n openshift-ingress

In the following example output, node port 30783 is exposed for public traffic (80).

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
router-external-default LoadBalancer 172.21.84.172 169.xx.xxx.xxx, 169.xx.xxx.xxx 80:30783/TCP,443:30413/TCP 24h
2. Using these IP addresses and the node port, create a layer 4 load balancer that is connected to your hosts' private network. For example, you might deploy a load balancer from your hosts' cloud provider, or deploy an F5 load balancer to your on-premises network. To create public routes, the load balancer must have public network connectivity and must be able to forward TCP and UDP traffic to the port for public traffic that you found in the previous step. To create private routes, the load balancer must be able to forward TCP and UDP traffic to the port for private traffic that you found in the previous step.
3. Get the Hostname for your cluster. This subdomain in the format <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud is registered with your cluster's Ingress controller.

ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>
4. Add the public IP addresses of your load balancer to your cluster's subdomain. Repeat this command for all public IP addresses that you want to add.

ibmcloud oc nlb-dns add --ip <public_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>
5. Remove the worker node IP addresses from your cluster's subdomain. Repeat this command for all IP addresses that you retrieved earlier.

ibmcloud oc nlb-dns rm classic --ip <private_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>
6.
The name or ID of the cluster group that includes the Red Hat OpenShift on IBM Cloud clusters where you want to deploy the configuration version. To list available cluster groups, run ibmcloud sat group ls.

--config CONFIG
: Required. The name of the configuration where you added the Kubernetes resource definition as a version that you want to deploy to your clusters. To list available configurations, run ibmcloud sat config ls.

--auth-required
: Include this option to use authentication when connecting to the remote repository. This option is used only when you create a Subscription to a Configuration using the GitOps strategy.

--gitref GITREF
: The GitRef to use for the Satellite subscription. This option is used only when you create a Subscription to a Configuration using the GitOps strategy. This option is used only when you create a Subscription to a Configuration using the GitOps strategy.

--gitref-type TYPE
: The type of GitRef to use for the Satellite subscription.This option is used only when you create a Subscription to a Configuration using the GitOps strategy.

--path PATH
: The path to the repository files or release assets in the remote repository that you want to use for the Satellite subscription. This option is used only when you create a Subscription to a Configuration using the GitOps strategy.

--repository REPOSITORY
: The remote repository to use for the Satellite subscription. This option is used only when you create a Subscription to a Configuration using the GitOps strategy.

--version VERSION
: The name or ID of the version that you want to deploy to the clusters in your cluster group. This option is used only when you create a Subscription to a Configuration using the Direct Upload strategy. To list versions in your configuration, run ibmcloud sat config get --config <configuration_name_or_ID>.

-q
: Optional. Do not show the message of the day or update reminders.





 Example 

ibmcloud sat subscription create --name myapp_prod_subscription --group mygroup --config myapp_prod --version 1.0
Cluster health image v1.3.0 v1.3.3 Updated golang.org/x/crypto to v0.0.0-20220214200702-86341886e292. Adds fix for [CVE-2021-43565](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-43565). Adds Golang dependency updates. 
 Gateway-enabled cluster controller 1586 1653 Updated to use Go version 1.17.7 and updated Go modules to fix CVEs. 
 GPU device plug-in and installer 4a174aa d7daae6 Updated GPU images to resolve CVEs. 
 IBM Calico extension 923 929 Updated universal base image (UBI) to the 8.5-230 version to resolve CVEs. Updated to use Go version 1.16.13. 
 IBM Cloud Controller Manager v1.23.3-4 v1.23.4-4 Updated to support the Kubernetes 1.23.4 release and to use Go version 1.17.7. 
 IBM Cloud File Storage for Classic plug-in and monitor 404 405 Adds fix for [CVE-2021-3538](https://nvd.nist.gov/vuln/detail/CVE-2021-3538) and adds dependency updates. 
 Key Management Service provider v2.4.0 v2.5.2 Updated golang.org/x/crypto to v0.0.0-20220214200702-86341886e292. Adds fix for [CVE-2021-43565](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-43565). Adds Golang dependency updates. 
 Konnectivity agent v0.0.27_309_iks v0.0.27_a6b5248a_323_iks See the [Konnectivity release notes](https://github.com/kubernetes-sigs/apiserver-network-proxy/releases/tag/v0.0.27).
Understanding user access permissions 

When you [assign cluster permissions](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms), it can be hard to judge which role you need to assign to a user. Use the tables in the following sections to determine the minimum level of permissions that are required to perform common tasks in IBM Cloud® Kubernetes Service.



 Permissions to create a cluster 

Review the minimum permissions in IBM Cloud IAM that the account owner must set up so that users can create clusters in IBM Cloud Kubernetes Service.

IAM Services
: 

* Administrator platform access role for the Kubernetes Service in the console (containers-kubernetes in the API or CLI) in All resource groups.
* Writer or Manager service access role for Kubernetes Service in the console (containers-kubernetes in the API or CLI) in All resource groups.
* Administrator platform access role for Container Registry in the console (container-registry in the API or CLI) at the Account level. Do not limit policies for IBM Cloud Container Registry to the resource group level.
* If you plan to [expose apps with Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about), assign the user Administrator or Editor platform access role and the Manager service access role for Secrets Manager in All resource groups.
* Viewer platform access role for the resource group access.
* If your account [restricts service ID creation](https://cloud.ibm.com/docs/account?topic=account-restrict-service-id-create), the Service ID creator role to IAM Identity Service in the console (iam-identity in the API or CLI).
* If your account [restricts API key creation](https://cloud.ibm.com/docs/account?topic=account-allow-api-create), the User API key creator role to IAM Identity Service in the console (iam-identity in the API or CLI).
To log in to your cluster, choose from the following options.



* Log in as admin:



1. Make sure that you have the [Administrator platform access role for the cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users).
2. Set your command line context for the cluster and download the TLS certificates and permission files for the administrator.

ibmcloud oc cluster config -c <cluster_name_or_ID> --admin --endpoint private



* Log in with an API key: See [Using an API key to log in to Red Hat OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_api_key).
* Log in with IBM Cloud passcode:



1. Get the Private Service Endpoint URL of your cluster in the output of the following command.

ibmcloud oc cluster get -c <cluster_name_or_ID>
2. In your browser, open the following IBM Cloud IAM passcode website.

https://iam.cloud.ibm.com/identity/passcode
3. Log in with your IBMid and copy the passcode.
4. Log in to your cluster with the passcode.

oc login -u passcode -p <iam_passcode> --server=<private_service_endpoint_URL>





3. Verify that the oc commands run properly with your cluster through the private cloud service endpoint by checking the version.

oc version

Example output

Client Version: 4.5.0-0.okd-2020-09-04-180756
Server Version: 4.5.35
Kubernetes Version: v1.18.3+cdb0358







 Accessing classic clusters through the private cloud service endpoint
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.20.15-19 v1.20.15-23 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.22.15-3 v1.22.15-7 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.5.4 v3.5.5 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.5.5). 
 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.24.7-1 v1.24.7-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.