vania-janet/multiturn-rag-retrieval-data huggingface dataset:
After you label your worker pool, you can use the [label in your app deployments](https://cloud.ibm.com/docs/containers?topic=containers-applabel) so that your workloads run on only these worker nodes, or [taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) to prevent deployments from running on these worker nodes.





 Automatically resolving issues for your worker nodes 

Critical components, such as containerd, kubelet, kube-proxy, and calico, must be functional to have a healthy Kubernetes worker node. Over time these components can break and might leave your worker node in a nonfunctional state. Nonfunctional worker nodes decrease total capacity of the cluster and can result in downtime for your app.

You can [configure health checks for your worker node and enable Autorecovery](https://cloud.ibm.com/docs/containers?topic=containers-health-monitorautorecovery). If Autorecovery detects an unhealthy worker node based on the configured checks, Autorecovery triggers a corrective action like an OS reload on the worker node. For more information about how Autorecovery works, see the [Autorecovery blog](https://www.ibm.com/cloud/blog/autorecovery-utilizes-consistent-hashing-high-availability).
* [Change log for worker node fix pack 1.8.15_1521, released 20 September 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1815_1521)
* [Change log for worker node fix pack 1.8.15_1520, released 23 August 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1815_1520)
* [Change log for worker node fix pack 1.8.15_1519, released 13 August 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1815_1519)
* [Change log for 1.8.15_1518, released 27 July 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1815_1518)
* [Change log for worker node fix pack 1.8.13_1516, released 3 July 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1813_1516)
* [Change log for worker node fix pack 1.8.13_1515, released 21 June 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1813_1515)
* [Change log 1.8.13_1514, released 19 June 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1813_1514)
* [Change log for worker node fix pack 1.8.11_1512, released 11 June 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1811_1512)
* [Change log for worker node fix pack 1.8.11_1511, released 18 May 2018](https://cloud.ibm.com/docs/containers?topic=containers-18_changelog1811_1511)
RHEL 7 Packages N/A N/A Worker node package updates for [CVE-2022-42898](https://nvd.nist.gov/vuln/detail/CVE-2022-42898). 
 RHEL 8 Packages N/A N/A Worker node package updates for [CVE-2022-42898](https://nvd.nist.gov/vuln/detail/CVE-2022-42898). 
 Red Hat OpenShift on IBM Cloud. 4.8.52 4.8.54 For more information, see the [change log](https://docs.openshift.com/container-platform/4.8/release_notes/ocp-4-8-release-notes.htmlocp-4-8-54). 
 HAProxy c619f4 508bf6 [CVE-2016-3709](https://nvd.nist.gov/vuln/detail/CVE-2016-3709), [CVE-2022-42898](https://nvd.nist.gov/vuln/detail/CVE-2022-42898), [CVE-2022-1304](https://nvd.nist.gov/vuln/detail/CVE-2022-1304). 







 Change log for worker node fix pack 4.8.52_1581_openshift, released 21 November 2022 

The following table shows the changes that are in the worker node fix pack 4.8.52_1581_openshift. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 4.8.52_1579_openshift

 Component Previous Current Description
Replica sets guarantee that if the CA node goes down, the CA replica immediately begins processing requests. You must provision an instance of a PostgreSQL database if you plan to use CA replica sets. See these instructions for more information about [how to configure CA replica sets](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-ha-ca).

This scenario uses redundant peers, ordering nodes, and CAs on a single worker node, which protects against component failure, but cannot protect from node failure. Therefore, it is only suitable for development and testing purposes.
2. Worker node failure.

Single-zone cluster with multiple worker nodes and anti-affinity:

A worker node is a VM that runs on a physical hardware. Worker node failures include hardware outages, such as power, cooling, or networking, and issues on the VM itself. You can account for a worker node failure by setting up multiple worker nodes when you provision your cluster. When blockchain components are distributed across multiple worker nodes, you are protected from a worker node failure.

Peers The IBM Blockchain Platform deployer anti-affinity policy distributes redundant peers, that is peers from the same organization, across the worker nodes in their cluster.

Ordering service Whenever you deploy a Raft ordering service, the five ordering nodes are automatically distributed across the worker nodes in your cluster, using the anti-affinity policy and based on resource availability on the nodes.

CAs Like peers and ordering nodes, if replica sets are chosen for a CA, an anti-affinity policy automatically distributes the CA replica sets across worker nodes in the cluster, based on resource availability.

This scenario uses redundant peers, ordering nodes, and CA replica sets, across multiple worker nodes in a single cluster or zone, which protects against node failure, but cannot protect from a cluster or zone failure. Therefore, it is not recommended for production.







 Multizone HA 

Zoom

!
Red Hat OpenShift on IBM Cloud toolkit 4.8.0+20210917 4.8.0+20211004 See the [Red Hat OpenShift on IBM Cloud toolkit release notes](https://github.com/openshift/ibm-roks-toolkit/releases/tag/v4.8.0+20211004). 







 Change log for worker node fix pack 4.8.15_1532_openshift, released 25 October 2021 

The following table shows the changes that are in the worker node fix pack patch update 4.8.15_1532_openshift. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 4.8.13_1528_openshift

 Component Previous Current Description 

 Red Hat OpenShift 4.8.13 4.8.15 See [the Red Hat OpenShift change logs](http://docs.openshift.com/container-platform/4.8/release_notes/ocp-4-8-release-notes.html). 
 RHEL 7 Packages 3.10.0-1160.42.2.el7 3.10.0-1160.45.1.el7 Updated worker node images and kernel with package updates for [CVE-2021-3778](https://nvd.nist.gov/vuln/detail/CVE-2021-3778) and [CVE-2021-3796](https://nvd.nist.gov/vuln/detail/CVE-2021-3796). 
 Worker-pool taint automation N/A N/A Fixes known issue related to worker-pool taint automation that prevents workers from getting providerID. 







 Change log for worker node fix pack 4.8.13_1528_openshift, released 11 October 2021 

The following table shows the changes that are in the worker node fix pack patch update 4.8.13_1528_openshift.
Ubuntu 16.04 packages N/A N/A Updated worker node image with package updates for [CVE-2020-11936](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11936), [CVE-2020-15701](https://nvd.nist.gov/vuln/detail/CVE-2020-15701), [CVE-2020-15702](https://nvd.nist.gov/vuln/detail/CVE-2020-15702), and [CVE-2020-15709](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15709). 







 Change log for worker node fix pack 1.18.6_1523, released 3 August 2020 

The following table shows the changes that are in the worker node fix pack 1.18.6_1523. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.18.6_1520

 Component Previous Current Description
Ubuntu 16.04 packages N/A N/A Updated worker node image with package updates for [CVE-2020-11936](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11936), [CVE-2020-15701](https://nvd.nist.gov/vuln/detail/CVE-2020-15701), [CVE-2020-15702](https://nvd.nist.gov/vuln/detail/CVE-2020-15702), and [CVE-2020-15709](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15709). 







 Change log for worker node fix pack 1.15.12_1549, released 3 August 2020 

The following table shows the changes that are in the worker node fix pack 1.15.12_1549. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.15.12_1546

 Component Previous Current Description
Ubuntu 16.04 packages N/A N/A Updated worker node image with package updates for [CVE-2020-11936](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11936), [CVE-2020-15701](https://nvd.nist.gov/vuln/detail/CVE-2020-15701), [CVE-2020-15702](https://nvd.nist.gov/vuln/detail/CVE-2020-15702), and [CVE-2020-15709](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15709). 







 Change log for worker node fix pack 1.17.9_1535, released 3 August 2020 

The following table shows the changes that are in the worker node fix pack 1.17.9_1535. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.17.9_1532

 Component Previous Current Description
Ubuntu 16.04 packages N/A N/A Updated worker node image with package updates for [CVE-2020-11936](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11936), [CVE-2020-15701](https://nvd.nist.gov/vuln/detail/CVE-2020-15701), [CVE-2020-15702](https://nvd.nist.gov/vuln/detail/CVE-2020-15702), and [CVE-2020-15709](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15709). 







 Change log for worker node fix pack 1.16.13_1542, released 3 August 2020 

The following table shows the changes that are in the worker node fix pack 1.16.13_1542. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.16.13_1539

 Component Previous Current Description
* [Change log for worker node fix pack 4.10.52_1556_openshift, released 27 February 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_41041052_1556_openshift)
* [Change log for worker node fix pack 4.10.51_1555_openshift, released 13 February 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_41041051_1555_openshift)
* [Change log for master fix pack 4.10.47_1553_openshift, released 30 January 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_41041047_1553_openshift)
* [Change log for worker node fix pack 4.10.50_1554_openshift, released 30 January 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_41041050_1554_openshift)
* [Change log for worker node fix pack 4.10.47_1551_openshift, released 16 January 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_41041047_1551_openshift)
* [Change log for worker node fix pack 4.10.45_1550_openshift, released 02 January 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_41041045_1550_openshift)
* [Change log for worker node fix pack 4.10.45_1549_openshift, released 19 December 2022](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_41041045_1549_openshift)
* [Change log for worker node fix pack 4.8.57_1588_openshift, released 30 January 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_484857_1588_openshift)
* [Change log for worker node fix pack 4.8.55_1586_openshift, released 16 January 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_484855_1586_openshift)
* [Change log for worker node fix pack 4.8.55_1585_openshift, released 02 January 2023](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_484855_1585_openshift)
* [Change log for worker node fix pack 4.8.54_1584_openshift, released 19 December 2022](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_484854_1584_openshift)
* [Change log for master fix pack 4.8.54_1583_openshift, released 14 December 2022](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_484854_1583_openshift)
* [Change log for worker node fix pack 4.8.54_1582_openshift, released 05 December 2022](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_484854_1582_openshift)
* [Change log for worker node fix pack 4.8.52_1581_openshift, released 21 November 2022](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_484852_1581_openshift)
Ubuntu 16.04 packages 4.4.0-187-generic 4.4.0-189-generic Updated worker node image with kernel and package updates for [CVE-2020-14344](https://nvd.nist.gov/vuln/detail/CVE-2020-14344) and [CVE-2020-14363](https://nvd.nist.gov/vuln/detail/CVE-2020-14363). 







 Change log for worker node fix pack 1.15.12_1551, released 31 August 2020 

The following table shows the changes that are in the worker node fix pack 1.15.12_1551. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.15.12_1550

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Updated worker node image with package updates for [CVE-2020-12403](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12403), [CVE-2020-8231](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8231), [CVE-2020-8622](https://nvd.nist.gov/vuln/detail/CVE-2020-8622), [CVE-2020-8623](https://nvd.nist.gov/vuln/detail/CVE-2020-8623), and [CVE-2020-8624](https://nvd.nist.gov/vuln/detail/CVE-2020-8624).
Ubuntu 16.04 packages 4.4.0-187-generic 4.4.0-189-generic Updated worker node image with kernel and package updates for [CVE-2020-14344](https://nvd.nist.gov/vuln/detail/CVE-2020-14344) and [CVE-2020-14363](https://nvd.nist.gov/vuln/detail/CVE-2020-14363). 







 Change log for worker node fix pack 1.16.14_1545, released 31 August 2020 

The following table shows the changes that are in the worker node fix pack 1.16.14_1545. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.16.14_1544

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Updated worker node image with package updates for [CVE-2020-12403](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12403), [CVE-2020-8231](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8231), [CVE-2020-8622](https://nvd.nist.gov/vuln/detail/CVE-2020-8622), [CVE-2020-8623](https://nvd.nist.gov/vuln/detail/CVE-2020-8623), and [CVE-2020-8624](https://nvd.nist.gov/vuln/detail/CVE-2020-8624).
Ubuntu 16.04 packages 4.4.0-187-generic 4.4.0-189-generic Updated worker node image with kernel and package updates for [CVE-2020-14344](https://nvd.nist.gov/vuln/detail/CVE-2020-14344) and [CVE-2020-14363](https://nvd.nist.gov/vuln/detail/CVE-2020-14363). 







 Change log for worker node fix pack 1.18.8_1526, released 31 August 2020 

The following table shows the changes that are in the worker node fix pack 1.18.8_1526. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.18.8_1525

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Updated worker node image with package updates for [CVE-2020-12403](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12403), [CVE-2020-8231](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8231), [CVE-2020-8622](https://nvd.nist.gov/vuln/detail/CVE-2020-8622), [CVE-2020-8623](https://nvd.nist.gov/vuln/detail/CVE-2020-8623), and [CVE-2020-8624](https://nvd.nist.gov/vuln/detail/CVE-2020-8624).
Ubuntu 16.04 packages 4.4.0-187-generic 4.4.0-189-generic Updated worker node image with kernel and package updates for [CVE-2020-14344](https://nvd.nist.gov/vuln/detail/CVE-2020-14344) and [CVE-2020-14363](https://nvd.nist.gov/vuln/detail/CVE-2020-14363). 







 Change log for worker node fix pack 1.17.11_1538, released 31 August 2020 

The following table shows the changes that are in the worker node fix pack 1.17.11_1538. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.17.11_1537

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Updated worker node image with package updates for [CVE-2020-12403](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12403), [CVE-2020-8231](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8231), [CVE-2020-8622](https://nvd.nist.gov/vuln/detail/CVE-2020-8622), [CVE-2020-8623](https://nvd.nist.gov/vuln/detail/CVE-2020-8623), and [CVE-2020-8624](https://nvd.nist.gov/vuln/detail/CVE-2020-8624).
For console and CLI commands to assign these permissions, see [Classic infrastructure roles](https://cloud.ibm.com/docs/containers?topic=containers-classic-roles).
2. Make sure that the [infrastructure credentials owner for the API key or the manually set account has the correct permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsowner_permissions). You can change the [API key](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_api_key_reset) or [manually set](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_set) infrastructure credentials owner for the region and resource group.



3. Test that the changed permissions permit authorized users to perform infrastructure operations for the cluster.



1. For example, you might try to a delete a worker node.

ibmcloud ks worker rm --cluster <cluster_name_or_ID> --worker <worker_node_ID>
2. Check to see if the worker node is removed.

ibmcloud ks worker get --cluster <cluster_name_or_ID> --worker <worker_node_ID>

Example output shows if the worker node removal is successful. The worker get operation fails because the worker node is deleted. The infrastructure permissions are correctly set up.

FAILED
The specified worker node could not be found. (E0011)
3. If the worker node is not removed, review the [State and Status fields](https://cloud.ibm.com/docs/containers?topic=containers-debug_worker_nodes) and the [common issues with worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-common_worker_nodes_issues) to continue debugging.
4.
The Autorecovery system uses various checks to query worker node health status. If Autorecovery detects an unhealthy worker node based on the configured checks, Autorecovery triggers a corrective action like rebooting a VPC worker node or reloading the operating system in a classic worker node. Only one worker node undergoes a corrective action at a time. The worker node must complete the corrective action before any other worker node undergoes a corrective action. For more information, see this [Autorecovery blog post](https://www.ibm.com/cloud/blog/autorecovery-utilizes-consistent-hashing-high-availability).

Autorecovery requires at least one healthy worker node to function properly. Configure Autorecovery with active checks only in clusters with two or more worker nodes.

Before you begin:



* Ensure that you have the following [IBM Cloud IAM roles](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms):



* Administrator platform access role for the cluster
* Writer or Manager service access role for the kube-system namespace



* [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 configure Autorecovery:



1. [Follow the instructions](https://cloud.ibm.com/docs/containers?topic=containers-helminstall_v3) to install the Helm version 3 client on your local machine.
2. Create a configuration map file that defines your checks in JSON format. For example, the following YAML file defines three checks: an HTTP check and two Kubernetes API server checks.
If you [customized stub domains and upstream DNS servers for CoreDNS](https://cloud.ibm.com/docs/containers?topic=containers-cluster_dnsdns_customize), you must also [customize the NodeLocal DNS cache](https://cloud.ibm.com/docs/containers?topic=containers-cluster_dnsdns_nodelocal_customize) with these stub domains and upstream DNS servers.
3. List the nodes in your cluster. The NodeLocal DNS caching agent pods are part of a daemon set that run on each node.

kubectl get nodes
4. Add the ibm-cloud.kubernetes.io/node-local-dns-enabled=true label to the worker node. The label starts the DNS caching agent pod on the worker node.



1. Add the label to one or more worker nodes.



* To label all worker nodes in the cluster: [Add the label to all existing worker pools](https://cloud.ibm.com/docs/containers?topic=containers-add_workersworker_pool_labels).
* To label an individual worker node:

kubectl label node <node_name> --overwrite "ibm-cloud.kubernetes.io/node-local-dns-enabled=true"



2. Verify that the node has the label by checking that the NODE-LOCAL-DNS-ENABLED field is set to true.

kubectl get nodes -L "ibm-cloud.kubernetes.io/node-local-dns-enabled"

Example output

NAME STATUS ROLES AGE VERSION NODE-LOCAL-DNS-ENABLED
10.xxx.xx.xxx Ready,SchedulingDisabled <none> 28h v1.26+IKS true
3. Verify that the DNS caching agent pod is running on the worker node.

kubectl get pods -n kube-system -l k8s-app=node-local-dns -o wide

Example output

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
To find the device path after you attach the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.
* Select a device on a worker node where you want Portworx to create the journal.



4. If you want to use a specific device for the internal Portworx KVDB, choose from the following options.



* Attach an additional disk to at least 3 worker nodes use for the KVDB, add a 3 GB block storage device to at least 3 worker nodes in your cluster and find the device path. To find the device path after attaching the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.
* Select one of the block storage devices that you added earlier to use for the KVDB and find the device path. To find the device path after attaching the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.



5. Continue with your Portworx setup by [Setting up a key-value store for Portworx metadata](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store).