vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[List available flavors for a zone](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_machine_types).





 ibmcloud ks locations 

[List supported IBM Cloud Kubernetes Service locations](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_supported-locations).





 ibmcloud ks messages 

[View the current user messages](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_messages).





 ibmcloud ks versions 

[List all the container platform versions that are available for IBM Cloud Kubernetes Service clusters](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_versions_command).





 ibmcloud ks api 

Deprecated[View or set the API endpoint and API version for the service](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cli_api).





 ibmcloud ks init 

[Initialize the Kubernetes Service plug-in and get authentication tokens](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_init).





 ibmcloud ks script 

[Rewrite scripts that call IBM Cloud Kubernetes Service plug-in commands](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliscript).



* [ibmcloud ks script update](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliscript_update)







 ibmcloud ks security-group 

[Reset or sync security group settings](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clisecurity_group)
: Standard clusters in [accounts that are enabled with VRF and service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint): Enable the [private cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsworkeruser-master) so that your Kubernetes master and the worker nodes communicate over the private VLAN. In addition, you can choose to enable the public cloud service endpoint by using the --public-service-endpoint option to access your cluster over the internet. If you enable the private cloud service endpoint only, you must be connected to the private VLAN to communicate with your Kubernetes master. After you enable a private cloud service endpoint, you can't later disable it. After you create the cluster, you can get the endpoint by running ibmcloud ks cluster get --cluster <cluster_name_or_ID>.

--public-service-endpoint
: Enable the [public cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsworkeruser-master) so that your Kubernetes master can be accessed over the public network, for example to run kubectl commands from your command line. If you have an [account that is enabled with VRF and service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint) and also include the --private-service-endpoint option, master-worker node communication goes over the private and the public network. You can later disable the public cloud service endpoint if you want a private-only cluster. After you create the cluster, you can get the endpoint by running ibmcloud ks cluster get --cluster <cluster_name_or_ID>.

--workers WORKER
: Optional: Specify the number of worker nodes to include in the cluster. If you don't specify this option, a cluster with the minimum value of 1 is created. For more information, see [What is the smallest size cluster that I can make?]
: Viewer platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

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

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

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



 Example infra-permissions get command 

ibmcloud ks infra-permissions get --region us-south

Example output

Missing Virtual Worker Permissions

Add Server suggested
Cancel Server suggested
View Virtual Server Details required

Missing Physical Worker Permissions

No changes are suggested or required.

Missing Network Permissions

No changes are suggested or required.

Missing Storage Permissions

Add Storage required
Manage Storage required









 kms commands 

Enable a [key management service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms) in your cluster to encrypt the etcd component and Kubernetes secrets with a root key that you control.



 ibmcloud ks kms crk ls 

Virtual Private Cloud

Classic infrastructure

List available customer root keys (CRKs) in a key management service instance. Root keys wrap and unwrap the local data encryption keys (DEKs) that the cluster uses to encrypt its secrets. For more information, see [Understanding Key Management Service (KMS) providers](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms).

Do not delete root keys in your KMS instance, even if you rotate to use a new key. If you delete a root key that a cluster uses, the cluster becomes unusable, loses all its data, and can't be recovered.

ibmcloud ks kms crk ls --instance-id KMS_INSTANCE_ID [--output json] [-q]

Minimum required permissions
[Organization of IBM Cloud Kubernetes Service locations](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_regions_hierarchy.png)

Figure 1. Organization of IBM Cloud Kubernetes Service locations



Organization of IBM Cloud Kubernetes Service locations.

 Type Example Description 

 Geography North America (na) An organizational grouping that is based on geographic continents. 
 Country Canada (ca) The location's country within the geography. 
 Metro For example, Dallas (dal). The name of a city where 1 or more data centers are located. A metro might have a multizone region, such as Dallas, or might have a single zone region, such as Milan. If you create a cluster in a multizone region, the Kubernetes master and worker nodes can be spread across zones for high availability. 
 Data center (zone) Dallas 12 (dal12) A physical location of the compute, network, and storage infrastructure and related cooling and power that host cloud services and applications. In a region, clusters can be spread across data centers, or zones, in an multizone architecture for high availability. Zones are isolated from each other, which ensures no shared single point of failure. 







 Classic multizone regions 

If you create a classic cluster in a multizone region, the replicas of your highly available Kubernetes master are automatically spread across the data centers (zones). You have the option to spread your worker nodes across zones to protect your apps from a zone failure. To determine whether a location has a multizone region, your can run ibmcloud ks locations and look for the value in the Multizone Metro column.



Available multizone metro locations for classic clusters in IBM Cloud Kubernetes Service.

 Geography Country Metro Region Zones 

 Asia Pacific Australia Sydney au-syd syd01, syd04, syd05 
 Asia Pacific Japan Osaka jp-osa osa21, osa22, osa23 
 Asia Pacific Japan Tokyo jp-tok tok02, tok04, tok05
Using IBM Cloud Kubernetes Service on classic to host the dl-reverse-proxy 

Follow these steps to set up the dl-reverse-proxy for IBM Cloud® Direct Link by using IBM Cloud Kubernetes Service on classic.



 Step 1: Create an IBM Cloud Kubernetes Service cluster 

Create an IBM Cloud Kubernetes Service cluster in your IBM Cloud account, which serves as the connection between your Satellite location and IBM Cloud on the private network.



1. Review the networking basics of [clusters](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters). In particular, ensure that you prepare the following:



* VLAN management (classic clusters only): Manage and choose both a public and private VLAN for your cluster's network connectivity.
* Subnet routing: Enable a Virtual Router Function (VRF) or VLAN spanning for your IBM Cloud infrastructure account so your worker nodes can communicate with each other on the private network and communicate with private cloud service endpoints internally.
* IP address schema: Ensure that no subnet conflicts exist between the cluster and your on-premises network.



2. Review the steps you need to take to [prepare to create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusterscluster_prepare).
3. Create a standard [classic cluster](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-classic&interface=cli) or [VPC cluster](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2&interface=cli) in the CLI. Create the cluster with the following features.



* Classic clusters:



* Zone: Any [multizone-capable zone](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz)
* Worker node flavor: Any classic infrastructure flavor
* Network connectivity: Public and private VLANs
* Worker pool: At least 2 worker nodes
* Version: 1.20.7 or later
(https://cloud.ibm.com/docs/containers?topic=containers-faqsstandards). 
 Service limitations See [Service limitations](https://cloud.ibm.com/docs/containers?topic=containers-limitationstech_limits). Feature-specific limitations are documented by section. 







 Troubleshooting and support 

Classic, VPC, and Satellite clusters are supported through the same IBM Cloud Support processes.



* For cluster issues, check out the [Debugging your clusters](https://cloud.ibm.com/docs/containers?topic=containers-debug_clusters) guide.
* For Satellite-specific issues, see [Troubleshooting errors](https://cloud.ibm.com/docs/satellite?topic=satellite-sitemap&interface=clisitemap_troubleshooting_errors).
* For VPC-specific topics. For questions, try posting in the [Slack channel](https://cloud.ibm.com/kubernetes/slack).
* IBM Cloud Kubernetes Service CBR rules that apply to all API types or the cluster API type do not support Report-only enforcement for the cluster API type.
* IBM Cloud Kubernetes Service CBR rules that apply to all API types or the cluster API types are limited to no more than 20 IPs/subnets for private rules, and 200 IPs/subnets for public rules. These limits are expected to increase after the backend scalability of our implementation of Red Hat OpenShift on IBM Cloud CBR is updated.
* IBM Cloud Kubernetes Service public CBR rules that apply to the cluster API type do not effect clusters that are private service endpoint only. All public traffic to the cluster APIserver is blocked. To use public CBR rules to control access to your cluster, update your cluster to enable public service endpoint.
* Due to a limitation with how IBM Cloud Kubernetes Service fetches cluster details, the APIs for getting clusters and listing clusters are still accessible regardless of the CBR rules. This means clusters are still visible (read-only) in the console and CLI. When this limitation is addressed, you must add new rules to protect the APIs for getting clusters and listing clusters.
* Due to a limitation that is currently being addressed, when you create a single private CBR rule that applies to the cluster API type and specifies a single, empty network zone, the rule does not block the private service endpoint completely. Instead, the cluster is treated as if there are no CBR rules and allows all traffic. Until this limitation is resolved, you must create a private CBR rule with at least one IP, for example, 1.1.1.1/32, or another IP that you control.
* Some IBM Cloud Kubernetes Service clusters that were created before 8 October 2022 are not able to enforce public CBR rules for the cluster's APIserver. 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.
When you select a zone that is located outside your country, keep in mind that you might require legal authorization before data can be physically stored in a foreign country.

--vpc-id VPC_ID
: Required: The ID of the VPC in which to create the cluster and worker nodes. To list available IDs, run ibmcloud ks vpcs.

--subnet-id VPC_SUBNET_ID
: Required: The VPC subnet to assign the cluster. To list available VPC subnets, run ibmcloud ks subnets --provider vpc-gen2.

--version MAJOR.MINOR.PATCH
: The Kubernetes version for the cluster master node. To see available versions, run ibmcloud ks versions.

--flavor FLAVOR
: Choose a flavor for your worker nodes. You can deploy your worker nodes as virtual machines on shared or dedicated hardware. To see flavors that are available in a zone, run ibmcloud ks flavors --zone <vpc_zone> --provider vpc-gen2.

--workers NUMBER_WORKERS_PER_ZONE
: Optional: Specify the number of worker nodes to include in the cluster. If you don't specify this option, a cluster with the minimum value of 1 is created. For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/containers?topic=containers-faqssmallest_cluster). Every worker node is assigned a unique worker node ID and domain name that must not be manually changed after the cluster is created. Changing the ID or domain name prevents the Kubernetes master from managing your cluster.

--disable-public-service-endpoint
: To ensure that worker nodes and authorized cluster users communicate with the master through the private cloud service endpoint only, include this option to create the cluster without the public cloud service endpoint.

--pod-subnet SUBNET
: In the first cluster that you create in a VPC, the default pod subnet is 172.17.0.0/18.
: You can create or [update](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions_120) your cluster to Kubernetes version 1.20. With Kubernetes 1.20, you get the latest stable enhancements from the community, as well as beta access to features such as [API server priority](https://cloud.ibm.com/docs/containers?topic=containers-kubeapi-priority). For more information, see the [blog announcement](http://www.ibm.com/cloud/blog/announcements/kubernetes-version-120-now-available-in-ibm-cloud-kubernetes-service).

Deprecated Kubernetes 1.17
: With the release of Kubernetes 1.20, clusters that run version 1.17 are deprecated, with a tentative unsupported date of 2 July 2021. Update your cluster to at least [version 1.18](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsk8s_version_archive) as soon as possible.





 15 February 2021 

New! Osaka multizone region
: You can now create classic or VPC clusters in the Osaka, Japan (jp-osa) [location](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zones).

Worker node versions
: Worker node fix pack update change log documentation is available for version [1.19.7_1535](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1191197_1535), [1.18.15_1541](https://cloud.ibm.com/docs/containers?topic=containers-118_changelog11815_1541), and [1.17.17_1553](https://cloud.ibm.com/docs/containers?topic=containers-117_changelog11717_1553).





 12 February 2021 

Gateway firewalls and Calico policies
You must add the containers-kubernetes to your network zones for rules created against the following services.

IAM Identity service
: Allow IBM Cloud Kubernetes Service to create tokens and API Keys like the cluster API Key and the IBM Cloud Container Registry token and API Key.

IAM Access Management Service
: Allow IBM Cloud Kubernetes Service to create an IAM Access Policy for Reader service access role to IBM Cloud Container Registry.

IAM Access Groups Service
: Allow IBM Cloud Kubernetes Service to look up access groups when syncing IAM access policies with RBAC in the cluster.

User Management
: Allow IBM Cloud Kubernetes Service to access user information when syncing IAM access policies with RBAC in the cluster.

Key protect:
: Allow IBM Cloud Kubernetes Service to enable encryption on the cluster.







 Creating network zones 

Network zones act as allowlists for the target resources you define when you create CBR rules. After you create a network zone, or allowlist, you can create rules that define which resources the network zone can access.

Make sure to add the containers-kubernetes service to your network zones for rules that apply to other IBM Cloud resources, such as a rule that protects IBM Cloud Object Storage or some cluster operations might fail. For more information, see [Allowing IBM Cloud Kubernetes Service to access other IBM Cloud resources by using CBR](https://cloud.ibm.com/docs/containers?topic=containers-cbr&interface=uicbr-integrations).

Review the [limitations](https://cloud.ibm.com/docs/containers?topic=containers-cbr&interface=uicbr-limitations) before you create network zones.



 Creating network zones from the API 

You can create network zones by using the /v1/zones API. For more information, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone). You can add the containers-kubernetes service to your network zones to allow IBM Cloud Kubernetes Service to access resources and services in your account.

You can include multiple address types in your network zone payload.
For more information, see the documentation for the ibmcloud ks flavors (machine-types)[command](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clics_machine_types). This value is required for standard clusters and is not available for free clusters. In gateway-enabled classic clusters, you can choose the flavor for compute worker nodes only. Gateway worker nodes are created with the u3c.2x4 flavor by default.

--name NAME
: Required: The name for the cluster. The name must start with a letter, can contain letters, numbers, periods (.), and hyphen (-), and must be 35 characters or fewer. Use a name that is unique across regions. The cluster name and the region in which the cluster is deployed form the fully qualified domain name for the Ingress subdomain. To ensure that the Ingress subdomain is unique within a region, the cluster name might be truncated and appended with a random value within the Ingress domain name.

--operating-system SYSTEM
: Optional. The operating system of the worker nodes you want to provision in your cluster. For a list of available operating systems by cluster version, see [IBM Cloud Kubernetes Service version information](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).

--version MAJOR.MINOR.PATCH
: Optional: The Kubernetes version for the cluster master node. When the version is not specified, the cluster is created with the default of supported Kubernetes versions. To see available versions, run ibmcloud ks versions.

--no-subnet
: By default, a public and a private portable subnet are created on the VLAN associated with the cluster. Include the --no-subnet option to avoid creating subnets with the cluster.
* [View documentation on the API commands](https://containers.cloud.ibm.com/global/swagger-global-api//).
* Generate a client of the API to use in automation by using the [swagger.json API](https://containers.cloud.ibm.com/global/swagger-global-api/swagger.json).



To interact with the global IBM Cloud Kubernetes Service API, enter the command type and append global/v1/command to the endpoint.

Example of GET /clusters global API:

GET https://containers.cloud.ibm.com/global/v1/clusters

If you need to specify a region in an API call, remove the /global parameter from the path and pass the region name in the X-Region header. To list available regions, review the [Previous region](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) column in the IBM Cloud Kubernetes Service locations table.







 Previous IBM Cloud region and zone structure 

Previously, your IBM Cloud resources were organized into regions. Regions are a conceptual tool to organize zones, and can include zones (data centers) in different countries and geographies. The following table maps the previous IBM Cloud regions, IBM Cloud Kubernetes Service regions, and IBM Cloud Kubernetes Service zones. Multizone-capable zones are in bold.

Region-specific endpoints for IBM Cloud Kubernetes Service are deprecated. Use the [global endpoint](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zonesendpoint) instead. If you must use regional endpoints, [use the ibmcloud ks api command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cli_api).

By using IBM Cloud Kubernetes Service regions, you can create or access Kubernetes clusters in a region other than the IBM Cloud region that you are logged in to.
* Platform: If you have only a platform access role, you can perform this command, but you need a [service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) or a [custom RBAC policy](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewrole-binding) to perform Kubernetes actions in the cluster.
* Service: If you have only a service access role, you can perform this command. However, your cluster admin must give you the cluster name and ID because you can't run the ibmcloud ks cluster ls command or open the IBM Cloud Kubernetes Service console to view clusters. After you receive the cluster name and ID, you can [launch the Kubernetes dashboard from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appdb_cli) and work with Kubernetes.



Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--admin
: Optional: Download the TLS certificates and permission files for the Super User role. 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.
Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

--zone ZONE
: Required: The zone that you want to add. The zone must be a [multizone-capable zone](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) within the cluster's region.

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-p, --worker-pool WORKER_POOL
: The name of the worker pool to add the zone to. To specify multiple worker pools, use multiple options, such as -p pool1 -p pool2.

--private-vlan PRIVATE_VLAN
: The ID of the private VLAN. This value is required, whether you want to use the same or a different private VLAN than the one that you used for your other worker nodes. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed. The private and public VLANs must be compatible, which you can determine from the Router ID prefix.

--public-vlan PUBLIC_VLAN
: The ID of the public VLAN. This value is required only if you want to change the public VLAN for the zone. To change the public VLAN, you must always provide a compatible private VLAN. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed. The private and public VLANs must be compatible, which you can determine from the Router ID prefix.

--private-only
: Optional: Unset the public VLAN so that the workers in this zone are connected to a private VLAN only.

-f
: Optional: Force the command to run with no user prompts.

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

Usage:



1. Check the VLANs that are available in your cluster.