years
2014, 2018

lastupdated

2018-07-10

{:new_window: target="_blank"} {:shortdesc: .shortdesc} {:screen: .screen} {:pre: .pre} {:table: .aria-labeledby="caption"} {:codeblock: .codeblock} {:tip: .tip} {:download: .download}

CLI reference for managing clusters

{: #cs_cli_reference}

Refer to these commands to create and manage clusters on {{site.data.keyword.Bluemix_notm}}. {:shortdesc}

ibmcloud cs commands

{: #cs_commands}

Tip: To see the version of the {{site.data.keyword.containershort_notm}} plug-in, run the following command.

ibmcloud plugin list

{: pre}

API commands

API commands
[ibmcloud cs api](#cs_api)	[ibmcloud cs api-key-info](#cs_api_key_info)	[ibmcloud cs api-key-reset](#cs_api_key_reset)	[ibmcloud cs apiserver-config-get](#cs_apiserver_config_get)
[ibmcloud cs apiserver-config-set](#cs_apiserver_config_set)	[ibmcloud cs apiserver-config-unset](#cs_apiserver_config_unset)	[ibmcloud cs apiserver-refresh](#cs_apiserver_refresh)

CLI plug-in usage commands

CLI plug-in usage commands
[ibmcloud cs help](#cs_help)	[ibmcloud cs init](#cs_init)	[ibmcloud cs messages](#cs_messages)

Cluster commands: Management commands

Cluster commands: Management
[ibmcloud cs cluster-config](#cs_cluster_config)	[ibmcloud cs cluster-create](#cs_cluster_create)	[ibmcloud cs cluster-feature-enable](#cs_cluster_feature_enable)	[ibmcloud cs cluster-get](#cs_cluster_get)
[ibmcloud cs cluster-rm](#cs_cluster_rm)	[ibmcloud cs cluster-update](#cs_cluster_update)	[ibmcloud cs clusters](#cs_clusters)	[ibmcloud cs kube-versions](#cs_kube_versions)

Cluster commands: Services and integrations commands

Cluster commands: Services and integrations
[ibmcloud cs cluster-service-bind](#cs_cluster_service_bind)	[ibmcloud cs cluster-service-unbind](#cs_cluster_service_unbind)	[ibmcloud cs cluster-services](#cs_cluster_services)	[ibmcloud cs va](#cs_va)
[ibmcloud cs webhook-create](#cs_webhook_create)

Cluster commands: Subnets commands

Cluster commands: Subnets
[ibmcloud cs cluster-subnet-add](#cs_cluster_subnet_add)	[ibmcloud cs cluster-subnet-create](#cs_cluster_subnet_create)	[ibmcloud cs cluster-user-subnet-add](#cs_cluster_user_subnet_add)	[ibmcloud cs cluster-user-subnet-rm](#cs_cluster_user_subnet_rm)
[ibmcloud cs subnets](#cs_subnets)

Cluster commands: Infrastructure commands

Infrastructure commands
[ibmcloud cs credentials-set](#cs_credentials_set)	[ibmcloud cs credentials-unset](#cs_credentials_unset)	[ibmcloud cs machine-types](#cs_machine_types)	[ibmcloud cs vlans](#cs_vlans)

Ingress application load balancer (ALB) commands

Ingress application load balancer (ALB) commands
[ibmcloud cs alb-cert-deploy](#cs_alb_cert_deploy)	[ibmcloud cs alb-cert-get](#cs_alb_cert_get)	[ibmcloud cs alb-cert-rm](#cs_alb_cert_rm)	[ibmcloud cs alb-certs](#cs_alb_certs)
[ibmcloud cs alb-configure](#cs_alb_configure)	[ibmcloud cs alb-get](#cs_alb_get)	[ibmcloud cs alb-types](#cs_alb_types)	[ibmcloud cs albs](#cs_albs)

Logging commands

Logging commands
[ibmcloud cs logging-config-create](#cs_logging_create)	[ibmcloud cs logging-config-get](#cs_logging_get)	[ibmcloud cs logging-config-refresh](#cs_logging_refresh)	[ibmcloud cs logging-config-rm](#cs_logging_rm)
[ibmcloud cs logging-config-update](#cs_logging_update)	[ibmcloud cs logging-filter-create](#cs_log_filter_create)	[ibmcloud cs logging-filter-update](#cs_log_filter_update)	[ibmcloud cs logging-filter-get](#cs_log_filter_view)
[ibmcloud cs logging-filter-rm](#cs_log_filter_delete)

Region commands

Region commands
[ibmcloud cs zones](#cs_datacenters)	[ibmcloud cs region](#cs_region)	[ibmcloud cs region-set](#cs_region-set)	[ibmcloud cs regions](#cs_regions)

Worker node commands

Worker node commands
Deprecated: [ibmcloud cs worker-add](#cs_worker_add)	[ibmcloud cs worker-get](#cs_worker_get)	[ibmcloud cs worker-reboot](#cs_worker_reboot)	[ibmcloud cs worker-reload](#cs_worker_reload)
[ibmcloud cs worker-rm](#cs_worker_rm)	[ibmcloud cs worker-update](#cs_worker_update)	[ibmcloud cs workers](#cs_workers)	[ibmcloud cs worker-get](#cs_worker_get)
[ibmcloud cs worker-reboot](#cs_worker_reboot)	[ibmcloud cs worker-reload](#cs_worker_reload)	[ibmcloud cs worker-rm](#cs_worker_rm)	[ibmcloud cs workers](#cs_workers)

Worker pool commands

Worker pool commands
[ibmcloud cs worker-pool-create](#cs_worker_pool_create)	[ibmcloud cs worker-pool-get](#cs_worker_pool_get)	[ibmcloud cs worker-pool-rebalance](#cs_rebalance)	[ibmcloud cs worker-pool-resize](#cs_worker_pool_resize)
[ibmcloud cs worker-pool-rm](#cs_worker_pool_rm)	[ibmcloud cs worker-pools](#cs_worker_pools)	[ibmcloud cs zone-add](#cs_zone_add)	[ibmcloud cs zone-network-set](#cs_zone_network_set)
[ibmcloud cs zone-rm](#cs_zone_rm)

API commands

{: #api_commands}

ibmcloud cs api ENDPOINT [--insecure] [--skip-ssl-validation] [--api-version VALUE] [-s]

{: #cs_api}

Target the API endpoint for {{site.data.keyword.containershort_notm}}. If you do not specify an endpoint, you can view information about the current endpoint that is targeted.

Switching regions? Use the ibmcloud cs region-set command instead. {: tip}

Command options:

ENDPOINT

The {{site.data.keyword.containershort_notm}} API endpoint. Note that this endpoint is different than the {{site.data.keyword.Bluemix_notm}} endpoints. This value is required to set the API endpoint. Accepted values are:

Global endpoint: https://containers.bluemix.net
AP North endpoint: https://ap-north.containers.bluemix.net
AP South endpoint: https://ap-south.containers.bluemix.net
EU Central endpoint: https://eu-central.containers.bluemix.net
UK South endpoint: https://uk-south.containers.bluemix.net
US East endpoint: https://us-east.containers.bluemix.net
US South endpoint: https://us-south.containers.bluemix.net

--insecure

Allow an insecure HTTP connection. This flag is optional.

--skip-ssl-validation

Allow insecure SSL certificates. This flag is optional.

--api-version VALUE

Specify the API version of the service that you want to use. This value is optional.

-s

Do not show the message of the day or update reminders. This value is optional.

Example: View information about the current API endpoint that is targeted.

ibmcloud cs api

{: pre}

API Endpoint:          https://containers.bluemix.net   
API Version:           v1   
Skip SSL Validation:   false   
Region:                us-south

{: screen}

ibmcloud cs api-key-info CLUSTER [--json] [-s]

{: #cs_api_key_info}

View the name and email address for the owner of the IAM API key in an {{site.data.keyword.containershort_notm}} region.

The Identity and Access Management (IAM) API key is automatically set for a region when the first action that requires the {{site.data.keyword.containershort_notm}} admin access policy is performed. For example, one of your admin users creates the first cluster in the us-south region. By doing that, the IAM API key for this user is stored in the account for this region. The API key is used to order resources in IBM Cloud infrastructure (SoftLayer), such as new worker nodes or VLANs.

When a different user performs an action in this region that requires interaction with the IBM Cloud infrastructure (SoftLayer) portfolio, such as creating a new cluster or reloading a worker node, the stored API key is used to determine if sufficient permissions exist to perform that action. To make sure that infrastructure-related actions in your cluster can be successfully performed, assign your {{site.data.keyword.containershort_notm}} admin users the Super user infrastructure access policy. For more information, see Managing user access.

If you find that you need to update the API key that is stored for a region, you can do so by running the ibmcloud cs api-key-reset command. This command requires the {{site.data.keyword.containershort_notm}} admin access policy and stores the API key of the user that executes this command in the account.

Tip: The API key that is returned in this command might not be used if IBM Cloud infrastructure (SoftLayer) credentials were manually set by using the ibmcloud cs credentials-set command.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs api-key-info my_cluster

{: pre}

ibmcloud cs api-key-reset [-s]

{: #cs_api_key_reset}

Replace the current IAM API key in an {{site.data.keyword.containershort_notm}} region.

This command requires the {{site.data.keyword.containershort_notm}} admin access policy and stores the API key of the user that executes this command in the account. The IAM API key is required to order infrastructure from the IBM Cloud infrastructure (SoftLayer) portfolio. Once stored, the API key is used for every action in a region that requires infrastructure permissions independent of the user that executes this command. For more information about how IAM API keys work, see the ibmcloud cs api-key-info command.

Important Before you use this command, make sure that the user who executes this command has the required {{site.data.keyword.containershort_notm}} and IBM Cloud infrastructure (SoftLayer) permissions.

Command options:

-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs api-key-reset

{: pre}

ibmcloud cs apiserver-config-get

{: #cs_apiserver_config_get}

Get information about an option for a cluster's Kubernetes API server configuration. This command must be combined with one of the following subcommands for the configuration option you want information on.

ibmcloud cs apiserver-config-get audit-webhook CLUSTER

{: #cs_apiserver_api_webhook_get}

View the URL for the remote logging service that you are sending API server audit logs to. The URL was specified when you created the webhook backend for the API server configuration.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.

Example:

ibmcloud cs apiserver-config-get audit-webhook my_cluster

{: pre}

ibmcloud cs apiserver-config-set

{: #cs_apiserver_config_set}

Set an option for a cluster's Kubernetes API server configuration. This command must be combined with one of the following subcommands for the configuration option you want to set.

ibmcloud cs apiserver-config-set audit-webhook CLUSTER [--remoteServer SERVER_URL_OR_IP] [--caCert CA_CERT_PATH] [--clientCert CLIENT_CERT_PATH] [--clientKey CLIENT_KEY_PATH]

{: #cs_apiserver_api_webhook_set}

Set the webhook backend for the API server configuration. The webhook backend forwards API server audit logs to a remote server. A webhook configuration is created based on the information you provide in this command's flags. If you do not provide any information in the flags, a default webhook configuration is used.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--remoteServer SERVER_URL: The URL or IP address for the remote logging service you want to send audit logs to. If you provide an insecure server URL, any certificates are ignored. This value is optional.
--caCert CA_CERT_PATH: The filepath for the CA certificate that is used to verify the remote logging service. This value is optional.
--clientCert CLIENT_CERT_PATH: The filepath for the client certificate that is used to authenticate against the remote logging service. This value is optional.
--clientKey CLIENT_KEY_PATH: The filepath for the corresponding client key that is used to connect to the remote logging service. This value is optional.

Example:

ibmcloud cs apiserver-config-set audit-webhook my_cluster --remoteServer https://audit.example.com/audit --caCert /mnt/etc/kubernetes/apiserver-audit/ca.pem --clientCert /mnt/etc/kubernetes/apiserver-audit/cert.pem --clientKey /mnt/etc/kubernetes/apiserver-audit/key.pem

{: pre}

ibmcloud cs apiserver-config-unset

{: #cs_apiserver_config_unset}

Disable an option for a cluster's Kubernetes API server configuration. This command must be combined with one of the following subcommands for the configuration option you want to unset.

ibmcloud cs apiserver-config-unset audit-webhook CLUSTER

{: #cs_apiserver_api_webhook_unset}

Disable the webhook backend configuration for the cluster's API server. Disabling the webhook backend stops forwarding API server audit logs to a remote server.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.

Example:

ibmcloud cs apiserver-config-unset audit-webhook my_cluster

{: pre}

ibmcloud cs apiserver-refresh CLUSTER [-s]

{: #cs_apiserver_refresh}

Restart the Kubernetes master in the cluster to apply changes to the API server configuration.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs apiserver-refresh my_cluster

{: pre}

CLI plug-in usage commands

{: #cli_plug-in_commands}

ibmcloud cs help

{: #cs_help}

View a list of supported commands and parameters.

Command options:

None

Example:

ibmcloud cs help

{: pre}

ibmcloud cs init [--host HOST] [--insecure] [-p] [-u] [-s]

{: #cs_init}

Initialize the {{site.data.keyword.containershort_notm}} plug-in or specify the region where you want to create or access Kubernetes clusters.

Command options:

--host HOST: The {{site.data.keyword.containershort_notm}} API endpoint to use. This value is optional. [View the available API endpoint values.](cs_regions.html#container_regions)
--insecure: Allow an insecure HTTP connection.
-p: Your IBM Cloud password.
-u: Your IBM Cloud username.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs init --host https://uk-south.containers.bluemix.net

{: pre}

ibmcloud cs messages

{: #cs_messages}

View current messages for the IBMid user.

Example:

ibmcloud cs messages

{: pre}

Cluster commands: Management

{: #cluster_mgmt_commands}

ibmcloud cs cluster-config CLUSTER [--admin] [--export] [-s] [--yaml]

{: #cs_cluster_config}

After logging in, download Kubernetes configuration data and certificates to connect to your cluster and run kubectl commands. The files are downloaded to user_home_directory/.bluemix/plugins/container-service/clusters/<cluster_name>.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--admin: 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 re-authenticate. The files are downloaded to `/.bluemix/plugins/container-service/clusters/-admin`. This value is optional.
--export: Download Kubernetes configuration data and certificates without any messages other than the export command. Because no messages are displayed, you can use this flag when you create automated scripts. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.
--yaml: Prints the command output in YAML format. This value is optional.

Example:

ibmcloud cs cluster-config my_cluster

{: pre}

ibmcloud cs cluster-create [--file FILE_LOCATION] [--hardware HARDWARE] --zone ZONE --machine-type MACHINE_TYPE --name NAME [--kube-version MAJOR.MINOR.PATCH] [--no-subnet] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--workers WORKER] [--disable-disk-encrypt] [--trusted] [-s]

{: #cs_cluster_create}

Create a cluster in your organization. For free clusters, you specify the cluster name; everything else is set to a default value. A free cluster is automatically deleted after 30 days. You can have one free cluster at a time. To take advantage of the full capabilities of Kubernetes, create a standard cluster.

Command options

--file FILE_LOCATION

The path to the YAML file to create your standard cluster. Instead of defining the characteristics of your cluster by using the options provided in this command, you can use a YAML file. This value is optional for standard clusters and is not available for free clusters.

Note: If you provide the same option in the command as parameter in the YAML file, the value in the command takes precedence over the value in the YAML. For example, you define a location in your YAML file and use the --zone option in the command, the value that you entered in the command option overrides the value in the YAML file.

name: <cluster_name>
zone: <zone>
no-subnet: <no-subnet>
machine-type: <machine_type>
private-vlan: <private_VLAN>
public-vlan: <public_VLAN>
hardware: <shared_or_dedicated>
workerNum: <number_workers>
kube-version: <kube-version>
diskEncryption: false
trusted: true

Understanding the YAML file components

Understanding the YAML file components
`name`	Replace `<cluster_name>` with a name for your cluster. The name must start with a letter, can contain letters, numbers, and hyphen (-), and must be 35 characters or fewer. 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.
`zone`	Replace `<zone>` with the zone where you want to create your cluster. The available zones are dependent on the region that you are logged in. To list available zones, run `ibmcloud cs zones`.
`no-subnet`	By default, a public and a private portable subnet are created on the VLAN associated with the cluster. Replace `<no-subnet>` with `true` to avoid creating subnets with the cluster. You can [create](#cs_cluster_subnet_create) or [add](#cs_cluster_subnet_add) subnets to a cluster later.
`machine-type`	Replace `<machine_type>` with the type of machine that you want to deploy your worker nodes to. You can deploy your worker nodes as virtual machines on shared or dedicated hardware, or as physical machines on bare metal. Available physical and virtual machines types vary by the zone in which you deploy the cluster. For more information, see the documentation for the `ibmcloud cs machine-type` [command](cs_cli_reference.html#cs_machine_types).
`private-vlan`	Replace `<private_VLAN>` with the ID of the private VLAN that you want to use for your worker nodes. To list available VLANs, run `ibmcloud cs vlans <zone>` and look for VLAN routers that start with `bcr` (back-end router).
`public-vlan`	Replace `<public_VLAN>` with the ID of the public VLAN that you want to use for your worker nodes. To list available VLANs, run `ibmcloud cs vlans <zone>` and look for VLAN routers that start with `fcr` (front-end router).
`hardware`	For virtual machine types: The level of hardware isolation for your worker node. Use dedicated if you want to have available physical resources dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is `shared`.
`workerNum`	Replace `<number_workers>` with the number of worker nodes that you want to deploy.
`kube-version`	The Kubernetes version for the cluster master node. This value is optional. When the version is not specified, the cluster is created with the default of supported Kubernetes versions. To see available versions, run `ibmcloud cs kube-versions`.
`diskEncryption: false`	Worker nodes feature disk encryption by default; [learn more](cs_secure.html#encrypted_disk). To disable encryption, include this option and set the value to `false`.
`trusted: true`	Bare metal only: Enable [Trusted Compute](cs_secure.html#trusted_compute) to verify your bare metal worker nodes against tampering. If you don't enable trust during cluster creation but want to later, you can use the `ibmcloud cs feature-enable` [command](cs_cli_reference.html#cs_cluster_feature_enable). After you enable trust, you cannot disable it later.

--hardware HARDWARE

The level of hardware isolation for your worker node. Use dedicated to have available physical resources dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. This value is optional for standard clusters and is not available for free clusters.

--zone ZONE

The zone where you want to create the cluster. The zones that are available to you depend on the {{site.data.keyword.Bluemix_notm}} region you are logged in to. Select the region that is physically closest to you for best performance. This value is required for standard clusters and is optional for free clusters.

Review [available zones](cs_regions.html#zones).

Note: 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.

--machine-type MACHINE_TYPE

Choose a machine type. You can deploy your worker nodes as virtual machines on shared or dedicated hardware, or as physical machines on bare metal. Available physical and virtual machines types vary by the zone in which you deploy the cluster. For more information, see the documentation for the `ibmcloud cs machine-types` [command](cs_cli_reference.html#cs_machine_types). This value is required for standard clusters and is not available for free clusters.

--name NAME

The name for the cluster. This value is required. The name must start with a letter, can contain letters, numbers, and hyphen (-), and must be 35 characters or fewer. 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.

--kube-version MAJOR.MINOR.PATCH

The Kubernetes version for the cluster master node. This value is optional. When the version is not specified, the cluster is created with the default of supported Kubernetes versions. To see available versions, run ibmcloud cs kube-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 flag to avoid creating subnets with the cluster. You can [create](#cs_cluster_subnet_create) or [add](#cs_cluster_subnet_add) subnets to a cluster later.

--private-vlan PRIVATE_VLAN

This parameter is not available for free clusters.
If this standard cluster is the first standard cluster that you create in this zone, do not include this flag. A private VLAN is created for you when the clusters is created.
If you created a standard cluster before in this zone or created a private VLAN in IBM Cloud infrastructure (SoftLayer) before, you must specify that private VLAN.
Note: Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When creating a cluster and specifying the public and private VLANs, the number and letter combination after those prefixes must match.

To find out if you already have a private VLAN for a specific zone or to find the name of an existing private VLAN, run ibmcloud cs vlans <zone>.

--public-vlan PUBLIC_VLAN

This parameter is not available for free clusters.
If this standard cluster is the first standard cluster that you create in this zone, do not use this flag. A public VLAN is created for you when the cluster is created.
If you created a standard cluster before in this zone or created a public VLAN in IBM Cloud infrastructure (SoftLayer) before, specify that public VLAN. If you want to connect your worker nodes to a private VLAN only, do not specify this option.
Note: Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When creating a cluster and specifying the public and private VLANs, the number and letter combination after those prefixes must match.

To find out if you already have a public VLAN for a specific zone or to find the name of an existing public VLAN, run ibmcloud cs vlans <zone>.

--workers WORKER

The number of worker nodes that you want to deploy in your cluster. If you do not specify this option, a cluster with 1 worker node is created. This value is optional for standard clusters and is not available for free clusters.

Note: 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-disk-encrypt

Worker nodes feature disk encryption by default; [learn more](cs_secure.html#encrypted_disk). To disable encryption, include this option.

--trusted

**Bare metal only**: Enable [Trusted Compute](cs_secure.html#trusted_compute) to verify your bare metal worker nodes against tampering. If you don't enable trust during cluster creation but want to later, you can use the `ibmcloud cs feature-enable` [command](cs_cli_reference.html#cs_cluster_feature_enable). After you enable trust, you cannot disable it later.

To check whether the bare metal machine type supports trust, check the `Trustable` field in the output of the `ibmcloud cs machine-types ` [command](#cs_machine_types). To verify that a cluster is trust-enabled, view the **Trust ready** field in the output of the `ibmcloud cs cluster-get` [command](#cs_cluster_get). To verify a bare metal worker node is trust-enabled, view the **Trust** field in the output of the `ibmcloud cs worker-get` [command](#cs_worker_get).

-s

Do not show the message of the day or update reminders. This value is optional.

Examples:

Create a free cluster: Specify the cluster name only; everything else is set to a default value. A free cluster is automatically deleted after 30 days. You can have one free cluster at a time. To take advantage of the full capabilities of Kubernetes, create a standard cluster.

ibmcloud cs cluster-create --name my_cluster

{: pre}

Create your first standard cluster: The first standard cluster that is created in a zone also creates a private VLAN. Therefore, do not include the --public-vlan flag. {: #example_cluster_create}

ibmcloud cs cluster-create --zone dal10 --private-vlan my_private_VLAN_ID --machine-type b2c.4x16 --name my_cluster --hardware shared --workers 2

{: pre}

Create subsequent standard clusters: If you already created a standard cluster in this zone or created a public VLAN in IBM Cloud infrastructure (SoftLayer) before, specify that public VLAN with the --public-vlan flag. To find out if you already have a public VLAN for a specific zone or to find the name of an existing public VLAN, run ibmcloud cs vlans <zone>.

ibmcloud cs cluster-create --zone dal10 --public-vlan my_public_VLAN_ID --private-vlan my_private_VLAN_ID --machine-type b2c.4x16 --name my_cluster --hardware shared --workers 2

{: pre}

Create a cluster in an {{site.data.keyword.Bluemix_dedicated_notm}} environment:

ibmcloud cs cluster-create --machine-type machine-type --workers number --name cluster_name

{: pre}

ibmcloud cs cluster-feature-enable [-f] CLUSTER [--trusted] [-s]

{: #cs_cluster_feature_enable}

Enable a feature on an existing cluster.

Command options:

CLUSTER

The name or ID of the cluster. This value is required.

-f

Use this option to force the --trusted option with no user prompts. This value is optional.

--trusted

Include the flag to enable [Trusted Compute](cs_secure.html#trusted_compute) for all supported bare metal worker nodes that are in the cluster. After you enable trust, you cannot later disable it for the cluster.

To check whether the bare metal machine type supports trust, check the **Trustable** field in the output of the `ibmcloud cs machine-types ` [command](#cs_machine_types). To verify that a cluster is trust-enabled, view the **Trust ready** field in the output of the `ibmcloud cs cluster-get` [command](#cs_cluster_get). To verify a bare metal worker node is trust-enabled, view the **Trust** field in the output of the `ibmcloud cs worker-get` [command](#cs_worker_get).

-s

Do not show the message of the day or update reminders. This value is optional.

Example command:

ibmcloud cs cluster-feature-enable my_cluster --trusted=true

{: pre}

ibmcloud cs cluster-get CLUSTER [--json] [--showResources] [-s]

{: #cs_cluster_get}

View information about a cluster in your organization.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--json: Prints the command output in JSON format. This value is optional.
--showResources: Show more cluster resources such as add-ons, VLANs, subnets, and storage.
-s: Do not show the message of the day or update reminders. This value is optional.

Example command:

ibmcloud cs cluster-get my_cluster --showResources

{: pre}

Example output:

Name:        my_cluster
ID:          abc1234567
State:       normal
Trust ready: false
Created:     2018-01-01T17:19:28+0000
Zone:        dal10
Master URL:  https://169.xx.xxx.xxx:xxxxx
Master Location: Dallas
Ingress subdomain: my_cluster.us-south.containers.appdomain.cloud
Ingress secret:    my_cluster
Workers:      3
Worker Zones: dal10
Version:      1.10.3
Owner Email:  name@example.com
Monitoring dashboard: https://metrics.ng.bluemix.net/app/#/grafana4/dashboard/db/link

Addons
Name                   Enabled
customer-storage-pod   true
basic-ingress-v2       true
storage-watcher-pod    true

Subnet VLANs
VLAN ID   Subnet CIDR         Public   User-managed
2234947   10.xxx.xx.xxx/29    false    false
2234945   169.xx.xxx.xxx/29  true    false

{: screen}

ibmcloud cs cluster-rm [-f] CLUSTER [-s]

{: #cs_cluster_rm}

Remove a cluster from your organization.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the removal of a cluster with no user prompts. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs cluster-rm my_cluster

{: pre}

ibmcloud cs cluster-update [-f] CLUSTER [--kube-version MAJOR.MINOR.PATCH] [--force-update] [-s]

{: #cs_cluster_update}

Update the Kubernetes master to the default API version. During the update, you cannot access or change the cluster. Worker nodes, apps, and resources that were deployed by the user are not modified and continue to run.

You might need to change your YAML files for future deployments. Review this release note for details.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--kube-version MAJOR.MINOR.PATCH: The Kubernetes version of the cluster. If you do not specify a version, the Kubernetes master is updated to the default API version. To see available versions, run [ibmcloud cs kube-versions](#cs_kube_versions). This value is optional.
-f: Use this option to force the update of the master with no user prompts. This value is optional.
--force-update: Attempt the update even if the change is greater than two minor versions. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs cluster-update my_cluster

{: pre}

ibmcloud cs clusters [--json] [-s]

{: #cs_clusters}

View a list of clusters in your organization.

Command options:

--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs clusters

{: pre}

ibmcloud cs kube-versions [--json] [-s]

{: #cs_kube_versions}

View a list of Kubernetes versions supported in {{site.data.keyword.containershort_notm}}. Update your cluster master and worker nodes to the default version for the latest, stable capabilities.

Command options:

--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs kube-versions

{: pre}

Cluster commands: Services and integrations

{: #cluster_services_commands}

ibmcloud cs cluster-service-bind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_NAME [-s]

{: #cs_cluster_service_bind}

Add an {{site.data.keyword.Bluemix_notm}} service to a cluster. To view available {{site.data.keyword.Bluemix_notm}} services from the {{site.data.keyword.Bluemix_notm}} catalog, run ibmcloud service offerings. Note: You can only add {{site.data.keyword.Bluemix_notm}} services that support service keys.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
KUBERNETES_NAMESPACE: The name of the Kubernetes namespace. This value is required.
SERVICE_INSTANCE_NAME: The name of the {{site.data.keyword.Bluemix_notm}} service instance that you want to bind. To find the name of your service instance, run ibmcloud service list. If more than one instance has the same name in the account, use the service instance ID instead of the name. To find the ID, run ibmcloud service show --guid. One of these values is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs cluster-service-bind my_cluster my_namespace my_service_instance

{: pre}

ibmcloud cs cluster-service-unbind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_GUID [-s]

{: #cs_cluster_service_unbind}

Remove an {{site.data.keyword.Bluemix_notm}} service from a cluster.

Note: When you remove an {{site.data.keyword.Bluemix_notm}} service, the service credentials are removed from the cluster. If a pod is still using the service, it fails because the service credentials cannot be found.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
KUBERNETES_NAMESPACE: The name of the Kubernetes namespace. This value is required.
SERVICE_INSTANCE_GUID: The ID of the {{site.data.keyword.Bluemix_notm}} service instance that you want to remove. To find the ID of the service instance, run `ibmcloud cs cluster-services `.This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs cluster-service-unbind my_cluster my_namespace 8567221

{: pre}

ibmcloud cs cluster-services CLUSTER [--namespace KUBERNETES_NAMESPACE] [--all-namespaces] [--json] [-s]

{: #cs_cluster_services}

List the services that are bound to one or all of the Kubernetes namespace in a cluster. If no options are specified, the services for the default namespace are displayed.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--namespace KUBERNETES_NAMESPACE, -n KUBERNETES_NAMESPACE: Include the services that are bound to a specific namespace in a cluster. This value is optional.
--all-namespaces: Include the services that are bound to all of the namespaces in a cluster. This value is optional.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs cluster-services my_cluster --namespace my_namespace

{: pre}

ibmcloud cs va CONTAINER_ID [--extended] [--vulnerabilities] [--configuration-issues] [--json]

{: #cs_va}

After you install the container scanner, view a detailed vulnerability assessment report for a container in your cluster.

Command options:

CONTAINER_ID

The ID of the container. This value is required.

To find the ID of your container:

[Target the Kubernetes CLI to your cluster](cs_cli_install.html#cs_cli_configure).
List your pods by running `kubectl get pods`.
Find the **Container ID** field in the output of the `kubectl describe pod ` command. For example, `Container ID: docker://1a11a1aa2b2b22223333c44444ccc555667d7dd777888e8ef99f1011121314g15`.
Remove the `docker://` prefix from the ID before you use the container ID for the `ibmcloud cs va` command. For example, `1a11a1aa2b2b22223333c44444ccc555667d7dd777888e8ef99f1011121314g15`.

--extended

Extend the command output to show more fix information for vulnerable packages. This value is optional.

By default, the scan results show the ID, policy status, affected packages, and how to resolve. With the `--extended` flag, it adds information such as the summary, vendor security notice, and official notice link.

--vulnerabilities

Restrict the command output to show package vulnerabilities only. This value is optional. You cannot use this flag if you use the `--configuration-issues` flag.

--configuration-issues

Restrict the command output to show configuration issues only. This value is optional. You cannot use this flag if you use the `--vulnerabilities` flag.

--json

Prints the command output in JSON format. This value is optional.

Example:

ibmcloud cs va 1a11a1aa2b2b22223333c44444ccc555667d7dd777888e8ef99f1011121314g15 --extended --vulnerabilities --json

{: pre}

ibmcloud cs webhook-create --cluster CLUSTER --level LEVEL --type slack --url URL [-s]

{: #cs_webhook_create}

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--level LEVEL: The notification level, such as Normal or Warning. Warning is the default value. This value is optional.
--type slack: The webhook type. Currently slack is supported. This value is required.
--url URL: The URL for the webhook. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs webhook-create --cluster my_cluster --level Normal --type slack --url http://github.com/mywebhook

{: pre}

Cluster commands: Subnets

{: #cluster_subnets_commands}

ibmcloud cs cluster-subnet-add CLUSTER SUBNET [-s]

{: #cs_cluster_subnet_add}

You can add existing portable public or private subnets from your IBM Cloud infrastructure (SoftLayer) account to your Kubernetes cluster or reuse subnets from a deleted cluster instead of using the automatically provisioned subnets.

Note:

Portable public IP addresses are charged monthly. If you remove portable public IP addresses after your cluster is provisioned, you still must pay the monthly charge, even if you used them only for a short amount of time.
When you make a subnet available to a cluster, IP addresses of this subnet are used for cluster networking purposes. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of {{site.data.keyword.containershort_notm}} at the same time.
To route between subnets on the same VLAN, you must turn on VLAN spanning.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
SUBNET: The ID of the subnet. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs cluster-subnet-add my_cluster 1643389

{: pre}

ibmcloud cs cluster-subnet-create CLUSTER SIZE VLAN_ID [-s]

{: #cs_cluster_subnet_create}

Create a subnet in an IBM Cloud infrastructure (SoftLayer) account and make it available to a specified cluster in {{site.data.keyword.containershort_notm}}.

Note:

When you make a subnet available to a cluster, IP addresses of this subnet are used for cluster networking purposes. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of {{site.data.keyword.containershort_notm}} at the same time.
To route between subnets on the same VLAN, you must turn on VLAN spanning.

Command options:

CLUSTER: The name or ID of the cluster. This value is required. To list your clusters, use the `ibmcloud cs clusters` [command](#cs_clusters).
SIZE: The number of subnet IP addresses. This value is required. Possible values are 8, 16, 32, or 64.
VLAN_ID: The VLAN in which to create the subnet. This value is required. To list available VLANS, use the `ibmcloud cs vlans ` [command](#cs_vlans). The subnet is provisioned in the same zone that the VLAN is in.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs cluster-subnet-create my_cluster 8 1764905

{: pre}

ibmcloud cs cluster-user-subnet-add CLUSTER SUBNET_CIDR PRIVATE_VLAN

{: #cs_cluster_user_subnet_add}

Bring your own private subnet to your {{site.data.keyword.containershort_notm}} clusters.

This private subnet is not one provided by IBM Cloud infrastructure (SoftLayer). As such, you must configure any inbound and outbound network traffic routing for the subnet. To add an IBM Cloud infrastructure (SoftLayer) subnet, use the ibmcloud cs cluster-subnet-add command.

Note:

When you add a private user subnet to a cluster, IP addresses of this subnet are used for private Load Balancers in the cluster. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of {{site.data.keyword.containershort_notm}} at the same time.
To route between subnets on the same VLAN, you must turn on VLAN spanning.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
SUBNET_CIDR: The subnet Classless InterDomain Routing (CIDR). This value is required, and must not conflict with any subnet that is used by IBM Cloud infrastructure (SoftLayer).
Supported prefixes range from /30 (1 IP address) to /24 (253 IP addresses). If you set the CIDR at one prefix length and later need to change it, first add the new CIDR, then remove the old CIDR.
PRIVATE_VLAN: The ID of the private VLAN. This value is required. It must match the private VLAN ID of one or more of the worker nodes in the cluster.

Example:

ibmcloud cs cluster-user-subnet-add my_cluster 169.xx.xxx.xxx/29 1502175

{: pre}

ibmcloud cs cluster-user-subnet-rm CLUSTER SUBNET_CIDR PRIVATE_VLAN

{: #cs_cluster_user_subnet_rm}

Remove your own private subnet from a specified cluster.

Note: Any service that was deployed to an IP address from your own private subnet remains active after the subnet is removed.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
SUBNET_CIDR: The subnet Classless InterDomain Routing (CIDR). This value is required, and must match the CIDR that was set by the `ibmcloud cs cluster-user-subnet-add` [command](#cs_cluster_user_subnet_add).
PRIVATE_VLAN: The ID of the private VLAN. This value is required, and must match the VLAN ID that was set by the `ibmcloud cs cluster-user-subnet-add` [command](#cs_cluster_user_subnet_add).

Example:

ibmcloud cs cluster-user-subnet-rm my_cluster 169.xx.xxx.xxx/29 1502175

{: pre}

ibmcloud cs subnets [--json] [-s]

{: #cs_subnets}

View a list of subnets that are available in an IBM Cloud infrastructure (SoftLayer) account.

Command options:

--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs subnets

{: pre}

Ingress application load balancer (ALB) commands

{: #alb_commands}

ibmcloud cs alb-cert-deploy [--update] --cluster CLUSTER --secret-name SECRET_NAME --cert-crn CERTIFICATE_CRN [-s]

{: #cs_alb_cert_deploy}

Deploy or update a certificate from your {{site.data.keyword.cloudcerts_long_notm}} instance to the ALB in a cluster.

Note:

Only a user with the Administrator access role can execute this command.
You can only update certificates that are imported from the same {{site.data.keyword.cloudcerts_long_notm}} instance.

Command options

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--update: Update the certificate for an ALB secret in a cluster. This value is optional.
--secret-name SECRET_NAME: The name of the ALB secret. This value is required.
--cert-crn CERTIFICATE_CRN: The certificate CRN. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Examples:

Example for deploying an ALB secret:

ibmcloud cs alb-cert-deploy --secret-name my_alb_secret --cluster my_cluster --cert-crn crn:v1:staging:public:cloudcerts:us-south:a/06580c923e40314421d3b6cb40c01c68:0db4351b-0ee1-479d-af37-56a4da9ef30f:certificate:4bc35b7e0badb304e60aef00947ae7ff

{: pre}

Example for updating an existing ALB secret:

ibmcloud cs alb-cert-deploy --update --secret-name my_alb_secret --cluster my_cluster --cert-crn crn:v1:staging:public:cloudcerts:us-south:a/06580c923e40314421d3b6cb40c01c68:0db4351b-0ee1-479d-af37-56a4da9ef30f:certificate:7e21fde8ee84a96d29240327daee3eb2

{: pre}

ibmcloud cs alb-cert-get --cluster CLUSTER [--secret-name SECRET_NAME] [--cert-crn CERTIFICATE_CRN] [--json] [-s]

{: #cs_alb_cert_get}

View information about an ALB secret in a cluster.

Note: Only a user with the Administrator access role can execute this command.

Command options

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--secret-name SECRET_NAME: The name of the ALB secret. This value is required to get information on a specific ALB secret in the cluster.
--cert-crn CERTIFICATE_CRN: The certificate CRN. This value is required to get information on all ALB secrets matching a specific certificate CRN in the cluster.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Examples:

Example for fetching information on an ALB secret:

ibmcloud cs alb-cert-get --cluster my_cluster --secret-name my_alb_secret

{: pre}

Example for fetching information on all ALB secrets that match a specified certificate CRN:

ibmcloud cs alb-cert-get --cluster my_cluster --cert-crn  crn:v1:staging:public:cloudcerts:us-south:a/06580c923e40314421d3b6cb40c01c68:0db4351b-0ee1-479d-af37-56a4da9ef30f:certificate:4bc35b7e0badb304e60aef00947ae7ff

{: pre}

ibmcloud cs alb-cert-rm --cluster CLUSTER [--secret-name SECRET_NAME] [--cert-crn CERTIFICATE_CRN] [-s]

{: #cs_alb_cert_rm}

Remove an ALB secret in a cluster.

Note: Only a user with the Administrator access role can execute this command.

Command options

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--secret-name SECRET_NAME: The name of the ALB secret. This value is required to remove a specific ALB secret in the cluster.
--cert-crn CERTIFICATE_CRN: The certificate CRN. This value is required to remove all ALB secrets matching a specific certificate CRN in the cluster.
-s: Do not show the message of the day or update reminders. This value is optional.

Examples:

Example for removing an ALB secret:

ibmcloud cs alb-cert-rm --cluster my_cluster --secret-name my_alb_secret

{: pre}

Example for removing all ALB secrets that match a specified certificate CRN:

ibmcloud cs alb-cert-rm --cluster my_cluster --cert-crn crn:v1:staging:public:cloudcerts:us-south:a/06580c923e40314421d3b6cb40c01c68:0db4351b-0ee1-479d-af37-56a4da9ef30f:certificate:4bc35b7e0badb304e60aef00947ae7ff

{: pre}

ibmcloud cs alb-certs --cluster CLUSTER [--json] [-s]

{: #cs_alb_certs}

View a list of ALB secrets in a cluster.

Note: Only users with the Administrator access role can execute this command.

Command options

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs alb-certs --cluster my_cluster

{: pre}

ibmcloud cs alb-configure --albID ALB_ID [--enable][--disable][--user-ip USERIP] [-s]

{: #cs_alb_configure}

Enable or disable an ALB in your standard cluster. The public ALB is enabled by default.

Command options:

--albID ALB_ID

The ID for an ALB. Run ibmcloud cs albs --cluster CLUSTER to view the IDs for the ALBs in a cluster. This value is required.

--enable

Include this flag to enable an ALB in a cluster.

--disable

Include this flag to disable an ALB in a cluster.

--user-ip USER_IP

This parameter is available for enabling a private ALB only.
The private ALB is deployed with an IP address from a user-provided private subnet. If no IP address is provided, the ALB is deployed with a private IP address from the portable private subnet that was provisioned automatically when you created the cluster.

-s

Do not show the message of the day or update reminders. This value is optional.

Examples:

Example for enabling an ALB:

ibmcloud cs alb-configure --albID private-cr18a61a63a6a94b658596aa93a087aaa9-alb1 --enable

{: pre}

Example for enabling an ALB with a user-provided IP address:

ibmcloud cs alb-configure --albID private-cr18a61a63a6a94b658596aa93a087aaa9-alb1 --enable --user-ip user_ip

{: pre}

Example for disabling an ALB:

ibmcloud cs alb-configure --albID public-cr18a61a63a6a94b658596aa93a087aaa9-alb1 --disable

{: pre}

ibmcloud cs alb-get --albID ALB_ID [--json] [-s]

{: #cs_alb_get}

View the details of an ALB.

Command options:

--albID ALB_ID: The ID for an ALB. Run ibmcloud cs albs --cluster CLUSTER to view the IDs for the ALBs in a cluster. This value is required.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs alb-get --albID public-cr18a61a63a6a94b658596aa93a087aaa9-alb1

{: pre}

ibmcloud cs alb-types [--json] [-s]

{: #cs_alb_types}

View the ALB types that are supported in the region.

Command options:

--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs alb-types

{: pre}

ibmcloud cs albs --cluster CLUSTER [--json] [-s]

{: #cs_albs}

View the status of all ALBs in a cluster. If no ALB IDs are returned, then the cluster does not have a portable subnet. You can create or add subnets to a cluster.

Command options:

--cluster CLUSTER: The name or ID of the cluster where you list available ALBs. This value is required.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs albs --cluster my_cluster

{: pre}

Infrastructure commands

{: #infrastructure_commands}

ibmcloud cs credentials-set --infrastructure-api-key API_KEY --infrastructure-username USERNAME [-s]

{: #cs_credentials_set}

Set IBM Cloud infrastructure (SoftLayer) account credentials for your {{site.data.keyword.containershort_notm}} account.

If you have an {{site.data.keyword.Bluemix_notm}} Pay-As-You-Go account, you have access to the IBM Cloud infrastructure (SoftLayer) portfolio by default. However, you might want to use a different IBM Cloud infrastructure (SoftLayer) account that you already have to order infrastructure. You can link this infrastructure account to your {{site.data.keyword.Bluemix_notm}} account by using this command.

If IBM Cloud infrastructure (SoftLayer) credentials are manually set, these credentials are used to order infrastructure, even if an IAM API key already exists for the account. If the user whose credentials are stored does not have the required permissions to order infrastructure, then infrastructure-related actions, such as creating a cluster or reloading a worker node can fail.

You cannot set multiple credentials for one {{site.data.keyword.containershort_notm}} account. Every {{site.data.keyword.containershort_notm}} account is linked to one IBM Cloud infrastructure (SoftLayer) portfolio only.

Important: Before you use this command, make sure that the user whose credentials are used has the required {{site.data.keyword.containershort_notm}} and IBM Cloud infrastructure (SoftLayer) permissions.

Command options:

--infrastructure-username USERNAME

IBM Cloud infrastructure (SoftLayer) account API username. This value is required. **Note**: The infrastructure API username is not the same as the IBMid. To view the infrastructure API username:

Log in to the [{{site.data.keyword.Bluemix_notm}} portal ![External link icon](../icons/launch-glyph.svg "External link icon")](https://console.bluemix.net/).
From the expanding menu, select **Infrastructure**.
From the menu bar, select **Account** > **Users** > **User List**.
For the user that you want to view, click the **IBMid or Username**.
In the **API Access Information** section, view the **API Username**.

--infrastructure-api-key API_KEY

IBM Cloud infrastructure (SoftLayer) account API key. This value is required.

To generate an API key:

Log in to the [IBM Cloud infrastructure (SoftLayer) portal ![External link icon](../icons/launch-glyph.svg "External link icon")](https://control.bluemix.net/).
Select Account, and then Users.
Click Generate to generate an IBM Cloud infrastructure (SoftLayer) API key for your account.
Copy the API key to use in this command.

To view your existing API key:

Log in to the [IBM Cloud infrastructure (SoftLayer)portal ![External link icon](../icons/launch-glyph.svg "External link icon")](https://control.bluemix.net/).
Select Account, and then Users.
Click View to see your existing API key.
Copy the API key to use in this command.

-s

Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs credentials-set --infrastructure-api-key <api_key> --infrastructure-username dbmanager

{: pre}

ibmcloud cs credentials-unset

{: #cs_credentials_unset}

Remove IBM Cloud infrastructure (SoftLayer) account credentials from your {{site.data.keyword.containershort_notm}} account.

After you remove the credentials, the IAM API key is used to order resources in IBM Cloud infrastructure (SoftLayer).

Command options:

-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs credentials-unset

{: pre}

ibmcloud cs machine-types ZONE [--json] [-s]

{: #cs_machine_types}

View a list of available machine types for your worker nodes. Machine types vary by zone. Each machine type includes the amount of virtual CPU, memory, and disk space for each worker node in the cluster. By default, the secondary storage disk directory where all container data is stored, is encrypted with LUKS encryption. If the disable-disk-encrypt option is included during cluster creation, then the host's Docker data is not encrypted. Learn more about the ecryption. {:shortdesc}

You can provision your worker node as a virtual machine on shared or dedicated hardware, or as a physical machine on bare metal. Learn more about your machine type options.

Command options:

ZONE: Enter the zone where you want to list available machine types. This value is required. Review [available zones](cs_regions.html#zones).
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example command:

ibmcloud cs machine-types dal10

{: pre}

ibmcloud cs vlans ZONE [--all] [--json] [-s]

{: #cs_vlans}

List the public and private VLANs that are available for a zone in your IBM Cloud infrastructure (SoftLayer) account. To list available VLANs, you must have a paid account.

Command options:

ZONE: Enter the zone where you want to list your private and public VLANs. This value is required. Review [available zones](cs_regions.html#zones).
--all: Lists all available VLANs. By default VLANs are filtered to show only those VLANS that are valid. To be valid, a VLAN must be associated with infrastructure that can host a worker with local disk storage.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs vlans dal10

{: pre}

Logging commands

{: #logging_commands}

ibmcloud cs logging-config-create CLUSTER --logsource LOG_SOURCE --type LOG_TYPE [--namespace KUBERNETES_NAMESPACE] [--hostname LOG_SERVER_HOSTNAME_OR_IP] [--port LOG_SERVER_PORT] [--space CLUSTER_SPACE] [--org CLUSTER_ORG] [--app-containers CONTAINERS] [--app-paths PATHS_TO_LOGS] [--syslog-protocol PROTOCOL] [--json] [--skip-validation] [-s]

{: #cs_logging_create}

Create a logging configuration. You can use this command to forward logs for containers, applications, worker nodes, Kubernetes clusters, and Ingress application load balancers to {{site.data.keyword.loganalysisshort_notm}} or to an external syslog server.

Command options:

CLUSTER: The name or ID of the cluster.
--logsource LOG_SOURCE: The log source to enable log forwarding for. This argument supports a comma-separated list of log sources to apply the configuration for. Accepted values are container, application, worker, kubernetes, and ingress, and kube-audit. If you do not provide a log source, configurations are created for container and ingress.
--type LOG_TYPE: Where you want to forward your logs. Options are ibm, which forwards your logs to {{site.data.keyword.loganalysisshort_notm}} and syslog, which forwards your logs to an external server.
--namespace KUBERNETES_NAMESPACE: The Kubernetes namespace that you want to forward logs from. Log forwarding is not supported for the ibm-system and kube-system Kubernetes namespaces. This value is valid only for the container log source and is optional. If you do not specify a namespace, then all namespaces in the cluster use this configuration.
--hostname LOG_SERVER_HOSTNAME: When the logging type is syslog, the hostname or IP address of the log collector server. This value is required for syslog. When the logging type is ibm, the {{site.data.keyword.loganalysislong_notm}} ingestion URL. You can find the list of available ingestion URLs [here](/docs/services/CloudLogAnalysis/log_ingestion.html#log_ingestion_urls). If you do not specify an ingestion URL, the endpoint for the region where your cluster was created is used.
--port LOG_SERVER_PORT: The port of the log collector server. This value is optional. If you do not specify a port, then the standard port 514 is used for syslog and the standard port 9091 is used for ibm.
--space CLUSTER_SPACE: The name of the Cloud Foundry space that you want to send logs to. This value is valid only for log type ibm and is optional. If you do not specify a space, logs are sent to the account level.
--org CLUSTER_ORG: The name of the Cloud Foundry org that the space is in. This value is valid only for log type ibm and is required if you specified a space.
--app-paths: The path on the container that the apps are logging to. To forward logs with source type application, you must provide a path. To specify more than one path, use a comma-separated list. This value is required for log source application. Example: /var/log/myApp1/*,/var/log/myApp2/*
--syslog-protocol: The transfer layer protocol that is used when the logging type is syslog. Supported values are tcp and the default udp. When forwarding to an rsyslog server with the udp protocol, logs that are over 1KB are truncated.
--app-containers: To forward logs from apps, you can specify the name of the container that contains your app. You can specify more than one container by using a comma-separated list. If no containers are specified, logs are forwarded from all of the containers that contain the paths that you provided. This option is only valid for log source application.
--json: Prints the command output in JSON format. This value is optional.
--skip-validation: Skip validation of the org and space names when they are specified. Skipping validation decreases processing time, but an invalid logging configuration does not correctly forward logs. This value is optional.

Examples:

Example for log type ibm that forwards from a container log source on default port 9091:

ibmcloud cs logging-config-create my_cluster --logsource container --namespace my_namespace --hostname ingest.logging.ng.bluemix.net --type ibm

{: pre}

Example for log type syslog that forwards from a container log source on default port 514:

ibmcloud cs logging-config-create my_cluster --logsource container --namespace my_namespace  --hostname 169.xx.xxx.xxx --type syslog

{: pre}

Example for log type syslog that forwards logs from an ingress source on a port different than the default:

ibmcloud cs logging-config-create my_cluster --logsource container --hostname 169.xx.xxx.xxx --port 5514 --type syslog

{: pre}

ibmcloud cs logging-config-get CLUSTER [--logsource LOG_SOURCE] [--json] [-s]

{: #cs_logging_get}

View all log forwarding configurations for a cluster, or filter logging configurations based on log source.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--logsource LOG_SOURCE: The kind of log source for which you want to filter. Only logging configurations of this log source in the cluster are returned. Accepted values are container, application, worker, kubernetes, ingress, and kube-audit. This value is optional.
--show-covering-filters: Shows the logging filters that render previous filters obsolete.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs logging-config-get my_cluster --logsource worker

{: pre}

ibmcloud cs logging-config-refresh CLUSTER [-s]

{: #cs_logging_refresh}

Refresh the logging configuration for the cluster. This refreshes the logging token for any logging configuration that is forwarding to the space level in your cluster.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs logging-config-refresh my_cluster

{: pre}

ibmcloud cs logging-config-rm CLUSTER [--id LOG_CONFIG_ID] [--all] [-s]

{: #cs_logging_rm}

Delete one log forwarding configuration or all logging configurations for a cluster. This stops log forwarding to a remote syslog server or to {{site.data.keyword.loganalysisshort_notm}}.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--id LOG_CONFIG_ID: If you want to remove a single logging configuration, the logging configuration ID.
--all: The flag to remove all logging configurations in a cluster.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs logging-config-rm my_cluster --id f4bc77c0-ee7d-422d-aabf-a4e6b977264e

{: pre}

ibmcloud cs logging-config-update CLUSTER --id LOG_CONFIG_ID --type LOG_TYPE [--namespace NAMESPACE] [--hostname LOG_SERVER_HOSTNAME_OR_IP] [--port LOG_SERVER_PORT] [--space CLUSTER_SPACE] [--org CLUSTER_ORG] [--app-paths PATH] [--app-containers PATH] [--json] [--skipValidation] [-s]

{: #cs_logging_update}

Update the details of a log forwarding configuration.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--id LOG_CONFIG_ID: The logging configuration ID that you want to update. This value is required.
--type LOG_TYPE: The log forwarding protocol that you want to use. Currently, syslog and ibm are supported. This value is required.
--namespace NAMESPACE: The Kubernetes namespace that you want to forward logs from. Log forwarding is not supported for the ibm-system and kube-system Kubernetes namespaces. This value is valid only for the container log source. If you do not specify a namespace, then all namespaces in the cluster use this configuration.
--hostname LOG_SERVER_HOSTNAME: When the logging type is syslog, the hostname or IP address of the log collector server. This value is required for syslog. When the logging type is ibm, the {{site.data.keyword.loganalysislong_notm}} ingestion URL. You can find the list of available ingestion URLs [here](/docs/services/CloudLogAnalysis/log_ingestion.html#log_ingestion_urls). If you do not specify an ingestion URL, the endpoint for the region where your cluster was created is used.
--port LOG_SERVER_PORT: The port of the log collector server. This value is optional when the logging type is syslog. If you do not specify a port, then the standard port 514 is used for syslog and 9091 is used for ibm.
--space CLUSTER_SPACE: The name of the space that you want to send logs to. This value is valid only for log type ibm and is optional. If you do not specify a space, logs are sent to the account level.
--org CLUSTER_ORG: The name of the org that the space is in. This value is valid only for log type ibm and is required if you specified a space.
--app-paths PATH,PATH: An absolute file path in the container to collect logs from. Wildcards, such as '/var/log/*.log', can be used, but recursive globs, such as '/var/log/**/test.log', cannot be used. To specify more than one path, use a comma separated list. This value is required when you specify 'application' for the log source.
--app-containers PATH,PATH: The path on the containers that the apps are logging to. To forward logs with source type application, you must provide a path. To specify more than one path, use a comma separated list. Example: /var/log/myApp1/*,/var/log/myApp2/*
--json: Prints the command output in JSON format. This value is optional.
--skipValidation: Skip validation of the org and space names when they are specified. Skipping validation decreases processing time, but an invalid logging configuration does not correctly forward logs. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example for log type ibm:

ibmcloud cs logging-config-update my_cluster --id f4bc77c0-ee7d-422d-aabf-a4e6b977264e --type ibm

{: pre}

Example for log type syslog:

ibmcloud cs logging-config-update my_cluster --id f4bc77c0-ee7d-422d-aabf-a4e6b977264e --hostname localhost --port 5514 --type syslog

{: pre}

ibmcloud cs logging-filter-create CLUSTER --type LOG_TYPE [--logging-configs CONFIGS] [--namespace KUBERNETES_NAMESPACE] [--container CONTAINER_NAME] [--level LOGGING_LEVEL] [--regex-message MESSAGE] [--json] [-s]

{: #cs_log_filter_create}

Create a logging filter. You can use this command to filter out logs that are forwarded by your logging configuration.

Command options:

CLUSTER: The name or ID of the cluster that you want to create a logging filter for. This value is required.
--type LOG_TYPE: The type of logs that you want to apply the filter to. Currently all, container, and host are supported.
--logging-configs CONFIGS: A comma separated list of your logging configuration IDs. If not provided, the filter is applied to all of the cluster logging configurations that are passed to the filter. You can view log configurations that match the filter by using the --show-matching-configs flag with the command. This value is optional.
--namespace KUBERNETES_NAMESPACE: The Kubernetes namespace from which you want to filter logs. This value is optional.
--container CONTAINER_NAME: The name of the container from which you want to filter out logs. This flag applies only when you are using log type container. This value is optional.
--level LOGGING_LEVEL: Filters out logs that are at the specified level and less. Acceptable values in their canonical order are fatal, error, warn/warning, info, debug, and trace. This value is optional. As an example, if you filtered logs at the info level, debug, and trace are also filtered. **Note**: You can use this flag only when log messages are in JSON format and contain a level field. Example output: {"log": "hello", "level": "info"}
--regex-message MESSAGE: Filters out any logs that contain a specified message that is written as a regular expression anywhere in the log. This value is optional.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Examples:

This example filters out all logs that are forwarded from containers with the name test-container in the default namespace that are at the debug level or less, and have a log message that contains "GET request".

ibmcloud cs logging-filter-create example-cluster --type container --namespace default --container test-container --level debug --message "GET request"

{: pre}

This example filters out all of the logs that are forwarded, at an info level or less, from a specific cluster. The output is returned as JSON.

ibmcloud cs logging-filter-create example-cluster --type all --level info --json

{: pre}

ibmcloud cs logging-filter-get CLUSTER [--id FILTER_ID] [--show-matching-configs] [--show-covering-filters] [--json] [-s]

{: #cs_log_filter_view}

View a logging filter configuration. You can use this command to view the logging filters that you created.

Command options:

CLUSTER: The name or ID of the cluster that you want to view filters from. This value is required.
--id FILTER_ID: The ID of the log filter that you want to view.
--show-matching-configs: Show the logging configurations that match the configuration that you're viewing. This value is optional.
--show-covering-filters: Show the logging filters that render previous filters obsolete. This value is optional.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

ibmcloud cs logging-filter-rm CLUSTER [--id FILTER_ID] [--all] [-s]

{: #cs_log_filter_delete}

Delete a logging filter. You can use this command to remove a logging filter that you created.

Command options:

CLUSTER: The name or ID of the cluster that you want to delete a filter from.
--id FILTER_ID: The ID of the log filter to delete.
--all: Delete all of your log forwarding filters. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

ibmcloud cs logging-filter-update CLUSTER --id FILTER_ID --type LOG_TYPE [--logging-configs CONFIGS] [--namespace KUBERNETES_NAMESPACE] [--container CONTAINER_NAME] [--level LOGGING_LEVEL] [--message MESSAGE] [--json] [-s]

{: #cs_log_filter_update}

Update a logging filter. You can use this command to update a logging filter that you created.

Command options:

CLUSTER: The name or ID of the cluster that you want to update a logging filter for. This value is required.
--id FILTER_ID: The ID of the log filter to update.
--type LOG_TYPE: The type of logs that you want to apply the filter to. Currently all, container, and host are supported.
--logging-configs CONFIGS: A comma separated list of your logging configuration IDs. If not provided, the filter is applied to all of the cluster logging configurations that are passed to the filter. You can view log configurations that match the filter by using the --show-matching-configs flag with the command. This value is optional.
--namespace KUBERNETES_NAMESPACE: The Kubernetes namespace from which you want to filter logs. This value is optional.
--container CONTAINER_NAME: The name of the container from which you want to filter out logs. This flag applies only when you are using log type container. This value is optional.
--level LOGGING_LEVEL: Filters out logs that are at the specified level and less. Acceptable values in their canonical order are fatal, error, warn/warning, info, debug, and trace. This value is optional. As an example, if you filtered logs at the info level, debug, and trace are also filtered. **Note**: You can use this flag only when log messages are in JSON format and contain a level field. Example output: {"log": "hello", "level": "info"}
--message MESSAGE: Filters out any logs that contain a specified message anywhere in the log. The message is matched literally and not as an expression. Example: The messages “Hello”, “!”, and “Hello, World!”, would apply to the log “Hello, World!”. This value is optional.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Region commands

{: #region_commands}

ibmcloud cs zones [--json] [-s]

{: #cs_datacenters}

View a list of available zones for you to create a cluster in. The available zones vary by the region that you are logged in to. To switch regions, run ibmcloud cs region-set.

Command options:

--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs zones

{: pre}

ibmcloud cs region

{: #cs_region}

Find the {{site.data.keyword.containershort_notm}} region that you are currently in. You create and manage clusters specific to the region. Use the ibmcloud cs region-set command to change regions.

Example:

ibmcloud cs region

{: pre}

Output:

Region: us-south

{: screen}

ibmcloud cs region-set [REGION]

{: #cs_region-set}

Set the region for {{site.data.keyword.containershort_notm}}. You create and manage clusters specific to the region, and you might want clusters in multiple regions for high availability.

For example, you can log in to {{site.data.keyword.Bluemix_notm}} in the US South region and create a cluster. Next, you can use ibmcloud cs region-set eu-central to target the EU Central region and create another cluster. Finally, you can use ibmcloud cs region-set us-south to return to US South to manage your cluster in that region.

Command options:

REGION: Enter the region that you want to target. This value is optional. If you do not provide the region, you can select it from the list in the output.
For a list of available regions, review regions and zones or use the ibmcloud cs regions command.

Example:

ibmcloud cs region-set eu-central

{: pre}

ibmcloud cs region-set

{: pre}

Output:

Choose a region:
1. ap-north
2. ap-south
3. eu-central
4. uk-south
5. us-east
6. us-south
Enter a number> 3
OK

{: screen}

ibmcloud cs regions

{: #cs_regions}

Lists the available regions. The Region Name is the {{site.data.keyword.containershort_notm}} name, and the Region Alias is the general {{site.data.keyword.Bluemix_notm}} name for the region.

Example:

ibmcloud cs regions

{: pre}

Output:

Region Name   Region Alias
ap-north      jp-tok
ap-south      au-syd
eu-central    eu-de
uk-south      eu-gb
us-east       us-east
us-south      us-south

{: screen}

Worker node commands

{: worker_node_commands}

Deprecated: ibmcloud cs worker-add --cluster CLUSTER [--file FILE_LOCATION] [--hardware HARDWARE] --machine-type MACHINE_TYPE --workers NUMBER --private-vlan PRIVATE_VLAN --public-vlan PUBLIC_VLAN [--disable-disk-encrypt] [-s]

{: #cs_worker_add}

Add standalone worker nodes to your standard cluster that are not in a worker pool.

Command options:

--cluster CLUSTER

The name or ID of the cluster. This value is required.

--file FILE_LOCATION

The path to the YAML file to add worker nodes to the cluster. Instead of defining additional worker nodes by using the options provided in this command, you can use a YAML file. This value is optional.

Note: If you provide the same option in the command as the parameter in the YAML file, the value in the command takes precedence over the value in the YAML. For example, you define a machine type in your YAML file and use the --machine-type option in the command, the value that you entered in the command option overrides the value in the YAML file.

name: <cluster_name_or_ID>
zone: <zone>
machine-type: <machine_type>
private-vlan: <private_VLAN>
public-vlan: <public_VLAN>
hardware: <shared_or_dedicated>
workerNum: <number_workers>
diskEncryption: false

Understanding the YAML file components

Understanding the YAML file components
`name`	Replace `<cluster_name_or_ID>` with the name or ID of the cluster where you want to add worker nodes.
`zone`	Replace `<zone>` with the zone to deploy your worker nodes. The available zones are dependent on the region that you are logged in. To list available zones, run `ibmcloud cs zones`.
`machine-type`	Replace `<machine_type>` with the type of machine that you want to deploy your worker nodes to. You can deploy your worker nodes as virtual machines on shared or dedicated hardware, or as physical machines on bare metal. Available physical and virtual machines types vary by the zone in which you deploy the cluster. For more information, see the `ibmcloud cs machine-types` [command](cs_cli_reference.html#cs_machine_types).
`private-vlan`	Replace `<private_VLAN>` with the ID of the private VLAN that you want to use for your worker nodes. To list available VLANs, run `ibmcloud cs vlans <zone>` and look for VLAN routers that start with `bcr` (back-end router).
`public-vlan`	Replace `<public_VLAN>` with the ID of the public VLAN that you want to use for your worker nodes. To list available VLANs, run `ibmcloud cs vlans <zone>` and look for VLAN routers that start with `fcr` (front-end router). Note: {[private_VLAN_vyatta]}
`hardware`	For virtual machine types: The level of hardware isolation for your worker node. Use dedicated if you want to have available physical resources dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared.
`workerNum`	Replace `<number_workers>` with the number of worker nodes that you want to deploy.
`diskEncryption: false`	Worker nodes feature disk encryption by default; [learn more](cs_secure.html#encrypted_disk). To disable encryption, include this option and set the value to `false`.

--hardware HARDWARE

The level of hardware isolation for your worker node. Use dedicated if you want to have available physical resources dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. This value is optional.

--machine-type MACHINE_TYPE

--workers NUMBER

An integer that represents the number of worker nodes to create in the cluster. The default value is 1. This value is optional.

--private-vlan PRIVATE_VLAN

The private VLAN that was specified when the cluster was created. This value is required.

Note: Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When creating a cluster and specifying the public and private VLANs, the number and letter combination after those prefixes must match.

--public-vlan PUBLIC_VLAN

The public VLAN that was specified when the cluster was created. This value is optional. If you want your worker nodes to exist on a private VLAN only, do not provide a public VLAN ID. Note: {[private_VLAN_vyatta]}

--disable-disk-encrypt

Worker nodes feature disk encryption by default; [learn more](cs_secure.html#encrypted_disk). To disable encryption, include this option.

-s

Do not show the message of the day or update reminders. This value is optional.

Examples:

ibmcloud cs worker-add --cluster my_cluster --number 3 --public-vlan my_public_VLAN_ID --private-vlan my_private_VLAN_ID --machine-type b2c.4x16 --hardware shared

{: pre}

Example for {{site.data.keyword.Bluemix_dedicated_notm}}:

ibmcloud cs worker-add --cluster my_cluster --number 3 --machine-type b2c.4x16

{: pre}

ibmcloud cs worker-get [CLUSTER_NAME_OR_ID] WORKER_NODE_ID [--json] [-s]

{: #cs_worker_get}

View the details of a worker node.

Command options:

CLUSTER_NAME_OR_ID: The name or ID of the worker node's cluster. This value is optional.
WORKER_NODE_ID: The name of your worker node. Run ibmcloud cs workers CLUSTER to view the IDs for the worker nodes in a cluster. This value is required.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example command:

ibmcloud cs worker-get my_cluster kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1

{: pre}

Example output:

ID:           kube-dal10-123456789-w1
State:        normal
Status:       Ready
Trust:        disabled
Private VLAN: 223xxxx
Public VLAN:  223xxxx
Private IP:   10.xxx.xx.xxx
Public IP:    169.xx.xxx.xxx
Hardware:     shared
Zone:         dal10
Version:      1.8.11_1509

{: screen}

ibmcloud cs worker-reboot [-f] [--hard] CLUSTER WORKER [WORKER] [-s]

{: #cs_worker_reboot}

Reboot a worker node in a cluster. During the reboot, the state of your worker node does not change.

Attention: Rebooting a worker node can cause data corruption on the worker node. Use this command with caution and when you know that a reboot can help recover your worker node. In all other cases, reload your worker node instead.

Before you reboot your worker node, make sure that pods are rescheduled on other worker nodes to help avoid a downtime for your app or data corruption on your worker node.

List all worker nodes in your cluster and note the name of the worker node that you want to reboot.
```
kubectl get nodes
```
Thename that is returned in this command is the private IP address that is assigned to your worker node. You can find more information about your worker node when you run the ibmcloud cs workers <cluster_name_or_ID> command and look for the worker node with the same Private IP address.
Mark the worker node as unschedulable in a process that is known as cordoning. When you cordon a worker node, you make it unavailable for future pod scheduling. Use the name of the worker node that you retrieved in the previous step.
```
kubectl cordon <worker_name>
```
{: pre}
Verify that pod scheduling is disabled for your worker node.
```
kubectl get nodes
```
{: pre} Your worker node is disabled for pod scheduling if the status displays SchedulingDisabled.
Force pods to be removed from your worker node and rescheduled onto remaining worker nodes in the cluster.
```
kubectl drain <worker_name>
```
{: pre} This process can take a few minutes.
Reboot the worker node. Use the worker ID that is returned from the ibmcloud cs workers <cluster_name_or_ID> command.
```
ibmcloud cs worker-reboot <cluster_name_or_ID> <worker_name_or_ID>
```
{: pre}
Wait about 5 minutes before you make your worker node available for pod scheduling to ensure that the reboot is finished. During the reboot, the state of your worker node does not change. The reboot of a worker node is usually completed in a few seconds.
Make your worker node available for pod scheduling. Use the name for your worker node that is returned from the kubectl get nodes command.
```
kubectl uncordon <worker_name>
```
{: pre}

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the restart of the worker node with no user prompts. This value is optional.
--hard: Use this option to force a hard restart of a worker node by cutting off power to the worker node. Use this option if the worker node is unresponsive or the worker node has a Docker hang. This value is optional.
WORKER: The name or ID of one or more worker nodes. Use a space to list multiple worker nodes. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs worker-reboot my_cluster kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2

{: pre}

ibmcloud cs worker-reload [-f] CLUSTER WORKER [WORKER] [-s]

{: #cs_worker_reload}

Reload all the necessary configurations for a worker node. A reload can be useful if your worker node experiences problems, such as slow performance or if your worker node is stuck in an unhealthy state.

Reloading a worker node applies patch version updates to your worker node, but not major or minor updates. To see the changes from one patch version to the next, review the Version changelog documentation. {: tip}

Before you reload your worker node, make sure that pods are rescheduled on other worker nodes to help avoid a downtime for your app or data corruption on your worker node.

List all worker nodes in your cluster and note the name of the worker node that you want to reload.
```
kubectl get nodes
```
The name that is returned in this command is the private IP address that is assigned to your worker node. You can find more information about your worker node when you run the ibmcloud cs workers <cluster_name_or_ID> command and look for the worker node with the same Private IP address.
Mark the worker node as unschedulable in a process that is known as cordoning. When you cordon a worker node, you make it unavailable for future pod scheduling. Use the name of the worker node that you retrieved in the previous step.
```
kubectl cordon <worker_name>
```
{: pre}
Verify that pod scheduling is disabled for your worker node.
```
kubectl get nodes
```
{: pre} Your worker node is disabled for pod scheduling if the status displays SchedulingDisabled.
Force pods to be removed from your worker node and rescheduled onto remaining worker nodes in the cluster.
```
kubectl drain <worker_name>
```
{: pre} This process can take a few minutes.
Reload the worker node. Use the worker ID that is returned from the ibmcloud cs workers <cluster_name_or_ID> command.
```
ibmcloud cs worker-reload <cluster_name_or_ID> <worker_name_or_ID>
```
{: pre}
Wait for the reload to complete.
Make your worker node available for pod scheduling. Use the name for your worker node that is returned from the kubectl get nodes command.
```
kubectl uncordon <worker_name>
```

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the reload of a worker node with no user prompts. This value is optional.
WORKER: The name or ID of one or more worker nodes. Use a space to list multiple worker nodes. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs worker-reload my_cluster kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2

{: pre}

ibmcloud cs worker-rm [-f] CLUSTER WORKER [WORKER] [-s]

{: #cs_worker_rm}

Remove one or more worker nodes from a cluster. If you remove a worker node, your cluster becomes unbalanced. You can automatically rebalance your worker pool by running the ibmcloud cs worker-pool-rebalance command.

Before you remove your worker node, make sure that pods are rescheduled on other worker nodes to help avoid a downtime for your app or data corruption on your worker node. {: tip}

List all worker nodes in your cluster and note the name of the worker node that you want to remove.
```
kubectl get nodes
```
The name that is returned in this command is the private IP address that is assigned to your worker node. You can find more information about your worker node when you run the ibmcloud cs workers <cluster_name_or_ID> command and look for the worker node with the same Private IP address.
Mark the worker node as unschedulable in a process that is known as cordoning. When you cordon a worker node, you make it unavailable for future pod scheduling. Use the name of the worker node that you retrieved in the previous step.
```
kubectl cordon <worker_name>
```
{: pre}
Verify that pod scheduling is disabled for your worker node.
```
kubectl get nodes
```
{: pre} Your worker node is disabled for pod scheduling if the status displays SchedulingDisabled.
Force pods to be removed from your worker node and rescheduled onto remaining worker nodes in the cluster.
```
kubectl drain <worker_name>
```
{: pre} This process can take a few minutes.
Remove the worker node. Use the worker ID that is returned from the ibmcloud cs workers <cluster_name_or_ID> command.
```
ibmcloud cs worker-rm <cluster_name_or_ID> <worker_name_or_ID>
```
{: pre}

Verify that the worker node is removed.

ibmcloud cs workers <cluster_name_or_ID>

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the removal of a worker node with no user prompts. This value is optional.
WORKER: The name or ID of one or more worker nodes. Use a space to list multiple worker nodes. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs worker-rm my_cluster kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2

{: pre}

ibmcloud cs worker-update [-f] CLUSTER WORKER [WORKER] [--kube-version MAJOR.MINOR.PATCH] [--force-update] [-s]

{: #cs_worker_update}

Update worker nodes to apply the latest security updates and patches to the operating system, and to update the Kubernetes version to match the version of the master node. You can update the master node Kubernetes version with the ibmcloud cs cluster-update command.

Important: Running ibmcloud cs worker-update can cause downtime for your apps and services. During the update, all pods are rescheduled onto other worker nodes and data is deleted if not stored outside the pod. To avoid downtime, ensure that you have enough worker nodes to handle your workload while the selected worker nodes are updating.

You might need to change your YAML files for deployments before updating. Review this release note for details.

Command options:

CLUSTER: The name or ID of the cluster where you list available worker nodes. This value is required.
-f: Use this option to force the update of the master with no user prompts. This value is optional.
--force-update: Attempt the update even if the change is greater than two minor versions. This value is optional.
--kube-version MAJOR.MINOR.PATCH: The version of Kubernetes that you want your worker nodes to be updated with. The default version is used if this value is not specified.
WORKER: The ID of one or more worker nodes. Use a space to list multiple worker nodes. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs worker-update my_cluster kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2

{: pre}

ibmcloud cs workers CLUSTER [--worker-pool] POOL [--show-deleted] [--json] [-s]

{: #cs_workers}

View a list of worker nodes and the status for each in a cluster.

Command options:

CLUSTER: The name or ID of the cluster for the available worker nodes. This value is required.
--worker-pool POOL: View only worker nodes that belong to the worker pool. To list available worker pools, run `ibmcloud cs worker-pools --cluster `. This value is optional.
--show-deleted: View worker nodes that were deleted from the cluster, including the reason for deletion. This value is optional.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs workers my_cluster

{: pre}

Worker pool commands

{: #worker-pool}

ibmcloud cs worker-pool-create --name POOL_NAME --cluster CLUSTER --machine-type MACHINE_TYPE --size-per-zone WORKERS_PER_ZONE [--hardware ISOLATION] [--labels LABELS] [--disable-disk-encrypt]

{: #cs_worker_pool_create}

You can create a worker pool in your cluster. When you add a worker pool, it is not assigned a zone by default. You specify the number of workers that you want in each zone and the machine types for the workers. The worker pool is given the default Kubernetes versions. To finish creating the workers, add a zone or zones to your pool.

Command options:

--name POOL_NAME: The name that you want to give your worker pool.
--cluster CLUSTER: The name or ID of the cluster. This value is required.
--machine-type MACHINE_TYPE: Choose a machine type. You can deploy your worker nodes as virtual machines on shared or dedicated hardware, or as physical machines on bare metal. Available physical and virtual machines types vary by the zone in which you deploy the cluster. For more information, see the documentation for the `ibmcloud cs machine-types` [command](cs_cli_reference.html#cs_machine_types). This value is required for standard clusters and is not available for free clusters.
--size-per-zone WORKERS_PER_ZONE: The number of workers to create in each zone. This value is required.
--hardware HARDWARE: The level of hardware isolation for your worker node. Use dedicated if you want to have available physical resources dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. This value is optional.
--labels LABELS: The labels that you want to assign to the workers in your pool. Example: =,=
--diable-disk-encrpyt: Specifies that the disk is not encrypted. The default value is false.

Example command:

ibmcloud cs worker-pool-create my_cluster --machine-type b2c.4x16 --size-per-zone 6

{: pre}

ibmcloud cs worker-pool-get --worker-pool WORKER_POOL --cluster CLUSTER

{: #cs_worker_pool_get}

View the details of a worker pool.

Command options:

--worker-pool WORKER_POOL: The name of the worker node pool that you want to view the details of. To list available worker pools, run `ibmcloud cs worker-pools --cluster `. This value is required.
--cluster CLUSTER: The name or ID of the cluster where the worker pool is located. This value is required.

Example command:

ibmcloud cs worker-pool-get --worker-pool pool1 --cluster my_cluster

{: pre}

Example output:

Name:               pool   
ID:                 a1a11b2222222bb3c33c3d4d44d555e5-f6f777g   
State:              active   
Hardware:           shared   
Zones:              dal10,dal12   
Workers per zone:   3   
Machine type:       b2c.4x16.encrypted   
Labels:             -   
Version:            1.9.8_1512

{: screen}

ibmcloud cs worker-pool-rebalance --cluster CLUSTER --worker-pool WORKER_POOL [-s]

{: #cs_rebalance}

You can rebalance your worker pool after you delete a worker node. When you run this command a new worker or workers are added to your worker pool.

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--worker-pool WORKER_POOL: The worker pool that you want to rebalance. This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs worker-pool-rebalance --cluster my_cluster --worker-pool my_pool

{: pre}

ibmcloud cs worker-pool-resize --worker-pool WORKER_POOL --cluster CLUSTER --size-per-zone WORKERS_PER_ZONE [-s]

{: #cs_worker_pool_resize}

Resize your worker pool to increase or decrease the number of worker nodes that are in each zone of your cluster. Your worker pool must have at least 1 worker node.

Command options:

--worker-pool WORKER_POOL: The name of the worker node pool that you want to update. This value is required.
--cluster CLUSTER: The name or ID of the cluster for which you want to resize worker pools. This value is required.
--size-per-zone WORKERS_PER_ZONE: The number of workers that you want to have in each zone. This value is required, and must be 1 or greater.
-s: Do not show the message of the day or update reminders. This value is optional.

Example command:

ibmcloud cs worker-pool-resize --cluster my_cluster --worker-pool my_pool --size-per-zone 3

{: pre}

ibmcloud cs worker-pool-rm --worker-pool WORKER_POOL --cluster CLUSTER [--json] [-s]

{: #cs_worker_pool_rm}

Remove a worker pool from your cluster. All worker nodes in the pool are deleted. Your pods are rescheduled when you delete. To avoid downtime, be sure that you have enough workers to run your workload.

Command options:

--worker-pool WORKER_POOL: The name of the worker node pool that you want to remove. This value is required.
--cluster CLUSTER: The name or ID of the cluster that you want to remove the worker pool from. This value is required.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example command:

ibmcloud cs worker-pool-rm --cluster my_cluster --worker-pool pool1

{: pre}

ibmcloud cs worker-pools --cluster CLUSTER [--json] [-s]

{: #cs_worker_pools}

View the worker pools that you have in a cluster.

Command options:

--cluster CLUSTER_NAME_OR_ID: The name or ID of the cluster for which you want to list worker pools. This value is required.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example command:

ibmcloud cs worker-pools --cluster my_cluster

{: pre}

ibmcloud cs zone-add --zone ZONE --cluster CLUSTER --worker-pools WORKER_POOL1,[WORKER_POOL2] --private-vlan PRIVATE_VLAN [--public-vlan PUBLIC_VLAN] [--private-only] [--json] [-s]

{: #cs_zone_add}

Multizone clusters only: After you create a cluster or worker pool, you can add a zone. When you add a zone, worker nodes are added to the new zone to match the number of workers per zone that you specified for the worker pool.

Command options:

--zone ZONE

The zone that you want to add. It must be a [multizone-capable zone](cs_regions.html#zones) within the cluster's region. This value is required.

--cluster CLUSTER

The name or ID of the cluster. This value is required.

--worker-pool WORKER_POOLS

A comma-separated list of worker pools that the zone is added to. At least 1 worker pool is required.

--private-vlan PRIVATE_VLAN

The ID of the private VLAN. This value is conditional.

If you have a private VLAN in the zone, this value must match the private VLAN ID of one or more of the worker nodes in the cluster. To see the VLANs that you have available, run ibmcloud cs cluster-get --cluster <cluster> --showResources.

If you do not have a private or public VLAN in that zone, do not specify this option. A private and a public VLAN are automatically created for you when you initially add a new zone to your worker pool. Then, enable VLAN spanning for your account so that worker nodes in different zones can communicate with each other.

**Note**: New worker nodes are added to the VLANs that you specify, but the VLANs for any existing worker nodes are not changed.

--public-vlan PUBLIC_VLAN

The ID of the public VLAN. This value is required if you want to expose workloads on the nodes to the public after you create the cluster. It must match the public VLAN ID of one or more of the worker nodes in the cluster for the zone. To see the VLANs that you have available, run ibmcloud cs cluster-get --cluster <cluster> --showResources.

**Note**: New worker nodes are added to the VLANs that you specify, but the VLANs for any existing worker nodes are not changed.

--private-only

Use this option to prevent a public VLAN from being created. Required only when you specify the `--private-vlan` flag and do not include the `--public-vlan` flag. **Note**: If you want a private-only cluster, you must configure a gateway appliance for network connectivity. For more information, see [Planning private external networking for a private VLAN setup only](cs_network_planning.html#private_vlan).

--json

Prints the command output in JSON format. This value is optional.

-s

Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs zone-add --zone dal10 --cluster my_cluster --worker-pools pool1,pool2,pool3 --private-vlan 2294021

{: pre}

ibmcloud cs zone-network-set --zone ZONE --cluster CLUSTER --worker-pools WORKER_POOL1,[WORKER_POOL2] --private-vlan PRIVATE_VLAN [--public-vlan PUBLIC_VLAN] [--json] [-s]

{: #cs_zone_network_set}

Multizone clusters only: Set the network metadata for a worker pool to use a different public or private VLAN for the zone than it previously used. Worker nodes that were already created in the pool continue to use the previous public or private VLAN, but new worker nodes in the pool use the new network data.

Command options:

--zone ZONE: The zone that you want to add. It must be a [multizone-capable zone](cs_regions.html#zones) within the cluster's region. This value is required.
--cluster CLUSTER: The name or ID of the cluster. This value is required.
--worker-pool WORKER_POOLS: A comma-separated list of worker pools that the zone is added to. At least 1 worker pool is required.
--private-vlan PRIVATE_VLAN: The ID of the private VLAN. This value is required. It must match the private VLAN ID of one or more of the worker nodes in the cluster. To see the VLANs that you have available, run ibmcloud cs cluster-get --cluster <cluster> --showResources. If you do not have any VLANs available, you can enable VLAN spanning for your account.

**Note**: New worker nodes are added to the VLANs that you specify, but the VLANs for any existing worker nodes are not changed.
--public-vlan PUBLIC_VLAN: The ID of the public VLAN. This value is required if you want to change the public VLAN for the zone. If you do not want to change the private VLAN with the public VLAN, use the same private VLAN ID. The public VLAN ID must match the public VLAN ID of one or more of the worker nodes in the cluster. To see the VLANs that you have available, run ibmcloud cs cluster-get --cluster <cluster> --showResources. If you do not have any VLANs available, you can enable VLAN spanning for your account.

**Note**: New worker nodes are added to the VLANs that you specify, but the VLANs for any existing worker nodes are not changed.
--json: Prints the command output in JSON format. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs zone-network-set --zone dal10 --cluster my_cluster --worker-pools pool1,pool2,pool3 --private-vlan 2294021

{: pre}

ibmcloud cs zone-rm --zone ZONE --cluster CLUSTER [-f] [-s]

{: #cs_zone_rm}

Multizone clusters only: Remove a zone from all the worker pools in your cluster. All worker nodes in the worker pool for this zone are deleted.

Before you remove a zone, make sure that you have enough worker nodes in other zones in the cluster so that your pods can reschedule to help avoid a downtime for your app or data corruption on your worker node. {: tip}

Command options:

--zone ZONE: The zone that you want to add. It must be a [multizone-capable zone](cs_regions.html#zones) within the cluster's region. This value is required.
--cluster CLUSTER: The name or ID of the cluster. This value is required.
-f: Force the update with no user prompts. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud cs zone-rm --zone dal10 --cluster my_cluster

{: pre}

FilesExpand file tree

cs_cli_devtools.md

Latest commit

History

cs_cli_devtools.md

File metadata and controls

CLI reference for managing clusters

ibmcloud cs commands

API commands

ibmcloud cs api ENDPOINT [--insecure] [--skip-ssl-validation] [--api-version VALUE] [-s]

ibmcloud cs api-key-info CLUSTER [--json] [-s]

ibmcloud cs api-key-reset [-s]

ibmcloud cs apiserver-config-get

ibmcloud cs apiserver-config-get audit-webhook CLUSTER

ibmcloud cs apiserver-config-set

ibmcloud cs apiserver-config-set audit-webhook CLUSTER [--remoteServer SERVER_URL_OR_IP] [--caCert CA_CERT_PATH] [--clientCert CLIENT_CERT_PATH] [--clientKey CLIENT_KEY_PATH]

ibmcloud cs apiserver-config-unset

ibmcloud cs apiserver-config-unset audit-webhook CLUSTER

ibmcloud cs apiserver-refresh CLUSTER [-s]

CLI plug-in usage commands

ibmcloud cs help

ibmcloud cs init [--host HOST] [--insecure] [-p] [-u] [-s]

ibmcloud cs messages

Cluster commands: Management

ibmcloud cs cluster-config CLUSTER [--admin] [--export] [-s] [--yaml]

ibmcloud cs cluster-create [--file FILE_LOCATION] [--hardware HARDWARE] --zone ZONE --machine-type MACHINE_TYPE --name NAME [--kube-version MAJOR.MINOR.PATCH] [--no-subnet] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--workers WORKER] [--disable-disk-encrypt] [--trusted] [-s]

ibmcloud cs cluster-feature-enable [-f] CLUSTER [--trusted] [-s]

ibmcloud cs cluster-get CLUSTER [--json] [--showResources] [-s]

ibmcloud cs cluster-rm [-f] CLUSTER [-s]

ibmcloud cs cluster-update [-f] CLUSTER [--kube-version MAJOR.MINOR.PATCH] [--force-update] [-s]

ibmcloud cs clusters [--json] [-s]

ibmcloud cs kube-versions [--json] [-s]

Cluster commands: Services and integrations

ibmcloud cs cluster-service-bind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_NAME [-s]

ibmcloud cs cluster-service-unbind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_GUID [-s]

ibmcloud cs cluster-services CLUSTER [--namespace KUBERNETES_NAMESPACE] [--all-namespaces] [--json] [-s]

ibmcloud cs va CONTAINER_ID [--extended] [--vulnerabilities] [--configuration-issues] [--json]

ibmcloud cs webhook-create --cluster CLUSTER --level LEVEL --type slack --url URL [-s]

Cluster commands: Subnets

ibmcloud cs cluster-subnet-add CLUSTER SUBNET [-s]

ibmcloud cs cluster-subnet-create CLUSTER SIZE VLAN_ID [-s]

ibmcloud cs cluster-user-subnet-add CLUSTER SUBNET_CIDR PRIVATE_VLAN

ibmcloud cs cluster-user-subnet-rm CLUSTER SUBNET_CIDR PRIVATE_VLAN

ibmcloud cs subnets [--json] [-s]

Ingress application load balancer (ALB) commands

ibmcloud cs alb-cert-deploy [--update] --cluster CLUSTER --secret-name SECRET_NAME --cert-crn CERTIFICATE_CRN [-s]

ibmcloud cs alb-cert-get --cluster CLUSTER [--secret-name SECRET_NAME] [--cert-crn CERTIFICATE_CRN] [--json] [-s]

ibmcloud cs alb-cert-rm --cluster CLUSTER [--secret-name SECRET_NAME] [--cert-crn CERTIFICATE_CRN] [-s]

ibmcloud cs alb-certs --cluster CLUSTER [--json] [-s]

ibmcloud cs alb-configure --albID ALB_ID [--enable][--disable][--user-ip USERIP] [-s]

ibmcloud cs alb-get --albID ALB_ID [--json] [-s]

ibmcloud cs alb-types [--json] [-s]

ibmcloud cs albs --cluster CLUSTER [--json] [-s]

Infrastructure commands

ibmcloud cs credentials-set --infrastructure-api-key API_KEY --infrastructure-username USERNAME [-s]

ibmcloud cs credentials-unset

ibmcloud cs machine-types ZONE [--json] [-s]

ibmcloud cs vlans ZONE [--all] [--json] [-s]

Logging commands

ibmcloud cs logging-config-get CLUSTER [--logsource LOG_SOURCE] [--json] [-s]

ibmcloud cs logging-config-refresh CLUSTER [-s]

ibmcloud cs logging-config-rm CLUSTER [--id LOG_CONFIG_ID] [--all] [-s]

ibmcloud cs logging-config-update CLUSTER --id LOG_CONFIG_ID --type LOG_TYPE [--namespace NAMESPACE] [--hostname LOG_SERVER_HOSTNAME_OR_IP] [--port LOG_SERVER_PORT] [--space CLUSTER_SPACE] [--org CLUSTER_ORG] [--app-paths PATH] [--app-containers PATH] [--json] [--skipValidation] [-s]

ibmcloud cs logging-filter-create CLUSTER --type LOG_TYPE [--logging-configs CONFIGS] [--namespace KUBERNETES_NAMESPACE] [--container CONTAINER_NAME] [--level LOGGING_LEVEL] [--regex-message MESSAGE] [--json] [-s]

ibmcloud cs logging-filter-get CLUSTER [--id FILTER_ID] [--show-matching-configs] [--show-covering-filters] [--json] [-s]

ibmcloud cs logging-filter-rm CLUSTER [--id FILTER_ID] [--all] [-s]

ibmcloud cs logging-filter-update CLUSTER --id FILTER_ID --type LOG_TYPE [--logging-configs CONFIGS] [--namespace KUBERNETES_NAMESPACE] [--container CONTAINER_NAME] [--level LOGGING_LEVEL] [--message MESSAGE] [--json] [-s]

Region commands

ibmcloud cs zones [--json] [-s]

ibmcloud cs region

ibmcloud cs region-set [REGION]

ibmcloud cs regions

Worker node commands

Deprecated: ibmcloud cs worker-add --cluster CLUSTER [--file FILE_LOCATION] [--hardware HARDWARE] --machine-type MACHINE_TYPE --workers NUMBER --private-vlan PRIVATE_VLAN --public-vlan PUBLIC_VLAN [--disable-disk-encrypt] [-s]

ibmcloud cs worker-get [CLUSTER_NAME_OR_ID] WORKER_NODE_ID [--json] [-s]

ibmcloud cs worker-reboot [-f] [--hard] CLUSTER WORKER [WORKER] [-s]

ibmcloud cs worker-reload [-f] CLUSTER WORKER [WORKER] [-s]

ibmcloud cs worker-rm [-f] CLUSTER WORKER [WORKER] [-s]

ibmcloud cs worker-update [-f] CLUSTER WORKER [WORKER] [--kube-version MAJOR.MINOR.PATCH] [--force-update] [-s]

ibmcloud cs workers CLUSTER [--worker-pool] POOL [--show-deleted] [--json] [-s]