vania-janet/multiturn-rag-retrieval-data huggingface dataset:
This topic applies only to the cluster autoscaler add-on.

If you upgrade your cluster to a version that isn't supported by the cluster autoscaler add-on, your apps might experience downtime and your cluster might not scale.

The cluster autoscaler has two types of updates.

Patch updates
: Patch updates are delivered automatically by IBM and don't contain any feature updates or changes in the supported add-on and cluster versions.

Release updates
: Release updates contain new features for the cluster autoscaler or changes in the supported add-on or cluster versions. You must manually apply release updates to your cluster autoscaler add-on.



1. Check the version of the cluster autoscaler add-on that is deployed in your cluster. If an update is available, review the [release notes](https://cloud.ibm.com/docs/containers?topic=containers-ca_changelog) for the latest add-on version.

ibmcloud ks cluster addon ls --cluster <cluster_name>
2. Disable the cluster autoscaler add-on. You might see a warning that resources or data might be deleted. For the cluster autoscaler update, any autoscaling operations that are in process when you disable fail. When you re-enable the add-on, the autoscaling operation is restarted for you. Existing cluster autoscaler resources like the iks-ca-configmap are retained even after you disable the add-on. Your worker nodes are not deleted because of disabling the add-on.

ibmcloud ks cluster addon disable cluster-autoscaler --cluster <cluster_name>

Example output

Data and resources that you created for the add-on might be deleted when the add-on is disabled. Continue? [y/N]>
3. Enable the add-on to install the latest version.

ibmcloud ks cluster addon enable cluster-autoscaler --cluster <cluster_name>
4. Verify the add-on is successfully updated and Ready.

ibmcloud ks cluster addon ls --cluster <cluster_name>
: Updated the [Ingress ALB change log](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelog) for versions 0.49.3_1745_iks and 1.0.3_1730_iks.





 18 October 2021 

New troubleshooting topic
: See [Why does my cluster master status say it is approaching its resource limit?](https://cloud.ibm.com/docs/containers?topic=containers-master_resource_limit).





 13 October 2021 

CLI change log
: The [CLI change log](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_changelog) is updated for version 1.0.331.





 11 October 2021 

Unsupported Kubernetes version 1.18
: Kubernetes version 1.18 is unsupported. To continue receiving important security updates and support, you must [update your cluster to a supported version](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsprep-up) immediately.

Worker node fix pack update
: Change log documentation is available for version [1.22.2_1524](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1221222_1524), [1.21.5_1533](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1211215_1533), [1.20.11_1555](https://cloud.ibm.com/docs/containers?topic=containers-changelog_12012011_1555), and [1.19.15_1562](https://cloud.ibm.com/docs/containers?topic=containers-changelog_11911915_1562).





 7 October 2021 

Istio add-on change log
* cluster master: View and modify the master for a cluster.



* cluster master audit-webhook: View and modify the audit webhook configuration for a cluster's Kubernetes API server.



* [ibmcloud ks cluster master audit-webhook get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_apiserver_config_get)
* [ibmcloud ks cluster master audit-webhook set](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_apiserver_config_set)
* [ibmcloud ks cluster master audit-webhook unset](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_apiserver_config_unset)



* cluster master pod-security: View and modify your Pod Security configurations.



* [ibmcloud ks cluster master pod-security get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-get)
* [ibmcloud ks cluster master pod-security set](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-set)
* [ibmcloud ks cluster master pod-security unset](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-unset)
* ibmcloud ks cluster master pod-security policy: View and modify the deprecated Pod Security policy configuration in supported clusters.



* [ibmcloud ks cluster master pod-security policy disable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-policy-disable)
Master proxy 1.8.25-384f42 1.8.26-561f1a See the [HAProxy change logs](https://www.haproxy.org/download/1.8/src/CHANGELOG). 
 Red Hat OpenShift 4.4.16 4.4.18 See the [Red Hat OpenShift release notes](https://docs.openshift.com/container-platform/4.3/release_notes/ocp-4-3-release-notes.htmlocp-4-4-18). 
 RHEL 7 packages 3.10.0-1127.18.2.el7 3.10.0-1127.19.1.el7 Updated worker node image with kernel and package updates. 







 Change log for master fix pack 4.4.17_1515_openshift, released 21 August 2020 

The following table shows the changes that are in the master fix pack patch update 4.4.17_1515_openshift. Master patch updates are applied automatically.



Changes since version 4.4.16_1513_openshift

 Component Previous Current Description 

 Cluster master operations N/A N/A Fixed a problem that might cause cluster master operations to fail for clusters with a private cloud service endpoint enabled. 
 IBM Cloud Controller Manager v1.17.9-1 v1.17.11-1 Updated to support the Kubernetes 1.17.11 release and to use Go version 1.13.15. 
 Red Hat OpenShift 4.4.16 4.4.17 See the [Red Hat OpenShift release notes](https://docs.openshift.com/container-platform/4.4/release_notes/ocp-4-4-release-notes.htmlocp-4-4-17). 







 Change log for master fix pack 4.4.16_1513_openshift, released 18 August 2020 

The following table shows the changes that are in the master fix pack patch update 4.4.16_1513_openshift. Master patch updates are applied automatically.



Changes since version 4.4.11_1511_openshift

 Component Previous Current Description
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. For a complete list of changes, review the [community Kubernetes change logs](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG), [IBM version change logs](https://cloud.ibm.com/docs/containers?topic=containers-changelog), and [Kubernetes helpful warnings](https://kubernetes.io/blog/2020/09/03/warnings/).

For actions you should take before and after updating your cluster, see the version information links in [Available IBM Cloud® Kubernetes Service versions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionscs_versions_available).





 Archive 

Unsupported clusters are not provided with security and patch updates and are not supported by IBM Cloud Support. 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.
Change log for master fix pack 1.24.14_1568, released 23 May 2023 

The following table shows the changes that are in the master fix pack 1.24.14_1568. Master patch updates are applied automatically.



Changes since version 1.24.13_1566

 Component Previous Current Description 

 Cluster health image v1.3.19 v1.3.20 Updated Go to version 1.19.9 and updated dependencies. Updated the base image. Resolved add-on health bugs. 
 etcd v3.5.7 v3.5.8 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.5.8). 
 GPU device plug-in fc4cf22 28d80a0 Updated Go to version 1.19.8 
 IBM Cloud Controller Manager v1.24.13-1 v1.24.13-6 Updated support of the Kubernetes 1.24.13 release. Updated Go dependencies. Key rotation. 
 IBM Cloud RBAC Operator 778ef2b 4e2f346 Make armada-rbac-sync FIPS compliant 
 Key Management Service provider v2.6.5 v2.6.6 Updated Go to version 1.19.9 and updated dependencies. 
 Kubernetes v1.24.13 v1.24.14 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.26.5). 
 Kubernetes NodeLocal DNS cache 1.22.18 1.22.21 See the [Kubernetes NodeLocal DNS cache release notes]([https://github.com/kubernetes/dns/releases/tag/1.22.21](https://github.com/kubernetes/dns/releases/tag/1.22.21)
If a CRN number is listed for your root key, then you do not need to upgrade your cluster.



* Enable the cluster to use root keys to encrypt secrets.
* Cluster secrets are automatically updated after rotating root keys. Note For versions before 4.5.18_1521_openshift, you must rewrite cluster secrets manually after rotating root keys. You can rewrite secrets by using the oc get secrets --all-namespaces -o json | kubectl replace -f - command.
* You can view clusters that use the root key from the KMS provider interface.
* Clusters automatically respond if you disable, enable, or restore root keys.
* Disabling a root key restricts cluster functionality until you reenable the key.
* Deleting a root key makes the cluster unusable and unrecoverable.
* Root keys can't be deleted if the key is used by a cluster.









 Encrypting the Kubernetes secrets by using a KMS provider 

Virtual Private Cloud

Classic infrastructure

Enable a [key management service (KMS) provider](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms) to encrypt the Kubernetes secrets in your cluster.



 Prerequisites 

Before you enable a key management service (KMS) provider in your cluster, create a KMS instance and complete the following steps.

Setting up cross-account encryption by using a KMS in a different account is supported in the CLI or API.



1. Create a KMS instance, such as [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-provisionprovision) or [Hyper Protect Crypto Services](https://cloud.ibm.com/catalog/services/hyper-protect-crypto-services).
2. Create a customer root key (CRK) in your KMS instance.



* [Key Protect root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keyscreate-root-keys).
Change log for master fix pack 1.19.7_1532, released 19 January 2021 

The following table shows the changes that are in the master fix pack patch update 1.19.7_1532. Master patch updates are applied automatically.



Changes since version 1.19.6_1531

 Component Previous Current Description 

 Cluster health image v1.2.4 v1.2.6 Updated image to implement additional IBM security controls. 
 Gateway-enabled cluster controller 1184 1195 Updated image for [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971). 
 GPU device plug-in and installer c26e2ae af5a6cb Updated image for [CVE-2021-3114](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3114), [CVE-2021-3115](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3115), [CVE-2020-27350](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27350), [CVE-2020-29361](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29361), [CVE-2020-29362
You must set the cluster Distributed Resource Schedule (DRS) to manual to prevent unexpected migrations during the upgrade process.

Complete the following steps from the vCenter Server user interface.



1. Select Host and Clusters > Cluster > Configure > DRS.
2. Click EDIT.
3. Set the DRS field to Manual.







 Procedure to create a standard switch for the new vCenter Server Appliance 

Temporarily install the new vCenter Server Appliance that you deploy onto a vSphere Standard Switch. One of the existing vmnics is reassigned from the distributed switch during the upgrade.

Complete the following steps from the vCenter Server user interface.



1. Select Hosts and Clusters > HOST > Configure > Virtual Switches. Select a host for the new vCenter Server Appliance.
2. For the private network switch, select Managed Physical Adapters. The private network switch name ends with -private.
3. Select uplink1/vmnic2, then click the Close icon ![Close icon](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/icons/close-icon.svg) to delete the adapter. Click OK.
4. Return to the Virtual Switches and click Add Networking.



1. Select Virtual Machine Port Group for a standard switch and click Next.
2. For New Standard Switch, set the MTU to 9000 and click Next.
3. Click the green Add icon ![Add icon](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/icons/add.svg) to add an adapter. Click OK, then Next to accept vmnic2.
4. For Connection Settings, keep the VM Network and VLAN ID None defaults. Click Next, then Finish.
[Menu icon](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/icons/icon_hamburger.svg), click Kubernetes.
3. From the Clusters page, click your cluster.
4. From the Worker Nodes tab, select the checkbox for each worker node that you want to update. An action bar is displayed over the table header row.
5. From the action bar, click Update.









 Updating flavors (machine types) 

Before you begin:



* [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)
* Data on the worker node is deleted. Consider storing your data on persistent storage outside of the worker node.
* 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 flavors:



1. List available worker nodes and note their private IP address.

1. List available worker pools in your cluster.
 {: pre}
ibmcloud ks worker-pool ls --cluster CLUSTER

2. List the worker nodes in the worker pool. Note the ID and Private IP.
 {: pre}
ibmcloud ks worker ls --cluster CLUSTER --worker-pool WORKER-POOL

3. Get the details for a worker node. In the output, note the zone and either the private and public VLAN ID for classic clusters or the subnet ID for VPC clusters.
 {: pre}
ibmcloud ks worker get --cluster CLUSTER --worker WORKER-ID

2. List available flavors in the zone.

ibmcloud ks flavors --zone <zone>
3. Create a worker node with the new machine type.



1.
Review the changes included in version 1.0.3 of the managed cluster autoscaler add-on.



 Change log for patch update 1.0.3_360, released 26 August 2021 

Review the changes in version 1.0.3_360 of the cluster autoscaler add-on.



* Image tags: 1.17.4-5, 1.18.3-5, 1.19.1-5, 1.20.0-5, and 1.21.0-1.
* Supported cluster versions: 1.17 to 1.21
* Updates the Golang version to 1.16.6 which includes a fix for PVR0281096.
* Increases the default resource requests and limits.



* Previous values:

resourcesLimitsCPU: "600m"
resourcesLimitsMemory: "600Mi"
resourcesRequestsCPU: "200m"
resourcesRequestsMemory: "200Mi"
* Updated values:

resourcesLimitsCPU: "800m"
resourcesLimitsMemory: "1000Mi"
resourcesRequestsCPU: "200m"
resourcesRequestsMemory: "400Mi"









 Change log for patch update 1.0.3_352, released 23 June 2021 

Review the changes in version 1.0.3_352 of the cluster autoscaler add-on.



* Image tags: 1.17.4-4, 1.18.3-4, 1.19.1-4, 1.20.0-4, and 1.21.0-0.
* Supported cluster versions: 1.17 to 1.21
* Adds support for Kubernetes 1.21.









 Version 1.0.2 

Review the changes that are in version 1.0.2 of the managed cluster autoscaler add-on.



 Change log for patch update 1.0.2_267, released 10 May 2021 

Review the changes in version 1.0.2_267 of the cluster autoscaler add-on.



* Image tags: 1.17.4-3, 1.18.3-3, 1.19.1-3, and 1.20.0-3.
You can check the health, status, and state of the cluster master by running ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

The Master Health reflects the state of master components and notifies you if something needs your attention. The health might be one of the following states.



* error: The master is not operational. IBM is automatically notified and takes action to resolve this issue. You can continue monitoring the health until the master is normal. You can also [open an IBM Cloud support case](https://cloud.ibm.com/docs/containers?topic=containers-get-help).
* normal: The master is operational and healthy. No action is required.
* unavailable: The master might not be accessible, which means some actions such as resizing a worker pool are temporarily unavailable. IBM is automatically notified and takes action to resolve this issue. You can continue monitoring the health until the master is normal.
* unsupported: The master runs an unsupported version of Kubernetes. You must [update your cluster](https://cloud.ibm.com/docs/containers?topic=containers-update) to return the master to normal health.



The Master Status provides details of what operation from the master state is in progress. The status includes a timestamp of how long the master has been in the same state, such as Ready (1 month ago). The Master State reflects the lifecycle of possible operations that can be performed on the master, such as deploying, updating, and deleting. Each state is described in the following table.



Master states

 Master state Description 

 deployed The master is successfully deployed. Check the status to verify that the master is Ready or to see if an update is available. 
 deploying The master is currently deploying. Wait for the state to become deployed before working with your cluster, such as adding worker nodes. 
 deploy_failed The master failed to deploy. IBM Support is notified and works to resolve the issue. Check the Master Status field for more information, or wait for the state to become deployed. 
 deleting The master is currently deleting because you deleted the cluster.
You can upgrade your existing cluster autoscaler release to the latest version of the Helm chart. To check your current release version, run helm list -n <namespace> | grep cluster-autoscaler. Compare your version to the latest available release by reviewing the Chart Version in the [IBM Cloud Helm Catalog](https://cloud.ibm.com/kubernetes/helm/iks-charts/ibm-iks-cluster-autoscaler).



 Prerequisites 

Before you begin to upgrade your cluster autoscaler release, complete the following steps.

This topic applies only to the cluster autoscaler Helm chart.



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. To review the change log of chart versions, [download the source code tar file](https://cloud.ibm.com/kubernetes/helm/iks-charts/ibm-iks-cluster-autoscaler) and open the RELEASENOTES.MD file.







 Upgrading the cluster autoscaler release version 

This topic applies only to the cluster autoscaler Helm chart.

To upgrade your cluster autoscaler release, you can update the Helm chart repo and re-create the cluster autoscaler pods. Use the same version of Helm that you used to install the initial Helm chart and release.

Before you begin, see the [Prerequisites](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_helm_up_prereqs).



1. Update the Helm repo to retrieve the latest version of all Helm charts in this repo.

helm repo update
2. Optional: Download the latest Helm chart to your local machine. Then, extract the package and review the release.md file to find the latest release information.

helm pull iks-charts/ibm-iks-cluster-autoscaler
3. Find the name of the cluster autoscaler release that you installed in your cluster.
Change log for master fix pack 3.11.161_1542_openshift, released 18 February 2020 

The following table shows the changes that are in the master fix pack update 3.11.161_1542_openshift. Master patch updates are applied automatically.



Changes since version 3.11.161_1540_openshift

 Component Previous Current Description 

 Cluster master HA configuration N/A N/A Updated configuration to improve availability during cluster master operations. 
 Heapster v1.5.4 v3.11.161 Replaces [Kubernetes Heapster](https://github.com/kubernetes-retired/heapster/releases/tag/v1.5.4) with [Red Hat OpenShift Heapster](https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.htmlocp-3-11-161). 
 IBM Cloud Controller Manager v1.15.9-240 v1.15.10-252 Updated to support the Kubernetes 1.15.10 release. 







 Change log for worker node fix pack 3.11.170_1543_openshift, released 17 February 2020 

The following table shows the changes that are in the worker node fix pack update 3.11.170_1543_openshift. Worker node patch updates can be applied by updating or reloading the worker node



Changes since version 3.11.161_1542_openshift

 Component Previous Current Description 

 Red Hat OpenShift node 3.11.161 3.11.170 See the [Red Hat OpenShift release notes](https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.htmlocp-3-11-170). Fixes [CVE-2019-11244](https://nvd.nist.gov/vuln/detail/CVE-2019-11244). 







 Change log for worker node fix pack 3.11.161_1542_openshift, released 17 February 2020
You can also [open an IBM Cloud support case](https://cloud.ibm.com/docs/containers?topic=containers-get-help).
* normal: The master is operational and healthy. No action is required.
* unavailable: The master might not be accessible, which means some actions such as resizing a worker pool are temporarily unavailable. IBM is automatically notified and takes action to resolve this issue. You can continue monitoring the health until the master is normal.
* unsupported: The master runs an unsupported version of Kubernetes. You must [update your cluster](https://cloud.ibm.com/docs/containers?topic=containers-update) to return the master to normal health.



The Master Status provides details of what operation from the master state is in progress. The status includes a timestamp of how long the master has been in the same state, such as Ready (1 month ago). The Master State reflects the lifecycle of possible operations that can be performed on the master, such as deploying, updating, and deleting. Each state is described in the following table.



Master states

 Master state Description 

 deployed The master is successfully deployed. Check the status to verify that the master is Ready or to see if an update is available. 
 deploying The master is currently deploying. Wait for the state to become deployed before working with your cluster, such as adding worker nodes. 
 deploy_failed The master failed to deploy. IBM Support is notified and works to resolve the issue. Check the Master Status field for more information, or wait for the state to become deployed. 
 deleting The master is currently deleting because you deleted the cluster. You can't undo a deletion. After the cluster is deleted, you can no longer check the master state because the cluster is completely removed. 
 delete_failed The master failed to delete. IBM Support is notified and works to resolve the issue. You can't resolve the issue by trying to delete the cluster again. Instead, check the Master Status field for more information, or wait for the cluster to delete.