vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You can run ibmcloud sat storage templates as an alias of the ibmcloud sat storage template ls command.



 Minimum required permissions 

IBM Cloud IAM Viewer platform role for the Configuration resource in Satellite. For more information, see [Checking user permissions](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-assign-accesschecking-perms).





 Command options 

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





 Example 

ibmcloud sat storage template ls









 Subscription commands 

Use these commands to manage subscriptions to Satellite configurations for your registered clusters.

You can use the sub alias for subscription commands.



 ibmcloud sat subscription create 

Create a subscription for Red Hat OpenShift on IBM Cloud clusters to deploy a Satellite configuration version. After you create the subscription, the associated Satellite configuration version is automatically deployed to the subscribed clusters.

ibmcloud sat subscription create --name NAME --group GROUP [--group GROUP] --config CONFIG (--auth-required --gitref GITREF --gitref-type TYPE --path PATH --repository REPOSITORY | --version VERSION) [-q]



 Minimum required permissions 

IBM Cloud IAM Editor platform role for the Subscription resource in Satellite. For more information, see [Checking user permissions](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-assign-accesschecking-perms).





 Command options 

--name NAME
: Required. The name to give your subscription.

--group GROUP
: Required. The name or ID of the cluster group that includes the Red Hat OpenShift on IBM Cloud clusters where you want to deploy the configuration version. To list available cluster groups, run ibmcloud sat group ls.

--config CONFIG
: Required. The name of the configuration where you added the Kubernetes resource definition as a version that you want to deploy to your clusters. To list available configurations, run ibmcloud sat config ls.
Cluster add-ons Review the [unsupported managed add-ons for Red Hat OpenShift clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-managed-addonsaddons-satellite) in a Satellite location. For example, the cluster autoscaler and Istio are not supported. 
 Logging and monitoring You can't currently use the Red Hat OpenShift on IBM Cloud console or the observability plug-in CLI (ibmcloud ob) to enable logging and monitoring for Satellite clusters. Instead, you can manually deploy [Log Analysis agents](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-tutorial-use-logdna) and [Monitoring agents](https://cloud.ibm.com/docs/monitoring?topic=monitoring-kubernetes_clusterkubernetes_cluster) to your cluster to forward logs and metrics to IBM Log Analysis and IBM Cloud Monitoring. 
 Network <br><br> * By default, there is no load balancer controller deployed with Satellite clusters and therefore, [Kubernetes LoadBalancer services](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) are not provision by default.
Opening required ports and IP addresses in your allowlist 

Classic clusters

This allowlist information is specific to classic clusters. For VPC clusters, see [Opening required ports and IP addresses in your allowlist for VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-firewall).

Review these situations in which you might need to open specific ports and IP addresses in your allowlists for your Red Hat® OpenShift® on IBM Cloud® clusters.



* [Corporate allowlists](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallcorporate): If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, you must allow access to run ibmcloud, ibmcloud oc, ibmcloud cr, oc, and calicoctl commands from your local system.
* [Gateway appliance allowlists](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallvyatta_firewall): If you have allowlists set up on the public or private network in your IBM Cloud infrastructure account, such as a VRA, you must open IP ranges, ports, and protocols to allow worker nodes to communicate with the master, with infrastructure resources, and with other IBM Cloud services. You can also open ports to allow incoming traffic to services exposing apps in your cluster.
* [Calico network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_calico_egress): If you use Calico network policies to act as an allowlist to restrict all worker node egress, you must allow your worker nodes to access the resources that are required for the cluster to function.
* [Other services or network allowlists](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_workers): To allow your cluster to access services that run inside or outside IBM Cloud or in on-premises networks and that are protected by an allowlist, you must add the IP addresses of your worker nodes in that allowlist.
[Multisite deployment topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-m-s.svg)

Figure 1. Multisite deployment topology



1. The vCenter Server automation deploys an initial vSphere cluster on the primary instance, which includes a vCenter, three NSX-T managers, and an Active Directory deployment. They run either on a single IBM Cloud Classic Virtual Server Instance or two VMware VMs in a high availability deployment. This instance includes a vCenter, three NSX-T managers, an Active Directory deployment with either running on a single IBM Cloud Classic Virtual Server Instance or two VMware VMs in a high availability deployment and two NSX-T edge clusters, one for services and one for workloads.
2. The initial vCenter Server instance can include several vSphere clusters (refer to single site deployment). They are typically deployed in the initial IBM Cloud data center location.
3. You can provision a secondary vCenter Server instance after the primary that is deployed. This option deploys automatically a secondary vCenter Server instance in the new IBM Cloud data center location. This instance is then linked to the initial primary vCenter Server single site deployed on step 1. You can create multiple secondary instances. As the primary, this instance includes a vCenter, three NSX-T managers, an Active Directory deployment with either running on a single IBM Cloud Classic Virtual Server Instance or two VMware VMs in a high availability deployment and two NSX-T edge clusters, one for services and one for workloads. The second site is under the same SSO and root domain as the primary.
4. As the primary, also the secondary vCenter Server instance can include several vSphere clusters. They are typically deployed in the same IBM Cloud data center location as the secondary.
5. You can add NFS based IBM Cloud File Storage for Classic to your clusters.
Your custom ingress gateway load balancer now uses the port in the Gateway resource and the microservice paths in the VirtualService resource to route traffic to the BookInfo app. Next, you can optionally [create a DNS record for the custom gateway load balancer](https://cloud.ibm.com/docs/containers?topic=containers-istio-custom-gatewaycustom-gateway-bookinfo-dns).





 Exposing BookInfo by using an IBM-provided subdomain with TLS 

Create an IBM-provided subdomain to register the IP address (classic) or hostname (VPC) of the custom gateway load balancer with a DNS record. The TLS certificate that is generated for the subdomain enables HTTPS connections to the BookInfo app.



1. Register the IP address or hostname of the custom gateway load balancer by creating a DNS subdomain. Specify the custom-gateway namespace for the TLS secrets.



* Classic clusters

ibmcloud ks nlb-dns create classic --cluster <cluster_name_or_id> --ip <LB_IP> --secret-namespace custom-gateways
* VPC clusters

ibmcloud ks nlb-dns create vpc-gen2 -c <cluster_name_or_ID> --lb-host <LB_hostname> --secret-namespace custom-gateways



2. Verify that the subdomain is created.

ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>

Example output for classic clusters

Hostname IP(s) Health Monitor SSL Cert Status SSL Cert Secret Name
mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud ["168.1.1.1"] None created <certificate>

Example output for VPC clusters

Subdomain Load Balancer Hostname Health Monitor SSL Cert Status SSL Cert Secret Name
--location LOCATION
: Required. Enter the ID or name of the location where the Satellite-enabled IBM Cloud service clusters exist. To retrieve the location ID or name, run ibmcloud sat location ls.

--output JSON
: Optional. Displays the command output in JSON format.

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





 Example 

ibmcloud sat service ls --location mylocation









 Storage commands 

Use these commands to view the storage resources that run in clusters that are registered with [Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig).

The ibmcloud sat storage assignment group of commands are available in beta.

Before working with your Satellite storage assignments and configurations, be sure to target the Managed from region of your Satellite by running ibmcloud sat location ls then ibmcloud target -r <region>.



 ibmcloud sat storage assignment create 

Create a Satellite storage assignment to deploy storage drivers to your clusters.

ibmcloud sat storage assignment create --config CONFIG (--cluster CLUSTER_ID | --group GROUP [--group GROUP ...] | --service-cluster-id CLUSTER_ID) [--name NAME] [-q]



 Minimum required permissions 

IBM Cloud IAM Editor platform role for the Resource resource in Satellite. For more information, see [Checking user permissions](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-assign-accesschecking-perms).





 Command options 

--config CONFIG
: Required. The name of the storage configuration that you want to assign to your cluster group. To list Satellite storage configurations, run ibmcloud sat storage config ls.

--cluster CLUSTER_ID
: The ID of a Satellite cluster. To list Satellite clusters, run ibmcloud oc cluster ls --provider satellite. To assign the storage configuration to multiple clusters at once, create a cluster group or run this command with this option multiple times.
Opening required ports and IP addresses in your allowlist 

Classic clusters

This allowlist information is specific to classic clusters. For VPC clusters, see [Opening required ports and IP addresses in your allowlist for VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-vpc-firewall).

Review these situations in which you might need to open specific ports and IP addresses in your allowlists for your IBM Cloud® Kubernetes Service clusters.



* [Corporate allowlists](https://cloud.ibm.com/docs/containers?topic=containers-firewallcorporate): If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, you must allow access to run ibmcloud, ibmcloud ks, ibmcloud cr, kubectl, and calicoctl commands from your local system.
* [Gateway appliance allowlists](https://cloud.ibm.com/docs/containers?topic=containers-firewallvyatta_firewall): If you have allowlists set up on the public or private network in your IBM Cloud infrastructure account, such as a VRA, you must open IP ranges, ports, and protocols to allow worker nodes to communicate with the master, with infrastructure resources, and with other IBM Cloud services. You can also open ports to allow incoming traffic to services exposing apps in your cluster.
* [Calico network policies](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_calico_egress): If you use Calico network policies to act as an allowlist to restrict all worker node egress, you must allow your worker nodes to access the resources that are required for the cluster to function.
* [Other services or network allowlists](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_workers): To allow your cluster to access services that run inside or outside IBM Cloud or in on-premises networks and that are protected by an allowlist, you must add the IP addresses of your worker nodes in that allowlist.





 Opening ports in a corporate allowlist
- In Classic or VPC Clusters: Problems with the network connections to and from workers in the new Classic VLANs or VPC subnets if you have any Security Groups, Network ACLs, Firewall/Gateway rules, Custom routing, coreDNS configurations, and so on, that are specific to the old VLANs, VPC subnets, or cluster worker IP addresses or subnets.
4. 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.



* 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



5. Verify that worker nodes are available in your new worker pool. In the output, find the listing for the new worker pool and check the number in the Workers column.

ibmcloud ks worker-pool ls --cluster <cluster_name_or-ID>
6. Classic clusters: If you created your worker pool in a new VLAN, move your ALBs to the new VLAN. For more information, see [Moving ALBs across VLANs in classic clusters](https://cloud.ibm.com/docs/containers?topic=containers-ingress-alb-managemigrate-alb-vlan).







 Removing your old worker pools 

Before you remove your Ubuntu 18 worker pools, consider scaling them down and keeping them for several days before you remove them. This way, you can scale the worker pool back up if your workload experiences disruptions during the migration process. When you determine that your workload is stable and functions normally, you can remove the Ubuntu 18 worker pool.



1. List your worker pools and note the name of the worker pool you want to remove.
Exposing apps with load balancers for VPC 

Virtual Private Cloud

Set up a Load Balancer for VPC to expose your app on the public or private network.

VPC load balancers can be created for VPC clusters only, and can't be created for classic clusters. To load balance in classic clusters, see [Classic: About network load balancers (NLBs)](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-about).

To expose an app in a VPC cluster, you can create a layer 7 Application Load Balancer for VPC. You can optionally create a layer 4 Network Load Balancer for VPC.

The following table describes the basic characteristics of each load balancing option.



Load balancing options for VPC clusters

 Characteristic Application Load Balancer for VPC Network Load Balancer for VPC 

 Supported Kubernetes version All versions All versions 
 Transport layer Layer 7 Layer 4 
 Types of load balancers Public and private Public and private 
 Supported protocols TCP TCP, UDP 
 Application access Hostname Hostname and static IP address 
 Source IP preservation Configurable* Yes 
 Improved performance with direct server return No Yes 
 Multizone routing Yes No 
 Port ranges No Public only 
 Security groups Yes Public only 





 Network Load Balancer for VPC 

In VPC clusters, set up a layer-4 [Network Load Balancer for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-network-load-balancers) (VPC NLB) in each zone of your cluster to serve as the external entry point for incoming requests to an app.

VPC NLBs provide several advantages, such as providing higher throughput and better performance by utilizing direct server return (DSR). With DSR, the worker node can send app response packets directly to the client IP address and skip the VPC NLB, decreasing the amount of traffic that the VPC NLB must handle. Additionally, the VPC NLB supports source IP address preservation on all client requests by default.
Single zone clusters can be created in one of the supported [single zone locations](https://cloud.ibm.com/docs/containers?topic=containers-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/containers?topic=containers-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/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/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/containers?topic=containers-add_workersresize_pool) or by [adding a new worker pool](https://cloud.ibm.com/docs/containers?topic=containers-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. Kubernetes automatically reschedules pods from unavailable worker nodes to ensure performance and capacity for your app. To ensure that your pods are evenly distributed across worker nodes, implement [pod affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).



 Is my master highly available in a single zone cluster?
Learning about Continuous Delivery and workload isolation 

IBM Cloud® Continuous Delivery is offered as a regional, shared, multi-tenant service with public endpoints. This service is composed of several major components. Most of these components are fully IBM-managed, and most support a shared compute, network, and physical storage model.

The following table lists the major components of the Continuous Delivery service, who manages each component, and the compute, network, and storage isolation characteristics of each component.



Table 1. Service component management

 Component Manager Isolation characteristics 

 Toolchain platform IBM Shared, compute, network, and storage 
 Third-party tool integrations IBM Shared, compute, network, and storage 
 Git Repos and Issue Tracking IBM Shared, compute, network, and storage 
 DevOps Insights IBM Shared, compute, network, and storage 
 Delivery Pipeline IBM Shared, compute, network, and storage 
 Delivery Pipeline shared workers IBM Each pipeline job or step runs in isolation, in its own container, on a pool of IBM-managed shared worker nodes with shared network and storage. 
 Delivery Pipeline private workers You Each pipeline job or step runs in isolation, in its own container on worker nodes that you manage, supported by network and storage that you define or manage. 



Delivery Pipeline jobs and steps run directly within containers on shared (IBM-managed) or private (customer-managed) Kubernetes worker nodes. All other components of the Continuous Delivery service are deployed as microservices within IBM-managed Kubernetes clusters. These components are logically partitioned across a set of clusters. Each set of clusters is replicated across three zones in each region in which the Continuous Delivery service is available.

Zoom

![Continuous Delivery clusters](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/CD_cluster_arch.svg)

Figure 1. Continuous Delivery clusters

For more information about availability, see [High availability and disaster recovery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-ha-dr).
29 September 2021 

New! OpenShift 4.8
: You can create or [update clusters to OpenShift version 4.8](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions). With OpenShift 4.8, you get the latest OpenShift features, as well as component updates on Red Hat OpenShift on IBM Cloud. For more information, [see the blog announcement](https://www.ibm.com/cloud/blog/announcements/openshift-version-48-now-available-in-red-hat-openshift-on-ibm-cloud).

Deprecated and unsupported OpenShift versions
: With the release of OpenShift 4.8, clusters that run version 4.5 remain deprecated, with a tentative unsupported date of 10 Oct 2021. Clusters that run versions 4.3 or 4.4 are unsupported. Update your cluster to at least [version 4.6](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions) as soon as possible.

Master fix pack and worker node fix pack update
: Change log documentation is available for OpenShift version [4.8.11_1526_openshift and 4.8.12_1527_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_48).





 27 September 2021 

Master fix pack update
* [Bringing your own OCP license](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clustersbyo-ocp-satellite)



[Creating a private-only cluster in VPC by using a Schematics template](https://cloud.ibm.com/docs/openshift?topic=openshift-templatestemplates)



* [Resources that are created from the template](https://cloud.ibm.com/docs/openshift?topic=openshift-templatessch-tf-resources-created)
* [Creating a secure cluster by using a template from the UI](https://cloud.ibm.com/docs/openshift?topic=openshift-templatessch-secure-cluster-ui)
* [Creating a secure cluster by using a template with the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-templatestf-secure-cluster-cli)
* [Next steps](https://cloud.ibm.com/docs/openshift?topic=openshift-templatessch-tf-whats-next)







 Accessing clusters 

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



* [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)
The Kubernetes 1.19 release is also certified.

Deprecated: Kubernetes version 1.16
: With the release of version 1.19, clusters that run version 1.16 are deprecated. Update your clusters to at least [version 1.17](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsk8s_version_archive) today.

New! Network load balancer for VPC
: In VPC Gen 2 clusters that run Kubernetes version 1.19, you can now create a layer 4 Network Load Balancer for VPC. VPC network load balancers offer source IP preservation and increased performance through direct server return (DSR). For more information, see [About VPC load balancing in IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas).

Version change logs
: Change log documentation is available for [1.19.2_1524](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1191192_1524).

VPC load balancer
: Added support for setting the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector and service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnet annotations when you create new VPC load balancers in clusters that run Kubernetes version 1.19.

VPC security groups
: Expanded the list of required rules based on the cluster version for default VPC security groups.

Object Storage in VPC Gen 2
: Added support for authorized IP addresses in IBM Cloud Object Storage for VPC Gen 2. For more information, see [Allowing IP addresses for IBM Cloud Object Storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_cos_vpc_ip).





 12 October 2020 

Versions
: Worker node fix pack update change log documentation is available.