vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Worker nodes carry the deployments and services that make up your app. When you host workloads in the public cloud, you want to ensure that your app is protected from being accessed, changed, or monitored by an unauthorized user or software.



 Who owns the worker node and am I responsible to secure it? 

The ownership of a worker node depends on the type of cluster that you create and the infrastructure provider that you choose.



* Classic clusters: Worker nodes are provisioned in to your IBM Cloud account. The worker nodes are dedicated to you and you are responsible to request timely updates to the worker nodes to ensure that the worker node OS and IBM Cloud Kubernetes Service components apply the latest security updates and patches.
* VPC clusters: Worker nodes are provisioned in to an IBM Cloud account that is owned by IBM to enable monitoring of malicious activities and apply security updates. You can't access your worker nodes by using the VPC dashboard. However, you can manage your worker nodes by using the IBM Cloud Kubernetes Service console, CLI, or API. The virtual machines that make up your worker nodes are dedicated to you and you are responsible to request timely updates so that your worker node OS and IBM Cloud Kubernetes Service components apply the latest security updates and patches.



For more information, see [Your responsibilities by using Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-responsibilities_iks).

Use the ibmcloud oc worker update[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_update) regularly (such as monthly) to deploy updates and security patches to the operating system and to update the Red Hat OpenShift version that your worker nodes run. When updates are available, you are notified when you view information about the master and worker nodes in the IBM Cloud console or CLI, such as with the ibmcloud oc clusters ls or ibmcloud oc workers ls --cluster <cluster_name> commands. Worker node updates are provided by IBM as a full worker node image that includes the latest security patches.
Install the [Calico CLI](https://cloud.ibm.com/docs/containers?topic=containers-network_policiescli_install).
3. List the available worker nodes in Calico. Replace <path_to_file> with the local path to the Calico configuration file.

calicoctl get nodes --config=filepath/calicoctl.cfg

NAME
kube-dal10-cr9b7371a7faaa46d08e04f046d5e6d8b4-w1
kube-dal10-cr9b7371a7faaa46d08e04f046d5e6d8b4-w2
4. Delete the duplicate worker node in Calico. Replace NODE_ID with the worker node ID.

calicoctl delete node NODE_ID --config=<path_to_file>/calicoctl.cfg
5. Reboot the worker node that was not deleted.

ibmcloud ks worker reboot --cluster <cluster_name_or_id> --worker <worker_id>



The deleted node is no longer listed in Calico.
Run [job logs](https://cloud.ibm.com/apidocs/schematics/schematicsget-job) to pull your workspace logs.

curl -X GET https://schematics.cloud.ibm.com/v1/workspaces/{w_id}/runtime_data/{template_id}/log_store -H 'authorization: <auth>' -H 'cache-control: no-cache' -H 'content-type: application/json'

Record the cluster_id and logdna_name from the Outputs: section of the Jobs log. This information are used while deploying the Agent service. If you do not observe cluster_id details in the Jobs log, ensure you IBM Cloud has right permission to create a VPC Infrastructure, and Kubernetes cluster service access. Then, apply command to refresh your workspace](/apidocs/schematics/schematics#refresh-workspace-command).
7. Review the output to view the [Agent infrastructure resource](https://cloud.ibm.com/docs/schematics?topic=schematics-agents-setupagents-setup-infra-output) provisioned.





 Deploying the Agent services 

Here are the list of CURL commands used to provision the Agent Service:



1. Run [workspace create](https://cloud.ibm.com/apidocs/schematics/schematicscreate-workspace) using the payload.

curl -X POST https://schematics.cloud.ibm.com/v1/workspaces -H 'authorization: <auth>' -H 'cache-control: no-cache' -H 'content-type: application/json' -d '{
"name": "smulampa-schematics-agent-service-workspace",
"type": [
"terraform_v1.0"
],
"description": "schematics agents service workspace",
"template_repo": {
"url": ""
},
"template_data": [{
"flow_job_data": {
"workitems": [
{
"command_object_id": "us-south.workspace.basic-resource-group.483b1ea2",
"command_object_name": "basic-resource-group",
"source": {
"source_type": "git_hub",
"git": {
"git_repo_url": "https://github.com/Cloud-Schematics/blueprint-example-modules/tree/main/IBM-DefaultResourceGroup",
"git_branch": "main"
},
"catalog": {},
"cos_bucket": {}
},
"outputs":
{
"name": "resource_group_id",
"metadata": {}
},
{
"name": "resource_group_name",
"metadata": {}
}
],
"last_job": {
"command_object_id": "us-south.workspace.basic-resource-group.483b1ea2",
"command_name": "workspace_apply",
"job_status": "job_finished"
},
"updated_at": "0001-01-01T00:00:00Z"
},
{
"command_object_id": "us-south.workspace.basic-cos-storage.535f45d6",
"command_object_name": "basic-cos-storage",
"source": {
"source_type": "git_hub",
"git": {
"git_repo_url": "https://github.com/Cloud-Schematics/blueprint-example-modules/tree/main/IBM-Storage",
"git_branch": "main"
},
The following table shows the changes that are in the worker node fix pack patch update 1.22.2_1527. 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.22.2_1524

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Updated worker node images with package updates. Contains fix for cloud-init performance problem. 
 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 1.22.2_1524, released 11 October 2021 

The following table shows the changes that are in the worker node fix pack patch update 1.22.2_1524. 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.22.2_1523

 Component Previous Current Description 

 Containerd v1.5.5 v1.5.7 See the [security bulletin](https://www.ibm.com/support/pages/node/6501867) and the [change log](https://github.com/containerd/containerd/releases/tag/v1.5.7). 
 Ubuntu 18.04 packages 4.15.0-158 4.15.0-159 Updated worker node images and kernel with package updates [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). 







 Change log for master fix pack 1.22.2_1522 and worker node fix pack 1.22.2_1523, released 29 September 2021 

The following table shows the changes that are in the master fix pack 1.22.2_1522 and the worker node fix pack patch update 1.22.2_1523.
Check the following settings and change the settings to reflect the deleted or added worker nodes as necessary.

If you added a worker node:localSubnetNAT : The added worker might be deployed on a new, different private subnet than the other existing subnets that other worker nodes are on. If you use subnet NAT to remap your cluster's private local IP addresses and the worker was added on a new subnet, add the new subnet CIDR to this setting.

nodeSelector
: If you previously limited VPN pod deployment to workers with a specific label, ensure the added worker node also has that label.

tolerations
: If the added worker node is tainted, then change this setting to allow the VPN pod to run on all tainted workers with any taints or specific taints.

local.subnet
: The added worker might be deployed on a new, different private subnet than the existing subnets that other workers are on. If your apps are exposed by NodePort or LoadBalancer services on the private network and the apps are on the added worker, add the new subnet CIDR to this setting. If you add values to local.subnet, check the VPN settings for the on-premises subnet to see whether they also must be updated.

If you deleted a worker node:

localSubnetNAT
: If you use subnet NAT to remap specific private local IP addresses, remove any IP addresses from this setting that are from the old worker. If you use subnet NAT to remap entire subnets and no workers remain on a subnet, remove that subnet CIDR from this setting. nodeSelector
: If you previously limited VPN pod deployment to a single worker and that worker was deleted, change this setting to allow the VPN pod to run on other workers.

tolerations
: If the worker that you deleted was not tainted, but the only workers that remain are tainted, change this setting to allow the VPN pod to run on workers with any taints or specific taints.
4. Install the new Helm chart with your updated values.

helm install <release_name> iks-charts/strongswan -f config.yaml
5. Check the chart deployment status.
* [Worker communication to other services or networks](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-vpn-services)
* [External communication to apps that run on worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_vpc_basicsvpc-vpn-external)





[Understanding network basics of classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsplan_basics)



* [Worker-to-worker communication: classic VLANs and subnets](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworker-worker)



* [VLAN connections for worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworker-worker-nodes)
* [Worker node communication across subnets and VLANs](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworker-worker-subnets)



* [Worker-to-master and user-to-master communication: Service endpoints](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworkeruser-master)



* [Public service endpoint only](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworkeruser-master-endpoint)
* [Public and private cloud service endpoints](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworkeruser-master-pub-priv)



* [Worker communication to other IBM Cloud services or on-premises networks](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworker-services-onprem)
(https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_update)





 Updating VPC worker nodes in the console 

You can update your VPC worker nodes in the console. Before you begin, consider [adding more worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workers) to the cluster to help avoid downtime for your apps.



1. Complete the [prerequisite steps](https://cloud.ibm.com/docs/openshift?topic=openshift-updatevpc_worker_prereqs).
2. From the [IBM Cloud console](https://cloud.ibm.com/) menu ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/icons/icon_hamburger.svg), click Red Hat OpenShift.
3. From the Clusters page, click your cluster.
4. From the Worker Nodes tab, select the checkbox for each worker node that you want to update. An action bar is displayed over the table header row.
5. From the action bar, click Update.









 Updating flavors (machine types) 

Before you begin:



* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* Data on the worker node is deleted. Consider storing your data on persistent storage outside of the worker node.
* Make sure that you have the [Operator or Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms).



To update flavors:



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

1. List available worker pools in your cluster.
 {: pre}
Keep in mind that the [worker nodes reserve certain amounts of CPU and memory resources](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesresource_limit_node) to run required components, such as the operating system or container runtime.
2. Consider whether your app pulls large or many images, which can take up local storage on the worker node.
3. Decide whether you want to [integrate services](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrationssupported_integrations) into your cluster, such as [Helm](https://cloud.ibm.com/docs/openshift?topic=openshift-helm) or [Prometheus](https://github.com/prometheus-operator/kube-prometheus). These integrated services and add-ons spin up pods that consume cluster resources.







 What type of availability do I want my workload to have? 

Don't forget that you want your workload to be up as much as possible! As such, you might need replicas of your workload pods.



1. Plan out your strategy for [highly available clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersha_clusters), such as deciding between single or multizone clusters.
2. Review [highly available deployments](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_deployhighly_available_apps) to help decide how you can make your app available.







 How many worker nodes do I need to handle my workload? 

Now that you have a good idea of what your workload looks like, let's map the estimated usage onto your available cluster configurations.



1. Estimate the max worker node capacity, which depends on what type of cluster you have. You don't want to max out worker node capacity in case a surge or other temporary event happens.



* Single zone clusters: Plan to have at least three worker nodes in your cluster.
DEBUG:urllib3.connectionpool:https://us.schematics.cloud.ibm.com:443 "GET /v1/workspaces/us-east.workspace.sunil-myworkspace-may12.2e0a560f/actions/6242ef71d4003bdae4a7ed7a3cbb0887 HTTP/1.1" 200 None
{
"action_id": "a11223334b11224345",
"name": "PLAN",
"status": "COMPLETED",
"message": [],
"performed_by": "user@us.ibm.com",
"performed_at": "2019-08-21T14:07:25.814722573Z",
"templates": [
{
"template_id": "a1234b-2124",
"template_type": "terraform_v0.12",
"start_time": "2019-08-21T14:07:26.120106199Z",
"end_time": "2019-08-21T14:07:30.088495607Z",
"status": "COMPLETED",
"message": "{"messagekey":"M2001_ActivitySuccessful","parms":{},"requestid":"1234b1234b123-1234n13","timestamp":"2019-08-21T14:07:30.088498532Z"}",
"log_url": "https://schematics.cloud.ibm.com/v1/workspaces/myworkspace-123456/runtime_data/a1234b-2124/log_store/actions/11223334b11224345"
}
]
}
INFO:root:Completed Retrieving the Schematic logs
Change log for worker node fix pack 1.19.11_1549, released 7 June 2021 

The following table shows the changes that are in the worker node fix pack 1.19.11_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.19.11_1548

 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.
The following table shows the changes that are in the worker node fix pack patch update 1.19.13_1556. 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.13_1555

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-151 4.15.0-153 N/A 
 HA proxy 68e6b3 9c98dc Updated image with fixes for [CVE-2021-27218](https://nvd.nist.gov/vuln/detail/CVE-2021-27218). 







 Change log for worker node fix pack 1.19.13_1555, released 02 August 2021 

The following table shows the changes that are in the worker node fix pack patch update 1.19.13_1555. 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.12_1553

 Component Previous Current Description
Change log for worker node fix pack 1.17.7_1530, released 6 July 2020 

The following table shows the changes that are in the worker node fix pack 1.17.7_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.17.7_1529

 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
You can find the primary IP of your worker node by running ibmcloud oc worker ls.

volumeId and spec.csi.volumeHandle
: In the spec CSI volume attributes section, enter the ID of the Block Storage for Classic volume that you retrieved earlier.

storageClassName
: For the spec storage class name, enter an empty string.

matchExpressions
: In the spec node affinity section, enter the node selector terms to match the zone. For the key, enter failure-domain.beta.kubernetes.io/zone. For the value, enter the zone of your worker node where you want to attach storage.

matchExpressions
: In the spec node affinity section, enter the node selector terms to match the region. For the key, enter failure-domain.beta.kubernetes.io/region. For the value, enter the region of the worker node where you want to attach storage.
6. Create the PV in your cluster.

oc apply -f pv.yaml
7. Verify that the PV is created in your cluster.

oc get pv
8. Create another configuration file for your PVC. In order for the PVC to match the PV that you created earlier, you must choose the same value for the storage size and access mode. In your storage class field, enter an empty string value to match your PV. If any of these fields don't match the PV, then a new PV and a Block Storage for Classic instance are created automatically via dynamic provisioning.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: <pvc_name>
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: <vpc_block_storage_size>
storageClassName: ""
9. Create your PVC.

oc apply -f pvc.yaml
10. Verify that your PVC is created and bound to the PV that you created earlier. This process can take a few minutes.

oc describe pvc <pvc_name>
11.
Node: 169.xx.xxx.xxx/169.xx.xxx.xxx

If the worker node IP address is private, run ibmcloud oc worker ls -c <cluster> | grep <private_IP> and note the corresponding public IP address.
3. Get the UID of the image-registry pod in the metadata.uid section in the pod YAML (not the UID of the replica set in the metadata.ownerReferences.uid section).

oc get pod -n openshift-image-registry <image-registry-pod> -o yaml

Example output

apiVersion: v1
kind: Pod
metadata:
uid: e8d7718d-b0bd-47e2-9aaa-05f3a608fd9b
...



5. Verify that the internal registry stores data to the emptyDir of the worker node.



1. [Access the registry directly from the cluster](https://docs.openshift.com/container-platform/4.11/registry/accessing-the-registry.htmlregistry-accessing-directly_accessing-the-registry), using the worker node that you previously retrieved. Follow the steps to push a test image to the internal registry.

To complete these steps in the Red Hat OpenShift documentation, you need the podman CLI tool. Your worker nodes might not have this CLI tool by default. See the [Podman installation guide](https://podman.io/get-started) for the available RHEL versions.
2. Navigate to the internal registry pod folder that saves to the emptyDir. For <pod_uid>, use the pod UID that you retrieved earlier.

cd var/lib/kubelet/pods/<pod_uid>/volumes/kubernetes.ioempty-dir/registry-storage/docker/registry/v2/repositories/openshift
3. Verify that your image is in repository directory.

ls

Example output
Change log for worker node fix pack 1.26.3_1529, released 27 March 2023 

The following table shows the changes that are in the worker node fix pack 1.26.3_1529. 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.1_1525

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Worker node package updates for [CVE-2021-36222](https://nvd.nist.gov/vuln/detail/CVE-2021-36222), [CVE-2021-37750](https://nvd.nist.gov/vuln/detail/CVE-2021-37750), [CVE-2022-47024](https://nvd.nist.gov/vuln/detail/CVE-2022-47024), [CVE-2023-0049](https://nvd.nist.gov/vuln/detail/CVE-2023-0049), [CVE-2023-0054](https://nvd.nist.gov/vuln/detail/CVE-2023-0054), [CVE-2023-0288](https://nvd.nist.gov/vuln/detail/CVE-2023-0288), [CVE-2023-0433](
The following table shows the changes that are in the worker node fix pack patch update 1.21.3_1527. 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.21.3_1526

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-151 4.15.0-153 N/A 
 HA proxy 68e6b3 9c98dc Updated image with fixes for [CVE-2021-27218](https://nvd.nist.gov/vuln/detail/CVE-2021-27218). 







 Change log for worker node fix pack 1.21.3_1526, released 02 August 2021 

The following table shows the changes that are in the worker node fix pack patch update 1.21.3_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.21.2_1524

 Component Previous Current Description
If you do not have an API key, click New + to create one.



7. Click Create to finish the setup of your toolchain. You see an overview of tools that were configured for your toolchain.
8. Open the Delivery Pipeline. The Delivery Pipeline includes stages to retrieve updates from your source repository, create a Terraform execution plan, apply this plan, and to run a health check against your workspace.
9. Update the Terraform file in your source repository and review how this change is processed in your Delivery Pipeline. If one of the stages fails, click View logs and history to start troubleshooting errors. For more information about viewing logs and history, see [Reviewing the Schematics job details](https://cloud.ibm.com/docs/schematics?topic=schematics-interrupt-jobsch-job-logs).