vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* [Release notes](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-relnotes)



* Tutorials



* [Tutorial library for Satellite](https://cloud.ibm.com/docs?tab=tutorials&page=1&pageSize=20&tags=satellite)
* [Deploying apps to clusters with Continuous Delivery and Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-sat_toolchain_tutorial)
* [Deploying apps to clusters with Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-begin-sat-config-tutorial)
* [Connecting Locations with IBM Cloud using Direct Link](https://cloud.ibm.com/docs/satellite?topic=satellite-direct-link-tutorial)
* [Using IBM Cloud Kubernetes Service on classic to host the dl-reverse-proxy](https://cloud.ibm.com/docs/satellite?topic=satellite-dl-iks-classic)
* [Deploying OpenShift Data Foundation on Satellite clusters with Azure worker nodes](https://cloud.ibm.com/docs/satellite?topic=satellite-odf-tutorial)
* [Attaching bare metal hosts to a location](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metal)
* [Setting up virtualization on a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-virtualization-location)



* How to



* Installing the CLI



* [Installing the CLI](https://cloud.ibm.com/docs/satellite?topic=satellite-cli-install)
* [Updating the CLI](https://cloud.ibm.com/docs/satellite?topic=satellite-cli-update)
If you do not see that the new NFS storage is added to the list in the cluster, check your email or console notifications for more details.







 Related links 



* [Planning for Cyber Recovery](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-cr_planning)
* [Requirements for Cyber Recovery](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-cr_orderinginstance_reqs)
* [Adding clusters to Cyber Recovery instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-cr_addingclusters)
- list
- watch
- apiGroups:
- ""
resources:
- events
verbs:
- list
- watch
- create
- update
- patch
- apiGroups:
- snapshot.storage.k8s.io
resources:
- volumesnapshots
verbs:
- get
- list
- apiGroups:
- snapshot.storage.k8s.io
resources:
- volumesnapshotcontents
verbs:
- get
- list
- apiGroups:
- storage.k8s.io
resources:
- csinodes
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- list
- watch
- apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
version: 2.0.2_285
labels:
addonmanager.kubernetes.io/mode: Reconcile
app: ibm-vpc-block-csi-driver
name: vpc-block-provisioner-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: vpc-block-provisioner-role
subjects:
- kind: ServiceAccount
name: ibm-vpc-block-controller-sa
namespace: kube-system
- apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
version: 2.0.2_285
labels:
addonmanager.kubernetes.io/mode: Reconcile
app: ibm-vpc-block-csi-driver
name: vpc-block-external-attacher-role
rules:
- apiGroups:
- ""
resources:
For example, if you filter clusters for the wdc metro, multizone clusters in that metro and single-zone clusters in data centers (zones) within that metro are returned. If you filter clusters for the wdc06 data center (zone), multizone clusters that have a worker node in that zone and single-zone clusters in that zone are returned. ibmcloud oc cluster ls -l dal.
* Other commands don't return resources in all locations. To run credential set/unset/get, api-key reset, and vlan spanning get commands, you must specify a region in the --region.



* Working with resources:



* When you use the global endpoint, you can work with resources that you have access permissions to in any location, even if you target one region and the resource that you want to work with is in another region.
* If you have clusters with the same name in different regions, use the cluster ID when you run commands or set a region with the ibmcloud oc init command and use the cluster name when you run commands.



* Legacy functionality:



* If you need to list and work with resources from one region only, you can use the ibmcloud oc init[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_init) to target a regional endpoint instead of the global endpoint. Example to target the US South regional endpoint:

ibmcloud oc init --host https://us-south.containers.cloud.ibm.com
* To use the global functionality, you can use the ibmcloud oc init command again to target the global endpoint. Example to target the global endpoint again:

ibmcloud oc init --host https://containers.cloud.ibm.com





Red Hat OpenShift on IBM Cloud API:



* [Get started with the API](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_api_installcs_api).
You can also review security information about this decision in [Container isolation and security](https://cloud.ibm.com/docs/containers?topic=containers-securitycontainer).

Multiple clusters: You need to set up [a global load balancer](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmultiple-clusters-glb) and copy and apply the same configuration YAML files in each to balance workloads across the clusters. Therefore, multiple clusters are generally more complex to manage, but can help you achieve important goals such as the following.



* Comply with security policies that require you to isolate workloads.
* Test how your app runs in a different version of Kubernetes or other cluster software such as Calico.
* Create a cluster with your app in another region for higher performance for users in that geographical area.
* Configure user access on the cluster-instance level instead of customizing and managing multiple RBAC policies to control access within a cluster at the namespace level.



Fewer or single clusters: Fewer clusters can help you to reduce operational effort and per-cluster costs for fixed resources. Instead of making more clusters, you can add worker pools for different flavors of computing resources available for the app and service components that you want to use. When you develop the app, the resources it uses are in the same zone, or otherwise closely connected in a multizone, so that you can make assumptions about latency, bandwidth, or correlated failures. However, it becomes even more important for you to organize your cluster by using namespaces, resource quotas, and labels.





 How can I set up my resources within the cluster? 



 Consider your worker node capacity 

To get the most out of your worker node's performance, consider the following: - Keep up your core strength: Each machine has a certain number of cores. Depending on your app's workload, set a limit for the number of pods per core, such as 10. - Avoid node overload: Similarly, just because a node can contain more than 100 pods doesn't mean that you want it to. Depending on your app's workload, set a limit for the number of pods per node, such as 40.
If you prefer single zone clusters for simplified management, or if your cluster must reside in a specific [single zone city](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-sz) that does not support multizone capabilities, you can create [multiple clusters](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmultiple-clusters-glb) and connect them with a global load balancer.







 Multizone cluster 

Create a multizone cluster to distribute your workloads across multiple worker nodes and zones, and protect against zone failures with hosts, networks, or apps. If resources in one zone go down, your cluster workloads continue to run in the other zones.

Zoom

![High availability for multizone clusters.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/ha-cluster-multizone.svg)

Figure 1. High availability for multizone clusters

In a multizone cluster, the worker nodes in your worker pools are replicated across multiple zones within one region. Multizone clusters are designed to evenly schedule pods across worker nodes and zones to assure availability and failure recovery. If worker nodes are not spread evenly across the zones or capacity is insufficient in one of the zones, the Kubernetes scheduler or Red Hat OpenShift controller might fail to schedule all requested pods. As a result, pods might go into a Pending state until enough capacity is available. If you want to change the default behavior to make Kubernetes scheduler or Red Hat OpenShift controller distribute pods across zones in a best effort distribution, use the preferredDuringSchedulingIgnoredDuringExecution[pod affinity policy](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).
For the Problem type, search for or select Kubernetes Service.
6. For the Case details, provide a descriptive title and include the details that you previously gathered. From the Resources, you can also select the cluster that the issue is related to.







 Requesting access to allowlisted features 



1. [Create a ticket](https://cloud.ibm.com/unifiedsupport/cases/form).
2. On the Category tab, select Account
3. On the Topic tab, select the Other subtopic and click Next.
4. On the Details tab, in the Subject field, enter Allowlist request for <FEATURE> for account <ACCOUNTID> and include the feature name and your account ID.
5. In the Description field, include details about the feature that you want access to.
6. Click Next and review your selections ticket.
7. Click Submit case.
8. After support processes the ticket, you will receive a notification that your account is updated.
Primary cluster 



 Cluster name 

By default, the primary cluster name is set to vrw-xx-management.

You can also specify a cluster name that meets the following requirements:



* Only lowercase alphabetic, numeric, and dash (-) characters are allowed.
* The cluster name must start with a lowercase alphabetic character.
* The cluster name must end with a lowercase alphabetic or numeric character.
* The maximum length of the cluster name is 10 characters.
* The cluster name must be unique within your account.







 Cluster type 

You can start with a smaller footprint by deploying a consolidated management and workload cluster, or you can deploy a management cluster and a separate cluster for workloads.



* Management-optimized cluster supports separate management and workload clusters.

If you don't want workloads to run on the primary cluster, select this option. With this option, you get a 2-CPU Intel® Cascade Lake processor with 20 cores, 2.2 GHz, and 192 GB RAM per bare metal server. You must include a separate cluster for workloads. Under Additional cluster for workloads, complete the settings to customize the bare metal hardware based on your workload capacity requirements.
* Customizable consolidated cluster supports a range of CPU and RAM options to optimize capacity for both management and workload clusters.

You can choose the Cascade Lake server and RAM size according to your needs. This option is available in single-zone deployments (nonstretched) and brings down the entry price point by enabling workloads to run alongside VMware® management components in the same cluster. You can start with only 6 hosts instead of 10. This option is helpful for proof of concepts (POCs) or if you want to start small and grow over time.







 Number of bare metal servers 

You can order 4-51 servers. All servers have the same configuration.





 vSAN configuration 



* For the Small capacity, you get two vSAN™ capacity disks 1.9 TB SSD.
* For the Customizable capacity, you can choose the type and number of capacity disks according to your needs.
* Use the IBM-provided VMware license for vSAN by selecting Include with purchase.
* Satellite resources, such as the names of locations, hosts, Satellite Link endpoints, Satellite configurations, versions, subscriptions, cluster group names, or storage configurations.
* [Satellite-enabled services](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services) resources, such as the names of service instances or clusters.
* Managed Kubernetes resources that run in clusters in your Satellite location, such as the names and resource definitions of deployments, pods, services, secrets, or config maps.
* The definitions of resources managed by Satellite config, including their data. Sensitive keys or personally identifiable information should be managed with Secrets Manager, or encrypted with Key Protect.
* Any other resources that run in your Satellite location.









 How is my information stored, backed up, and encrypted when using Satellite? 

Review the following image to see how your personal and sensitive information is stored, backed up, and encrypted.

Zoom

![Satellite data security](https://cloud.ibm.com/docs-content/v1/content/c8335d66af691d19e837116fd633481c477061eb/satellite/images/satellite_data_security.svg)

Figure 1. Satellite data security

(1) All personal and sensitive information
: Review the location, access, backup and encryption details for personal and sensitive information.



* Location: All data is stored in a Satellite persistent storage instance in the location's Satellite control plane master.
* Access and data management: The persistent storage instance is owned and managed by the Satellite control plane service team. You cannot access the data in the persistent storage instance.
* Backup: See 2 and 3 to see how data is backed up.
* Encryption: Data is encrypted at rest with a customer root key from an IBM-owned IBM Key Protect service instance.



(2) TLS certificate, TLS secret, and Certificate Authority to encrypt the Satellite control plane domain
: Review the location, access, backup and encryption details for TLS secret and CA information.
* [ibmcloud ks worker-pool](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_worker-pool)
* [ibmcloud ks zone](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_zone)
* [ibmcloud ks ingress](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_ingress)
* [ibmcloud ks logging](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_logging)
* [ibmcloud ks nlb-dns](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_nlb-dns)
* [ibmcloud ks webhook-create](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_webhook-create)
* [ibmcloud ks api-key](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_api-key)
* [ibmcloud ks credential](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_credential)
* [ibmcloud ks infra-permissions](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_infra-permissions)
* [ibmcloud ks kms](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_kms)
* [ibmcloud ks quota](https://cloud.ibm.com/docs/containers?topic=containers-icks_mapicks_map_quota)
[API reference](https://containers.cloud.ibm.com/global/swagger-global-api//satellite-cluster)





 CLI plug-in reference 

[IBM Cloud Satellite CLI map](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map)



* [ibmcloud sat cluster](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_cluster)
* [ibmcloud sat config](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_config)
* [ibmcloud sat endpoint](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_endpoint)
* [ibmcloud sat group](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_group)
* [ibmcloud sat host](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_host)
* [ibmcloud sat key](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_key)
* [ibmcloud sat location](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_location)
* [ibmcloud sat resource](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_resource)
* [ibmcloud sat service](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_service)
* [ibmcloud sat storage](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_storage)
Get the ID of the cluster, cluster group, or service that you want to assign storage to.

To make sure that your cluster is registered with Satellite Config or to create groups, see [Setting up clusters to use with Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig).

Example command to list cluster groups.

ibmcloud sat group ls

Example command to list clusters.

ibmcloud oc cluster ls --provider satellite

Example command to list Satellite services.

ibmcloud sat service ls --location <location>
3. Assign your storage configuration to the cluster, group, or service that you retrieved earlier. For more information, see the ibmcloud sat storage assignment create[command](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencecli-storage-assign-create).

Example command to assign a configuration to a cluster group.

ibmcloud sat storage assignment create --group GROUP --config CONFIG --name NAME

Example command to assign a configuration to a cluster.

ibmcloud sat storage assignment create --cluster CLUSTER --config CONFIG --name NAME

Example command to assign a configuration to a service cluster.

ibmcloud sat storage assignment create --service-cluster-id CLUSTER --config CONFIG --name NAME
4. Verify that your assignment is created.

ibmcloud sat storage assignment ls (--cluster CLUSTER | --config CONFIG | --location LOCATION | --service-cluster-id CLUSTER)







 Creating a storage assignment in the API 



1. Copy one of the following example requests.

Example request to assign a [configuration to a cluster](https://containers.cloud.ibm.com/global/swagger-global-api//satellite/createAssignmentByCluster).
-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

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

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



 Example worker-pool rebalance command 

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







 ibmcloud oc worker-pool resize 

Virtual Private Cloud

Classic infrastructure

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

ibmcloud oc worker-pool resize --cluster CLUSTER --worker-pool WORKER_POOL --size-per-zone WORKERS_PER_ZONE [-q]

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

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster for which you want to resize worker pools.

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

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

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



 Example worker-pool resize command 

ibmcloud oc worker-pool resize --cluster my_cluster --worker-pool my_pool --size-per-zone 3







 ibmcloud oc worker-pool rm 

Virtual Private Cloud

Classic infrastructure

Remove a worker pool from your cluster. All worker nodes in the pool are deleted.
* [Prerequisites](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusterprereqs)
* [Accessing clusters through the public cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_public_se)



* [Connecting to the cluster from the console](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_oc_console)
* [Connecting to the cluster from the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_oc_cli)



* [Accessing clusters through the private cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_private_se)



* [Accessing VPC clusters through the private cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clustervpc_private_se)
* [Accessing classic clusters through the private cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusterclassic_private_se)
* [Creating an allowlist for the private cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusterprivate-se-allowlist)



* [Accessing Red Hat OpenShift clusters on Satellite](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat)



* [Accessing clusters through the cluster service URL](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat_se)
In the labels section, specify the existing cluster role that you want to aggregate permissions to. The following example extends the predefined admin cluster role to allow users to run kubectl top pods. For more examples, [see the Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/aggregated-clusterroles).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: view-pod-metrics
labels:
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
- apiGroups:
- "metrics.k8s.io"
resources:
- pods
verbs:
- list



Table 4. Understanding the YAML parameters

 Parameter Description 

 metadata.name Enter a name for the cluster role. don't use the predefined cluster role names: view, edit, admin, and cluster-admin. 
 metadata.labels Add a label that matches the cluster role that you want to aggregate to in the format rbac.authorization.k8s.io/aggregate-to-<cluster_role>: "true". The labels for the predefined cluster roles are as follows.<br><br><br><br> * IAM Manager service access role, scoped to a namespace: rbac.authorization.k8s.io/aggregate-to-admin: "true"<br> * IAM Writer service access role: rbac.authorization.k8s.io/aggregate-to-edit: "true"<br> * IAM Reader service access role: rbac.authorization.k8s.io/aggregate-to-view: "true"<br><br><br>
Clusters with public network connectivity: [Multiple clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmultiple-clusters-glb) that are set up across zones or regions and that are connected via a global load balancer.





 Single zone clusters 

Single zone clusters can be created in one of the supported [single zone locations](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-sz). To improve availability for your app and to allow failover for the case that one worker node is not available in your cluster, add additional worker nodes to your single zone cluster.

VPC clusters are supported only in [multizone metro locations](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-vpc). If your cluster must reside in one of the single zone cities, create a classic cluster instead.

Zoom

![High availability for clusters in a single zone.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/ha-cluster-singlezone.svg)

Figure 1. High availability for clusters in a single zone

You can add more worker nodes to your cluster by [resizing an existing worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersresize_pool) or by [adding a new worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersadd_pool). When you add more worker nodes, app instances can be distributed across multiple worker nodes. If one worker node goes down, app instances on available worker nodes continue to run. Red Hat OpenShift automatically reschedules pods from unavailable worker nodes to ensure performance and capacity for your app.