vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Set up the CIS global load balancer by following steps 1 - 5 in [Getting Started with IBM Cloud Internet Services (CIS)](https://cloud.ibm.com/docs/cis?topic=cis-getting-startedgetting-started). These steps walk you through provisioning the service instance, adding your app domain, and configuring your name servers, and creating DNS records. Create a DNS record for each ALB or NLB IP address that you collected. These DNS records map your app domain to all your cluster ALBs or NLBs, and ensure that requests to your app domain are forwarded to your clusters in a round-robin cycle.
3. [Add health checks](https://cloud.ibm.com/docs/cis?topic=cis-configure-glbadd-a-health-check) for the ALBs or NLBs. You can use the same health check for the ALBs or NLBs in all your clusters, or create specific health checks to use for specific clusters.
4. [Add an origin pool](https://cloud.ibm.com/docs/cis?topic=cis-configure-glbadd-a-pool) for each cluster by adding the cluster's ALB or NLB IPs. For example, if you have 3 clusters that each have two ALBs, create three origin pools that each have two ALB IP addresses. You can find the NLB or ALB IP addresses by running kubectl get svc -n <namespace>. Add a health check to each origin pool that you create.
5. [Add a global load balancer](https://cloud.ibm.com/docs/cis?topic=cis-configure-glb).







 Setting up your own global load balancer 



1.
: Some PVC settings, such as the reclaimPolicy, fstype, or the volumeBindingMode can't be set in the Kubernetes secret and must be set in the storage class. As the cluster admin, if you want to enable your cluster users to override your default settings, you must ensure that you set up enough customized storage classes that reference a generic Kubernetes secret so that your users can provision Block Storage for VPC with different reclaimPolicy, fstype, and volumeBindingMode settings.





 Enabling every user to customize the default PVC settings 



1. As the cluster admin, follow the steps to [create a customized storage class](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-customize-storage-class). In the customized storage class YAML file, reference the Kubernetes secret in the metadata.parameters section as follows. Make sure to add the code as-is and not to change variables names.

csi.storage.k8s.io/provisioner-secret-name: ${pvc.name}
csi.storage.k8s.io/provisioner-secret-namespace: ${pvc.namespace}
2. As the cluster user, create a Kubernetes secret that customizes the default settings of the storage class.

apiVersion: v1
kind: Secret
type: vpc.block.csi.ibm.io
metadata:
name: <secret_name>
namespace: <namespace_name>
stringData:
iops: "<IOPS_value>"
zone: "<zone>"
tags: "<tags>"
encrypted: <true_or_false>
resourceGroup: "<resource_group>"
data
encryptionKey: <encryption_key>

name
: Enter a name for your Kubernetes secret.

namespace
: Enter the namespace where you want to create your secret. To reference the secret in your PVC, the PVC must be created in the same namespace.

iops
In any of these cases, you can [check the versions change log](https://cloud.ibm.com/docs/containers?topic=containers-changelog) for any potential impact and choose to safely use the ibmcloud ks cluster master update[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update) yourself without waiting for the update automation to apply.

Unlike the master, you must update your workers for each patch version.

What happens during the master update?
: Your master is highly available with three replica master pods. The master pods have a rolling update, during which only one pod is unavailable at a time. Two instances are up and running so that you can access and change the cluster during the update. Your worker nodes, apps, and resources continue to run.

Can I roll back the update?
: No, you can't roll back a cluster to a previous version after the update process takes place. Be sure to use a test cluster and follow the instructions to address potential issues before you update your production master.

What process can I follow to update the master?
: The following diagram shows the process that you can take to update your master.

Zoom

![Master update process diagram](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers//images/updating-master2.svg)

Figure 1. Updating Kubernetes master process diagram





 Steps to update the cluster master 

Before you begin, make sure that you have the [Operator or Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms).

To update the Kubernetes master major or minor version:



1. Review the [Kubernetes changes](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions) and make any updates marked Update before master.
2.
update_cancelled The master update is canceled because the cluster was not in a healthy state at the time of the update. Your master remains in this state until your cluster is healthy and you manually update the master. To update the master, use the ibmcloud ks cluster master update[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update). If you don't want to update the master to the default major.minor version during the update, include the --version option and specify the latest patch version that is available for the major.minor version that you want, such as 1.26. To list available versions, run ibmcloud ks versions. 
 update_failed The master update failed. IBM Support is notified and works to resolve the issue. You can continue to monitor the health of the master until the master reaches a normal state. If the master remains in this state for more than 1 day, [open an IBM Cloud support case](https://cloud.ibm.com/docs/containers?topic=containers-get-help). IBM Support might identify other issues in your cluster that you must fix before the master can be updated. 









 Setting up IBM Cloud® Monitoring alerts 

When you set up alerts, make sure to allow your cluster enough time to self-heal. Because Kubernetes has self healing capabilities, configure your alerts only for the issues that arise over time. By observing your cluster over time, you can learn which issues Kubernetes can resolve itself and which issues require alerts to avoid downtime.

On 15 June 2022, the naming convention for IBM Cloud® Monitoring alerts is changing to a Prometheus compatible format.
You cannot interact with your cluster while it is in this state. Wait for the etcd restoration to complete and the master state to return to deployed. 
 updating The master is updating its Kubernetes version. The update might be a patch update that is automatically applied, or a minor or major version that you applied by updating the cluster. During the update, your highly available master can continue processing requests, and your app workloads and worker nodes continue to run. After the master update is complete, you can [update your worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-updateworker_node). If the update is unsuccessful, the master returns to a deployed state and continues running the previous version. IBM Support is notified and works to resolve the issue. You can check if the update failed in the Master Status field. 
 update_cancelled The master update is canceled because the cluster was not in a healthy state at the time of the update. Your master remains in this state until your cluster is healthy and you manually update the master. To update the master, use the ibmcloud ks cluster master update[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update). If you don't want to update the master to the default major.minor version during the update, include the --version option and specify the latest patch version that is available for the major.minor version that you want, such as 1.26. To list available versions, run ibmcloud ks versions. 
 update_failed The master update failed. IBM Support is notified and works to resolve the issue. You can continue to monitor the health of the master until the master reaches a normal state. If the master remains in this state for more than 1 day, [open an IBM Cloud support case](https://cloud.ibm.com/docs/containers?topic=containers-get-help). IBM Support might identify other issues in your cluster that you must fix before the master can be updated. 







 Understanding the impact of a master outage
You cannot interact with your cluster while it is in this state. Wait for the etcd restoration to complete and the master state to return to deployed. 
 updating The master is updating its Kubernetes version. The update might be a patch update that is automatically applied, or a minor or major version that you applied by updating the cluster. During the update, your highly available master can continue processing requests, and your app workloads and worker nodes continue to run. After the master update is complete, you can [update your worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-updateworker_node). If the update is unsuccessful, the master returns to a deployed state and continues running the previous version. IBM Support is notified and works to resolve the issue. You can check if the update failed in the Master Status field. 
 update_cancelled The master update is canceled because the cluster was not in a healthy state at the time of the update. Your master remains in this state until your cluster is healthy and you manually update the master. To update the master, use the ibmcloud oc cluster master update[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update). If you don't want to update the master to the default major.minor version during the update, include the --version option and specify the latest patch version that is available for the major.minor version that you want, such as 1.26. To list available versions, run ibmcloud oc versions. 
 update_failed The master update failed. IBM Support is notified and works to resolve the issue. You can continue to monitor the health of the master until the master reaches a normal state. If the master remains in this state for more than 1 day, [open an IBM Cloud support case](https://cloud.ibm.com/docs/containers?topic=containers-get-help). IBM Support might identify other issues in your cluster that you must fix before the master can be updated. 







 Understanding the impact of a master outage
Your worker nodes, apps, and resources continue to run.

Can I roll back the update?
: No, you can't roll back a cluster to a previous version after the update process takes place. Be sure to use a test cluster and follow the instructions to address potential issues before you update your production master.

What process can I follow to update the master?
: The following diagram shows the process that you can take to update your master.

Zoom

![Master update process diagram](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift//images/updating-master2.svg)

Figure 1. Updating Kubernetes master process diagram





 Steps to update the cluster master 

Before you begin, make sure that you have the [Operator or Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms).

To update the Red Hat OpenShift master major or minor version:



1. Review the [Red Hat OpenShift changes](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions) and make any updates marked Update before master.
2. Review any [Kubernetes helpful warnings](https://kubernetes.io/blog/2020/09/03/warnings/), such as deprecation notices.
3. Check the add-ons and plug-ins that are installed in your cluster for any impact that might be caused by updating the cluster version.



* Checking add-ons



1. List the add-ons in the cluster.

ibmcloud oc cluster addon ls --cluster CLUSTER
2. Check the supported Red Hat OpenShift version for each add-on that is installed.

ibmcloud oc addon-versions
3.
ibmcloud ks cluster master refresh --cluster CLUSTER [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

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





 ibmcloud ks cluster master update 

Virtual Private Cloud

Classic infrastructure

Satellite

Update the Kubernetes master and API server. During the update, you can't access or change the cluster. Worker nodes, apps, and resources that were deployed are not modified and continue to run.

You might need to change your YAML files for future deployments. Review this [release note](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions) for details.

The cluster-update alias for this command is deprecated.

ibmcloud ks cluster master update --cluster CLUSTER [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--version MAJOR.MINOR.PATCH
: Optional: The Kubernetes version of the cluster. If you don't specify a version, the Kubernetes master is updated to the default API version. To see available versions, run [ibmcloud ks versions](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clics_versions_command).

--force-update
: Optional: Attempt the update even if the change is greater than two minor versions from the worker node version.

-f
: Optional: Force the command to run with no user prompts.

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



 Example cluster master update command
ibmcloud oc cluster master refresh 

Virtual Private Cloud

Classic infrastructure

Apply configuration changes for the Kubernetes master that are requested with the ibmcloud oc cluster master commands. The highly available Kubernetes master components are restarted in a rolling restart. Your worker nodes, apps, and resources are not modified and continue to run.

The apiserver-refresh and cluster-refresh aliases for this command are deprecated.

ibmcloud oc cluster master refresh --cluster CLUSTER [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

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





 ibmcloud oc cluster master update 

Virtual Private Cloud

Classic infrastructure

Satellite

Update the Kubernetes master and API server. During the update, you can't access or change the cluster. Worker nodes, apps, and resources that were deployed are not modified and continue to run.

You might need to change your YAML files for future deployments. Review this [release note](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions) for details.

The cluster-update alias for this command is deprecated.

ibmcloud oc cluster master update --cluster CLUSTER [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--version MAJOR.MINOR.PATCH
: Optional: The Kubernetes version of the cluster. If you don't specify a version, the Kubernetes master is updated to the default API version.
ibmcloud ks cluster master refresh --cluster CLUSTER [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

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





 ibmcloud ks cluster master update 

Virtual Private Cloud

Classic infrastructure

Satellite

Update the Kubernetes master and API server. During the update, you can't access or change the cluster. Worker nodes, apps, and resources that were deployed are not modified and continue to run.

You might need to change your YAML files for future deployments. Review this [release note](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions) for details.

The cluster-update alias for this command is deprecated.

ibmcloud ks cluster master update --cluster CLUSTER [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--version MAJOR.MINOR.PATCH
: Optional: The Kubernetes version of the cluster. If you don't specify a version, the Kubernetes master is updated to the default API version. To see available versions, run [ibmcloud ks versions](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_versions_command).

--force-update
: Optional: Attempt the update even if the change is greater than two minor versions from the worker node version.

-f
: Optional: Force the command to run with no user prompts.

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



 Example cluster master update command 

ibmcloud ks cluster master update --cluster my_cluster
If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
* [Update the master](https://cloud.ibm.com/docs/containers?topic=containers-updatemaster). The worker node version can't be higher than the API server version that runs in your Kubernetes master.
* Make any changes that are marked with Update after master in the [Kubernetes version preparation guide](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).
* If you want to apply a patch update, review the [Kubernetes version change log](https://cloud.ibm.com/docs/containers?topic=containers-changelog).
* Consider [adding more worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-add_workers) so that your cluster has enough capacity to rescheduling your workloads during the update.
* Make sure that you have the [Operator or Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms).







 Updating classic worker nodes in the CLI with a configmap 

Set up a ConfigMap to perform a rolling update of your classic worker nodes.



1. Complete the [prerequisite steps](https://cloud.ibm.com/docs/containers?topic=containers-updateworker-up-prereqs).
2. List available worker nodes and note their private IP address.

ibmcloud ks worker ls --cluster CLUSTER
3. View the labels of a worker node. You can find the worker node labels in the Labels section of your CLI output. Every label consists of a NodeSelectorKey and a NodeSelectorValue.

kubectl describe node PRIVATE-WORKER-IP

Example output

NAME: 10.184.58.3
Roles: <none>
The Kubernetes API server that runs in your Kubernetes master is being updated to a new Kubernetes API version. During the update, you can still access and change the cluster. However, you cannot initiate concurrent master operations, such as enabling API server auditing. Worker nodes, apps, and resources that the user deployed aren't modified and continue to run. Wait for the update to complete to review the health of your cluster.





 Unsupported 

Review the following description of the Unsupported cluster state. To view the state of your cluster, run ibmcloud ks cluster get --cluster <cluster_name_or_ID>.

The [Kubernetes version](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionscs_versions) that the cluster runs is no longer supported. Your cluster's health is no longer actively monitored or reported. Additionally, you can't add or reload worker nodes. To continue receiving important security updates and support, you must update your cluster. Review the [version update preparation actions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsprep-up), then [update your cluster](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate) to a supported Kubernetes version.





 Warning 

Review the following description of the Warning cluster state. To view the state of your cluster, run ibmcloud ks cluster get --cluster <cluster_name_or_ID>.

At least one worker node in the cluster is not available, but other worker nodes are available and can take over the workload. Try to [reload](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_reload) the unavailable worker nodes. - Your cluster has zero worker nodes, such as if you created a cluster without any worker nodes or manually removed all the worker nodes from the cluster.
If the cluster master runs two or more versions behind the oldest supported version, you can no longer apply updates and must delete the cluster and create a new one.
5. Archived: The version is unsupported with no upgrade path. IBM provides no support. IBM reserves the right to shut down the control planes for such clusters.



If you wait until your cluster is two or more minor versions behind the oldest supported version, you can't update the cluster. Instead, [create a new cluster](https://cloud.ibm.com/docs/containers?topic=containers-clustersclusters), [deploy your apps](https://cloud.ibm.com/docs/containers?topic=containers-appapp) to the new cluster, and [delete](https://cloud.ibm.com/docs/containers?topic=containers-remove) the unsupported cluster. To avoid this issue, update deprecated clusters to a supported version that is one or two behind the current version, such as 1.21 or 1.22 and then update to the latest version, 1.23. If the worker nodes run a version two or more behind the master, you might see your pods fail by entering a state such as MatchNodeSelector, CrashLoopBackOff, or ContainerCreating until you update the worker nodes to the same version as the master. After you update from a deprecated to a supported version, your cluster can resume normal operations and continue receiving support. You can find out whether your cluster is unsupported by reviewing the State field in the output of the ibmcloud ks cluster ls command or in the [IBM Cloud Kubernetes Service console](https://cloud.ibm.com/kubernetes/clusters).





 Preparing to update 

Updating a cluster to a new version from the previous version is likely to have an impact on deployed apps.
Although your cluster and apps might continue to run for a time, you can no longer create, reload, or take other corrective actions on your cluster master or worker nodes when an issue occurs. You can still delete the cluster or worker nodes, or update the cluster to the next version. Review the potential impacts and immediately [update the cluster](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate) to continue receiving important security updates and support. If your cluster master is two or more versions behind the oldest supported version, you must [make a new cluster](https://cloud.ibm.com/docs/containers?topic=containers-clustersclusters) and [deploy your apps](https://cloud.ibm.com/docs/containers?topic=containers-appapp) to the new cluster.

Unsupported Kubernetes versions
: [Archived version history](https://cloud.ibm.com/docs/containers?topic=containers-cs_sitemapsitemap_archived_version_history)