vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Setting up the API 

You can use the IBM Cloud® Kubernetes Service API to create and manage your community Kubernetes or Red Hat OpenShift clusters. To use the CLI, see [Setting up the CLI](https://cloud.ibm.com/docs/containers?topic=containers-cli-install).



 About the API 

The IBM Cloud Kubernetes Service API automates the provisioning and management of IBM Cloud infrastructure resources for your clusters so that your apps have the compute, networking, and storage resources that they need to serve your users.

The API supports the different infrastructure providers that are available for you to create clusters. For more information, see [Overview of Classic and VPC infrastructure providers](https://cloud.ibm.com/docs/containers?topic=containers-infrastructure_providers).

You can use the version two (v2) API to manage both classic and VPC clusters. The v2 API is designed to avoid breaking existing functionality when possible. However, make sure that you review the following differences between the v1 and v2 API.

API endpoint prefix
: v1 API: https://containers.cloud.ibm.com/global/v1
: v2 API: https://containers.cloud.ibm.com/global/v2

API reference docs
: v1 API: [https://containers.cloud.ibm.com/global/swagger-global-api/](https://containers.cloud.ibm.com/global/swagger-global-api//)
: v2 API: [https://containers.cloud.ibm.com/global/swagger-global-api/](https://containers.cloud.ibm.com/global/swagger-global-api//).

API architectural style
: v1 API: Representational state transfer (REST) that focuses on resources that you interact with through HTTP methods such as GET, POST, PUT, PATCH, and DELETE.
: v2 API: Remote procedure calls (RPC) that focus on actions through only GET and POST HTTP methods.

Supported container platforms
You can use the certs to automate tasks in a cluster without having to reauthenticate. The files are downloaded to <user_home_directory>/.bluemix/plugins/kubernetes-service/clusters/<cluster_name>-admin.

--endpoint ENDPOINT_TYPE
: Optional: Specify the type of endpoint to use to connect to the cluster. If you don't specify this option, the default service endpoint for your cluster is used.



* private: If the private cloud service endpoint is enabled for your cluster, set to private to use the private cloud service endpoint for your cluster context. Note you must be in your IBM Cloud private network or connected to the private network through a [VPC VPN connection](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-onprem-example), or for classic infrastructure, a [classic VPN connection](https://cloud.ibm.com/docs/iaas-vpn?topic=iaas-vpn-getting-started) or [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl).
* link: To connect to IBM Cloud Satellite clusters from within the IBM Cloud private network, set to link to use your Satellite location's Link endpoint for the cluster context. If you specify this option, you must also specify the --admin option. If you are not connected to the IBM Cloud private network, this option is not required because the cluster service URL is used. Before you can use the link endpoint type, make sure you set up the required Source[in your Location](https://cloud.ibm.com/docs/satellite?topic=satellite-link-endpoint-secure).
* vpe: If it is a VPC cluster, set to vpe to use the Virtual Private Endpoint gateway for your cluster context.
By default, IBM Cloud Kubernetes Service sets up many components such as the cluster master with replicas, anti-affinity, and other options to increase the high availability (HA) of the service. You can increase the redundancy and failure toleration of your cluster worker nodes, storage, networking, and workloads by configuring them in a highly available architecture. For an overview of the default setup and your options to increase HA, see [High availability for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-ha).

For the latest HA service level agreement terms, refer to the [IBM Cloud terms of service](https://cloud.ibm.com/docs/overview?topic=overview-slas). Generally, the SLA availability terms require that when you configure your infrastructure resources in an HA architecture, you must distribute them evenly across three different availability zones. For example, to receive full HA coverage under the SLA terms, you must [set up a multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmz-clusters) with a total of at least 6 worker nodes, two worker nodes per zone that are evenly spread across three zones.
* What compliance standards does the service meet?

IBM Cloud is built by following many data, finance, health, insurance, privacy, security, technology, and other international compliance standards. For more information, see [IBM Cloud compliance](https://cloud.ibm.com/docs/overview?topic=overview-compliance).

To view detailed system requirements, you can run a [software product compatibility report for IBM Cloud Kubernetes Service](https://www.ibm.com/software/reports/compatibility/clarity/softwareReqsForProduct.html). Note that compliance depends on the underlying [infrastructure provider](https://cloud.ibm.com/docs/containers?topic=containers-infrastructure_providers) for the cluster worker nodes, networking, and storage resources.

Classic infrastructure: IBM Cloud Kubernetes Service implements controls commensurate with the following security standards:
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). 
 4.2.8 IBM Cloud Kubernetes Service ensures that the hostname matches the name issued by the infrastructure. 
 4.2.11 IBM Cloud Kubernetes Service rotates certificates on every worker node reload or update. 
 4.2.12 IBM Cloud Kubernetes Service rotates certificates on every worker node reload or update. 
 5.1.2 IBM Cloud Kubernetes Service deploys some system components that could have their Kubernetes secret access further restricted. 
 5.1.3 IBM Cloud Kubernetes Service deploys some system components that could have their Kubernetes resource access further restricted. 
 5.1.5 IBM Cloud Kubernetes Service does not set [automountServiceAccountToken: false](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/use-the-default-service-account-to-access-the-api-server) for each default service account. 
 5.1.6 IBM Cloud Kubernetes Service deploys some system components that could set [automountServiceAccountToken: false](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/use-the-default-service-account-to-access-the-api-server). 
 5.2.1 IBM Cloud Kubernetes Service can optionally [configure pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psp). 
 5.2.2 IBM Cloud Kubernetes Service can optionally [configure pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psp).
* In IBM Cloud IAM, make sure that you have the Operator platform access role for Kubernetes Service for the cluster to create worker pools.
* [Create](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-classic) or have an existing a classic cluster in the same metro as the reservation that you want to use. If you want to use worker nodes only from a reservation, you can create a cluster with zero worker nodes, or remove existing, on demand worker pools from a cluster.



To use the reservation:



1. Log in to the [Kubernetes clusters console](https://cloud.ibm.com/kubernetes/clusters).
2. Select the cluster that you want to use.
3. From the cluster menu, select Worker pools.
4. Click Add+.
5. Fill out the worker pool details.



1. Enter the Worker pool name.
2. Select the Reservation that you want to use. Keep in mind that the reservation affects the flavor and number of worker nodes that you can provision in this worker pool.
3. Select the Worker zones and review the VLAN information.
4. For the Worker nodes, increase or decrease the number of worker nodes that you want to create per zone. You can review the percentage of your reservation that creating the worker pool uses. You can't create a worker pool with more worker nodes than you have in your reservation. To use worker nodes from another reservation, create a different worker pool.



6. In the Summary pane, notice that your estimated cost is zero, because your worker pool order uses the reservation. To complete the order, click Create.







 Reviewing reservation usage 

You can review your IBM Cloud Kubernetes Service reservation usage and billing details.

Before you begin, make sure that you have the following roles in IBM Cloud IAM.



* Viewer platform access role for Kubernetes Service to view reservation usage details.
* Viewer platform access role for Account Management > Billing service to view billing details.



Reservation usage:



1.
Planning app deployments 

Before you deploy an app to an IBM Cloud® Kubernetes Service cluster, decide how you want to set up your app so that your app can be accessed properly and be integrated with other services in IBM Cloud.



 Moving workloads to IBM Cloud Kubernetes Service 

Learn what kinds of workloads can be run on IBM Cloud Kubernetes Service, and the optimal way to set up these workloads.



 What kind of apps can I run in IBM Cloud Kubernetes Service? 

Your containerized app must be able to run on the supported operating system, Ubuntu 18.04 x86_64, 16.04 x86_64 (deprecated). You also want to consider the statefulness of your app.

Stateless apps
: Stateless apps are preferred for cloud-native environments like Kubernetes. They are simple to migrate and scale because they declare dependencies, store configurations separately from the code, and treat backing services such as databases as attached resources instead of coupled to the app. The app pods don't require persistent data storage or a stable network IP address, and as such, pods can be terminated, rescheduled, and scaled in response to workload demands. The app uses a Database-as-a-Service for persistent data, and NodePort, load balancer, or Ingress services to expose the workload on a stable IP address.

Stateful apps
: Stateful apps are more complicated than stateless apps to set up, manage, and scale because the pods require persistent data and a stable network identity. Stateful apps are often databases or other distributed, data-intensive workloads where processing is more efficient closer to the data itself. If you want to deploy a stateful app, you need to set up persistent storage and mount a persistent volume to the pod that is controlled by a StatefulSet object.
[AWS regions and zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html), such as us-east-1a, us-east-1b, us-east-1c.
3. [Azure topology.kubernetes.io/zone labels](https://docs.microsoft.com/en-us/azure/aks/availability-zonesverify-node-distribution-across-zones), such as eastus-1, eastus-2, and eastus-3. Do not use only the location name (eastus) or the zone number (1).
4. [GCP regions and zones](https://cloud.google.com/compute/docs/regions-zones), such as us-west1-a, us-west1-b, and us-west1-c.



: Optional: If you use this option, zone names must be specified in three repeated options. If you do not use this option, the zones in your location are assigned names, such as zone-1.

--coreos-enabled
: Optional. Enable [Red Hat CoreOS](https://cloud.ibm.com/docs/satellite?topic=satellite-infrastructure-planinfras-plan-os) features within the Satellite location. This action cannot be undone.

--logging-account-id LOGGING_ACCOUNT
: Optional. The IBM Cloud account ID with the instance of IBM Log Analysis that you want to forward your Satellite logs to. This option is available only in select environments.

--pod-subnet SUBNET
: Optional. Specify a custom subnet CIDR to provide private IP addresses for pods. This option can be used only if you also enable Red Hat CoreOS with the --coreos-enabled option. All pods that are deployed to a worker node are assigned a private IP address in the 172.16.0.0/16 range by default. You can avoid subnet conflicts with the network that you use to connect to your location by specifying a custom subnet CIDR that provides the private IP addresses for your pods.
This setup is called a [multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmz-clusters) and ensures that your app is accessible, even if a worker node or an entire zone is not available.

To protect against an entire region failure, create [multiple clusters and spread them across IBM Cloud regions](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmultiple-clusters-glb). By setting up a network load balancer (NLB) for your clusters, you can achieve cross-region load balancing and cross-region networking for your clusters.

If you have data that must be available, even if an outage occurs, make sure to store your data on [persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-plan).

For more information about how to achieve high availability for your cluster, see [High availability for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-haha).





 What options do I have to secure my cluster? 

You can use built-in security features in IBM Cloud Kubernetes Service to protect the components in your cluster, your data, and app deployments to ensure security compliance and data integrity. Use these features to secure your Kubernetes API server, etcd data store, worker node, network, storage, images, and deployments against malicious attacks. You can also leverage built-in logging and monitoring tools to detect malicious attacks and suspicious usage patterns.

For more information about the components of your cluster and how you can meet security standards for each component, see [Security for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-securitysecurity).





 What access policies do I give my cluster users? 

IBM Cloud Kubernetes Service uses Cloud Identity and Access Management (IAM) to grant access to cluster resources through IAM platform access roles and Kubernetes role-based access control (RBAC) policies through IAM service access roles.
Allow the IBM Cloud infrastructure private IP ranges for all the [zones](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneslocations) that you are using. Note: You must add the 166.8.0.0/14 and 161.26.0.0/16 IP ranges, the IP ranges for the dal01, dal10, wdc04 zones, and if your cluster is in the Europe geography, the ams01 zone. See [Service Network (on backend/private network)](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-ibm-cloud-ip-rangesback-end-network).



2. Note the private IP address for each worker node in the cluster.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>





 Allow worker nodes to communicate with cluster master 

To allow worker nodes to communicate with the cluster master over the private cloud service endpoint, allow outgoing network traffic from the source <each_worker_node_privateIP> to the destination TCP/UDP port range 30000-32767 and port 443, and the following IP addresses and network groups.

This table is moving. For the latest IP lists and continued updates, see the private network isolation folder in the IBM/kube-samples[repo](https://github.com/IBM-Cloud/kube-samples/tree/master/calico-policies/private-network-isolation). You can Watch pull requests in the repo for updates.



* TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_privateIP> TO <private_IPs>
* Replace <private_IPs> with the private IP addresses of the region where your cluster is located.





Table 3. IP addresses to open for outgoing traffic

 Region Private IP address
Before you use this command, make sure that the user who runs this command has the required [IBM Cloud Kubernetes Service and IBM Cloud infrastructure permissions](https://cloud.ibm.com/docs/containers?topic=containers-access_referencecluster_create_permissions). Target the resource group and region that you want to set the API key for. When the API key is reset, the previous API key that was used, if any, for the region and resource group is now obsolete. You can then delete the old API key from your list of API keys. Before you reset the API key, check whether you have other services that use the existing API key, such as a [key management service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkeyprotect) or [Secrets Manager](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr).

ibmcloud ks api-key reset --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 api-key reset command 

ibmcloud ks api-key reset --region us-south









 credential commands 

Set and unset credentials that allow you to access the classic IBM Cloud infrastructure portfolio through your IBM Cloud account.

You can manually set infrastructure credentials to a different account only for classic clusters, not for VPC clusters.



 ibmcloud ks credential get 

Classic infrastructure

If you set up your IBM Cloud account to use different credentials to access the IBM Cloud infrastructure portfolio, get the infrastructure username for the region and resource group that you are currently targeted to.

ibmcloud ks credential get --region REGION [-q] [--output json]

Minimum required permissions
IBM Cloud Kubernetes Service does not support the [Portworx experimental InitializerConfiguration admission controller](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/hyperconvergence/initializer-experimental-feature-in-stork-v1-1). 
 Private clusters To install Portworx in a cluster that doesn't have VRF or access to private cloud service endpoints (CSEs), you must create a rule in the default security group to allow inbound and outbound traffic for the following IP addresses: 166.9.24.81, 166.9.22.100, and 166.9.20.178. For more information, see [Updating the default security group](https://cloud.ibm.com/docs/vpc?topic=vpc-updating-the-default-security-groupupdating-the-default-security-group). 







 Overview of the Portworx lifecycle 



1. Create a [multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters).



1. Infrastructure provider: For Satellite clusters, make sure to add block storage volumes to your hosts before attaching them to your location. If you use classic infrastructure, you must choose a bare metal flavor for the worker nodes. For classic clusters, virtual machines have only 1000 Mbps of networking speed, which is not sufficient to run production workloads with Portworx. Instead, provision Portworx on bare metal machines for the best performance.
2. Worker node flavor: Choose an SDS or bare metal flavor. If you want to use virtual machines, use a worker node with 16 vCPU and 64 GB memory or more, such as b3c.16x64. Virtual machines with a flavor of b3c.4x16 or u3c.2x4 don't provide the required resources for Portworx to work properly.
3. Minimum number of workers: Two worker nodes per zone across three zones, for a minimum total of six worker nodes.



2.
After the cluster is created, you can [add custom subnets](https://cloud.ibm.com/docs/containers?topic=containers-subnetssubnets_custom) to your cluster. Additionally, you can specify a custom subnet CIDR for pods and services by using the --pod-subnet and --service-subnet options in the ibmcloud ks cluster create command when you create your cluster.





 Worker-to-master and user-to-master communication for private clusters 

The Kubernetes master is accessible through the private cloud service endpoint if authorized cluster users are in your IBM Cloud private network or are connected to the private network such as through a [classic VPN connection](https://cloud.ibm.com/docs/iaas-vpn?topic=iaas-vpn-getting-started) or [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl). However, communication with the Kubernetes master over the private cloud service endpoint must go through the 166.X.X.X IP address range, which is not routable from a classic VPN connection or through IBM Cloud Direct Link. You can expose the private cloud service endpoint of the master for your cluster users by using a private network load balancer (NLB). The private NLB exposes the private cloud service endpoint of the master as an internal 10.X.X.X IP address range that users can access with the VPN or IBM Cloud Direct Link connection. If you enable only the private cloud service endpoint, you can use the Kubernetes dashboard or temporarily enable the public cloud service endpoint to create the private NLB.





 Worker communication to other services or networks for private clusters 

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
Kubernetes version information 

Review this page for general information about IBM Cloud® Kubernetes Service versions and updating to newer versions.

For more information about the Kubernetes project versions, see the [Kubernetes change logs](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG).



 Available IBM Cloud® Kubernetes Service versions 

IBM Cloud Kubernetes Service concurrently supports multiple versions of Kubernetes. When a latest version (n) is released, versions up to 2 behind (n-2) are supported. Versions more than 2 behind the latest (n-3) are first deprecated and then unsupported. To continue receiving important security patch updates, make sure that your clusters always run a supported Kubernetes version. Deprecated clusters might not receive security updates. For more information, see [Release lifecycle](https://cloud.ibm.com/docs/containers?topic=containers-changelogrelease_lifecycle).

Review the supported versions of IBM Cloud Kubernetes Service. In the CLI, you can run ibmcloud ks versions.

Dates that are marked with a dagger (†) are tentative and subject to change.

Ubuntu 18 is deprecated and becomes unsupported soon. For migration actions, see [Migrating to a new Ubuntu version](https://cloud.ibm.com/docs/containers?topic=containers-ubuntu-migrate).

Latest: 1.27



* Release date: 24 May 2023
* End of support: 14 August 2024†
* Supported operating systems: UBUNTU_20_64, UBUNTU_18_S390X, UBUNTU_18_64
* [Version information and update actions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions_127)
* [Change log](https://cloud.ibm.com/docs/containers?topic=containers-changelog_127)



Default: 1.26



* Release date: 01 February 2023