vania-janet/multiturn-rag-retrieval-data huggingface dataset:
: When you [create a worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_pool), you specify how many worker nodes per zone it has. The worker pool maintains that number of worker nodes until you [resize](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_pool_resize) or [rebalance](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_rebalance) it. The worker pool does not add or remove worker nodes for you. If you have more pods than can be scheduled, the pods remain in pending state until you resize the worker pool. When you enable the cluster autoscaler for a worker pool, worker nodes are scaled up or down in response to your pod spec settings and resource requests. You don't need to resize or rebalance the worker pool manually.





 Following scalable deployment practices 

Make the most out of the cluster autoscaler by using the following strategies for your worker node and workload deployment strategies. For more information, see the [Kubernetes Cluster Autoscaler FAQs](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md).
When you add a zone, worker nodes are added to the new zone to match the number of workers per zone that you specified for the worker pool. You can add more than one zone only if your cluster is in a multizone metro.

ibmcloud oc zone add satellite --zone ZONE --cluster CLUSTER [--worker-pool WORKER_POOL] [--output json] [-q]

Minimum required permissions: IBM Cloud IAM Administrator platform access role for Satellite.

Command options:

--zone ZONE
: Required. The name of the zone that you want to add. To see the zone names for your location, run ibmcloud sat location get --location <location_name_or_ID> and look for the Host Zones field.

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

-p, --worker-pool WORKER_POOL
: The name of the worker pool to add the zone to. To specify multiple worker pools, use multiple options, such as -p pool1 -p pool2.

--output json
: Optional: Prints the command output in JSON format.

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



 Example zone add satellite command 

Satellite

ibmcloud oc zone add satellite --zone myzone2 --cluster my_cluster -p pool1 -p pool2
When you add a zone, worker nodes are added to the new zone to match the number of workers per zone that you specified for the worker pool. You can add more than one zone only if your cluster is in a multizone metro.

To add a zone to worker pools in a VPC cluster, use the [ibmcloud ks zone add vpc-gen2 command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_zone-add-vpc-gen2).

ibmcloud ks zone add classic --zone ZONE --cluster CLUSTER [--worker-pool WORKER_POOL] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--private-only] [--output json] [-q]

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

Command options:

--zone ZONE
: Required: The zone that you want to add. The zone must be a [multizone-capable zone](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) within the cluster's region.

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

-p, --worker-pool WORKER_POOL
: The name of the worker pool to add the zone to. To specify multiple worker pools, use multiple options, such as -p pool1 -p pool2.

--private-vlan PRIVATE_VLAN
: The ID of the private VLAN. This value is conditional. If you have a private VLAN in the zone, this value must match the private VLAN ID of one or more of the worker nodes in the cluster. To see the VLANs that you have available, run ibmcloud ks cluster get --cluster <cluster> --show-resources. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.
* Worker node fix packs 1.23.17_1574, 1.24.12_1564, 1.25.8_1541, and 1.26.3_1533.



* [5 April 2023](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-apr0523)



* Cluster autoscaler add-on versions 1.0.6_1010, 1.0.7_1021, and 1.0.8_1016.
* Block Storage for VPC add-on versions 5.0.10_1869 and 5.1.6_1872.



* [4 April 2023](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-apr0423)



* Ingress ALB version 1.4.0_3953_iks, 1.5.1_3951_iks, and 1.6.4_3947_iks



* [3 April 2023](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-apr0323)



* Pod Security admission
* IBM Cloud Object Storage plug-in version 2.2.13





* [March 2023](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-mar23)



* [29 March 2023](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-mar2923)



* Worker node fix packs 1.23.17_1572, 1.24.12_1562, 1.25.8_1539, and 1.26.3_1531.
* Block Storage for VPC add-on versions 5.0.9_1862 and 5.1.5_1857.
* Cluster autoscaler add-on versions 1.0.7_988 and 1.0.8_987.
Version 1.8 change log (Unsupported) 

Review the version 1.8 change logs.



 Change log for worker node fix pack 1.8.15_1521, released 20 September 2018 



Table 1. Changes since version 1.8.15_1520

 Component Previous Current Description 

 Log rotate N/A N/A Switched to use systemd timers instead of cronjobs to prevent logrotate from failing on worker nodes that are not reloaded or updated within 90 days. Note: In all earlier versions for this minor release, the primary disk fills up after the cron job fails because the logs are not rotated. The cron job fails after the worker node is active for 90 days without being updated or reloaded. If the logs fill up the entire primary disk, the worker node enters a failed state. The worker node can be fixed by using the [ibmcloud ks worker reload command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_reload) or the [ibmcloud ks worker update command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update). 
 Worker node runtime components (kubelet, kube-proxy, docker) N/A N/A Removed dependencies of runtime components on the primary disk. This enhancement prevents worker nodes from failing when the primary disk is filled up. 
 Root password expiration N/A N/A Root passwords for the worker nodes expire after 90 days for compliance reasons. If your automation tooling needs to log in to the worker node as root or relies on cron jobs that run as root, you can disable the password expiration by logging into the worker node and running chage -M -1 root. Note: If you have security compliance requirements that prevent running as root or removing password expiration, don't disable the expiration.
Worker communication to other services or networks with a gateway appliance 

To securely connect your worker nodes and apps to an on-premises network or services outside of IBM Cloud, set up an IPSec VPN endpoint on your gateway appliance and the strongSwan IPSec VPN service in your cluster to use the gateway VPN endpoint. If you don't want to use strongSwan, you can set up VPN connectivity directly with VRA.

Your worker nodes can securely communicate with other IBM Cloud services and public services outside of IBM Cloud through your gateway appliance. You can configure your firewall allow access to the public and private IP addresses of only the services that you want to use





 External communication to apps that run on worker nodes with a gateway appliance 

To provide private access to an app in your cluster, you can create a private network load balancer (NLB) or Ingress application load balancer (ALB) to expose your app to the private network only. If you need to provide limited public access to an app in your cluster, you can create a public NLB or ALB to expose your app. Because all traffic goes through your gateway appliance firewall, you can control public and private traffic to the network services that expose your apps by opening up the service's ports and IP addresses in your firewall to permit inbound traffic to these services.

Ready to get started with a cluster for this scenario? After you plan your [high availability](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clusters) and [worker node](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodes) setups, see [Creating clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters).
When you add a zone, worker nodes are added to the new zone to match the number of workers per zone that you specified for the worker pool. You can add more than one zone only if your cluster is in a multizone metro.

To add a zone to worker pools in a VPC cluster, use the [ibmcloud ks zone add vpc-gen2 command](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clicli_zone-add-vpc-gen2).

ibmcloud ks zone add classic --zone ZONE --cluster CLUSTER [--worker-pool WORKER_POOL] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--private-only] [--output json] [-q]

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

Command options:

--zone ZONE
: Required: The zone that you want to add. The zone must be a [multizone-capable zone](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) within the cluster's region.

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

-p, --worker-pool WORKER_POOL
: The name of the worker pool to add the zone to. To specify multiple worker pools, use multiple options, such as -p pool1 -p pool2.

--private-vlan PRIVATE_VLAN
: The ID of the private VLAN. This value is conditional. If you have a private VLAN in the zone, this value must match the private VLAN ID of one or more of the worker nodes in the cluster. To see the VLANs that you have available, run ibmcloud ks cluster get --cluster <cluster> --show-resources. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.
Allow worker nodes to communicate with other IBM Cloud services that support private cloud service endpoints, and in clusters that run Kubernetes version 1.19 or earlier, with the cluster master through the private cloud service endpoint. Allow ALL 166.8.0.0/14 <br><br> * <br><br><br> Any <br><br> * <br><br><br> After 1 
 Multizone clusters: Allow worker nodes in one subnet to communicate with the worker nodes in other subnets within the cluster. Create one rule for each subnet that you want to connect to. Allow ALL Other subnet's CIDR <br><br> * <br><br><br> Any <br><br> * <br><br><br> After 2 
 Allow incoming traffic requests to apps that run on your worker nodes. Allow TCP Any Any Any 30000 - 32767 After 3 
 To expose apps by using load balancers or Ingress, allow traffic through VPC load balancers. For example, for Ingress listening on TCP/443) Allow TCP Any Any Any 443 After 4 
 * Allow access from the Kubernetes control plane IP addresses that are used to health check and report the overall status of your Ingress components. Create one rule for each [control plane CIDR for the region where your cluster is located](https://github.com/IBM-Cloud/kube-samples/tree/master/control-plane-ips) Allow TCP Each [control plane CIDR for the region where your cluster is located](https://github.com/IBM-Cloud/kube-samples/tree/master/control-plane-ips) <br><br> * <br><br><br> Any 80 After 5 
 Deny all other traffic that does not match the previous rules. Deny ALL Any <br><br> * <br><br><br> Any <br><br> * <br><br><br> Set to bottom
The check in the example YAML runs every 3 minutes. If it fails three consecutive times, the worker node is reloaded. This action is equivalent to running ibmcloud ks worker reload. For example, the default PodFailureThresholdPercent is 50%. If the percentage of NotReady pods is greater than 50% three consecutive times, the worker node is reloaded. The check runs on all namespaces by default. To restrict the check to only pods in a specified namespace, add the Namespace field to the check. The pod check is enabled until you set the Enabled field to false or remove the check. Note that reloading is supported only for worker nodes on classic infrastructure.
* checkhttp.json: Defines an HTTP check that checks if an HTTP server that runs on your worker node is healthy. To use this check, you must deploy an HTTP server on every worker node in your cluster by using a [daemon set](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/). You must implement a health check that is available at the /myhealth path and that can verify whether your HTTP server is healthy. You can define other paths by changing the Route parameter. If the HTTP server is healthy, you must return the HTTP response code that is defined in ExpectedStatus. The HTTP server must be configured to listen on the private IP address of the worker node. You can find the private IP address by running kubectl get nodes. For example, consider two nodes in a cluster that have the private IP addresses 10.10.10.1 and 10.10.10.2. In this example, two routes are checked for a 200 HTTP response: http://10.10.10.1:80/myhealth and http://10.10.10.2:80/myhealth. The check in the example YAML runs every 3 minutes. If it fails three consecutive times, the worker node is rebooted. This action is equivalent to running ibmcloud ks worker reboot. The HTTP check is disabled until you set the Enabled field to true.







 Understanding the individual components of health checks
Migrating your worker nodes to RHEL 8 

With the release of RHEL 8, the use of RHEL 7 worker nodes is deprecated in clusters that run version 4.10. You cannot upgrade RHEL 7 worker nodes to RHEL 8.

Instead, you must provision a new worker pool and then delete the previous worker pool. In versions 4.10 and later, worker nodes in the new worker pool run RHEL 8 by default. See [Migrating to a new Red Hat Enterprise Linux version](https://cloud.ibm.com/docs/openshift?topic=openshift-rhel_migrate).
Testing access to apps with NodePorts 

Virtual Private Cloud

Classic infrastructure

Satellite

Make your containerized app available to internet access by using the public IP address of any worker node in a Kubernetes cluster and exposing a NodePort. Use this option for testing in IBM Cloud® Kubernetes Service and for short-term public access.



 About NodePorts 

Expose a public port on your worker node and use the public IP address of the worker node to access your service in the cluster publicly from the internet.

When you expose your app by creating a Kubernetes service of type NodePort, a NodePort in the range of 30000 - 32767 and an internal cluster IP address is assigned to the service. The NodePort service serves as the external entry point for incoming requests for your app. The assigned NodePort is publicly exposed in the kubeproxy settings of each worker node in the cluster. Every worker node starts listening on the assigned NodePort for incoming requests for the service. To access the service from the internet, you can use the public IP address of any worker node that was assigned during cluster creation and the NodePort in the format <IP_address>:<nodeport>. If you want to access the service on the private network, use the private IP address of any worker node instead of the public IP address.

The following diagram shows how communication is directed from the internet to an app when a NodePort service is configured.

Zoom

![Expose an app in IBM Cloud Kubernetes Service by using NodePort](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/nodeport.svg)

Figure 1. Expose an app by using NodePort



1. A request is sent to your app by using the public IP address of your worker node and the NodePort on the worker node.
2. The request is automatically forwarded to the NodePort service's internal cluster IP address and port. The internal cluster IP address is accessible inside the cluster only.
3.
Red Hat OpenShift on IBM Cloud Metrics Server and toolkit v4.8.0-20220920 v4.8.0-20221104 See the [Red Hat OpenShift on IBM Cloud toolkit release notes](https://github.com/openshift/ibm-roks-toolkit/releases/tag/v4.8.0+20221104). 







 Change log for worker node fix pack 4.8.52_1579_openshift, released 07 November 2022 

The following table shows the changes that are in the worker node fix pack 4.8.52_1579_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.51_1576_openshift

 Component Previous Current Description
The file storage volume is provisioned through the image-registry-storage persistent volume claim (PVC).

openshift-ingress, openshift-ingress-operator
: Red Hat OpenShift uses [routes](https://docs.openshift.com/container-platform/4.11/networking/routes/route-configuration.html) to directly expose an app's service on a hostname so that external clients can reach the service. To create routes, the cluster uses the Ingress operator. You can also use [Ingress](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-about-roks4) to expose apps externally and customize routing. Ingress consists of three components: the Ingress operator, Ingress controller, and Route resources. The Ingress controller maps the service to the hostname. By default, the Ingress controller includes two replicas. Make sure that your cluster has at least two worker nodes so that the Ingress controller can run on separate compute hosts for higher availability.

openshift-marketplace
: The marketplace includes the [OperatorHub](https://docs.openshift.com/container-platform/4.11/operators/understanding/olm-understanding-operatorhub.html) that comes with the Red Hat OpenShift cluster by default. The OperatorHub includes operators from Red Hat and 3rd-party providers. Keep in mind that these operators are provided by the community, might not integrate with your cluster, and are not supported by IBM. You can [enable operators](https://cloud.ibm.com/docs/openshift?topic=openshift-operators) from the OperatorHub in Red Hat OpenShift web console.

openshift-monitoring
: OpenShift Container Platform includes a [built-in monitoring stack](http://docs.openshift.com/container-platform/4.11/monitoring/monitoring-overview.html) for your cluster, that includes metrics and alert managing capabilities.
Red Hat OpenShift on IBM Cloud. 4.12.4 4.12.6 For more information, see the [change log](https://docs.openshift.com/container-platform/4.12/release_notes/ocp-4-12-release-notes.htmlocp-4-12-6). 







 Change log for master fix pack 4.12.3_1530_openshift, released 2 March 2023 

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



Changes since version 4.12.2_1527_openshift

 Component Previous Current Description 

 Cluster health image v1.3.15 v1.3.16 Updated Go dependencies and to Go version 1.19.6. Updated universal base image (UBI) to resolve CVEs. 
 etcd v3.5.6 v3.5.7 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.5.7). 
 IBM Calico extension 1305-amd64 1308-amd64 Updated universal base image (UBI) to resolve [CVE-2022-47629](https://nvd.nist.gov/vuln/detail/CVE-2022-47629). 
 IBM Cloud Controller Manager v1.25.6-8 v1.25.6-10 Updated Go dependencies. Updated k8s.io/utils digest to a5ecb01.
Red Hat OpenShift on IBM Cloud does not support the [Portworx experimental InitializerConfiguration admission controller](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/hyperconvergence/initializer-experimental-feature-in-stork-v1-1).





 Can I install Portworx in a private cluster? 

Yes. If you want to install Portworx in a private cluster, your IBM Cloud account must be set up with [Virtual Routing and Forwarding (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) and access to private cloud service endpoints for IBM Cloud services.

If you want to install Portworx in a cluster that doesn't have VRF or access to private cloud service endpoints (CSEs), you must create a rule in the default security group to allow inbound and outbound traffic for the following IP addresses: 166.9.24.81, 166.9.22.100, 166.9.20.178. For more information, see [Updating the default security group](https://cloud.ibm.com/docs/vpc?topic=vpc-updating-the-default-security-groupupdating-the-default-security-group).





 What's next? 

All set? Let's start with [creating a cluster with an SDS worker pool of at least three worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters). If you want to include non-SDS worker nodes into your Portworx cluster, [add raw block storage](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesmanual_block) to each worker node. After your cluster is prepared, [install Portworx](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_deploy) in your cluster and create your first hyper-converged storage cluster.
Red Hat OpenShift on IBM Cloud. 4.9.57 4.9.59 For more information, see the [change log](https://docs.openshift.com/container-platform/4.9/release_notes/ocp-4-9-release-notes.htmlocp-4-9-59). 
 Haproxy 8398d1 8895ad [CVE-2023-0361](https://nvd.nist.gov/vuln/detail/CVE-2023-0361). 







 Change log for master fix pack 4.9.57_1583_openshift, released 28 March 2023 

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



Changes since version 4.9.55_1579_openshift

 Component Previous Current Description 

 Cluster health image v1.3.16 v1.3.17 Updated Go to version 1.19.7 and updated dependencies. 
 etcd v3.4.23 v3.4.24 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.24). 
 IBM Calico extension 1308-amd64 1366-amd64 Updated to resolve [CVE-2023-23916](https://nvd.nist.gov/vuln/detail/CVE-2023-23916). 
 IBM Cloud Block Storage driver and plug-in v2.3.7 v2.4.0 Removed ExpandInUsePersistentVolumes feature gate. 
 IBM Cloud File Storage for Classic plug-in and monitor 427 429 Updated universal base image (UBI) to resolve CVEs. Updated Go to version 1.19.6 and updated dependencies. 
 Key Management Service provider v2.6.3 v2.6.4 Updated Go to version 1.19.7 and updated dependencies. 
 Load balancer and load balancer monitor for IBM Cloud Provider 2383 2420 Updated the image to resolve CVEs.
Red Hat OpenShift on IBM Cloud toolkit 4.10.0+20230123 4.10.0+20230220 See the [Red Hat OpenShift on IBM Cloud toolkit release notes](https://github.com/openshift/ibm-roks-toolkit/releases/tag/v4.10.0+20230220). 







 Change log for worker node fix pack 4.10.52_1556_openshift, released 27 February 2023 

The following table shows the changes that are in the worker node fix pack 4.10.52_1556_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.10.51_1555_openshift

 Component Previous Current Description