copyright

lastupdated

years
2014, 2018

2018-11-15

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

Command reference

{: #cs_cli_reference}

Refer to these commands to create and manage Kubernetes clusters in {{site.data.keyword.containerlong}}. {:shortdesc}

To install the CLI plug-in, see Installing the CLI.

In the terminal, you are notified when updates to the ibmcloud CLI and plug-ins are available. Be sure to keep your CLI up-to-date so that you can use all the available commands and flags.

Looking for ibmcloud cr commands? See the {{site.data.keyword.registryshort_notm}} CLI reference. Looking for kubectl commands? See the Kubernetes documentation External link icon . {:tip}

ibmcloud ks commands

{: #cs_commands}

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

ibmcloud plugin list

{: pre}

API commands

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

CLI plug-in usage commands

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

Cluster commands: Management commands

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

Cluster commands: Services and integrations commands

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

Cluster commands: Subnets commands

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

Cluster commands: Infrastructure commands

Infrastructure commands
[ibmcloud ks credential-get](#cs_credential_get)	[ibmcloud ks credential-set](#cs_credentials_set)	[ibmcloud ks credential-unset](#cs_credentials_unset)	[ibmcloud ks machine-types](#cs_machine_types)
[ibmcloud ks vlans](#cs_vlans)	[ibmcloud ks vlan-spanning-get](#cs_vlan_spanning_get)

Ingress application load balancer (ALB) commands

Ingress application load balancer (ALB) commands
[ibmcloud ks alb-autoupdate-disable](#cs_alb_autoupdate_disable)	[ibmcloud ks alb-autoupdate-enable](#cs_alb_autoupdate_enable)	[ibmcloud ks alb-autoupdate-get](#cs_alb_autoupdate_get)	[ibmcloud ks alb-cert-deploy](#cs_alb_cert_deploy)
[ibmcloud ks alb-cert-get](#cs_alb_cert_get)	[ibmcloud ks alb-cert-rm](#cs_alb_cert_rm)	[ibmcloud ks alb-certs](#cs_alb_certs)	[ibmcloud ks alb-configure](#cs_alb_configure)
[ibmcloud ks alb-get](#cs_alb_get)	[ibmcloud ks alb-rollback](#cs_alb_rollback)	[ibmcloud ks alb-types](#cs_alb_types)	[ibmcloud ks alb-update](#cs_alb_update)
[ibmcloud ks albs](#cs_albs)

Logging commands

Logging commands
[ibmcloud ks logging-autoupdate-enable](#cs_log_autoupdate_enable)	[ibmcloud ks logging-autoupdate-disable](#cs_log_autoupdate_disable)	[ibmcloud ks logging-autoupdate-get](#cs_log_autoupdate_get)	[ibmcloud ks logging-config-create](#cs_logging_create)
[ibmcloud ks logging-config-get](#cs_logging_get)	[ibmcloud ks logging-config-refresh](#cs_logging_refresh)	[ibmcloud ks logging-config-rm](#cs_logging_rm)	[ibmcloud ks logging-config-update](#cs_logging_update)
[ibmcloud ks logging-filter-create](#cs_log_filter_create)	[ibmcloud ks logging-filter-update](#cs_log_filter_update)	[ibmcloud ks logging-filter-get](#cs_log_filter_view)	[ibmcloud ks logging-filter-rm](#cs_log_filter_delete)
[ibmcloud ks logging-collect](#cs_log_collect)	[ibmcloud ks logging-collect-status](#cs_log_collect_status)

Region commands

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

Worker node commands

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

Worker pool commands

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

API commands

{: #api_commands}

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

{: #cs_api}

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

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

Minimum required permissions: None

Command options:

--endpoint ENDPOINT

The {{site.data.keyword.containerlong_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 ks api

{: pre}

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

{: screen}

ibmcloud ks api-key-info --cluster CLUSTER [--json] [-s]

{: #cs_api_key_info}

View the name and email address for the owner of the {{site.data.keyword.Bluemix_notm}} Identity and Access Management (IAM) API key in an {{site.data.keyword.containerlong_notm}} resource group and region.

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

When a different user performs an action in this resource group and 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.containerlong_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 resource group and region, you can do so by running the ibmcloud ks api-key-reset command. This command requires the {{site.data.keyword.containerlong_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 ks credential-set command.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks api-key-info --cluster my_cluster

{: pre}

ibmcloud ks api-key-reset [-s]

{: #cs_api_key_reset}

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

This command requires the {{site.data.keyword.containerlong_notm}} admin access policy and stores the API key of the user that executes this command in the account. The {{site.data.keyword.Bluemix_notm}} 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 {{site.data.keyword.Bluemix_notm}} IAM API keys work, see the ibmcloud ks api-key-info command.

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

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

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

Example:

ibmcloud ks api-key-reset

{: pre}

ibmcloud ks 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 ks apiserver-config-get audit-webhook --cluster CLUSTER

{: #cs_apiserver_config_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.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

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

Example:

ibmcloud ks apiserver-config-get audit-webhook --cluster my_cluster

{: pre}

ibmcloud ks 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 ks apiserver-config-set audit-webhook --cluster CLUSTER [--remoteServer SERVER_URL_OR_IP] [--caCert CA_CERT_PATH] [--clientCert CLIENT_CERT_PATH] [--clientKey CLIENT_KEY_PATH]

{: #cs_apiserver_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.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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 ks apiserver-config-set audit-webhook --cluster 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 ks 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 ks apiserver-config-unset audit-webhook --cluster CLUSTER

{: #cs_apiserver_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.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

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

Example:

ibmcloud ks apiserver-config-unset audit-webhook --cluster my_cluster

{: pre}

ibmcloud ks apiserver-refresh --cluster CLUSTER [-s]

{: #cs_apiserver_refresh}

Restart the cluster master to apply new Kubernetes API configuration changes. Your worker nodes, apps, and resources are not modified and continue to run.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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 ks apiserver-refresh --cluster my_cluster

{: pre}

CLI plug-in usage commands

{: #cli_plug-in_commands}

ibmcloud ks help

{: #cs_help}

View a list of supported commands and parameters.

Minimum required permissions: None

Command options:

None

Example:

ibmcloud ks help

{: pre}

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

{: #cs_init}

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

Minimum required permissions: None

Command options:

--host HOST: The {{site.data.keyword.containerlong_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 ks init --host https://uk-south.containers.bluemix.net

{: pre}

ibmcloud ks messages

{: #cs_messages}

View current messages for the IBMid user.

Minimum required permissions: None

Example:

ibmcloud ks messages

{: pre}

Cluster commands: Management

{: #cluster_mgmt_commands}

ibmcloud ks cluster-config --cluster CLUSTER [--admin] [--export] [--network] [-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>.

Minimum required permissions: None

Command options:

--cluster 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.
--network: Download the Calico configuration file, TLS certificates, and permission files required to run calicoctl commands in your cluster. This value is optional. **Note**: To get the export command for the downloaded Kubernetes configuration data and certificates, you must run this command without this flag.
--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 ks cluster-config --cluster my_cluster

{: pre}

ibmcloud ks 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] [--private-only] [--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.

Minimum required permissions:

Administrator platform role for {{site.data.keyword.containerlong_notm}} at the account level
Administrator platform role for {{site.data.keyword.registrylong_notm}} at the account level
Super User role for IBM Cloud infrastructure (SoftLayer)

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.

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 ks 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 ks 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 ks 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 ks 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 ks 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 ks 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).

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 ks 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 ks 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. 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 ks 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. 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 ks vlans <zone>.

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

If you want a private-only cluster, you must configure a gateway appliance for network connectivity. For more information, see [Private clusters](cs_clusters_planning.html#private_clusters).

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

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 ks 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 ks 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 ks 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 ks 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 ks 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 ks 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 ks vlans <zone>.

ibmcloud ks 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 ks cluster-create --machine-type machine-type --workers number --name cluster_name

{: pre}

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

{: #cs_cluster_feature_enable}

Enable a feature on an existing cluster.

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER

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

-f

Use this option to force the --trusted option without 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 ks 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 ks 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 ks 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 ks cluster-feature-enable --cluster my_cluster --trusted=true

{: pre}

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

{: #cs_cluster_get}

View information about a cluster in your organization.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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.
--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 ks cluster-get --cluster my_cluster --showResources

{: pre}

Example output:

Name:                   mycluster
ID:                     df253b6025d64944ab99ed63bb4567b6
State:                  normal
Created:                2018-09-28T15:43:15+0000
Location:               dal10
Master URL:             https://169.xx.xxx.xxx:30426
Master Location:        Dallas
Master Status:          Ready (21 hours ago)
Ingress Subdomain:      ...
Ingress Secret:         mycluster
Workers:                6
Worker Zones:           dal10, dal12
Version:                1.11.3_1524
Owner:                  owner@email.com
Monitoring Dashboard:   ...
Resource Group ID:      a8a12accd63b437bbd6d58fb6a462ca7
Resource Group Name:    Default

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 ks cluster-refresh --cluster CLUSTER [-f] [-s]

{: #cs_cluster_refresh}

Restart the cluster master nodes to apply new Kubernetes API configuration changes. Your worker nodes, apps, and resources are not modified and continue to run.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

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

Example:

ibmcloud ks cluster-refresh --cluster my_cluster

{: pre}

ibmcloud ks cluster-rm --cluster CLUSTER [--force-delete-storage] [-f] [-s]

{: #cs_cluster_rm}

Remove a cluster from your organization.

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--force-delete-storage: Deletes the cluster and any persistent storage that the cluster uses. **Attention**: If you include this flag, the data that is stored in the cluster or its associated storage instances cannot be recovered. This value is optional.
-f: Use this option to force the removal of a cluster without user prompts. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks cluster-rm --cluster my_cluster

{: pre}

ibmcloud ks cluster-update --cluster CLUSTER [--kube-version MAJOR.MINOR.PATCH] [--force-update] [-f] [-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.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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 ks kube-versions](#cs_kube_versions). This value is optional.
--force-update: Attempt the update even if the change is greater than two minor versions. This value is optional.
-f: Force the command to run without user prompts. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks cluster-update --cluster my_cluster

{: pre}

ibmcloud ks clusters [--json] [-s]

{: #cs_clusters}

View a list of clusters in your organization.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks clusters

{: pre}

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

{: #cs_kube_versions}

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

Minimum required permissions: None

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 ks kube-versions

{: pre}

Cluster commands: Services and integrations

{: #cluster_services_commands}

ibmcloud ks cluster-service-bind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE --service 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.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}} and Developer Cloud Foundry role

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--namespace KUBERNETES_NAMESPACE: The name of the Kubernetes namespace. This value is required.
--service 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 ks cluster-service-bind --cluster my_cluster --namespace my_namespace --service my_service_instance

{: pre}

ibmcloud ks cluster-service-unbind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE --service SERVICE_INSTANCE_GUID [-s]

{: #cs_cluster_service_unbind}

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

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. {: note}

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}} and Developer Cloud Foundry role

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--namespace KUBERNETES_NAMESPACE: The name of the Kubernetes namespace. This value is required.
--service 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 ks cluster-services `.This value is required.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks cluster-service-unbind --cluster my_cluster --namespace my_namespace --service 8567221

{: pre}

ibmcloud ks cluster-services --cluster 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.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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 ks cluster-services --cluster my_cluster --namespace my_namespace

{: pre}

ibmcloud ks va --container 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.

Minimum required permissions: Reader service access role for {{site.data.keyword.registrylong_notm}}. Note: Do not assign policies for {{site.data.keyword.registryshort_notm}} at the resource group level.

Command options:

--container 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: containerd://1a11a1aa2b2b22223333c44444ccc555667d7dd777888e8ef99f1011121314g15`.
Remove the `containerd://` prefix from the ID before you use the container ID for the `ibmcloud ks 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 ks va --container 1a11a1aa2b2b22223333c44444ccc555667d7dd777888e8ef99f1011121314g15 --extended --vulnerabilities --json

{: pre}

ibmcloud ks key-protect-enable --cluster CLUSTER_NAME_OR_ID --key-protect-url ENDPOINT --key-protect-instance INSTANCE_GUID --crk ROOT_KEY_ID

{: #cs_key_protect}

Encrypt your Kubernetes secrets by using {{site.data.keyword.keymanagementservicefull}} External link icon as a key management service (KMS) provider in your cluster. {: shortdesc}

If you delete the root key in your {{site.data.keyword.keymanagementserviceshort}} instance, you cannot access or remove the data from the secrets in your cluster. {: important}

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--container CLUSTER_NAME_OR_ID: The name or ID of the cluster.
--key-protect-url ENDPOINT: The {{site.data.keyword.keymanagementserviceshort}} endpoint for your cluster instance. To get the endpoint, see [service endpoints by region](/docs/services/key-protect/regions.html#endpoints).
--key-protect-instance INSTANCE_GUID: Your {{site.data.keyword.keymanagementserviceshort}} instance GUID. To get the instance GUID, run ibmcloud resource service-instance SERVICE_INSTANCE_NAME --id and copy the second value (not the full CRN).
--crk ROOT_KEY_ID: Your {{site.data.keyword.keymanagementserviceshort}} root key ID. To get the CRK, see [Viewing keys](/docs/services/key-protect/view-keys.html#view-keys).

Example:

ibmcloud ks key-protect-enable --cluster mycluster --key-protect-url keyprotect.us-south.bluemix.net --key-protect-instance a11aa11a-bbb2-3333-d444-e5e555e5ee5 --crk 1a111a1a-bb22-3c3c-4d44-55e555e55e55

{: pre}

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

{: #cs_webhook_create}

Register a webhook.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks webhook-create --cluster my_cluster --level Normal --type slack --url http://github.com/mywebhook

{: pre}

Cluster commands: Subnets

{: #cluster_subnets_commands}

ibmcloud ks cluster-subnet-add --cluster CLUSTER --subnet-id 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.

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.containerlong_notm}} at the same time.

To enable communication between workers that are on different subnets on the same VLAN, you must [enable routing between subnets on the same VLAN](cs_subnets.html#subnet-routing).

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--subnet-id 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 ks cluster-subnet-add --cluster my_cluster --subnet-id 1643389

{: pre}

ibmcloud ks cluster-subnet-create --cluster CLUSTER --size SIZE --vlan 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.containerlong_notm}}.

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.containerlong_notm}} at the same time.

If you have multiple VLANs for a cluster, multiple subnets on the same VLAN, or a multizone cluster, you must enable [VLAN spanning](/docs/infrastructure/vlans/vlan-spanning.html#vlan-spanning) for your IBM Cloud infrastructure (SoftLayer) account so your worker nodes can communicate with each other on the private network. To perform this action, you need the **Network > Manage Network VLAN Spanning** [infrastructure permission](cs_users.html#infra_access), or you can request the account owner to enable it. To check if VLAN spanning is already enabled, use the `ibmcloud ks vlan-spanning-get` [command](/docs/containers/cs_cli_reference.html#cs_vlan_spanning_get). If you are using {{site.data.keyword.BluDirectLink}}, you must instead use a [Virtual Router Function (VRF)](/docs/infrastructure/direct-link/subnet-configuration.html#more-about-using-vrf). To enable VRF, contact your IBM Cloud infrastructure (SoftLayer) account representative.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required. To list your clusters, use the `ibmcloud ks clusters` [command](#cs_clusters).
--size SIZE: The number of subnet IP addresses. This value is required. Possible values are 8, 16, 32, or 64.; The VLAN in which to create the subnet. This value is required. To list available VLANS, use the `ibmcloud ks 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 ks cluster-subnet-create --cluster my_cluster --size 8 --vlan 1764905

{: pre}

ibmcloud ks cluster-user-subnet-add --cluster CLUSTER --subnet-cidr SUBNET_CIDR --private-vlan PRIVATE_VLAN

{: #cs_cluster_user_subnet_add}

Bring your own private subnet to your {{site.data.keyword.containerlong_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 ks cluster-subnet-add command.

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.containerlong_notm}} at the same time.

If you have multiple VLANs for a cluster, multiple subnets on the same VLAN, or a multizone cluster, you must enable [VLAN spanning](/docs/infrastructure/vlans/vlan-spanning.html#vlan-spanning) for your IBM Cloud infrastructure (SoftLayer) account so your worker nodes can communicate with each other on the private network. To perform this action, you need the **Network > Manage Network VLAN Spanning** [infrastructure permission](cs_users.html#infra_access), or you can request the account owner to enable it. To check if VLAN spanning is already enabled, use the `ibmcloud ks vlan-spanning-get` [command](/docs/containers/cs_cli_reference.html#cs_vlan_spanning_get). If you are using {{site.data.keyword.BluDirectLink}}, you must instead use a [Virtual Router Function (VRF)](/docs/infrastructure/direct-link/subnet-configuration.html#more-about-using-vrf). To enable VRF, contact your IBM Cloud infrastructure (SoftLayer) account representative.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--subnet-cidr 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 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 ks cluster-user-subnet-add --cluster my_cluster --subnet-cidr 169.xx.xxx.xxx/29 --private-vlan 1502175

{: pre}

ibmcloud ks cluster-user-subnet-rm --cluster CLUSTER --subnet-cidr SUBNET_CIDR --private-vlan PRIVATE_VLAN

{: #cs_cluster_user_subnet_rm}

Remove your own private subnet from a specified cluster. Any service that was deployed to an IP address from your own private subnet remains active after the subnet is removed.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

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

Example:

ibmcloud ks cluster-user-subnet-rm --cluster my_cluster --subnet-cidr 169.xx.xxx.xxx/29 --private-vlan 1502175

{: pre}

ibmcloud ks subnets [--json] [-s]

{: #cs_subnets}

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

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks subnets

{: pre}

Ingress application load balancer (ALB) commands

{: #alb_commands}

ibmcloud ks alb-autoupdate-disable --cluster CLUSTER

{: #cs_alb_autoupdate_disable}

By default, automatic updates to the Ingress application load balancer (ALB) add-on are enabled. ALB pods are automatically updated when a new build version is available. To instead update the add-on manually, use this command to disable automatic updates. You can then update ALB pods by running the ibmcloud ks alb-update command.

When you update the major or minor Kubernetes version of your cluster, IBM automatically makes necessary changes to the Ingress deployment, but does not change the build version of your Ingress ALB add-on. You are responsible for checking the compatability of the latest Kubernetes versions and your Ingress ALB add-on images.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Example:

ibmcloud ks alb-autoupdate-disable --cluster mycluster

{: pre}

ibmcloud ks alb-autoupdate-enable --cluster CLUSTER

{: #cs_alb_autoupdate_enable}

If automatic updates for the Ingress ALB add-on are disabled, you can re-enable automatic updates. Whenever the next build version becomes available, the ALBs are automatically updated to the latest build.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Example:

ibmcloud ks alb-autoupdate-enable --cluster mycluster

{: pre}

ibmcloud ks alb-autoupdate-get --cluster CLUSTER

{: #cs_alb_autoupdate_get}

Check if automatic updates for the Ingress ALB add-on are enabled and whether your ALBs are updated to the latest build version.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Example:

ibmcloud ks alb-autoupdate-get --cluster mycluster

{: pre}

ibmcloud ks alb-cert-deploy [--update] --cluster CLUSTER --secret-name SECRET_NAME --cert-crn CERTIFICATE_CRN [--update] [-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. You can only update certificates that are imported from the same {{site.data.keyword.cloudcerts_long_notm}} instance.

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks 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 ks 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 ks 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.

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks 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 ks 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 ks 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.

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks 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 ks 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 ks alb-certs --cluster CLUSTER [--json] [-s]

{: #cs_alb_certs}

View a list of ALB secrets in a cluster.

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks alb-certs --cluster my_cluster

{: pre}

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

{: #cs_alb_configure}

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

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--albID ALB_ID

The ID for an ALB. Run ibmcloud ks 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.

--disable-deployment

Include this flag to disable the IBM-provided ALB deployment. This flag doesn't remove the DNS registration for the IBM-provided Ingress subdomain or the load balancer service that is used to expose the Ingress controller.

--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 ks alb-configure --albID private-cr18a61a63a6a94b658596aa93a087aaa9-alb1 --enable

{: pre}

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

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

{: pre}

Example for disabling an ALB:

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

{: pre}

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

{: #cs_alb_get}

View the details of an ALB.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--albID ALB_ID: The ID for an ALB. Run ibmcloud ks 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 ks alb-get --albID public-cr18a61a63a6a94b658596aa93a087aaa9-alb1

{: pre}

ibmcloud ks alb-rollback --cluster CLUSTER

{: #cs_alb_rollback}

If your ALB pods were recently updated, but a custom configuration for your ALBs is affected by the latest build, you can roll back the update to the build that your ALB pods were previously running. After you roll back an update, automatic updates for ALB pods are disabled. To re-enable automatic updates, use the alb-autoupdate-enable command.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Example:

ibmcloud ks alb-rollback --cluster mycluster

{: pre}

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

{: #cs_alb_types}

View the ALB types that are supported in the region.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks alb-types

{: pre}

ibmcloud ks alb-update --cluster CLUSTER

{: #cs_alb_update}

If automatic updates for the Ingress ALB add-on are disabled and you want to update the add-on, you can force a one-time update of your ALB pods. When you choose to manually update the add-on, all ALB pods in the cluster are updated to the latest build. You cannot update an individual ALB or choose which build to update the add-on to. Automatic updates remain disabled.

When you update the major or minor Kubernetes version of your cluster, IBM automatically makes necessary changes to the Ingress deployment, but does not change the build version of your Ingress ALB add-on. You are responsible for checking the compatability of the latest Kubernetes versions and your Ingress ALB add-on images.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Example:

ibmcloud ks alb-update --cluster <cluster_name_or_ID>

{: pre}

ibmcloud ks 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.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks albs --cluster my_cluster

{: pre}

Infrastructure commands

{: #infrastructure_commands}

ibmcloud ks credential-get [-s] [--json]

{: #cs_credential_get}

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

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks credential-get

{: pre}

Example output:

Infrastructure credentials for user name user@email.com set for resource group default.

ibmcloud ks credential-set --infrastructure-api-key API_KEY --infrastructure-username USERNAME [-s]

{: #cs_credentials_set}

Set IBM Cloud infrastructure (SoftLayer) account credentials for an {{site.data.keyword.containerlong_notm}} resource group and region.

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 for a region and a resource group, these credentials are used to order infrastructure for all clusters within that region in the resource group. These credentials are used to determine infrastructure permissions, even if an {{site.data.keyword.Bluemix_notm}} IAM API key already exists for the resource group and region. 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 the same {{site.data.keyword.containerlong_notm}} resource group and region.

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

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--infrastructure-username USERNAME

IBM Cloud infrastructure (SoftLayer) account API username. This value is required. Note that 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 menu ![Menu icon](../icons/icon_hamburger.svg "Menu icon"), 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 ks credential-set --infrastructure-api-key <api_key> --infrastructure-username dbmanager

{: pre}

ibmcloud ks credential-unset

{: #cs_credentials_unset}

Remove IBM Cloud infrastructure (SoftLayer) account credentials from an {{site.data.keyword.containerlong_notm}} region.

After you remove the credentials, the {{site.data.keyword.Bluemix_notm}} IAM API key is used to order resources in IBM Cloud infrastructure (SoftLayer).

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

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

Example:

ibmcloud ks credential-unset

{: pre}

ibmcloud ks machine-types --zone 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 container runtime data is not encrypted. Learn more about the encryption. {: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.

Minimum required permissions: None

Command options:

--zone 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 ks machine-types --zone dal10

{: pre}

ibmcloud ks vlans --zone 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.

Minimum required permissions:

To view the VLANs that the cluster is connected to in a zone: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}
To list all available VLANs in a zone: Viewer platform role for the region in {{site.data.keyword.containerlong_notm}}

Command options:

--zone 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 ks vlans --zone dal10

{: pre}

ibmcloud ks vlan-spanning-get [--json] [-s]

{: #cs_vlan_spanning_get}

View the VLAN spanning status for an IBM Cloud infrastructure (SoftLayer) account. VLAN spanning enables all devices on an account to communicate with each other by means of the private network, regardless of its assigned VLAN.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

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

Example:

ibmcloud ks vlan-spanning-get

{: pre}

Logging commands

{: #logging_commands}

ibmcloud ks logging-autoupdate-disable --cluster CLUSTER

{: #cs_log_autoupdate_disable}

Disable automatic updates of your Fluentd pods in a specific cluster. When you update the major or minor Kubernetes version of your cluster, IBM automatically makes necessary changes to the Fluentd configmap, but does not change the build version of your Fluentd for logging add-on. You are responsible for checking the compatability of the latest Kubernetes versions and your add-on images.

Command options:

--cluster CLUSTER: The name or ID of the cluster where you want to disable automatic updates for the Fluentd add-on. This value is required.

ibmcloud ks logging-autoupdate-enable --cluster CLUSTER

{: #cs_log_autoupdate_enable}

Enable automatic updates for your Fluentd pods in a specific cluster. Fluentd pods are automatically updated when a new build version is available.

Command options:

--cluster CLUSTER: The name or ID of the cluster where you want to enable automatic updates for the Fluentd add-on. This value is required.

ibmcloud ks logging-autoupdate-get --cluster CLUSTER

{: #cs_log_autoupdate_get}

Check if your Fluentd pods are set to automatically update in a specific cluster.

Command options:

--cluster CLUSTER: The name or ID of the cluster where you want to check if automatic updates for the Fluentd add-on are enabled. This value is required.

ibmcloud ks logging-config-create --cluster 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] [--force-update][-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.

Minimum required permissions: Editor platform role for the cluster for all log sources except kube-audit and Administrator platform role for the cluster for the kube-audit log source

Command options:

--cluster 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, storage, 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: Optional: 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. If you do, you must also specify an org.
--org CLUSTER_ORG: Optional: 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, tls, 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.
--force-update: Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version in order to make changes to your logging configurations.

Examples:

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

ibmcloud ks 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 ks 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 ks logging-config-create --cluster my_cluster --logsource container --hostname 169.xx.xxx.xxx --port 5514 --type syslog

{: pre}

ibmcloud ks logging-config-get --cluster 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.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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, storage, 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 ks logging-config-get --cluster my_cluster --logsource worker

{: pre}

ibmcloud ks logging-config-refresh --cluster CLUSTER [--force-update] [-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.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
--force-update: Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version in order to make changes to your logging configurations.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks logging-config-refresh --cluster my_cluster

{: pre}

ibmcloud ks logging-config-rm --cluster CLUSTER [--id LOG_CONFIG_ID] [--all] [--force-update] [-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}}.

Minimum required permissions: Editor platform role for the cluster for all log sources except kube-audit and Administrator platform role for the cluster for the kube-audit log source

Command options:

--cluster 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.
--force-update: Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version in order to make changes to your logging configurations.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

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

{: pre}

ibmcloud ks logging-config-update --cluster 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] [--force-update] [-s]

{: #cs_logging_update}

Update the details of a log forwarding configuration.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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: Optional: 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. If you do, you must also specify an org.
--org CLUSTER_ORG: Optional: 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 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.
--force-update: Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version in order to make changes to your logging configurations.
-s: Do not show the message of the day or update reminders. This value is optional.

Example for log type ibm:

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

{: pre}

Example for log type syslog:

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

{: pre}

ibmcloud ks logging-filter-create --cluster CLUSTER --type LOG_TYPE [--logging-configs CONFIGS] [--namespace KUBERNETES_NAMESPACE] [--container CONTAINER_NAME] [--level LOGGING_LEVEL] [--message MESSAGE] [--regex-message MESSAGE] [--force-update] [--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.

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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"}
--message MESSAGE: Filters out any logs that contain a specified message anywhere in the log. This value is optional. Example: The messages "Hello", "!", and "Hello, World!", would apply to the log "Hello, World!".
--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. Example: The pattern "hello [0-9]" would apply to "hello 1", "hello 2", and "hello 9".
--force-update: Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version in order to make changes to your logging configurations.
--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 ks logging-filter-create --cluster 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 ks logging-filter-create --cluster example-cluster --type all --level info --json

{: pre}

ibmcloud ks logging-filter-get --cluster 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.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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.

Example:

ibmcloud ks logging-filter-get mycluster --id 885732 --show-matching-configs

{: pre}

ibmcloud ks logging-filter-rm --cluster CLUSTER [--id FILTER_ID] [--all] [--force-update] [-s]

{: #cs_log_filter_delete}

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

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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.
--force-update: Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version in order to make changes to your logging configurations.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks logging-filter-rm mycluster --id 885732

{: pre}

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

{: #cs_log_filter_update}

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

Minimum required permissions: Editor platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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. This value is optional. Example: The messages "Hello", "!", and "Hello, World!", would apply to the log "Hello, World!".
--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. Example: The pattern "hello [0-9]" would apply to "hello 1", "hello 2", and "hello 9"
--force-update: Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version in order to make changes to your logging configurations.
--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 ks logging-filter-update --cluster example-cluster --id 885274 --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 ks logging-filter-update --cluster example-cluster --id 274885 --type all --level info --json

{: pre}

ibmcloud ks logging-collect --cluster CLUSTER --cos-bucket BUCKET_NAME --cos-endpoint ENDPOINT --hmac-key-id HMAC_KEY_ID --hmac-key HMAC_KEY --type LOG_TYPE [-s]

{: #cs_log_collect}

Make a request for a snapshot of your logs at a specific point in time and then store the logs in a {{site.data.keyword.cos_full_notm}} bucket.

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER: The name or ID of the cluster that you want to create a snapshot for. This value is required.
--cos-bucket BUCKET_NAME: The name of the {{site.data.keyword.cos_short}} bucket that you want to store your logs in. This value is required.
--cos-endpoint ENDPOINT: The {{site.data.keyword.cos_short}} endpoint for the bucket that you are storing your logs in. This value is required.
--hmac-key-id HMAC_KEY_ID: The unique ID for your HMAC credentials for your Object Storage instance. This value is required.
--hmac-key HMAC_KEY: The HMAC key for your {{site.data.keyword.cos_short}} instance. This value is required.
--type LOG_TYPE: The type of logs that you want to create a snapshot of. Currently, `master` is the only option, as well as the default.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks logging-collect --cluster mycluster --cos-bucket mybucket --cos-endpoint s3-api.us-geo.objectstorage.softlayer.net --hmac-key-id e2e7f5c9fo0144563c418dlhi3545m86 --hmac-key c485b9b9fo4376722f692b63743e65e1705301ab051em96j

{: pre}

Example output:

There is no specified log type. The default master will be used.
Submitting log collection request for master logs for cluster mycluster...
OK
The log collection request was successfully submitted. To view the status of the request run ibmcloud ks logging-collect-status mycluster.

{: screen}

ibmcloud ks logging-collect-status --cluster CLUSTER [--json] [-s]

{: #cs_log_collect_status}

Check the status of the log collection snapshot request for your cluster.

Minimum required permissions: Administrator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER: The name or ID of the cluster that you want to create a snapshot for. 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 ks logging-collect-status --cluster mycluster

{: pre}

Example output:

Getting the status of the last log collection request for cluster mycluster...
OK
State     Start Time             Error   Log URLs
success   2018-09-18 16:49 PDT   - s3-api.us-geo.objectstorage.softlayer.net/mybucket/master-0-0862ae70a9ae6c19845ba3pc0a2a6o56-1297318756.tgz
s3-api.us-geo.objectstorage.softlayer.net/mybucket/master-1-0862ae70a9ae6c19845ba3pc0a2a6o56-1297318756.tgz
s3-api.us-geo.objectstorage.softlayer.net/mybucket/master-2-0862ae70a9ae6c19845ba3pc0a2a6o56-1297318756.tgz

{: screen}

Region commands

{: #region_commands}

ibmcloud ks region

{: #cs_region}

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

Minimum required permissions: None

Example:

ibmcloud ks region

{: pre}

Output:

Region: us-south

{: screen}

ibmcloud ks region-set [--region REGION]

{: #cs_region-set}

Set the region for {{site.data.keyword.containerlong_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 ks region-set eu-central to target the EU Central region and create another cluster. Finally, you can use ibmcloud ks region-set us-south to return to US South to manage your cluster in that region.

Minimum required permissions: None

Command options:

--region 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 ks regions command.

Example:

ibmcloud ks region-set eu-central

{: pre}

ibmcloud ks 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 ks regions

{: #cs_regions}

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

Minimum required permissions: None

Example:

ibmcloud ks 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}

ibmcloud ks zones [--region-only] [--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 ks region-set.

Command options:

--region-only: List only multizones within the region that you are logged in to. 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 ks zones

{: pre}

Worker node commands

{: worker_node_commands}

Deprecated: ibmcloud ks 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. {: deprecated}

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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.

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 ks 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 ks 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 ks 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 ks vlans <zone>` and look for VLAN routers that start with `fcr` (front-end router). Note: If worker nodes are set up with a private VLAN only, you must configure an alternative solution for network connectivity. For more information, see [Planning private-only cluster networking](cs_network_cluster.html#private_vlan).
`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

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 ks machine-types` [command](cs_cli_reference.html#cs_machine_types). This value is required for standard clusters and is not available for free clusters.

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

If worker nodes are set up with a private VLAN only, you must configure an alternative solution for network connectivity. For more information, see [Planning private-only cluster networking](cs_network_cluster.html#private_vlan).

--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 ks worker-add --cluster my_cluster --workers 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 ks worker-add --cluster my_cluster --workers 3 --machine-type b2c.4x16

{: pre}

ibmcloud ks worker-get --cluster [CLUSTER_NAME_OR_ID] --worker WORKER_NODE_ID [--json] [-s]

{: #cs_worker_get}

View the details of a worker node.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster CLUSTER_NAME_OR_ID: The name or ID of the worker node's cluster. This value is optional.
--worker WORKER_NODE_ID: The name of your worker node. Run ibmcloud ks 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 ks worker-get --cluster my_cluster --worker 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 ks worker-reboot [-f] [--hard] --cluster CLUSTER --worker WORKER [WORKER] [--skip-master-healthcheck] [-s]

{: #cs_worker_reboot}

Reboot a worker node in a cluster. During the reboot, the state of your worker node does not change. For example, you might use a reboot if the worker node status in IBM Cloud infrastructure (SoftLayer) is Powered Off and you need to turn on the worker node.

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.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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
```
{: pre} 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 ks 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 ks workers <cluster_name_or_ID> command.
```
ibmcloud ks worker-reboot --cluster <cluster_name_or_ID> --workers <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 CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the restart of the worker node without 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's container runtime is unresponsive. This value is optional.
--workers WORKER: The name or ID of one or more worker nodes. Use a space to list multiple worker nodes. This value is required.
--skip-master-healthcheck: Skip a health check of your master before reloading or rebooting your worker nodes.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks worker-reboot --cluster my_cluster --worker kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2

{: pre}

ibmcloud ks worker-reload [-f] --cluster CLUSTER --workers WORKER [WORKER] [--skip-master-healthcheck] [-s]

{: #cs_worker_reload}

Reload the 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. Note that during the reload, your worker node machine is updated with the latest image and data is deleted if not stored outside the worker node. {: shortdesc}

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}

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks 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 ks workers <cluster_name_or_ID> command.
```
ibmcloud ks worker-reload --cluster <cluster_name_or_ID> --worker <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 CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the reload of a worker node without user prompts. This value is optional.
--worker WORKER: The name or ID of one or more worker nodes. Use a space to list multiple worker nodes. This value is required.
--skip-master-healthcheck: Skip a health check of your master before reloading or rebooting your worker nodes.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks worker-reload --cluster my_cluster --worker kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2

{: pre}

ibmcloud ks worker-rm [-f] --cluster CLUSTER --workers 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 ks worker-pool-rebalance command.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks 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 ks workers <cluster_name_or_ID> command.
```
ibmcloud ks worker-rm --cluster <cluster_name_or_ID> --worker <worker_name_or_ID>
```
{: pre}

Verify that the worker node is removed.

ibmcloud ks workers --cluster <cluster_name_or_ID>

Command options:

--cluster CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the removal of a worker node without user prompts. This value is optional.
--workers 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 ks worker-rm --cluster my_cluster --workers kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2

{: pre}

ibmcloud ks worker-update [-f] --cluster CLUSTER --workers 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 Kubernetes master. You can update the master Kubernetes version with the ibmcloud ks cluster-update command.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Running ibmcloud ks worker-update can cause downtime for your apps and services. During the update, all pods are rescheduled onto other worker nodes, the worker node is reimaged, 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. {: important}

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

Command options:

--cluster 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 without 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.
--workers 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 ks worker-update --cluster my_cluster --worker kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2

{: pre}

ibmcloud ks workers --cluster CLUSTER [--worker-pool POOL] [--show-pools] [--show-deleted] [--json] [-s]

{: #cs_workers}

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

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

Command options:

--cluster 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 ks worker-pools --cluster `. This value is optional.
--show-pools: List the worker pool that each worker node belongs to. 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 ks workers --cluster my_cluster

{: pre}

Worker pool commands

{: #worker-pool}

ibmcloud ks 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] [-s] [--json]

{: #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.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks 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, and must be 1 or greater.
--hardware ISOLATION: 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`. For bare metal machine types, specify `dedicated`. This value is required.
--labels LABELS: The labels that you want to assign to the workers in your pool. Example: =,=
--disable-disk-encrpyt: Specifies that the disk is not encrypted. The default value is false.
--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 ks worker-pool-create --name my_pool --cluster my_cluster --machine-type b2c.4x16 --size-per-zone 6

{: pre}

ibmcloud ks worker-pool-get --worker-pool WORKER_POOL --cluster CLUSTER [-s] [--json]

{: #cs_worker_pool_get}

View the details of a worker pool.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks 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.
--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 ks 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.10.8_1512

{: screen}

ibmcloud ks 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.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks worker-pool-rebalance --cluster my_cluster --worker-pool my_pool

{: pre}

ibmcloud ks 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.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks worker-pool-resize --cluster my_cluster --worker-pool my_pool --size-per-zone 3

{: pre}

ibmcloud ks worker-pool-rm --worker-pool WORKER_POOL --cluster CLUSTER [-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.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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.
-s: Do not show the message of the day or update reminders. This value is optional.

Example command:

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

{: pre}

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

{: #cs_worker_pools}

View the worker pools that you have in a cluster.

Minimum required permissions: Viewer platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks worker-pools --cluster my_cluster

{: pre}

ibmcloud ks 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.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 ks cluster-get --cluster <cluster> --showResources. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.

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.

If you have multiple VLANs for a cluster, multiple subnets on the same VLAN, or a multizone cluster, you must enable [VLAN spanning](/docs/infrastructure/vlans/vlan-spanning.html#vlan-spanning) for your IBM Cloud infrastructure (SoftLayer) account so your worker nodes can communicate with each other on the private network. To perform this action, you need the **Network > Manage Network VLAN Spanning** [infrastructure permission](cs_users.html#infra_access), or you can request the account owner to enable it. To check if VLAN spanning is already enabled, use the `ibmcloud ks vlan-spanning-get` [command](/docs/containers/cs_cli_reference.html#cs_vlan_spanning_get). If you are using {{site.data.keyword.BluDirectLink}}, you must instead use a [Virtual Router Function (VRF)](/docs/infrastructure/direct-link/subnet-configuration.html#more-about-using-vrf). To enable VRF, contact your IBM Cloud infrastructure (SoftLayer) account representative.

--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 ks cluster-get --cluster <cluster> --showResources. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.

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.

If you have multiple VLANs for a cluster, multiple subnets on the same VLAN, or a multizone cluster, you must enable [VLAN spanning](/docs/infrastructure/vlans/vlan-spanning.html#vlan-spanning) for your IBM Cloud infrastructure (SoftLayer) account so your worker nodes can communicate with each other on the private network. To perform this action, you need the **Network > Manage Network VLAN Spanning** [infrastructure permission](cs_users.html#infra_access), or you can request the account owner to enable it. To check if VLAN spanning is already enabled, use the `ibmcloud ks vlan-spanning-get` [command](/docs/containers/cs_cli_reference.html#cs_vlan_spanning_get). If you are using {{site.data.keyword.BluDirectLink}}, you must instead use a [Virtual Router Function (VRF)](/docs/infrastructure/direct-link/subnet-configuration.html#more-about-using-vrf). To enable VRF, contact your IBM Cloud infrastructure (SoftLayer) account representative.

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

If you want a private-only cluster, you must configure a gateway appliance for network connectivity. For more information, see [Private clusters](cs_clusters_planning.html#private_clusters).

--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 ks zone-add --zone dal10 --cluster my_cluster --worker-pools pool1,pool2,pool3 --private-vlan 2294021

{: pre}

ibmcloud ks zone-network-set --zone ZONE --cluster CLUSTER --worker-pools WORKER_POOL1[,WORKER_POOL2] --private-vlan PRIVATE_VLAN [--public-vlan PUBLIC_VLAN] [-f] [-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.

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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.

Check the VLANs that are available in your cluster.

ibmcloud ks cluster-get --cluster <cluster_name_or_ID> --showResources

Example output:

Subnet VLANs
VLAN ID   Subnet CIDR         Public   User-managed
229xxxx   169.xx.xxx.xxx/29   true     false
229xxxx   10.xxx.xx.x/29      false    false

Check that the public and private VLAN IDs that you want to use are compatible. To be compatible, the Router must have the same pod ID.
```
ibmcloud ks vlans --zone <zone>
```
Example output:
```
ID        Name   Number   Type      Router         Supports Virtual Workers
229xxxx          1234     private   bcr01a.dal12   true
229xxxx          5678     public    fcr01a.dal12   true
```
Note that Router pod IDs match: `01a` and `01a`. If one pod ID were `01a` and the other were `02a`, you cannot set these public and private VLAN IDs for your worker pool.
If you do not have any VLANs available, you can order new VLANs.

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, whether you want to use the same or a different private VLAN than the one that you used for your other worker nodes. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.
The private and public VLANs must be compatible, which you can determine from the **Router** ID prefix.
--public-vlan PUBLIC_VLAN: The ID of the public VLAN. This value is required only if you want to change the public VLAN for the zone. To change the public VLAN, you must always provide a compatible private VLAN. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.
The private and public VLANs must be compatible, which you can determine from the **Router** ID prefix.
-f: Force the command to run without user prompts. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

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

{: pre}

ibmcloud ks 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}

Minimum required permissions: Operator platform role for the cluster in {{site.data.keyword.containerlong_notm}}

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 without user prompts. This value is optional.
-s: Do not show the message of the day or update reminders. This value is optional.

Example:

ibmcloud ks zone-rm --zone dal10 --cluster my_cluster

{: pre}

Files

cs_cli_reference.md

Latest commit

History

cs_cli_reference.md

File metadata and controls

Command reference

ibmcloud ks commands

API commands

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

ibmcloud ks api-key-info --cluster CLUSTER [--json] [-s]

ibmcloud ks api-key-reset [-s]

ibmcloud ks apiserver-config-get

ibmcloud ks apiserver-config-get audit-webhook --cluster CLUSTER

ibmcloud ks apiserver-config-set

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

ibmcloud ks apiserver-config-unset

ibmcloud ks apiserver-config-unset audit-webhook --cluster CLUSTER

ibmcloud ks apiserver-refresh --cluster CLUSTER [-s]

CLI plug-in usage commands

ibmcloud ks help

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

ibmcloud ks messages

Cluster commands: Management

ibmcloud ks cluster-config --cluster CLUSTER [--admin] [--export] [--network] [-s] [--yaml]

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

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

ibmcloud ks cluster-refresh --cluster CLUSTER [-f] [-s]

ibmcloud ks cluster-rm --cluster CLUSTER [--force-delete-storage] [-f] [-s]

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

ibmcloud ks clusters [--json] [-s]

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

Cluster commands: Services and integrations

ibmcloud ks cluster-service-bind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE --service SERVICE_INSTANCE_NAME [-s]

ibmcloud ks cluster-service-unbind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE --service SERVICE_INSTANCE_GUID [-s]

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

ibmcloud ks va --container CONTAINER_ID [--extended] [--vulnerabilities] [--configuration-issues] [--json]

ibmcloud ks key-protect-enable --cluster CLUSTER_NAME_OR_ID --key-protect-url ENDPOINT --key-protect-instance INSTANCE_GUID --crk ROOT_KEY_ID

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

Cluster commands: Subnets

ibmcloud ks cluster-subnet-add --cluster CLUSTER --subnet-id SUBNET [-s]

ibmcloud ks cluster-subnet-create --cluster CLUSTER --size SIZE --vlan VLAN_ID [-s]

ibmcloud ks cluster-user-subnet-add --cluster CLUSTER --subnet-cidr SUBNET_CIDR --private-vlan PRIVATE_VLAN

ibmcloud ks cluster-user-subnet-rm --cluster CLUSTER --subnet-cidr SUBNET_CIDR --private-vlan PRIVATE_VLAN

ibmcloud ks subnets [--json] [-s]

Ingress application load balancer (ALB) commands

ibmcloud ks alb-autoupdate-disable --cluster CLUSTER

ibmcloud ks alb-autoupdate-enable --cluster CLUSTER

ibmcloud ks alb-autoupdate-get --cluster CLUSTER

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

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

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

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

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

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

ibmcloud ks alb-rollback --cluster CLUSTER

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

ibmcloud ks alb-update --cluster CLUSTER

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

Infrastructure commands

ibmcloud ks credential-get [-s] [--json]

ibmcloud ks credential-set --infrastructure-api-key API_KEY --infrastructure-username USERNAME [-s]

ibmcloud ks credential-unset

ibmcloud ks machine-types --zone ZONE [--json] [-s]

ibmcloud ks vlans --zone ZONE [--all] [--json] [-s]

ibmcloud ks vlan-spanning-get [--json] [-s]

Logging commands

ibmcloud ks logging-autoupdate-disable --cluster CLUSTER

ibmcloud ks logging-autoupdate-enable --cluster CLUSTER

ibmcloud ks logging-autoupdate-get --cluster CLUSTER

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

ibmcloud ks logging-config-refresh --cluster CLUSTER [--force-update] [-s]

ibmcloud ks logging-config-rm --cluster CLUSTER [--id LOG_CONFIG_ID] [--all] [--force-update] [-s]

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

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

ibmcloud ks logging-filter-rm --cluster CLUSTER [--id FILTER_ID] [--all] [--force-update] [-s]

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

ibmcloud ks logging-collect --cluster CLUSTER --cos-bucket BUCKET_NAME --cos-endpoint ENDPOINT --hmac-key-id HMAC_KEY_ID --hmac-key HMAC_KEY --type LOG_TYPE [-s]

ibmcloud ks logging-collect-status --cluster CLUSTER [--json] [-s]

Region commands