vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Bring your own Operators, drivers, and plug-ins
: You can also bring your own storage drivers to Satellite by installing them from the Catalog, OperatorHub, Helm charts, or by using your preferred method of deploying images to your clusters including images and drivers from various IBM Cloud storage and partner solutions, for example Portworx. Bringing your own storage driver is functionally supported, but you are responsible for the entire lifecycle operations, installation, troubleshooting, and support.

While bringing your own drivers or operators to your Satellite clusters is possible, if you want to deploy IBM Cloud services that use storage make sure you use one of the provided storage templates.





 Which deployment option should I use? 

Since Satellite storage templates are supported by IBM Cloud and the configurations that you create by deploying templates can be used across your Satellite clusters, service clusters, and cluster groups, templates are the preferred option when setting up storage for services in Satellite.

If the storage solution that you want to use does not have a Satellite template available, check the IBM Cloud Catalog for supported Helm charts and Operators.





 What are the benefits of using templates? 

With Satellite storage templates, you can create a storage configuration that can be deployed across your clusters without the need to re-create the configuration for each cluster.

The Satellite storage templates are provided and tested by IBM or third-party vendors. IBM provides the configuration tooling to install the storage drivers on clusters in your Satellite location as described in the templates. For issues with the installation process, you can contact IBM. However, for issues with lifecycle operations of the storage devices, contact the storage provider.

When you use a Satellite storage template to create a configuration, you include the details for the storage provider that you want to use. Each template contains a set of parameters that is specific to the storage provider. These parameters include things like credentials, device information, worker nodes, and more. After you use a template to create a storage configuration, you can reuse that configuration to assign storage across your Satellite clusters.

You can also quickly update the configuration parameters and apply them automatically across clusters, service clusters, and cluster groups in your locations.



Comparison of supported features between using Satellite storage templates and bringing your own storage drivers

 Feature or benefit Satellite storage templates Bring your own drivers
vSphere HA virtual machine failover failed Configure to send email one time when critical for critical appliances. [Creating and using vSphere HA Clusters](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.avail.doc/GUID-5432CA24-14F1-44E3-87FB-61D937831CF6.html) 
 vSphere HA virtual machine monitoring action Configure to send email one time when critical for critical appliances. [Creating and using vSphere HA clusters](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.avail.doc/GUID-5432CA24-14F1-44E3-87FB-61D937831CF6.html) 
 vSphere HA virtual machine monitoring error Configure to send email one time when critical for critical appliances. [Creating and using vSphere HA clusters](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.avail.doc/GUID-5432CA24-14F1-44E3-87FB-61D937831CF6.html) 
 vSphere HA VM Component Protection could not power off a virtual machine Configure to send email one time when critical for critical appliances. [Creating and Using vSphere HA Clusters](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.avail.doc/GUID-5432CA24-14F1-44E3-87FB-61D937831CF6.html) 
 License error * Not considered essential for notification. Alarm that is reviewed as part of proactive daily checks.
For example, if 1 zone becomes unavailable due to a failure, or if 1 host becomes unavailable due to updating, the remaining 2 zones are still available to run control plane operations. A poor high availability setup is 2 hosts that are virtual machines on the same hypervisor, because servicing the underlying hardware such as to update the machine would make both hosts become unavailable. For more information, see [High availability for IBM Cloud Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-ha).

Compute capacity
: Satellite monitors the available compute capacity of your location. When the location reaches 70% capacity, you see a warning status to notify you to attach more hosts to the location. If the location reaches 80% capacity, the status changes to critical and you see another warning that tells you to attach more hosts to the location.

Plan to keep at least 3 extra hosts attached and unassigned to your location. When you have extra hosts, then IBM can assign the hosts to your Satellite location control plane automatically when the location reaches the warning capacity threshold or an unhealthy host needs to be replaced.



 Location size for non Red Hat CoreOS enabled location 

The following tables show sizing guidance for the number of hosts that the Satellite location control plane requires to run the master components for various combinations of clusters and worker nodes in a non Red Hat CoreOS enabled location. These sizings are for reference only. Your sizing requirements can increase depending on the amount of workload running in a cluster. For more information, see [What types of changes can increase my location sizing requirements?](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizingtypes-changes-sizing-increase).

4 vCPU, 16 GB RAM

16 vCPU, 64 GB RAM



Sizing guidance for the Satellite location control plane

 Number of control plane hosts Max clusters in location Example of max worker nodes in location Max cluster size 

 6 hosts Up to 5 clusters 20 workers across 5 clusters, or 80 workers across 2 clusters 60 workers per cluster 
 9 hosts Up to 8 clusters 40 workers across 8 clusters, or 140 workers across 3 clusters 60 workers per cluster
Configuring classic subnets and IP addresses 

Change the pool of available portable public or private IP addresses by adding subnets to your IBM Cloud® Kubernetes Service cluster.

The content on this page is specific to classic clusters. For information about VPC clusters, see [Configuring subnets and IP addresses for VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnets).



 Overview of classic networking in IBM Cloud Kubernetes Service 

Understand the basic concepts of classic networking in IBM Cloud Kubernetes Service clusters. IBM Cloud Kubernetes Service uses VLANs, subnets, and IP addresses to give cluster components network connectivity.



 VLANs 

When you create a cluster, the cluster's worker nodes are connected automatically to a VLAN. A VLAN configures a group of worker nodes and pods as if they were attached to the same physical wire and provides a channel for connectivity among the workers and pods.

VLANs for standard clusters
: In standard clusters, the first time that you create a cluster in a zone, a public VLAN and a private VLAN in that zone are automatically provisioned for you in your IBM Cloud infrastructure account. For every subsequent cluster that you create in that zone, you must specify the VLAN pair that you want to use in that zone. You can reuse the same public and private VLANs that were created for you because multiple clusters can share VLANs. You can either connect your worker nodes to both a public VLAN and the private VLAN, or to the private VLAN only. If you want to connect your worker nodes to a private VLAN only, you can use the ID of an existing private VLAN or [create a private VLAN](https://cloud.ibm.com/docs/cli/reference/ibmcloud?topic=cli-manage-classic-vlanssl_vlan_create) and use the ID during cluster creation.

To see the VLANs that are provisioned in each zone for your account, run ibmcloud ks vlan ls --zone <zone>.
* [ClusterIP](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningcluster-ip-service)
* [NodePort](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningnodeport-service)
* [LoadBalancer](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningloadbalancer-service)
* [Ingress](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningingress-service)



* [Planning public external load balancing](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningpublic_access)



* [Choosing a deployment pattern for classic clusters](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningpattern_public)
* [Choosing a deployment pattern for VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningpattern_public_vpc)



* [Planning private external load balancing](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningprivate_access)



* [Choosing a deployment pattern for classic clusters](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningpattern_private_classic)
* [Choosing a deployment pattern for VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningpattern_private_vpc)







 Exposing apps with load balancers 

[Quick start for load balancers](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-qsloadbalancer-qs)
* UI







 Deploying apps to clusters with Satellite Config 

Set up a Satellite configuration to automatically deploy your Kubernetes resources to multiple clusters.



 Objectives 

With Satellite Config UI or CLI, you create a configuration that specifies which Kubernetes resources you want to deploy to a cluster group. Then, the system can automatically deploy these resources across the clusters.

In this tutorial, you create a configuration to deploy a food ordering app, which includes several micro services such as front end, back end, route, and database. After you deploy the version 1 of the food delivery app, you then create a version of app which changes the appearance to use a dark theme.





 Audience 

This tutorial is for Location administrators who are using Satellite Config to deploy resources for the first time.





 Prerequisites 

Before you start this tutorial, make sure that you have the following resources in place.



* A Satellite location for deploying the resources.
* A Satellite cluster or a Red Hat® OpenShift® cluster on IBM Cloud that is registered with your Satellite location.
* A Satellite cluster group that contains the clusters you want to deploy resources to.
* Make sure that Satellite Config has admin access to your clusters. You can either enable admin access when creating the cluster or [grant Satellite Config access to your clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig) after you create the cluster.







 Beginner tutorial: Deploying a hello world app 

Follow these steps if you are new to Satellite Config and want to try out the process by deploying some sample resources in an existing IBM Git repo to your clusters.



1. Log in to the [Satellite Config UI](https://cloud.ibm.com/satellite/configuration) with your IBM Cloud credentials.
2. Click Create configuration.
3. Select the GitOps - Sample application template and follow the prompts.







 Advanced tutorial: Deploying an app and updating it with new versions
A cron job periodically triggers a Cloud Function to push anonymized data documents from the regional centers to the global processing cluster's IBM Cloudant instance.
: The compute cluster runs the PyTorch ML framework, and machine learning apps are written in Python to analyze the aggregated data. In addition to ML apps, researchers in the collective group also develop their own apps that can be published and run on the global cluster.
: The nonprofit also provides apps that run on non-bare metal nodes of the global cluster. The apps view and extract the aggregated data and the ML app output. These apps are accessible by a public endpoint, which is secured by the API Gateway to the world. Then, researchers and data analysts from everywhere can download data sets and do their own analysis.

Developers started by deploying their research-sharing SaaS apps in containers with Red Hat OpenShift on IBM Cloud. They created clusters for a Development environment that allow worldwide Developers to collaboratively deploy app improvements quickly.

Security first: The Development Exec chose bare metal to host the research clusters. With bare metal for Red Hat OpenShift on IBM Cloud, the sensitive research workloads now have familiar isolation but within the flexibility of public cloud. Because this nonprofit also has a partnership with pharmaceutical companies, app security is crucial. Competition is fierce, and corporate espionage is possible. From that secure core, Vulnerability Advisor provides scanning.



* Image vulnerability scanning
* Policy scanning based on ISO 27k



Secured research apps lead to increased clinical trial participation.

To achieve global availability, the Dev, Test, and Production systems are deployed across the globe in several data centers. For HA, they use a combination of clusters in multiple geographic regions as well as multizone clusters. They can easily deploy the research app to Frankfurt clusters to comply with the local European regulation. They also deploy the app within the United States clusters to ensure availability and recovery locally. They also spread the research workload across multizone clusters in Frankfurt to ensure that the European app is available and also balances the workload efficiently. Because researchers are uploading sensitive data with the research-sharing app, the app’s clusters are hosted in regions where stricter regulations apply.
You can continue to work with these clusters in your account. Make sure that at least one other user has the [Administrator platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users) for the clusters.
* If the user owns the infrastructure account, then the infrastructure account is deleted when the user leaves. You can't continue to work with these clusters. To prevent the cluster from becoming orphaned, the user must delete the clusters before the user leaves. If the user leaves but the clusters were not deleted, you must use the ibmcloud oc credential set command to change your infrastructure credentials to the account that the cluster worker nodes are provisioned in, and delete the cluster. For more information, see [Unable to modify or delete infrastructure in an orphaned cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster_infra_errors).





5. Repeat these steps for each combination of resource groups and regions where you have clusters.







 Removing a user from your account 

If a user in your account is leaving your organization, you must remove permissions for that user carefully to ensure that you don't orphan clusters or other resources. After you remove permissions, you can remove the user from your IBM Cloud account.



1. [Check that the user's infrastructure credentials are not used](https://cloud.ibm.com/docs/openshift?topic=openshift-usersremoving_check_infra) for any Red Hat OpenShift on IBM Cloud resources.
2. If you have other service instances in your IBM Cloud account that the user might have provisioned, check the documentation for those services for any steps that you must complete before you remove the user from the account.
3. [Remove the user from the IBM Cloud account](https://cloud.ibm.com/docs/account?topic=account-remove). When you remove a user, the user's assigned IBM Cloud IAM platform access roles, Cloud Foundry roles, and IBM Cloud infrastructure roles are automatically removed.
4.
* [Public app networking for classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningpattern_public)
* [Public app networking for VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningpattern_public_vpc)



* [Planning private external load balancing](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningprivate_access)



* [Private app networking for classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningprivate_both_vlans)
* [Private app networking for VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningprivate_vpc)







 Exposing apps with routes 

[Exposing apps with routes in Red Hat OpenShift 4](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesopenshift_routes)



* [Overview](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroutes-overview)



* [Traffic flow in a classic single-zone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroute_single)
* [Traffic flow in a classic multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroute_multi)
* [Traffic flow in a multizone VPC cluster with a public cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routesroute_vpc)
host: <service_name> The name of your entrypoint microservice. For example, in the BookInfo app, productpage served as the entrypoint microservice that called the other app microservices.
port:
number: 443 If your microservice listens on a different port, replace 443 with the port.
Show more
6. Apply the virtual service rules in the namespace where your Istio-managed microservice is deployed.

kubectl apply -f my-virtual-service.yaml -n <namespace>
7. Get the EXTERNAL-IP address (classic clusters) or the hostname (VPC clusters) for the istio-ingressgateway public load balancer. If you [enabled an Istio load balancer in each zone of your cluster](https://cloud.ibm.com/docs/containers?topic=containers-istio-meshconfig-gateways), get the IP address or hostname of the load balancer service in each zone.

kubectl get svc -n istio-system

 Example output for classic clusters:
istio-ingressgateway LoadBalancer 172.21.XXX.XXX 169.1.1.1 80:31380/TCP,443:31390/TCP,31400:31400/TCP,5011:31323/TCP,8060:32483/TCP,853:32628/TCP,15030:31601/TCP,15031:31915/TCP 22m

 Example output for VPC clusters:
istio-ingressgateway LoadBalancer 172.21.XXX.XXX 1234abcd-us-south.lb.appdomain.cloud 80:31380/TCP,443:31390/TCP,31400:31400/TCP,5011:31323/TCP,8060:32483/TCP,853:32628/TCP,15030:31601/TCP,15031:31915/TCP 22m
8.
This cluster hosts also behave such as [IBM Cloud gateway appliance](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-about), which allows you to assign and route VLANs through the router or firewall that is hosted on the cluster.
3. You can add new vSphere clusters to increase the compute capacity for your workloads. You can add vSphere clusters with different host specifications, and define how to functionally position these clusters and what workloads are run on each cluster.
4. You can add NFS based IBM Cloud File Storage for Classic to your clusters. You can add one or more file shares and configure them individually by selecting the performance (IOPS) and size (GB) for each.
5. You can also use vSAN™ with your vSphere clusters. When using vSAN, due to the nature of dedicated local storage, you must select vSAN option when ordering the cluster.
6. The hosts in the specific data center or POD are attached to VLANs and subnets that are local to that IBM Cloud data center or POD. These VLANs and subnets cannot be extended or moved to other IBM Cloud data centers. However, these subnets can communicate with subnets that are provisioned to another IBM Cloud center over IBM Cloud private network.







 Extending a single-site vCenter Server deployment to another data center 

Single-site deployment can be expanded to another IBM Cloud data center by provisioning new clusters on a different IBM Cloud data center location.

The following diagram shows an example of a customer deployment by using this deployment topology.

Zoom

![Extended single-site deployment topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-s-s-2.svg)

Figure 2. Extended single-site deployment topology



1.
* After it is no longer listed in the available clusters list when you run the ibmcloud oc cluster ls command, you can reuse the name of a removed cluster.
* Classic clusters only: If you kept the subnets, you can [reuse them in a new cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-subnetssubnets_custom) or manually delete them later from your IBM Cloud infrastructure portfolio.
* VPC clusters only: If you have infrastructure resources that you no longer want to use, such as the VPC or subnets, remove these resources in the VPC portal.
* If you kept the persistent storage, you can delete your storage later through the IBM Cloud console for the corresponding storage service.
* **Satellite clusters: If you have hosts attached to your location that you no longer want to use, remove them. For more information see [Removing hosts and locations](https://cloud.ibm.com/docs/satellite?topic=satellite-host-remove).
* OpenShift Data Foundation: Supported through the [cluster add-on](https://cloud.ibm.com/docs/openshift?topic=openshift-ocs-storage-prep) for Classic and VPC clusters or through the Satellite [template](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov) for Satellite clusters.
* OVS and OVN SDN
* Performance Add-on Operator
* PTP Operator
* Quay Operator
* Red Hat OpenStack Platform Kuryr Integration
* Red Hat Integration Operator
* Service Registry Operator
* Smart Gateway Operator
* SR-IOV Network Operator: Supported in Satellite clusters only.
* Telemeter and Insights Connected Experience
* Windows Machine Config: Worker nodes with Windows operating systems are not supported.
: Added steps for bringing your own custom domain for [NLBs](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostnameloadbalancer_hostname_dns) in classic clusters and [VPC load balancers](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaasvpc_lb_dns) in VPC clusters.

Gateway appliance firewalls
: Updated the [required IP addresses and ports](https://cloud.ibm.com/docs/containers?topic=containers-firewallvyatta_firewall) that you must open in a public gateway device firewall.

Ingress ALB subdomain format
: [Changes are made to the Ingress subdomain](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-aboutmanaged-ingress-subdomain). New clusters are assigned an Ingress subdomain in the format cluster_name.globally_unique_account_HASH-0000.region.containers.appdomain.cloud and an Ingress secret in the format cluster_name.globally_unique_account_HASH-0000. Any existing clusters that use the cluster_name.region.containers.mybluemix.net subdomain are assigned a CNAME record that maps to a cluster_name.region_or_zone.containers.appdomain.cloud subdomain.





 21 November 2019 

Ingress ALB change log
: Updated the [ALB nginx-ingress image to 597 and the ingress-auth image to build 353](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog).

Version change log
: Master patch updates are available.