vania-janet/multiturn-rag-retrieval-data huggingface dataset:
-q
: Optional: Do not show the message of the day or update reminders.

Example:

ibmcloud oc versions





 api command 

Virtual Private Cloud

Classic infrastructure

Target the API endpoint for IBM Cloud Kubernetes Service. If you don't specify an endpoint, you can view information about the current endpoint that is targeted.

Region-specific endpoints are deprecated. Use the [global endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zonesendpoint) instead.

If you need to list and work with resources from one region only, you can use the ibmcloud oc api command to target a regional endpoint instead of the global endpoint.



* Dallas (US South, us-south): https://us-south.containers.cloud.ibm.com
* Frankfurt (EU Central, eu-de): https://eu-de.containers.cloud.ibm.com
* London (UK South, eu-gb): https://eu-gb.containers.cloud.ibm.com
* Osaka (jp-osa): https://jp-osa.containers.cloud.ibm.com
* São Paulo (br-sao): https://br-sao.containers.cloud.ibm.com
* Sydney (AP South, au-syd): https://au-syd.containers.cloud.ibm.com
* Tokyo (AP North, jp-tok): https://jp-tok.containers.cloud.ibm.com
* Toronto (ca-tor): https://ca-tor.containers.cloud.ibm.com
* Washington, D.C. (US East, us-east): https://us-east.containers.cloud.ibm.com



To use the global functionality, you can use the ibmcloud oc api command again to target the global endpoint: https://containers.cloud.ibm.com
Your worker nodes can automatically, securely communicate with other IBM Cloud services that support private cloud service endpoints, such as IBM Cloud® Container Registry, over your IBM Cloud infrastructure private network. For example, dedicated hardware environments for all standard plan instances of IBM Cloudant support private cloud service endpoints. If an IBM Cloud service does not support private cloud service endpoints, your cluster can't access that service.





 External communication to apps that run on worker nodes for private clusters 

To provide private access to an app in your cluster, you can create a private network load balancer (NLB) or Ingress application load balancer (ALB). These Kubernetes network services expose your app to the private network only so that any on-premises system with a connection to the subnet that the NLB IP is on can access the app.

Ready to get started with a cluster for this scenario? After you plan your [high availability](https://cloud.ibm.com/docs/containers?topic=containers-ha_clusters) and [worker node](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes) setups, see [Creating clusters](https://cloud.ibm.com/docs/containers?topic=containers-clusters).
To view or generate an infrastructure API key, see [Managing classic infrastructure API keys](https://cloud.ibm.com/docs/account?topic=account-classic_keys).

--region REGION
: Specify a region in IBM Cloud Kubernetes Service: jp-osa, jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

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



 Example credential set classic command 

ibmcloud ks credential set classic --infrastructure-api-key <api_key> --infrastructure-username dbmanager --region us-south







 ibmcloud ks credential unset 

Classic infrastructure

Remove the credentials for a resource group and region to remove access to the IBM Cloud infrastructure portfolio through your IBM Cloud account.

After you remove the credentials, the [IBM Cloud IAM API key](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_api_key_info) is used to order resources in IBM Cloud infrastructure.

ibmcloud ks credential unset --region REGION [-q]

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

Command options:

--region REGION
: Specify a region in IBM Cloud Kubernetes Service: jp-osa, jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

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



 Example credential unset command 

ibmcloud ks credential unset --region us-south









 infra-permissions commands 

Check classic IBM Cloud infrastructure permissions that are used in IBM Cloud Kubernetes Service.

The ibmcloud ks infra-permissions commands check only classic IBM Cloud infrastructure, not VPC permissions.



 ibmcloud ks infra-permissions get 

Classic infrastructure
: See [Overview of potential points of failure in IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-hafault_domains).

Where is the service located?
: See [Locations](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zonesregions-and-zones).

What am I responsible to configure disaster recovery options for?
: See [Your responsibilities with using IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-responsibilities_iks).





 Overview of potential points of failure in IBM Cloud Kubernetes Service 

The IBM Cloud Kubernetes Service architecture and infrastructure is designed to ensure reliability, low processing latency, and a maximum uptime of the service. However, failures can happen. Depending on the service that you host in IBM Cloud, you might not be able to tolerate failures, even if failures last for only a few minutes.

IBM Cloud Kubernetes Service provides several approaches to add more availability to your cluster by adding redundancy and anti-affinity. Review the following image to learn about potential points of failure and how to eliminate them.

Zoom

![Overview of fault domains in a high availability cluster within an IBM Cloud region.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/ha-failure-ov.svg)

Figure 1. Overview of fault domains in a high availability cluster

Potential failure point 1: Container or pod availability
: Containers and pods are, by design, short-lived and can fail unexpectedly. For example, a container or pod might crash if an error occurs in your app. To make your app highly available, you must ensure that you have enough instances of your app to handle the workload plus additional instances in the case of a failure. Ideally, these instances are distributed across multiple worker nodes to protect your app from a worker node failure.
Locations and versions Clusters are managed from one of the [supported IBM Cloud locations](https://cloud.ibm.com/docs/satellite?topic=satellite-sat-regions). However, you can deploy worker nodes to your own location, an IBM Cloud data center, or another cloud provider. For more information see [Understanding locations and hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-location-host). 
 Service interface Satellite are supported by the global [API](https://containers.cloud.ibm.com/global/swagger-global-api/) [IBM Cloud Kubernetes Service, the Red Hat OpenShift on IBM Cloud [CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install) and the Satellite [CLI](https://cloud.ibm.com/docs/satellite?topic=satellite-cli-install). You can also manage your clusters from the [console](https://cloud.ibm.com/satellite/clusters). 
 Service compliance For clusters, see [What standards does the service comply to?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqsstandards). For Satellite, see [Security and compliance](https://cloud.ibm.com/docs/satellite?topic=satellite-compliance). 
 Service limitations See [Limitations, default settings, and usage requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-requirements). 







 Classic 

Classic infrastructure



Table 3. Classic infrastructure overview.

 Component Description
* With the release of the [IBM Cloud Kubernetes Service version 2 API](https://cloud.ibm.com/docs/containers?topic=containers-cs_api_installapi_about), the IBM Cloud CLI kubernetes-service plug-in supports both classic and VPC infrastructure providers. Some ibmcloud ks commands support only one type of infrastructure, whereas other commands include additional names or options.
* Adds the --pod-subnet and --service-subnet options to the ibmcloud ks cluster create classic commands for standard clusters that run Kubernetes 1.15 or later. If you plan to connect your cluster to on-premises networks, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods and subnets.
* Enhances the ibmcloud ks nlb-dns create and ibmcloud ks nlb-dns add commands so that you can add more than one IP address at a time. For example, to create a DNS entry for multiple network load balancer IP addresses, use multiple options such as ibmcloud ks nlb-dns create --cluster mycluster --ip IP1 --ip IP2.







 Version 0.3.103 

Version 0.3.103 of the CLI was released on 12 August 2019.



* General refactoring and improvements.







 Version 0.3.99 

Version 0.3.99 of the CLI was released on 5 August 2019.



* Improves error handling for ibmcloud ks cluster config.
* Updates the help text in various languages.







 Version 0.3.95 

Version 0.3.95 of the CLI was released on 30 July 2019.



* Adds the [ibmcloud ks cluster subnet detach](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_subnet_detach) command to detach a public or private portable subnet in a classic IBM Cloud infrastructure account from a cluster.
* Renames the ibmcloud ks machine-types command to ibmcloud ks flavors. You can still use the machine-types alias.
This option duplicates your Kubernetes deployment across zones and regions, enabling high availability (HA) of your components and disaster recovery (DR).
* Connect to other Fabric networks: Join IBM Blockchain Platform peers to any network running Hyperledger Fabric components. Similarly, you can invite Fabric peers to join channels hosted on an ordering service deployed on the IBM Blockchain Platform. Note that you will need to use Hyperledger Fabric APIs or the CLI.



This offering is intended for experienced Fabric users who want to build and manage their own networks.

Have questions and want to speak to an IBM Blockchain Platform expert? [Schedule a consult](https://www.ibm.com/cloud/blockchain-platform/developer?schedulerform) now to learn more about how blockchain can transform your business.





 Supported IBM Cloud configuration 

Reminder: If your IBM Blockchain Platform instance is linked to an IBM Cloud Kubernetes Service cluster that is no longer supported, you must immediately upgrade it to a supported version listed in the table below. See [Kubernetes version information](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions) for Kubernetes version details. For the actual steps that are required, see [Updating clusters, worker nodes, and cluster components](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate).



Table 1. Supported IBM Cloud configuration



 Kubernetes <br><br> * v1.24 - v1.26<br><br><br> 
 Orchestration Service <br><br> * Kubernetes<br> * OpenShift Container Platform on IBM Cloud 4.9, 4.10, 4.11, 4.12<br><br><br> 
 Infrastructure <br><br> * Classic<br><br><br>
To view or generate an infrastructure API key, see [Managing classic infrastructure API keys](https://cloud.ibm.com/docs/account?topic=account-classic_keys).

--region REGION
: Specify a region in IBM Cloud Kubernetes Service: jp-osa, jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

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



 Example credential set classic command 

ibmcloud ks credential set classic --infrastructure-api-key <api_key> --infrastructure-username dbmanager --region us-south







 ibmcloud ks credential unset 

Classic infrastructure

Remove the credentials for a resource group and region to remove access to the IBM Cloud infrastructure portfolio through your IBM Cloud account.

After you remove the credentials, the [IBM Cloud IAM API key](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clics_api_key_info) is used to order resources in IBM Cloud infrastructure.

ibmcloud ks credential unset --region REGION [-q]

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

Command options:

--region REGION
: Specify a region in IBM Cloud Kubernetes Service: jp-osa, jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

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



 Example credential unset command 

ibmcloud ks credential unset --region us-south









 infra-permissions commands 

Check classic IBM Cloud infrastructure permissions that are used in IBM Cloud Kubernetes Service.

The ibmcloud ks infra-permissions commands check only classic IBM Cloud infrastructure, not VPC permissions.



 ibmcloud ks infra-permissions get 

Classic infrastructure
Type of storage Required version 

 File storage Kubernetes version 1.13.4_1512, 1.12.6_1544, 1.11.8_1550, 1.10.13_1551, or later 
 Block storage IBM Cloud Block Storage plug-in version 1.3.0 or later 
 Object storage IBM Cloud Object Storage plug-in version 1.0.3 or later, IBM Cloud Object Storage service set up with HMAC authentication 



If you must use a Kubernetes version or IBM Cloud storage plug-in version that does not support network communication over the private network, or if you want to use IBM Cloud Object Storage without HMAC authentication, allow egress access through your allowlist to IBM Cloud infrastructure and IBM Cloud Identity and Access Management:



* Allow all egress network traffic on TCP port 443.
* Allow access to the IBM Cloud infrastructure IP range for the zone that your cluster is in for both the [Front-end (public) network](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-ibm-cloud-ip-ranges) and [Back-end (private) Network](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-ibm-cloud-ip-ranges). To find the zone of your cluster, run ibmcloud ks cluster ls.







 Optional: Set up allowlist rules for IBM Log Analysis and IBM Cloud Monitoring services 

To send logging and metric data, set up allowlist rules for your IBM Log Analysis and IBM Cloud Monitoring services.



* [Log Analysis private endpoints](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-endpointsendpoints_api_private)
* [Monitoring private endpoints](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints_monitoring)









 Opening ports in a public or private allowlist for inbound traffic 

You can allow incoming access to NodePort, load balancer, and Ingress services.

NodePort service
: Open the port that you configured when you deployed the service to the public or private IP addresses for all the worker nodes to allow traffic to.
The Kubernetes cluster can run in the IBM Cloud, outside the IBM Cloud, or on-prem.



 Before you begin 

Complete the following steps:



1. Check that you have a Kubernetes cluster running and the kubectl CLI installed in your local environment.
2. Check that you have permissions to manage the cluster. You need administrator permissions to add secrets to the cluster and manage the Prometheus deployment.
3. Check that Prometheus in running in your cluster.

For example, you can run kubectl get pods --all-namespaces. Look for Prometheus and the namespace where the Prometheus server is running.
4. Check that you have access to a Monitoring instance.
5. If you use a firewall, check the firewall rules are opened for accessing the Monitoring ingestion endpoint port TCP 443.







 Step 1. Create a Kubernetes Secret 

To avoid including sensitive information directly in the Prometheus ConfigMap, you must create a Kubernetes secret to store your instance's Monitor API Token that will be referenced in the Remote Write configuration.. For more information on how to get the token, see [Monitor API token](https://cloud.ibm.com/docs/monitoring?topic=monitoring-api_monitoring_token).

Run the following command to create the secret:

kubectl create secret generic <SECRET_NAME> --from-literal=monitor-api-token="<MONITOR_API_TOKEN>" -n <PROMETHEUS_NAMESPACE>

Where



* <SECRET_NAME> is the name of the secret.
* <MONITOR_API_TOKEN> contains the [Monitor API token](https://cloud.ibm.com/docs/monitoring?topic=monitoring-api_monitoring_token).
* <PROMETHEUS_NAMESPACE> is the namespace where you have Prometheus server running in your cluster.



For example, run the following command to create the secret monitor-api-token in the namespace prometheus.
Financial services use cases for IBM Cloud 

These use cases highlight how workloads on IBM Cloud® Kubernetes Service can take advantage of high availability, high-performance compute, easy spin-up of clusters for faster development, and AI from IBM Watson®.



 Mortgage company trims costs and accelerates regulatory compliance 

A Risk Management VP for a residential mortgage company processes 70 million records a day, but the on-premises system was slow and also inaccurate. IT expenses soared because hardware quickly went out of date and wasn't utilized fully. While they waited for hardware provisioning, their regulatory compliance slowed.



 Context 

To improve risk analysis, the company looked to IBM Cloud Kubernetes Service and IBM Cloud Analytic services to reduce costs, increase worldwide availability, and ultimately accelerate regulatory compliance. With IBM Cloud Kubernetes Service in multiple regions, their analysis apps can be containerized and deployed across the globe, improving availability and addressing local regulations. Those deployments are accelerated with familiar open source tools, already part of IBM Cloud Kubernetes Service.

They started by containerizing the analysis apps and putting them in the cloud. In a flash, their hardware headaches went away. They were able to easily design Kubernetes clusters to fit their high-performance CPU, RAM, storage, and security needs. And when their analysis apps change, they can add or shrink compute without huge hardware investments. With the IBM Cloud Kubernetes Service horizontal scaling, their apps scale with the growing number of records, resulting in faster regulatory reports. IBM Cloud Kubernetes Service provides elastic compute resources around the world that are secure and capable.

Now those apps receive high-volume data from a data warehouse on IBM Cloudant. Cloud-based storage in IBM Cloudant ensures higher availability than when it was locked in an on-premises system. Since availability is essential, the apps are deployed across global data centers: for DR and for latency too.

They also accelerated their risk analysis and compliance. Their predictive and risk analytics functions, such as Monte Carlo calculations, are now constantly updated through iterative agile deployments. Container orchestration is handled by a managed Kubernetes so that operations costs are reduced too. Ultimately risk analysis for mortgages is more responsive to the fast-paced changes in the market.
For more information about the kinds of apps that can run in IBM Cloud Kubernetes Service, see [Planning app deployments](https://cloud.ibm.com/docs/containers?topic=containers-plan_deployapp_types).

If you already have an app, you can [migrate it to IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-plan_deploymigrate_containerize). If you want to develop a new app, check out the [guidelines for developing stateless, cloud-native apps](https://cloud.ibm.com/docs/containers?topic=containers-plan_deploy12factor).





 What about serverless apps? 

You can run serverless apps and jobs through the [IBM Cloud Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started) service. Code Engine can also build your images for you. Code Engine is designed so that you don't need to interact with the underlying technology it is built upon. However, if you have existing tooling that is based upon Kubernetes or Knative, you can still use it with Code Engine. For more information, see [Using Kubernetes to interact with your application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-kubernetes).





 What skills should I have before I move my apps to a cluster? 

Kubernetes is designed to provide capabilities to two main personas, the cluster admin and the app developer. Each persona uses different technical skills to successfully run and deploy apps to a cluster.

What are a cluster admin's main tasks and technical knowledge?
: As a cluster admin, you are responsible to set up, operate, secure, and manage the IBM Cloud infrastructure of your cluster. Typical tasks include:



* Size the cluster to provide enough capacity for your workloads.
* Design a cluster to meet the high availability, disaster recovery, and compliance standards of your company.
1.2.23 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.24 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.25 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.33 IBM Cloud Kubernetes Service can optionally [enable a Kubernetes Key Management Service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms). 
 1.2.34 IBM Cloud Kubernetes Service can optionally [enable a Kubernetes Key Management Service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms). 
 1.3.6 IBM Cloud Kubernetes Service rotates certificates on every worker node reload or update. 
 3.2.1 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 3.2.2 IBM Cloud Kubernetes Service can optionally [enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 4.2.6 IBM Cloud Kubernetes Service does not protect kernel defaults to allow customers to [tune kernel parameters](https://cloud.ibm.com/docs/containers?topic=containers-kernel).
1.2.23 IBM Cloud Kubernetes Service can optionally [Enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.24 IBM Cloud Kubernetes Service can optionally [Enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.25 IBM Cloud Kubernetes Service can optionally [Enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 1.2.33 IBM Cloud Kubernetes Service can optionally [Enable a Kubernetes Key Management Service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms). 
 1.2.34 IBM Cloud Kubernetes Service can optionally [Enable a Kubernetes Key Management Service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms). 
 1.3.6 IBM Cloud Kubernetes Service rotates certificates on every worker node reload or update. 
 3.2.1 IBM Cloud Kubernetes Service can optionally [Enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 3.2.2 IBM Cloud Kubernetes Service can optionally [Enable Kubernetes API server auditing](https://cloud.ibm.com/docs/containers?topic=containers-health-auditaudit-api-server). 
 4.2.6 IBM Cloud Kubernetes Service does not protect kernel defaults to allow customers to [Tune kernel parameters](https://cloud.ibm.com/docs/containers?topic=containers-kernel).