vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Satellite infrastructure overview.

 Component Description 

 Compute and worker node resources Worker nodes can be virtual machines using either shared infrastructure or dedicated hosts, or even bare metal servers. You manage maintenance and billing activity for the worker nodes through your host infrastructure provider whether that is IBM Cloud, your own on-premises hardware, or another cloud provider. You also manage billing through IBM Cloud. For more information about pricing, see [What am I charged for when I use IBM Cloud Satellite?](https://cloud.ibm.com/docs/satellite?topic=satellite-faqspricing). 
 Security See [Security and compliance](https://cloud.ibm.com/docs/satellite?topic=satellite-compliance). 
 High availability See [About high availability and recover](https://cloud.ibm.com/docs/satellite?topic=satellite-ha). 
 Reservations Reservations aren't available for Satellite. 
 Cluster administration See [Updating hosts that are assigned as worker nodes](https://cloud.ibm.com/docs/satellite?topic=satellite-host-update-workers). 
 Cluster networking If you attach IBM Cloud Classic or VPC hosts to your location, refer to those descriptions. 
 Apps and container platform You can create [Red Hat OpenShift clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-faqscontainer_platforms) to manage your containerized apps. Your app build processes don't differ because of the infrastructure provider, but how you expose the app does. For more information, see [Choosing an app exposure service](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planning). 
 App networking All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range by default. You can avoid subnet conflicts with the network that you use to connect to your location by specifying a custom subnet CIDR that provides the private IP addresses for your pods.
Change log for worker node fix pack 1.25.8_1537, released 27 March 2023 

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

 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](
Planning your worker node setup 

IBM Cloud® Kubernetes Service provides different worker node flavors and isolation levels so that you can choose the flavor and isolation that best meet the requirements of the workloads that you want to run in the cloud.

A worker node flavor describes the compute resources, such as CPU, memory, and disk capacity that you get when you provision your worker node. Worker nodes of the same flavor are grouped in worker node pools. The total number of worker nodes in a cluster determine the compute capacity that is available to your apps in the cluster.

Want to save on your classic worker node costs? [Create a reservation](https://cloud.ibm.com/docs/containers?topic=containers-reservations) to lock in a discount over 1 or 3 year terms! Then, create your worker pool by using the reserved instances. Note that autoscaling can't be enable on worker pools that use reservations.

Trying to plan how many worker nodes your need in your cluster? Check out [Sizing your Kubernetes cluster to support your workload](https://cloud.ibm.com/docs/containers?topic=containers-strategysizing) to find information about the default worker node setup and how you can determine the resource requirements of your workloads.



 Available hardware for worker nodes 

The worker node flavors and isolation levels that are available to you depend on your container platform, cluster type, the infrastructure provider that you want to use, and the IBM Cloud Kubernetes Service location where you want to create your cluster.

Zoom

![Hardware options for worker nodes in a standard cluster](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_clusters_hardware.png)

Figure 1. Hardware options for worker nodes in a standard cluster



 What flavors are available to me?
For highly available data storage, Portworx requires at least 3 worker nodes with raw and unformatted block storage.
3. If you want to use [journal devices](https://docs.portworx.com/install-with-other/operate-and-maintain/performance-and-tuning/tuning/), choose from the following options. Journal devices allow Portworx to write logs directly to a local disk on your worker node.



* Attach an additional disk to at least 3 worker nodes to use for the journal. [Manually add](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesmanual_block) a 3 GB block storage device to a worker node in your cluster and find the device path. To find the device path after attaching the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.
* Select one of the block storage devices that you added earlier to use for the journal and find the device path. To find the device path after attaching the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.
* Let Portworx automatically create a journal partition during installation.



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



* Attach an additional disk to at least 3 worker nodes to use for key value database (KVDB). [Manually add](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesmanual_block) a 3 GB block storage device to at least 3 worker nodes in your cluster and find the device path. To find the device path after attaching the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.
* Select one of the block storage devices that you added earlier and find the device path.
Change log for worker node fix pack 1.19.16_1571, released 6 December 2021 

The following table shows the changes that are in the worker node fix pack patch update 1.19.16_1571. 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.16_1569

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-162 4.15.0-163 Updated worker node images and kernel with package updates. Contains fixes for [CVE-2021-43527](https://nvd.nist.gov/vuln/detail/CVE-2021-43527) 
 Containerd v1.4.11 v1.4.12 See the [change log](https://github.com/containerd/containerd/releases/tag/v1.4.12) and the [security bulletin](https://www.ibm.com/support/pages/node/6524974). 







 Change log for worker node fix pack 1.19.16_1569, released 22 November 2021 

The following table shows the changes that are in the worker node fix pack patch update 1.19.16_1569. 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.15_1567

 Component Previous Current Description 

 Kubernetes 1.19.15 1.19.16 For more information, see the [change log](https://github.com/kubernetes/kubernetes/releases/tag/v1.19.16).
Kubernetes v1.21.11 v1.21.12 See [change logs](https://github.com/kubernetes/kubernetes/releases/tag/v1.21.12). 







 Change log for worker node fix pack 1.21.11_1556, released 11 April 2022 

The following table shows the changes that are in the worker node fix pack 1.21.11_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.21.11_1554

 Component Previous Current Description 

 Containerd v1.5.10 v1.5.11 See the [change log](https://github.com/containerd/containerd/releases/tag/v1.5.11) and the [security bulletin](https://www.ibm.com/support/pages/node/6572257).
The following table shows the changes that are in the worker node fix pack 1.14.10_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.14.10_1548

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Updated worker node images with package updates for [CVE-2019-13734](https://nvd.nist.gov/vuln/detail/CVE-2019-13734), [CVE-2019-13750](https://nvd.nist.gov/vuln/detail/CVE-2019-13750), [CVE-2019-13751](https://nvd.nist.gov/vuln/detail/CVE-2019-13751), [CVE-2019-13752](https://nvd.nist.gov/vuln/detail/CVE-2019-13752), [CVE-2019-13753](https://nvd.nist.gov/vuln/detail/CVE-2019-13753), [CVE-2019-19923](https://nvd.nist.gov/vuln/detail/CVE-2019-19923), [CVE-2019-19924](https://nvd.nist.gov/vuln/detail/CVE-2019-19924), [CVE-2019-19925](https://nvd.nist.gov/vuln/detail/CVE-2019-19925), [CVE-2019-19926](https://nvd.nist.gov/vuln/detail/CVE-2019-19926), [CVE-2019-19959](https://nvd.nist.gov/vuln/detail/CVE-2019-19959), and [CVE-2019-20218](https://nvd.nist.gov/vuln/detail/CVE-2019-20218).
Change log for worker node fix pack 1.25.6_1530, released 30 January 2023 

The following table shows the changes that are in the worker node fix pack 1.25.6_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.25.5_1528

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Worker node kernel & package updates for [CVE-2018-20217](https://nvd.nist.gov/vuln/detail/CVE-2018-20217), [CVE-2022-23521](https://nvd.nist.gov/vuln/detail/CVE-2022-23521), [CVE-2022-28321](https://nvd.nist.gov/vuln/detail/CVE-2022-28321), [CVE-2022-40897](https://nvd.nist.gov/vuln/detail/CVE-2022-40897), [CVE-2022-40898](https://nvd.nist.gov/vuln/detail/CVE-2022-40898), [CVE-2022-41903](https://nvd.nist.gov/vuln/detail/CVE-2022-41903), [CVE-2022-42898](https://nvd.nist.gov/vuln/detail/CVE-2022-42898), [CVE-2023-22809](https://nvd.nist.gov/vuln/detail/CVE-2023-22809).
Install the [Calico CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-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 oc worker reboot --cluster <cluster_name_or_id> --worker <worker_id>



The deleted node is no longer listed in Calico.
You can retrieve a list of your Block Storage for Classic volumes by running ibmcloud is volumes.

volume_attachment_ID
: The unique ID that is assigned to your volume attachment. You can retrieve this ID by running ibmcloud is volume <volume_ID>.







 Reviewing volume attachment details for a VPC worker node by using the API 

You can use a GET request to retrieve volume attachment details for a VPC worker node.



1. Retrieve your IAM token.

ibmcloud iam oauth-tokens
2. Retrieve the ID of the resource group where your cluster is deployed.

ibmcloud ks cluster get <cluster_name_or_ID> | grep "Resource Group ID"
3. Retrieve the ID of the worker node for which you want to see volume attachment details. Make sure to select a worker node that is located in the same zone as your Block Storage for Classic instance.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>
4. Review a list of existing volume attachments on a worker node.

curl -X GET "https://containers.cloud.ibm.com/v2/storage/getAttachments?cluster=<cluster_ID>&worker=<worker_ID>" --header "X-Auth-Resource-Group-ID: <resource_group_ID>" --header "Authorization: <IAM_token>"
5. Retrieve the details for a specific attachment.

curl -X GET "https://containers.cloud.ibm.com/v2/storage/getAttachment?cluster=<cluster_ID>&worker=<worker_ID>&volumeAttachmentID=<volume_attachment_ID>" --header "X-Auth-Resource-Group-ID: <resource_group_ID>" --header "Authorization: <IAM_token>"

IAM_token
: The IAM OAuth token for your current session. You can retrieve this value by running ibmcloud iam oauth-tokens.

cluster_ID
: The unique ID that is assigned to your cluster.
The following table shows the changes that are in the worker node fix pack update 4.3.40_1546_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.3.40_1545_openshift

 Component Previous Current Description 

 Ephemeral storage reservations N/A N/A Local ephemeral storage is reserved on the Kubernetes data disk for system components. For more information, see [Worker node resource reserves](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesresource_limit_node).
In the output, note the zone and either the private and public VLAN ID for classic clusters or the subnet ID for VPC clusters.
 {: pre}
ibmcloud ks worker get --cluster CLUSTER --worker WORKER-ID

2. List available flavors in the zone.

ibmcloud ks flavors --zone <zone>
3. Create a worker node with the new machine type.



1. Create a worker pool with the number of worker nodes that you want to replace.



* Classic clusters:

ibmcloud ks worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
* VPC Generation 2 clusters:

ibmcloud ks worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL



2. Verify that the worker pool is created.

ibmcloud ks worker-pool ls --cluster CLUSTER
3. Add the zone to your worker pool that you retrieved earlier. When you add a zone, the worker nodes that are defined in your worker pool are provisioned in the zone and considered for future workload scheduling. If you want to spread your worker nodes across multiple zones, choose a [classic](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) or [VPC](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-vpc) multizone location.



* Classic clusters:

ibmcloud ks zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
* VPC clusters:

ibmcloud ks zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID





4. Wait for the worker nodes to be deployed.
ibm.io/volID
: Enter the ID of the block storage volume that you retrieved earlier.

storage
: Enter the size of the block storage device that you created earlier. For example, if your block storage device is 20 gigabytes, enter 20Gi.



2. Create the PV to attach the block storage device to your non-SDS worker node.



* If you used the mkpvyaml container, run the following command.

oc apply -f pv-<cluster_name>.yaml
* If you manually added block storage, run the following command.

oc apply -f pv.yaml



3. Verify that the block storage is successfully attached to your worker node.

oc describe pv <pv_name>

Example output

NAME: kube-wdc07-cr398f790bc285496dbeb8e9137bc6409a-w1-pv1
Labels: <none>
Annotations: ibm.io/attachstatus=attached
ibm.io/dm=/dev/dm-1
ibm.io/iqn=iqn.2018-09.com.ibm:ibm02su1543159-i106288771
ibm.io/lunid=0
ibm.io/mpath=3600a09803830445455244c4a38754c66
ibm.io/nodeip=10.176.48.67
ibm.io/password=R6lqLBj9al6e2lbp
ibm.io/targetip=161.26.98.114
ibm.io/username=IBM02SU1543159-I106288771
Adding a host node in PIM 

Complete the following steps to add a host node as a worker of another in PIM:



1.  On the server that you designated as the Controller, go to Infrastructure > Hardware Nodes > New Hardware Node.
2.  Enter the IP address/username(root)/password of the remote hardware node and register.



The new node resources are not immediately updated in the Controller PIM.
Updating Classic worker nodes that use OpenShift Data Foundation 

Classic infrastructure

For Classic clusters with a storage solution such as OpenShift Data Foundation you must cordon, drain, and replace each worker node sequentially. If you deployed OpenShift Data Foundation to a subset of worker nodes in your cluster, then after you replace the worker node, you must then edit the ocscluster resource to include the new worker node.

The following tutorial covers both major and minor worker node updates. Each step is flagged with

Major

or

Minor

.



Major

Applies to major updates, for example if you are updating your worker nodes to a new major version, such as from 4.11 to 4.12 as well as OpenShift Data Foundation from 4.11 to 4.12
Minor

Applies to minor patch updates, for example if you are updating from 4.12.15_1542_openshift to 4.12.16_1544_openshift while keeping OpenShift Data Foundation at version 4.12.



Skipping versions during an upgrade, such as from 4.8 to 4.12 is not supported.

[Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)

Before updating your worker nodes, make sure to back up your app data. Also, plan to complete the following steps for one worker node at a time. Repeat the steps for each worker node that you want to update.



 Step 1: Update the cluster master 

Major



1. If you are updating your worker nodes to a new major version, such as from 4.11 to 4.12, update the cluster master first.

ibmcloud oc cluster master update --cluster CLUSTER [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

Example command:

ibmcloud oc cluster master update --cluster mycluster --version 4.11.42 --force-update
2. Wait until the master update finishes.
* [Updating hosts that are assigned as worker nodes ](https://cloud.ibm.com/docs/satellite?topic=satellite-host-update-workers)
* [Copying a location](https://cloud.ibm.com/docs/satellite?topic=satellite-location-copy)
* [Configuring an HTTP proxy for your Satellite hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-config-http-proxy)
* [Specifying a custom Network Time Protocol (NTP) server](https://cloud.ibm.com/docs/satellite?topic=satellite-config-custom-ntp)
* [Removing hosts and locations](https://cloud.ibm.com/docs/satellite?topic=satellite-host-remove)



* Creating connectors



* [Creating a Connector](https://cloud.ibm.com/docs/satellite?topic=satellite-create-connector)
* [Running a Connector agent](https://cloud.ibm.com/docs/satellite?topic=satellite-run-agent-locally)
* [Running your Connector agent as a service in Docker Swarm Mode for high availability](https://cloud.ibm.com/docs/satellite?topic=satellite-run-agent-swarm)
* [Satellite Connector end-to-end example](https://cloud.ibm.com/docs/satellite?topic=satellite-end-to-end)
* [Creating and managing Connector endpoints](https://cloud.ibm.com/docs/satellite?topic=satellite-connector-create-endpoints)



* Managing apps with Satellite Config



* [Understanding Satellite Config ](https://cloud.ibm.com/docs/satellite?topic=satellite-cluster-config)
* Setting up clusters to use with Satellite Config



* [Granting Satellite Config access to your clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig)
In the installation directory on the bastion, locate the worker ignition file named worker.ign. Create a base64 version of this file by using the command base64 -w0 worker.ign > worker.ign.b64. The contents of the newly created worker.ign.b64 file is used in the next step.



3. Set the VM attributes.



1. Edit the configuration parameters of the new worker VM. Power off the VM before you start. To go to the Configuration Parameters window, select the new worker VM and click Actions > Edit Settings.
2. In the Edit Settings window, click the VM Options tab. On the left, click Advanced to expand the Advanced section in the window. Then, scroll down to Configuration Parameters on the left. To open the Configuration Parameters window, click Edit Configuration.
3. The Configuration Parameters window might have a long list of existing parameters for the VM. To add a value, click Add Configuration Params. Two empty fields that are labeled Name and Value are displayed for you to complete. Use this process to use for each of the following values.
4. Create a value named guestinfo.ignition.config.data. Set the value to the contents of the base64-encoded ignition config file worker.ign.b64 that was created earlier.
5. Create a value named guestinfo.ignition.config.data.encoding. Set the value to the string base64.
6. Create a value named disk.EnableUUID. Set the value to the string TRUE.
7. After you create the new parameters, click OK to close the Configuration Parameters window. Click OK to close the Edit Settings window.



4. Create a DHCP binding for the worker VM:



1. Log in to NSX-T™.
2. Go to Networking > Segments.
3. Edit the ocp-internal segment.
4. Expand DHCP Static Bindings and click Set to open the Set Static Bindings window.
5.
List the names of the worker pools in your cluster.

ibmcloud ks worker-pool ls --cluster <cluster_name_or_ID>
2. Determine the zones for one of the worker pools. In the output, look for the Zones field.

ibmcloud ks worker-pool get --cluster <cluster_name_or_ID> --worker-pool <pool_name>
3. For each zone that you found in the previous step, get an available public and private VLAN that are compatible with each other.



1. Check the available public and private VLANs that are listed under Type in the output.

ibmcloud ks vlan ls --zone <zone>
2. Check that the public and private VLANs in the zone are compatible. To be compatible, the Router must have the same pod ID. In this example output, the Router pod IDs match: 01a and 01a. If one pod ID was 01a and the other was 02a, you can't set these public and private VLAN IDs for your worker pool.

ID Name Number Type Router Supports Virtual Workers
229xxxx 1234 private bcr01a.dal12 true
229xxxx 5678 public fcr01a.dal12 true
3. If you need to order a new public or private VLAN for the zone, you can order in the [IBM Cloud console](https://cloud.ibm.com/docs/vlans?topic=vlans-ordering-premium-vlansordering-premium-vlans), or use the following command. Remember that the VLANs must be compatible, with matching Router pod IDs as in the previous step. If you are creating a pair of new public and private VLANs, they must be compatible with each other.

ibmcloud sl vlan create -t [public|private] -d <zone> -r <compatible_router>
4. Note the IDs of the compatible VLANs.



4. Set up a worker pool with the new VLAN network metadata for each zone.