vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Provision Red Hat OpenShift clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-getting-started) Yes 
 [Create clusters in a Virtual Private Cloud (VPC)](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorial) Yes 
 [Ability to create cluster in every IBM Cloud Kubernetes Service region](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zones) Yes 
 [Multizone clusters to increase app high availability](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmz-clusters) Yes 
 Replicated masters for higher availability Yes 
 [Scalable number of worker nodes to increase capacity](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-classic-vpc) Yes 
 [Persistent NFS file-based storage with volumes](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_storage) Yes 
 [Public or private network app access by a network load balancer (NLB) service to a stable IP address](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer) Yes 
 [Public network app access by an Ingress service to a stable IP address and customizable URL](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-aboutmanaged-ingress-albs) Yes 
 [Portable public IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-subnetsreview_ip) Yes 
 [Logging and monitoring](https://cloud.ibm.com/docs/containers?topic=containers-healthlogging) Yes 
 [Option to provision your worker nodes on physical (bare metal) servers](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesplanning_worker_nodes) Yes 







 Comparison between Red Hat OpenShift and community Kubernetes clusters
Refresh your cluster by running ibmcloud ks cluster master refresh --cluster CLUSTERID for the changes to take effect.
6. Run the following command to verify that the accessTokenMaxAgeSeconds has been updated for your OAuth clients.

oc get oauthclients -o json | jq -j '.items[]|"Name:t", .metadata.name, "t", "value:t", .accessTokenMaxAgeSeconds, "n"'







 Disconnected usage by component 

The following tables explain the behavior and limitations of different components when your location is running disconnected.



 Cluster management disconnected usage 



Disconnected cluster management

 Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Cluster create Create clusters from the CLI and console. You cannot create clusters. N/A 
 Cluster update Update clusters from the CLI and console. You cannot update clusters. N/A 
 Cluster remove Remove clusters from the CLI and console. You cannot remove clusters. N/A 
 Viewing status View cluster status from the CLI and console. You cannot view cluster status. N/A 
 Removing/adding nodes Remove or add nodes from the CLI and console. You cannot remove or add nodes. N/A 
 Autoscaling clusters Autoscaling is managed by the Cluster Autoscaler Add-on. You cannot autoscale clusters. N/A 







 Apps disconnected usage 



Disconnected app management

 Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Deployment You can deploy apps by using your preferred methods, such as kubectl command line, the OpenShift Console, CI/CD pipelines, and Sat Config. You can still deploy apps while disconnected by using the Kubernetes API. Equal to the accessTokenMaxAgeSeconds from last authentication 
 Removal You can remove apps by using your preferred methods, such as kubectl command line, the OpenShift Console, CI/CD pipelines, and Sat Config. You can still remove apps while disconnected by using the Kubernetes API. Equal to the accessTokenMaxAgeSeconds from last authentication
Calico configuration N/A N/A Calico calico-* pods in the kube-system namespace now set CPU and memory resource requests for all containers. 
 Cluster DNS provider N/A N/A Kubernetes DNS (KubeDNS) remains the default cluster DNS provider.. 
 Cluster metrics provider N/A N/A Kubernetes Metrics Server replaces Kubernetes Heapster (deprecated since Kubernetes version 1.8) as the cluster metrics provider. 
 containerd 1.1.4 1.2.0 See the [containerd release notes]([https://github.com/containerd/containerd/releases/tag/v1.2.0](https://github.com/containerd/containerd/releases/tag/v1.2.0)]{: external}. 
 CoreDNS N/A 1.2.2 See the [CoreDNS release notes]([https://github.com/coredns/coredns/releases/tag/v1.2.2](https://github.com/coredns/coredns/releases/tag/v1.2.2)]{: external}. 
 Kubernetes v1.11.3 v1.12.2 See the [Kubernetes release notes]([https://github.com/kubernetes/kubernetes/releases/tag/v1.12.2](https://github.com/kubernetes/kubernetes/releases/tag/v1.12.2)]{: external}. 
 Kubernetes configuration N/A N/A Added three new IBM pod security policies and their associated cluster roles. For more information, see [Understanding default resources for IBM cluster management](https://cloud.ibm.com/docs/containers?topic=containers-pspibm_psp).
In this document, the source cluster is named A and the target cluster is named B. These cluster aliases are configurable when mirroring is enabled, so for example, they could be "us-south" and "us-east".

A topic called mytopic from the source cluster (A) appears on the target cluster (B) as mytopic.A indicating it originates from A. This type of topic is called a remote topic because it originates from the remote cluster. In contrast, any topics that are directly created on a cluster by users are called local topics.

To select which topics are mirrored, a regular expression pattern can be configured by using [Mirroring User Controls](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-mirroringuser_controls).

To allow consumer groups to switch between clusters, special topics are used to mirror consumer group offsets. These topics are named <ALIAS>.checkpoints.internal, where <ALIAS> is the alias of the remote cluster. For example, us-east.checkpoints.internal. Consumers need to access these topics to seamlessly switch between clusters.

Finally, because of the naming of remote topics, avoid using cluster aliases as part of the Kafka resource names.





 Capacity planning 

Both the network usage and geographical location of the source and target service instances must be considered when you plan capacity.



 Network bandwidth 

The network bandwidth needed to mirror the selected topics must be considered in the bandwidth allowance of both the source and target service instances. For example, if 10 MB/s of message traffic is produced by applications in the source service instance to the mirrored topics, an extra 10 MB/s of outgoing bandwidth is required to mirror these messages into the target instance. This must be allowed for alongside any existing outgoing bandwidth that is already used by consuming applications. The monitoring dashboards can be used to determine the network usage in a service instance. For more information, see [Monitoring Event Streams metrics](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-metrics).





 Geographical location
* [Private traffic to cluster apps](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsexternal-workers-private)
* [Public traffic to cluster apps](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsexternal-workers-public)



* [Scenario: Running internet-facing app workloads in a classic cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsinternet-facing)



* [Worker-to-worker communication in classic clusters with internet-facing workloads](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsinternet-facing-worker)
* [Worker-to-master and user-to-master communication in classic clusters with internet-facing workloads](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsinternet-facing-master)
* [Worker communication to other services or networks with internet-facing workloads](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsinternet-facing-services)
* [External communication to apps that run on worker nodes with internet-facing workloads](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsinternet-facing-external)



* [Scenario: Allow limited public connectivity with a gateway appliance](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsvyatta-gateway)



* [Worker-to-worker communication, worker-to-master and user-to-master communication with a gateway appliance](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicslimited-public-gw-worker)
* [Creating selector expressions](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-creating-selector-expressions)
* [Selector syntax](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-selector-syntax)
* [IBM Cloudant Operators](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-operators)
* [More about text indexes](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-note-about-text-indexes)
* [Movies demo database example](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-example-movies-demo-database)
* [Creating Views (MapReduce)](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-creating-views-mapreduce)
* [Using Views](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-using-views)
* [Using IBM Cloudant Search](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-cloudant-search)
* [Search analyzers](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-search-analyzers)
* [Pagination and bookmarks](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-pagination-and-bookmarks)
* [IBM Cloudant Geospatial notice](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-cloudant-nosql-db-geospatial)



* Replicating databases



* [What is replication?](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-replication-guide)
* [IBM Cloudant Replication](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-replication-api)
Cluster networking <br><br> * Set up cluster management components, such as public or private cloud service endpoints, VLANs, and load balancers.<br> * Fulfill requests for more infrastructure, such as attaching worker nodes to existing VLANs or subnets upon resizing a worker pool.<br> * Create clusters with subnet IP addresses reserved to use to expose apps externally.<br> * Set up a Konnectivity connection between the master and worker nodes when the cluster is created.<br> * Provide the ability to set up a VPN connection with on-premises resources such as through the strongSwan IPSec VPN service or the IBM Cloud VPC VPN.<br> * Provide the ability to isolate network traffic with edge nodes.<br><br><br> <br><br> * Use the provided API, CLI, or console tools to adjust [cluster networking configuration](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster) to meet the needs of your workload, such as configuring service endpoints, adding VLANs to provide IP addresses for more worker nodes, setting up a VPN connection, or edge node worker pools.<br><br><br> 
 App networking <br><br> * Set up a public application load balancer (ALB) that is multizone, if applicable. Provide the ability to set up private ALBs and public or private network load balancers (NLBs).<br> * Support native Kubernetes public and private load balancers and Ingress routes for exposing services externally.<br> * Install Calico as the container networking interface, and set up default Calico network policies to control basic cluster traffic.<br><br><br> <br><br> * Set up any additional app networking capabilities that are needed, such as private ALBs, public or private NLBs, or additional Calico network policies.<br><br><br> 
 Observability <br><br> * Provide Log Analysis and Monitoring as managed add-ons to enable observability of your cluster and container environments.
Command options 

--resource RESOURCE
: Required. The ID of the Kubernetes resource. To list Kubernetes resources, run ibmcloud sat resource ls.

--limit LIMIT
: Optional. The maximum number of history entries to return.

--output json
: Optional. Prints the command output in JSON format.

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





 Example 

ibmcloud sat resource history get --resource 123456 --limit 200







 ibmcloud sat resource ls 

Search for and list Kubernetes resources that are managed by a Satellite configuration.

ibmcloud sat resource ls [--cluster CLUSTER] [--limit NUMBER] [--search STRING] [-q]



 Minimum required permissions 

IBM Cloud IAM Viewer 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 

--cluster CLUSTER
: Optional. The name or ID of the registered cluster that the Kubernetes resource runs in. To list registered clusters, run ibmcloud sat cluster ls.

--limit NUMBER
: Optional. Limit the number of Kubernetes resources that are returned.

--search STRING
: Optional. A string to filter results by, such as the name of a pod, namespace, or other string.

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





 Example 

ibmcloud sat resource ls









 Service commands 

Use these commands to view the Satellite-enabled IBM Cloud service clusters that are deployed to your Satellite location.



 ibmcloud sat service ls 

List all Satellite-enabled IBM Cloud service clusters in your location to review details such as requested host resources.
Review the estimated price of the cluster. Click Pricing details to generate a PDF summary. To save or print your order summary, click the Print or Download icon on the upper right of the PDF window.
3. Click the link or links of the terms that apply to your order, and confirm that you agree with these terms before you add the cluster.
4. Click Create.







 Results after you add clusters to vCenter Server with Hybridity Bundle instances 



1. The deployment of the cluster starts automatically and the status of the cluster is changed to Initializing. You can check the status of the deployment by viewing the deployment history on instance details page.
2. When the cluster is ready to use, its status changes to Available. The newly added cluster is enabled with vSphere High Availability (HA) and vSphere Distributed Resource Scheduler (DRS).



You can't change the cluster name. Changing the cluster name might cause the add or delete ESXi servers operations in the cluster to fail.







 Procedure to view clusters in vCenter Server with Hybridity Bundle instances 



1. From the IBM Cloud for VMware Solutions console, click Resources > vCenter Server from the left navigation pane.
2. In the vCenter Server table, click the instance to view the clusters in it.
3. Click the Infrastructure tab. In the CLUSTERS table, view the summary about the clusters.



* Name - The name of the cluster.
* ESXi servers - The number of ESXi servers in the cluster.
* CPU - The CPU specification of the ESXi servers in the cluster.
* Customized vSAN disks - The number of vSAN disks in the cluster, including the disk type and capacity.
* Memory - The total memory size of the ESXi servers in the cluster.
* Data center location - The IBM Cloud data center where the cluster is hosted.
* Pod - The pod where the cluster is deployed.
* Status - The status of the cluster. The status can have one of the following values:



* Initializing - The cluster is being created and configured.
* Modifying - The cluster is being modified.
* Available - The cluster is ready to use.
Encryption enabled cluster-encryption Config Set to true if you want to enable cluster-wide encryption. true false 
 IAM API key iam-api-key Secret Your IAM API key. true N/A 
 Perform Cleanup perform-cleanup Config Set to true if you want to perform complete cleanup of ODF on assignment deletion. true false 
 KMS encryption kms-encryption Config Set to true if you want to enable storage class encryption. true false 
 KMS instance name kms-instance-name Config Your KMS instance name. The instance name must only include alphanumeric characters, -, _ or . and start and end with an alphanumeric character. false N/A 
 KMS instance id kms-instance-id Config Your KMS instance id. false N/A 
 KMS instance Base URL kms-base-url Config Your KMS instance public URL to connect to the instance. false N/A 
 KMS instance API key token URL kms-token-url Config API key token URL to generate token for KMS instance. false N/A 
 KMS root key kms-root-key Secret KMS root key of your instance. false N/A 
 KMS IAM API key kms-api-key Secret IAM API key to access the KMS instance. The API key that you provide must have at least Viewer access to the KMS instance. false N/A 
 Ignore Noobaa ignore-noobaa Config Set to true if you do not want to deploy MultiCloud Object Gateway (Noobaa) true false 







 4.12 parameter reference 



Table 4. 4.12 parameter reference

 Display name CLI option Type Description Required? Default value 

 OSD pod volume size osd-size Config The OSD storage size in Gi. The default value is 100Gi. true 100Gi 
 OSD pod storage class osd-storage-class Config The storage class to use when dynamically provisioning volumes for the OSD pods. true N/A
To check if your cluster supports these public cluster API type CBR rules, run the ibmcloud ks cluster get -c <CLUSTER-ID> command. If either of the Service Endpoint URLs starts with the https://cXXX (where XXX is any three digit number), then the cluster does support public CBR rules. If the Service Endpoint URLs starts with https://cX (where the number after the c is a single digit), then the cluster is not able to enforce public CBR rules for the cluster's APIserver. To use public CBR rules, you must create a new cluster.
Preparing to create clusters 

Create a cluster in IBM Cloud® Kubernetes Service.

After [getting started](https://cloud.ibm.com/docs/containers?topic=containers-getting-started), you might want to create a cluster that is customized to your use case and different public and private cloud environments. Consider the following steps to create the correct cluster each time.



1. [Prepare your account to create clusters](https://cloud.ibm.com/docs/containers?topic=containers-clusterscluster_prepare). This step includes creating a billable account, setting up an API key with infrastructure permissions, making sure that you have Administrator access in IBM Cloud IAM, planning resource groups, and setting up account networking.
2. [Decide on your cluster setup](https://cloud.ibm.com/docs/containers?topic=containers-clustersprepare_cluster_level). This step includes planning cluster network and HA setup, estimating costs, and if applicable, allowing network traffic through a firewall.
3. Create your [VPC Gen2](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2) or [classic](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-classic) cluster by following the steps in the IBM Cloud console or CLI.





 Preparing to create clusters at the account level 

Prepare your IBM Cloud account for IBM Cloud Kubernetes Service. After the account administrator makes these preparations, you might not need to change them each time that you create a cluster. However, each time that you create a cluster, you still want to verify that the current account-level state is what you need it to be.



1. [Create or upgrade your account to a billable account (IBM Cloud Pay-As-You-Go or Subscription)](https://cloud.ibm.com/registration).
2.
For multizone clusters, you can choose any of the existing Worker Zones of your cluster, or add one of the [multizone locations](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) for the region that your cluster is in. You can list available zones by running ibmcloud ks zone ls.

ibmcloud ks cluster get --cluster <cluster_name_or_ID>

Example output

...
Worker Zones: dal10, dal12, dal13
2. For each zone, list available private and public VLANs. Note the private and the public VLAN that you want to use. If you don't have a private or a public VLAN, the VLAN is automatically created for you when you add a zone to your worker pool.

ibmcloud ks vlan ls --zone <zone>
3. For each zone, review the [available flavors for worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesplanning_worker_nodes).

ibmcloud ks flavors --zone <zone>
4. Create a worker pool. For more options, see the [CLI documentation](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_pool_create).



* The minimum number of worker nodes per zone is 1. For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/containers?topic=containers-faqssmallest_cluster).
* Include the --label option to automatically label worker nodes that are in the pool with the label key=value.
* If you provision a bare metal or dedicated VM worker pool, specify --hardware dedicated.
* The new worker nodes run the same major.minor version as the cluster master, but the latest worker node patch of that major.minor version.
RESOURCE_GROUP is the name of the resource group where the cluster is available, for example, default.

REGION is the region where the cluster is available, for example, us-south.

Set the cluster where you want to configure logging as the context for this session.

ibmcloud ks cluster config --cluster <cluster_name_or_ID>
2. Detach the logging agent by using the ob CLI. Run the following command:

ibmcloud ob logging config delete --cluster <cluster_name_or_ID> --instance <LogDNA_instance_name_or_ID> [--force]

Where



* <cluster_name_or_ID> is the name or the ID of the cluster.
* <LogDNA_instance_name_or_ID> is the name or the ID of the logging instance where you want to forward the cluster logs for analysis.
* [--force] is used to force the command to run with no user prompts.











 Detaching a logging agent from an Openshift Kubernetes cluster 

To stop your OpenShift cluster from sending logs to your IBM Log Analysis instance, you must remove the logging agent from your cluster.



 Detaching a logging agent by using kubectl commands 

Complete the following steps from the command line:



1. Open a terminal to log in to IBM Cloud.

ibmcloud login -a cloud.ibm.com

Select the account where you provisioned the IBM Log Analysis instance.
2. Set the cluster where you want to configure logging as the context for this session.

ibmcloud cs cluster config --cluster <cluster_name_or_ID>
3. Log in to the cluster. Choose a method to login to an OpenShift cluster. [Learn more about the methods to login](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_automation).
4. Delete the logging agent serviceaccount.

oc delete serviceaccount logdna-agent -n ibm-observe