vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Change log for worker node fix pack 1.19.9_1542, released 12 April 2021 

The following table shows the changes that are in the worker node fix pack 1.19.9_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.19.9_1541

 Component Previous Current Description 

 HA proxy 9b2dca a3b1ff The update addresses [CVE-2021-3449](https://nvd.nist.gov/vuln/detail/CVE-2021-3449) and [CVE-2021-3450](https://nvd.nist.gov/vuln/detail/CVE-2021-3450). 
 Ubuntu 18.04 packages N/A N/A Updated worker node images with package updates for [CVE-2021-22876](https://nvd.nist.gov/vuln/detail/CVE-2021-22876). 
 Ubuntu 16.04 packages N/A N/A Updated worker node images with package updates for [CVE-2021-22876](https://nvd.nist.gov/vuln/detail/CVE-2021-22876). 







 Change log for master fix pack 1.19.9_1540, released 30 March 2021 

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



Changes since version 1.19.8_1538

 Component Previous Current Description 

 Activity Tracker event N/A N/A Now, the containers-kubernetes.version.update event is sent to Activity Tracker when a master fix pack update is initiated for a cluster. 
 Cluster health image v1.2.8 v1.2.9 Updated image for [CVE-2020-28851](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28851).
Why does block storage change to read-only? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

You might see the following symptoms:



* When you run kubectl get pods -o wide, you see that multiple pods on the same worker node are stuck in the ContainerCreating or CrashLoopBackOff state. All these pods use the same block storage instance.
* When you run a kubectl describe pod command, you see the following error in the Events section: MountVolume.SetUp failed for volume ... read-only.



 Why it’s happening 

If a network error occurs while a pod writes to a volume, IBM Cloud infrastructure protects the data on the volume from getting corrupted by changing the volume to a read-only mode. Pods that use this volume can't continue to write to the volume and fail.

 How to fix it 

Verify the plug-in version, re-create your app, and safely reload your worker node.



1. Check the version of the IBM Cloud Block Storage plug-in that is installed in your cluster.

helm list --all-namespaces
2. Verify that you use the [latest version of the IBM Cloud Block Storage plug-in](https://cloud.ibm.com/kubernetes/helm/iks-charts/ibmcloud-block-storage-plugin). If not, [update your plug-in](https://cloud.ibm.com/docs/containers?topic=containers-block_storageupdate_block).
3. If you used a Kubernetes deployment for your pod, restart the pod that is failing by removing the pod and letting Kubernetes re-create it. If you did not use a deployment, retrieve the YAML file that was used to create your pod by running kubectl get pod <pod_name> -o yaml >pod.yaml. Then, delete and manually re-create the pod.

kubectl delete pod <pod_name>
4. Check whether re-creating your pod resolved the issue. If not, reload the worker node.



1.
Additionally, the type of cluster and the number of worker pools that you have can impact the size of your cluster.



* Single zone clusters: [Create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters) with 2 worker nodes in the default worker pool.
* Multizone clusters: You must [create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters) with 1 worker node per zone in the worker pool. Later, you can [remove zones](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_zone_rm) from the worker pool or [remove individual worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_rm) so that your cluster size reduces to the minimum size of 2.
* Worker pools: For any type of cluster, each worker pool must always have at least 1 worker node. For the smallest size cluster possible, you can have only 1 worker pool.



Keep in mind that some services such as Ingress might require multiple worker nodes for high availability, and you might not be able to run these services or your apps in the smallest size cluster possible.

Classic clusters only: Initially, you can create a classic cluster with only 1 worker node. This operation is allowed for multizone clusters, so that you are not forced to create 2 worker nodes per zone. If you have a single zone cluster, resize the worker pool to 2. Also, note that after resizing a worker pool to 2, you can't later resize back down to 1 worker node.
* Which Red Hat OpenShift versions does the service support?

Red Hat OpenShift on IBM Cloud concurrently supports multiple versions of Red Hat OpenShift. When a new version (n) is released, versions up to 2 behind (n-2) are supported. Versions more than 2 behind the latest (n-3) are first deprecated and then unsupported.
When you run this command, a new worker or workers are added to your worker pool so that the worker pool has the same number of nodes per zone that you specified.

ibmcloud ks worker-pool rebalance --cluster CLUSTER --worker-pool WORKER_POOL [-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.

-p, --worker-pool WORKER_POOL
: Required: The worker pool that you want to rebalance.

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



 Example worker-pool rebalance command 

ibmcloud ks worker-pool rebalance --cluster my_cluster --worker-pool my_pool







 ibmcloud ks worker-pool resize 

Virtual Private Cloud

Classic infrastructure

Resize your worker pool to increase or decrease the number of worker nodes that are in each zone of your cluster. Your worker pool must have at least 1 worker node.

ibmcloud ks worker-pool resize --cluster CLUSTER --worker-pool WORKER_POOL --size-per-zone WORKERS_PER_ZONE [-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 for which you want to resize worker pools.

--worker-pool WORKER_POOL
: Required: The name of the worker node pool that you want to update.

--size-per-zone WORKERS_PER_ZONE
: The number of workers that you want to have in each zone. This value is required, and must be 1 or greater. For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/containers?topic=containers-faqssmallest_cluster).

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



 Example worker-pool resize command
* UI
* API







 Using services with classic infrastructure assets 

You can easily use API-based public IBM Cloud® services with your classic infrastructure assets. All APIs are secure and encrypted so that your data is protected.

You can gain insights and cognitive knowledge by calling Watson APIs from your apps to make them more personalized. Or, use data and analytics services to tap into high-performance analytics for your apps. Or, choose database-as-a-service where you can leave the management to IBM Cloud.

Modernize your application development by using containers with services like Active Deploy and Delivery Pipeline. You can then use the IBM® VPN service to communicate and connect your container in a private network to the classic infrastructure private network. All of the usage charges of the compute resources and services are reflected in your IBM Cloud invoice.



 Add a service to classic infrastructure assets 

For example, do you want to add cognitive capabilities from Watson to your apps that are running on classic infrastructure bare metal servers? You can add a service such as Personality Insights to help understand your app's user by completing the following steps:



1. In the IBM Cloud console, search for the service in the catalog.
2. Create an instance of the service with just a few clicks.
3. Set up the service to run with your existing code by copying the service credentials and adding them to your application.
4. After the update to the app, deploy the new version to your classic infrastructure assets.







 Add a service to classic infrastructure assets by using the API 

For example, do you want to add cognitive capabilities from Watson to your apps that are running on classic infrastructure bare metal servers? You can add a service such as Personality Insights to help understand your app's user by completing the following steps:



1. Create an instance of the service by calling [Resource Controller API](https://cloud.ibm.com/apidocs/resource-controller/resource-controller?code=gocreate-resource-instance) as shown in the following example request:



* Curl
* Java
* Python
* Go
* Node
Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes. These worker node fix packs can be at a higher version than the master because some build fix packs are specific to worker nodes. Other change logs are for master fix packs, and apply only to the cluster master. Master fix packs might not be automatically applied. You can choose to [apply them manually](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update). For more information about patch types, see [Update types](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsupdate_types).





 Version 1.25 change log 

Review the version 1.25 change log.



 Change log for worker node fix pack 1.25.11_1550, released 03 July 2023 

The following table shows the changes that are in the worker node fix pack 1.25.11_1550. 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.25.10_1548

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Worker node package updates for [CVE-2023-2603](https://nvd.nist.gov/vuln/detail/CVE-2023-2603),[CVE-2023-3138](https://nvd.nist.gov/vuln/detail/CVE-2023-3138)
Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes. These worker node fix packs can be at a higher version than the master because some build fix packs are specific to worker nodes. Other change logs are for master fix packs, and apply only to the cluster master. Master fix packs might not be automatically applied. You can choose to [apply them manually](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update). For more information about patch types, see [Update types](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsupdate_types).





 Version 1.27 change log 

Review the version 1.27 change log.



 Change log for worker node fix pack 1.27.3_1530, released 03 July 2023 

The following table shows the changes that are in the worker node fix pack 1.27.3_1530. 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.27.2_1528

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Worker node package updates for [CVE-2023-2603](https://nvd.nist.gov/vuln/detail/CVE-2023-2603),[CVE-2023-3138](https://nvd.nist.gov/vuln/detail/CVE-2023-3138)
Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes. These worker node fix packs can be at a higher version than the master because some build fix packs are specific to worker nodes. Other change logs are for master fix packs, and apply only to the cluster master. Master fix packs might not be automatically applied. You can choose to [apply them manually](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update). For more information about patch types, see [Update types](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsupdate_types).





 Version 1.26 change log 

Review the version 1.26 change log.



 Change log for worker node fix pack 1.26.6_1542, released 03 July 2023 

The following table shows the changes that are in the worker node fix pack 1.26.6_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.26.5_1540

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Worker node package updates for [CVE-2023-2603](https://nvd.nist.gov/vuln/detail/CVE-2023-2603),[CVE-2023-3138](https://nvd.nist.gov/vuln/detail/CVE-2023-3138)
Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes. These worker node fix packs can be at a higher version than the master because some build fix packs are specific to worker nodes. Other change logs are for master fix packs, and apply only to the cluster master. Master fix packs might not be automatically applied. You can choose to [apply them manually](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update). For more information about patch types, see [Update types](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsupdate_types).





 Version 1.24 change log 

Review the version 1.24 change log.



 Change log for worker node fix pack 1.24.15_1574, released 03 July 2023 

The following table shows the changes that are in the worker node fix pack 1.24.15_1574. 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.24.14_1572

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Worker node package updates for [CVE-2023-2603](https://nvd.nist.gov/vuln/detail/CVE-2023-2603),[CVE-2023-3138](https://nvd.nist.gov/vuln/detail/CVE-2023-3138)
Using reservations to reduce classic worker node costs 

When you have consistent computing needs over time of at least one year, create a reservation to reduce the costs of worker nodes in your Red Hat® OpenShift® on IBM Cloud® clusters. With a reservation, you reserve virtual worker node instances in a contract for a fixed, predictable, and lower price than regular instances.

Reservations are available only for classic infrastructure worker nodes in multizone regions (MZRs). Also note that you can't enable the cluster autoscaler add-on on worker pools that use reservations.

Reservations are available only for allowlisted accounts. For more information, see [Requesting access to allowlisted features](https://cloud.ibm.com/docs/openshift?topic=openshift-get-helpallowlist-access-request).



 Understanding reservations 

A reservation is a type of IBM Cloud resource that you set up to describe the flavor, location, and other details of worker nodes that you want to purchase. Then, you create contracts for the reservation, which are agreements to pay a certain amount each month for a certain number of worker nodes for 1 or 3 year terms.

Review the following diagram for an example scenario of how you might set up your reservation and contracts to use across clusters.

Zoom

![Overview of reservations for Red Hat OpenShift on IBM Cloud.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/reservations-ov.png)

Figure 1. An example scenario of using a reservation for worker nodes in your clusters.

Reservation: The reservation contains details such as the container platform, worker node flavor, location, and infrastructure provider.

Contract: The example reservation has two contracts for different terms. One contract is for 10 worker nodes across 3 years. The other contract is for 5 worker nodes across 1 year. Therefore, the total capacity of the reservation is 15 worker nodes.

Clusters: Each cluster is in the same multizone region as the reservation, but can be in a different resource group.
Red Hat OpenShift 4.3.25 4.3.27 See the [Red Hat OpenShift release notes](https://docs.openshift.com/container-platform/4.3/release_notes/ocp-4-3-release-notes.htmlocp-4-3-27). 
 Worker node drain automation N/A N/A Fixes a race condition that can cause worker node drain automation to fail. 







 Change log for master fix pack 4.3.23_1527_openshift and worker node fix pack 4.3.25_1527_openshift, released 22 June 2020 

The following table shows the changes that are in the master fix pack update 4.3.23_1527_openshift and in worker node fix pack update 4.3.25_1527_openshift. Master patch updates are applied automatically. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node. For more information, see [Update types](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions).



Changes since version 4.3.23_1525_openshift

 Component Location Previous Current Description 

 Cluster health image Master v1.1.7 v1.1.8 Improved performance when handling cluster status updates. 
 CRI-O Worker 1.16.5 1.16.6 See [CRI-O change logs](https://github.com/cri-o/cri-o/releases/tag/v1.16.6). 
 Gateway-enabled cluster controller Master N/A N/A Added missing Calico deny-public-nodeport global network policy for gateway-enabled clusters. 
 IBM Cloud Controller Manager Master v1.17.6-4 v1.17.7-1 Updated to support the Kubernetes 1.17.7 release.
When you create a classic cluster, the cluster's worker nodes are connected automatically to a private VLAN and optionally connected to a public VLAN. A VLAN configures a group of worker nodes and pods as if they were attached to the same physical wire and provides a channel for connectivity among the workers.

You can't create classic Red Hat OpenShift on IBM Cloud clusters that are connected to a private VLAN only. Your worker nodes must be connected to both public and private VLANs.



 VLAN connections for worker nodes 

All worker nodes must be connected to a private VLAN so that each worker node can send information to and receive information from other worker nodes. The private VLAN provides private subnets that are used to assign private IP addresses to your worker nodes and private app services. You can create a cluster with worker nodes that are also connected to a public VLAN. The public VLAN provides public subnets that are used to assign public IP addresses to your worker nodes and public app services. However, if you need to secure your apps from the public network interface, several options are available to secure your cluster such as creating [Calico network policies](https://cloud.ibm.com/docs/containers?topic=containers-network_policies) or isolating external network workloads to [edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edge).

The first time that you create a cluster in a zone, a public VLAN and a private VLAN in that zone are automatically provisioned for you in your IBM Cloud infrastructure account. If you specify that worker nodes must be connected to a private VLAN only, then a private VLAN only in that zone is automatically provisioned. For every subsequent cluster that you create in that zone, you can specify the VLAN pair that you want to use. You can reuse the same public and private VLANs that were created for you because multiple clusters can share VLANs.

For more information about VLANs, subnets, and IP addresses, see [Overview of networking in IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-subnetsbasics).
Review the percentage of usage of CPU and memory across the worker nodes in your cluster. If the usage is consistently over 80%, [add more worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-add_workers) to the cluster to support the workloads.



5. Check for custom admission controllers that are installed in your cluster. Admission controllers often block required pods from running, which might make your worker nodes enter a critical state. If you have custom admission controllers, try removing them with kubectl delete. Then, check if the worker node issue resolves.

kubectl get mutatingwebhookconfigurations --all-namespaces

kubectl get validatingwebhookconfigurations --all-namespaces
6. If you configured [log forwarding](https://cloud.ibm.com/docs/containers?topic=containers-health), review the node-related logs from the following paths.

/var/log/containerd.log
/var/log/kubelet.log
/var/log/kube-proxy.log
/var/log/syslog
7. Check that a workload deployment does not cause the worker node issue.



1. Taint the worker node with the issue.

kubectl taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
2. Make sure that you deleted any custom admission controllers as described in step 5.
3. Restart the worker node.



* Classic: Reload the worker node.

ibmcloud ks worker reload -c <cluster_name_or_ID> --worker <worker_ID>
* VPC: Replace the worker node.

ibmcloud ks worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update



4. Wait for the worker node to finish restarting. If the worker node enters a healthy state, the issue is likely caused by a workload.
5.