vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Plan your [worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes).





Looking for serverless? Try [Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started).





 Create a cluster 

Create a cluster with infrastructure, network, and availability setups that are customized to your use case and cloud environment.



1. Firewall: If you have corporate firewalls, make sure that you [open the required ports and IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-firewallcorporate) to work with IBM Cloud Kubernetes Service.
2. CLI and API:



1. [Set up the CLIs](https://cloud.ibm.com/docs/containers?topic=containers-cli-install) that are necessary to create and work with clusters. As you work with your cluster, refer to the [command reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli) and keep track of CLI version updates with the [CLI change log](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_changelog).
2. Optionally set up [automated deployments with the API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_install). As you work with your cluster, refer to the [IBM Cloud Kubernetes Service API reference](https://containers.cloud.ibm.com/global/swagger-global-api//) and [Community Kubernetes API reference](https://kubernetes.io/docs/reference/).



3. Cluster deployment:



1. [Create the cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters).
2.
Change log for worker node fix pack 1.19.15_1561, released 27 September 2021 

The following table shows the changes that are in the worker node fix pack patch update 1.19.15_1561. 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.14_1559

 Component Previous Current Description 

 Disk identification N/A N/A Enhanced the disk identification logic to handle the case of 2+ partitions. 
 HA proxy 9c98dc5 07f1e9 Updated image with fixes for [CVE-2021-22922](https://nvd.nist.gov/vuln/detail/CVE-2021-22922), [CVE-2021-22923](https://nvd.nist.gov/vuln/detail/CVE-2021-22923), [CVE-2021-22924](https://nvd.nist.gov/vuln/detail/CVE-2021-22924), [CVE-2021-36222](https://nvd.nist.gov/vuln/detail/CVE-2021-36222), and [CVE-2021-37750](https://nvd.nist.gov/vuln/detail/CVE-2021-37750). 
 Kubernetes 1.19.14 1.19.15 See the [change logs](https://github.com/kubernetes/kubernetes/releases/tag/v1.19.15). This update resolves [CVE-2021-25741](https://nvd.nist.gov/vuln/detail/CVE-2021-25741). For more information, see the [IBM security bulletin](https://www.ibm.com/support/pages/node/6496649)).
worker_node_instance_type Specify the virtual server instance profile type to be used to create the worker nodes for the Slurm cluster. The worker nodes are the ones where the workload execution takes place and the choice should be made according to the characteristics of the workloads. For choices on profile types, see [Instance profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles). String No bx2-4x16 
 zone IBM Cloud zone name within the selected region where the Slurm cluster should be deployed. To get a full list of zones within a region, see [Get zones by using the CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-in-a-different-regionget-zones-using-the-cli). String Yes None
Ubuntu 18.04 packages N/A N/A Updated worker node images with kernel package updates. 







 Change log for worker node fix pack 1.17.17_1567, released 6 July 2021 

The following table shows the changes that are in the worker node fix pack 1.17.17_1567. 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.17_1566

 Component Previous Current Description 

 HA proxy 700dc6 aae810 Updated image with fixes for [CVE-2021-3520](https://nvd.nist.gov/vuln/detail/CVE-2021-3520), [CVE-2021-20271](https://nvd.nist.gov/vuln/detail/CVE-2021-20271), [CVE-2021-3516](https://nvd.nist.gov/vuln/detail/CVE-2021-3516), [CVE-2021-3517](https://nvd.nist.gov/vuln/detail/CVE-2021-3517), [CVE-2021-3518](https://nvd.nist.gov/vuln/detail/CVE-2021-3518), [CVE-2021-3537](https://nvd.nist.gov/vuln/detail/CVE-2021-3537), and [CVE-2021-3541](https://nvd.nist.gov/vuln/detail/CVE-2021-3541).
Allow worker nodes to be created in your cluster. ALL <br><br> * <br><br><br> CIDR block 161.26.0.0/16 
 Allow worker nodes to communicate with other IBM Cloud services that support private cloud service endpoints. ALL <br><br> * <br><br><br> CIDR block 166.8.0.0/14 
 Allow all worker nodes in this cluster to communicate with each other. ALL <br><br> * <br><br><br> Security group kube-<cluster_ID> 
 Allow outbound traffic to be sent to the Virtual private endpoint gateway which is used to talk to the Kubernetes master. ALL <br><br> * <br><br><br> Virtual private endpoint gateway IP addresses. The Virtual private endpoint gateway is assigned an IP address from a VPC subnet in each of the zones where your cluster has a worker node. For example, if the cluster spans 3 zones, there are up to 3 IP addresses assigned to each Virtual private endpoint gateway. To find the Virtual private endpoint gateway IPs:<br><br><br><br>1. Go to the [Virtual private cloud dashboard](https://cloud.ibm.com/vpc-ext/network/vpcs).<br>2. Click Virtual private endpoint gateways, then select the Region where your cluster is located.<br>3. Find your cluster, then click the IP addresses in the IP Address column to copy them.<br><br><br> 
 Allow the worker nodes to connect to the public service endpoint IPs for the OAuth service. To find the IPs needed to apply this rule, see [Allow the worker nodes to connect to the public service endpoint IPs for the OAuth service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupworker-node-public-service-endpoint). TCP OAuth port OAuth IP addresses 
 Allow the worker nodes to connect to the Ingress LoadBalancer.
Change log for worker node fix pack 1.15.12_1544, released 6 July 2020 

The following table shows the changes that are in the worker node fix pack 1.15.12_1544. 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_1543

 Component Previous Current Description 

 HAProxy 1.8.25-30b675 2.0.15-afe432 See the [HAProxy change log](https://www.haproxy.org/download/2.0/src/CHANGELOG). 
 Ubuntu 18.04 packages 4.15.0-106-generic 4.15.0-109-generic Updated worker node images with kernel and package updates for [CVE-2019-12380](https://nvd.nist.gov/vuln/detail/CVE-2019-12380), [CVE-2019-16089](https://nvd.nist.gov/vuln/detail/CVE-2019-16089), [CVE-2019-19036](https://nvd.nist.gov/vuln/detail/CVE-2019-19036), [CVE-2019-19039](https://nvd.nist.gov/vuln/detail/CVE-2019-19039), [CVE-2019-19318](https://nvd.nist.gov/vuln/detail/CVE-2019-19318), [CVE-2019-19642
Change log for worker node fix pack 1.25.3_1521, released 07 November 2022 

The following table shows the changes that are in the worker node fix pack 1.25.3_1521. 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.2_1519

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Worker node package updates for [CVE-2022-32221](https://nvd.nist.gov/vuln/detail/CVE-2022-32221), [CVE-2022-40284](https://nvd.nist.gov/vuln/detail/CVE-2022-40284), [CVE-2022-42010](https://nvd.nist.gov/vuln/detail/CVE-2022-42010), [CVE-2022-42011](https://nvd.nist.gov/vuln/detail/CVE-2022-42011), [CVE-2022-42012](https://nvd.nist.gov/vuln/detail/CVE-2022-42012). 
 Kubernetes 1.25.2 1.25.3 For more information, see the [change log](https://github.com/kubernetes/kubernetes/releases/tag/v1.25.3).
Also note the annotation task details, such as the task name, due date, and which document sets are assigned to which users.









 Downloading artifacts 

For each workspace that you want to migrate, download the following artifacts. Store them in a secure location from which you will be able to upload them into the new instance later.



* Type system
* Dictionaries

Note:



* Only editable dictionaries will be downloaded. You cannot download read-only dictionaries.
* For dictionaries, entity type mappings are not migrated. After you restore these artifacts, you will need to map the dictionaries to entity types, as necessary.



* Documents

For more information about how to download these artifacts so that they can be imported into a new workspace, see [Uploading resources from another workspace](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-knowledge-studio-exportimport).







 Recreating workspaces 

In this step, the only setting that must match the setting of the original (downloaded) workspace is the language. The rest of the settings can differ from the settings of the original workspace.

Re-create each workspace by copying the following information from the previous instance to the new one:



* Workspace name
* Workspace description
* Language of documents (this setting must match the setting in the original workspace)
* If you previously used a dictionary-based tokenizer in the workspace and have a valid need to continue using it, you must specify that you want to use the dictionary-based tokenizer instead of the default tokenizer when you create the workspace. For more information about the options, see [Tokenizers](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-knowledge-studio-create-projectwks_tokenizer).

To use a dictionary-based tokenizer, expand the Advanced Options section of the "Create Workspace" window (in IBM Marketplace, the "Create Workspace" window) and change the tokenizer setting.







 Restoring workspace data 

After re-creating the workspaces, upload the previously downloaded artifacts:



1.
(https://nvd.nist.gov/vuln/detail/CVE-2020-36226), [CVE-2020-36227](https://nvd.nist.gov/vuln/detail/CVE-2020-36227), [CVE-2020-36228](https://nvd.nist.gov/vuln/detail/CVE-2020-36228), [CVE-2020-36229](https://nvd.nist.gov/vuln/detail/CVE-2020-36229), [CVE-2020-36230](https://nvd.nist.gov/vuln/detail/CVE-2020-36230), [CVE-2021-25682](https://nvd.nist.gov/vuln/detail/CVE-2021-25682), [CVE-2021-25683](https://nvd.nist.gov/vuln/detail/CVE-2021-25683), and [CVE-2021-25684](https://nvd.nist.gov/vuln/detail/CVE-2021-25684). 







 Change log for worker node fix pack 1.18.15_1540, released 3 February 2021 

The following table shows the changes that are in the worker node fix pack 1.18.15_1540. 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.15_1539

 Component Previous Current Description 

 Metadata updates N/A N/A Updated the worker node version fix pack metadata for internal documentation purposes. 







 Change log for worker node fix pack 1.18.15_1539, released 1 February 2021 

The following table shows the changes that are in the worker node fix pack 1.18.15_1539. 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.15_1538
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w3 169.xx.xxx.xxx 10.176.48.78 u3c.2x4.encrypted normal Ready dal10 1.26_1513
3. Copy the public IP of the worker node and the node port into your text cheat sheet to use in later lessons.
4. Verify that you can access the public IP address the worker node through the node port. Note: Because worker nodes in VPC clusters don't have a public IP address, you can access an app through a NodePort only if you are connected to your private VPC network, such as through a VPN connection. Then, you can use the worker node's private IP address and NodePort: <worker_private_IP>:<NodePort>.

curl --connect-timeout 10 <worker_IP>:<NodePort>

The following example output confirms that the request to your app came through the private IP address 10.1.1.1 for the worker node and the 31024 node port. The webserver-855556f688-xd849 app pod received the curl request:

Hostname: webserver-855556f688-xd849
Pod Information:
-no pod information available-
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Information:
client_address=1.1.1.1
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://10.1.1.1:8080/
Request Headers:
accept=/
host=10.1.1.1:31024
user-agent=curl/7.60.0
Request Body:
-no body in request-





At this point, your app is exposed from multiple IP addresses and ports. Most of these IPs are internal to the cluster and can be accessed only over the private network.
Verify that the devices that you want to use are unmounted and unformatted.

fdisk -l



4. List available block storage disks on your worker node. You must use unmounted disks for the local storage configuration. In the following example output from the lsblk command, the nvme2n1 disk is unmounted and has no partitions.

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:3 0 100G 0 disk
|-nvme0n1p1 259:4 0 1M 0 part
-nvme0n1p2 259:5 0 100G 0 part /
nvme1n1 259:0 0 20G 0 disk
nvme2n1 259:1 0 20G 0 disk
nvme3n1 259:2 0 139.7G 0 disk /var/data
5. Repeat the previous steps for each worker node that you want to use for your local block storage configuration.







 Labeling your worker nodes when using local block storage 

After you have [retrieved the device paths for the disks that you want to use in your configuration](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-local-volume-blocksat-storage-block-local-devices), label the worker nodes where the disks are located.



1. Get the worker node IP addresses.

oc get nodes
2. Label the worker nodes that you retrieved earlier. The local storage drivers are deployed to the worker nodes with this label. You can use the storage=local-block label in the example command or you can create your own label in the key=value format.

oc label nodes <worker-IP> <worker-IP> <worker-IP> "storage=local-block"

Example output

node/<worker-IP> labeled
node/<worker-IP> labeled
node/<worker-IP> labeled
3. Verify that the label is added to the worker nodes that you want to use. Run the following command to display the labels on your worker nodes and highlight the label that you added previous step.
Change log for worker node fix pack 1.25.6_1531, released 13 February 2023 

The following table shows the changes that are in the worker node fix pack 1.25.6_1531. 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.6_1530

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-202 4.15.0-204 Worker node kernel & package updates for [CVE-2022-28321](https://nvd.nist.gov/vuln/detail/CVE-2022-28321), [CVE-2022-3437](https://nvd.nist.gov/vuln/detail/CVE-2022-3437), [CVE-2022-4304](https://nvd.nist.gov/vuln/detail/CVE-2022-4304), [CVE-2022-4450](https://nvd.nist.gov/vuln/detail/CVE-2022-4450), [CVE-2022-45142](https://nvd.nist.gov/vuln/detail/CVE-2022-45142), [CVE-2022-47016](https://nvd.nist.gov/vuln/detail/CVE-2022-47016), [CVE-2023-0215](https://nvd.nist.gov/vuln/detail/CVE-2023-0215), [CVE-2023-0286](https://nvd.nist.gov/vuln/detail/CVE-2023-0286).
On the top bar, click Sources and select the name of the host (worker node) you are interested in checking the logs. Works well if you have multiple worker nodes in your cluster.
2. To check other container or file logs, click app-log-analysis or Apps and select the checkbox(s) you are interested in seeing the logs.







 Create a view 

Views are saved shortcuts to a specific set of filters and search queries.

As soon as you search or filter logs, you should see Unsaved View in the top bar. To save this as a view:



1. Click Apps and select the checkbox next to app-log-analysis
2. Click on Unsaved View > click save as new view and name the view as app-log-analysis-view. Leave the Category as empty.
3. Click Save View and new view should appear on the left pane showing logs for the app.







 Visualize logs with graphs and breakdowns 

In this section, you will create a board and then add a graph with a breakdown to visualize the app level data. A board is a collection of graphs and breakdowns.



1. On the left pane, click on the board icon (above the settings icon) > click New Board.
2. Set Name to app-log-analysis-board. Click Save.
3. Under Select a field to graph:



1. Select app as the field
2. Select app-log-analysis as the field value



4. Click Add Graph.
5. Select Counts as your metric to see the number of lines in each interval over last 24 hours.
6. To add a breakdown, click on the arrow below the graph:



* Choose Histogram as your breakdown type.
* Choose level as your field type.
* Click Add Breakdown to see a breakdown with all the levels you logged for the app.











 Step 6: Validate IBM Cloud Monitoring instance configuration and monitor your cluster 

During creation of the IBM Cloud Kubernetes Service cluster, it is expected that you completed the steps to also connect to a Monitoring service.
Change log for worker node fix pack 1.20.7_1542, released 7 June 2021 

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

 Component Previous Current Description 

 HA proxy 26c5cc 700dc6 Updated the image for [CVE-2021-27219](https://nvd.nist.gov/vuln/detail/CVE-2021-27219). 
 TCP keepalive optimization for VPC N/A N/A Set the net.ipv4.tcp_keepalive_time setting to 180 seconds for compatibility with VPC gateways.
* [Updating VPC worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-updatevpc_worker_node)



* [Prerequisites](https://cloud.ibm.com/docs/openshift?topic=openshift-updatevpc_worker_prereqs)
* [Updating VPC worker nodes in the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-updatevpc_worker_cli)
* [Updating VPC worker nodes in the console](https://cloud.ibm.com/docs/openshift?topic=openshift-updatevpc_worker_ui)



* [Updating flavors (machine types)](https://cloud.ibm.com/docs/openshift?topic=openshift-updatemachine_type)
* [Updating cluster components](https://cloud.ibm.com/docs/openshift?topic=openshift-updatecomponents)



* [Managing automatic updates for Fluentd](https://cloud.ibm.com/docs/openshift?topic=openshift-updatelogging-up)
* [Managing automatic updates for Ingress ALBs](https://cloud.ibm.com/docs/openshift?topic=openshift-updatealb)



* [Updating managed add-ons](https://cloud.ibm.com/docs/openshift?topic=openshift-updateaddons)



[Removing clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-removeremove)

[Preparing for host maintenance updates](https://cloud.ibm.com/docs/openshift?topic=openshift-host-maintenancehost-maintenance)



* [Identifying your affected workers](https://cloud.ibm.com/docs/openshift?topic=openshift-host-maintenanceworker-maintenance-list)
* [Permissions error](https://cloud.ibm.com/docs/openshift?topic=openshift-common_worker_nodes_issuespermissions-error)
* [Firewall error](https://cloud.ibm.com/docs/openshift?topic=openshift-common_worker_nodes_issuesfirewall-error)
* [Hard reboot](https://cloud.ibm.com/docs/openshift?topic=openshift-common_worker_nodes_issueshard-reboot)
* [Instance can't be found](https://cloud.ibm.com/docs/openshift?topic=openshift-common_worker_nodes_issuesinstance-not-found)



[Troubleshooting worker nodes in Critical or NotReady state](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-critical-notreadyts-critical-notready)



* [Check the common causes of worker node failures](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-critical-notreadyts-critical-notready-common)
* [Troubleshooting steps](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-critical-notreadyts-critical-notready-steps)



* [If one or some worker nodes are affected](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-critical-notreadyts-critical-notready-steps-some)
* [If all worker nodes in a single zone, subnet, or VLAN are affected](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-critical-notreadyts-critical-notready-steps-zone)
* [If all worker nodes in a cluster are affected](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-critical-notreadyts-critical-notready-steps-all)
* [Why do my worker nodes have the master role?](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesflavor-master-role)
* [How can I check the operating system that my worker nodes run?](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesflavor-os-check)



* [Virtual machines](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesvm)



* [Planning considerations for VMs](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesvm-planning)
* [Available flavors for VMs](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesvm-table)



* [Physical machines (bare metal)](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesbm)



* [Planning considerations for bare metal](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesbm-planning)
* [Available flavors for bare metal](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesbm-table)



* [Software-defined storage (SDS) machines](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodessds)



* [Planning considerations for SDS](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodessds-planning)
* [Available flavors for SDS](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodessds-table)
Change log for worker node fix pack 1.24.10_1554, released 27 February 2023 

The following table shows the changes that are in the worker node fix pack 1.24.10_1554. 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.10_1553

 Component Previous Current Description 

 containerd v1.6.17 v1.6.18 See the [1.6.18 change log](https://github.com/containerd/containerd/releases/tag/v1.6.18) and the [security bulletin for CVE-2023-25153 and CVE-2023-25173](https://www.ibm.com/support/pages/node/6960181). 
 Ubuntu 18.04 packages N/A N/A Worker node package updates for [CVE-2023-22490](https://nvd.nist.gov/vuln/detail/CVE-2023-22490), [CVE-2023-23946](https://nvd.nist.gov/vuln/detail/CVE-2023-23946), [CVE-2023-25725](https://nvd.nist.gov/vuln/detail/CVE-2023-25725). 
 Ubuntu 20.04 packages N/A N/A Worker node package updates for [CVE-2023-22490](https://nvd.nist.gov/vuln/detail/CVE-2023-22490), [CVE-2023-23946](https://nvd.nist.gov/vuln/detail/CVE-2023-23946), [CVE-2023-25725](https://nvd.nist.gov/vuln/detail/CVE-2023-25725). 
 Kubernetes N/A N/A N/A
Change log for worker node fix pack 1.24.6_1539, released 26 September 2022 

The following table shows the changes that are in the worker node fix pack 1.24.6_1539. 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.4_1537

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-192 4.15.0-193 Worker node kernel & package updates for [CVE-2020-35525](https://nvd.nist.gov/vuln/detail/CVE-2020-35525), [CVE-2021-33655](https://nvd.nist.gov/vuln/detail/CVE-2021-33655), [CVE-2021-33656](https://nvd.nist.gov/vuln/detail/CVE-2021-33656), [CVE-2022-0943](https://nvd.nist.gov/vuln/detail/CVE-2022-0943), [CVE-2022-1154](https://nvd.nist.gov/vuln/detail/CVE-2022-1154), [CVE-2022-1616](https://nvd.nist.gov/vuln/detail/CVE-2022-1616), [CVE-2022-