copyright

lastupdated

years
2014, 2017

2017-10-13

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

CLI reference for managing clusters

{: #cs_cli_reference}

Refer to these commands to create and manage clusters. {:shortdesc}

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

Commands for creating clusters on {{site.data.keyword.Bluemix_notm}}
[bx cs cluster-config](cs_cli_devtools.html#cs_cluster_config)	[bx cs cluster-create](cs_cli_devtools.html#cs_cluster_create)	[bx cs cluster-get](cs_cli_devtools.html#cs_cluster_get)	[bx cs cluster-rm](cs_cli_devtools.html#cs_cluster_rm)	[bx cs cluster-service-bind](cs_cli_devtools.html#cs_cluster_service_bind)
[bx cs cluster-service-unbind](cs_cli_devtools.html#cs_cluster_service_unbind)	[bx cs cluster-services](cs_cli_devtools.html#cs_cluster_services)	[bx cs cluster-subnet-add](cs_cli_devtools.html#cs_cluster_subnet_add)	[bx cs clusters](cs_cli_devtools.html#cs_clusters)	[bx cs credentials-set](cs_cli_devtools.html#cs_credentials_set)
[bx cs credentials-unset](cs_cli_devtools.html#cs_credentials_unset)	[bx cs help](cs_cli_devtools.html#cs_help)	[bx cs init](cs_cli_devtools.html#cs_init)	[bx cs locations](cs_cli_devtools.html#cs_datacenters)	[bx cs machine-types](cs_cli_devtools.html#cs_machine_types)
[bx cs subnets](cs_cli_devtools.html#cs_subnets)	[bx cs vlans](cs_cli_devtools.html#cs_vlans)	[bx cs webhook-create](cs_cli_devtools.html#cs_webhook_create)	[bx cs worker-add](cs_cli_devtools.html#cs_worker_add)	[bx cs worker-get](cs_cli_devtools.html#cs_worker_get)
[bx cs worker-reboot](cs_cli_devtools.html#cs_worker_reboot)	[bx cs worker-reload](cs_cli_devtools.html#cs_worker_reload)	[bx cs worker-rm](cs_cli_devtools.html#cs_worker_rm)	[bx cs workers](cs_cli_devtools.html#cs_workers)

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

bx plugin list

{: pre}

bx cs commands

{: #cs_commands}

bx cs cluster-config CLUSTER [--admin]

{: #cs_cluster_config}

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

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--admin: Download the certificates and permission files for the Administrator rbac role. Users with these files can perform admin actions on the cluster, such as removing the cluster. This value is optional.

Example:

bx cs cluster-config my_cluster

{: pre}

bx cs cluster-create [--file FILE_LOCATION] [--hardware HARDWARE] --location LOCATION --machine-type MACHINE_TYPE --name NAME [--no-subnet] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--workers WORKER]

{: #cs_cluster_create}

To create a cluster in your organization.

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

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

name: <cluster_name>
location: <location>
machine-type: <machine_type>
private-vlan: <private_vlan>
public-vlan: <public_vlan>
hardware: <shared_or_dedicated>
workerNum: <number_workers>

Table 1.Understanding the YAML file components

Understanding the YAML file components
`name`	Replace `<cluster_name>` with a name for your cluster.
`location`	Replace `<location>` with the location where you want to create your cluster. The available locations are dependent on the region that you are logged in. To list available locations, run `bx cs locations`.
`machine-type`	Replace `<machine_type>` with the machine type that you want for your worker nodes. To list available machine types for your location, run `bx cs machine-types <location>`.
`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 `bx cs vlans <location>` 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 `bx cs vlans <location>` and look for VLAN routers that start with `fcr` (front-end router).
`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`.
`workerNum`	Replace `<number_workers>` with the number of worker nodes that you want to deploy.

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

--location LOCATION

The location where you want to create the cluster. The locations 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 lite clusters.

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

Note: When you select a location 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

The machine type that you choose impacts the amount of memory and disk space that is available to the containers that are deployed to your worker node. To list available machine types, see [bx cs machine-types LOCATION](cs_cli_reference.html#cs_machine_types). This value is required for standard clusters and is not available for lite clusters.

--name NAME

The name for the cluster. This value is required.

--no-subnet

Include the flag to create a cluster without a portable subnet. The default is to not use the flag and to create a subnet in your IBM Bluemix Infrastructure (SoftLayer) portfolio. This value is optional.

--private-vlan PRIVATE_VLAN

This parameter is not available for lite clusters.
If this standard cluster is the first standard cluster that you create in this location, 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 location or created a private VLAN in IBM Bluemix Infrastructure (SoftLayer) before, you must specify that private VLAN.
Note: The public and private VLANs that you specify with the create command must match. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). The number and letter combination after those prefixes must match to use those VLANs when creating a cluster. Do not use public and private VLANs that do not match to create a cluster.

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

--public-vlan PUBLIC_VLAN

This parameter is not available for lite clusters.
If this standard cluster is the first standard cluster that you create in this location, 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 location or created a public VLAN in IBM Bluemix Infrastructure (SoftLayer) before, you must specify that public VLAN.
Note: The public and private VLANs that you specify with the create command must match. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). The number and letter combination after those prefixes must match to use those VLANs when creating a cluster. Do not use public and private VLANs that do not match to create a cluster.

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

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

Note: Every worker node is assigned a unique worker node ID and domain name that must not be manually changed after the cluster is created. Changing the ID or domain name prevents the Kubernetes master from managing your cluster.

Examples:

Example for a standard cluster: {: #example_cluster_create}

bx cs cluster-create --location dal10 --public-vlan my_public_vlan_id --private-vlan my_private_vlan_id --machine-type u1c.2x4 --name my_cluster --hardware shared --workers 2

{: pre}

Example for a lite cluster:

bx cs cluster-create --name my_cluster

{: pre}

Example for a {{site.data.keyword.Bluemix_notm}} Dedicated environment:

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

{: pre}

bx cs cluster-get CLUSTER

{: #cs_cluster_get}

View information about a cluster in your organization.

Command options:

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

Example:

bx cs cluster-get my_cluster

{: pre}

bx cs cluster-rm [-f] CLUSTER

{: #cs_cluster_rm}

Remove a cluster from your organization.

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the removal of a cluster with no user prompts. This value is optional.

Example:

bx cs cluster-rm my_cluster

{: pre}

bx cs cluster-service-bind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_GUID

{: #cs_cluster_service_bind}

Add a {{site.data.keyword.Bluemix_notm}} service to a cluster.

Tip: For {{site.data.keyword.Bluemix_notm}} Dedicated users, see Adding {{site.data.keyword.Bluemix_notm}} services to clusters in {{site.data.keyword.Bluemix_notm}} Dedicated (Closed Beta).

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
KUBERNETES_NAMESPACE: The name of the Kubernetes namespace. This value is required.
SERVICE_INSTANCE_GUID: The ID of the {{site.data.keyword.Bluemix_notm}} service instance that you want to bind. This value is required.

Example:

bx cs cluster-service-bind my_cluster my_namespace my_service_instance_GUID

{: pre}

bx cs cluster-service-unbind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_GUID

{: #cs_cluster_service_unbind}

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

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

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
KUBERNETES_NAMESPACE: The name of the Kubernetes namespace. This value is required.
SERVICE_INSTANCE_GUID: The ID of the {{site.data.keyword.Bluemix_notm}} service instance that you want to remove. This value is required.

Example:

bx cs cluster-service-unbind my_cluster my_namespace my_service_instance_GUID

{: pre}

bx cs cluster-services CLUSTER [--namespace KUBERNETES_NAMESPACE] [--all-namespaces]

{: #cs_cluster_services}

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

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
--namespace KUBERNETES_NAMESPACE, -n KUBERNETES_NAMESPACE: Include the services that are bound to a specific namespace in a cluster. This value is optional.
--all-namespaces: Include the services that are bound to all of the namespaces in a cluster. This value is optional.

Example:

bx cs cluster-services my_cluster --namespace my_namespace

{: pre}

bx cs cluster-subnet-add CLUSTER SUBNET

{: #cs_cluster_subnet_add}

Make a subnet in a IBM Bluemix Infrastructure (SoftLayer) account available to a specified cluster.

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

Command options:

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

Example:

bx cs cluster-subnet-add my_cluster subnet

{: pre}

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

{: #cs_cluster_user_subnet_add}

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

This private subnet is not one provided by IBM Bluemix Infrastructure (SoftLayer). As such, you must configure any inbound and outbound network traffic routing for the subnet. If you want to add an IBM Bluemix Infrastructure (SoftLayer) subnet, use the bx cs cluster-subnet-add command.

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

Command options:

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

Example:

bx cs cluster-user-subnet-add my_cluster 192.168.10.0/29 1502175

{: pre}

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

{: #cs_cluster_user_subnet_rm}

Remove your own private subnet from a specified cluster.

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

Command options:

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

Example:

bx cs cluster-user-subnet-rm my_cluster 192.168.10.0/29 1502175

{: pre}

bx cs cluster-update [-f] CLUSTER

{: #cs_cluster_update}

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

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

Command options:

CLUSTER: The name or ID of the cluster. This value is required.
-f: Use this option to force the update of the master with no user prompts. This value is optional.

Example:

bx cs cluster-update my_cluster

{: pre}

bx cs clusters

{: #cs_clusters}

View a list of clusters in your organization.

Command options:

None

Example:

bx cs clusters

{: pre}

bx cs credentials-set --infrastructure-api-key API_KEY --infrastructure-username USERNAME

{: #cs_credentials_set}

Set IBM Bluemix Infrastructure (SoftLayer) account credentials for your {{site.data.keyword.Bluemix_notm}} account. These credentials allow you to access the IBM Bluemix Infrastructure (SoftLayer) portfolio through your {{site.data.keyword.Bluemix_notm}} account.

Note: Do not set multiple credentials for one {{site.data.keyword.Bluemix_notm}} account. Every {{site.data.keyword.Bluemix_notm}} account is linked to one IBM Bluemix Infrastructure (SoftLayer) portfolio only.

Command options:

--infrastructure-username USERNAME: An IBM Bluemix Infrastructure (SoftLayer) account username. This value is required.

--infrastructure-api-key API_KEY

An IBM Bluemix Infrastructure (SoftLayer) account API key. This value is required.

To generate an API key:

Log in to the [IBM Bluemix Infrastructure (SoftLayer) portal ![External link icon](../icons/launch-glyph.svg "External link icon")](https://control.softlayer.com/).
Select Account, and then Users.
Click Generate to generate an IBM Bluemix 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 Bluemix Infrastructure (SoftLayer) portal ![External link icon](../icons/launch-glyph.svg "External link icon")](https://control.softlayer.com/).
Select Account, and then Users.
Click View to see your existing API key.
Copy the API key to use in this command.

Example:

bx cs credentials-set --infrastructure-api-key API_KEY --infrastructure-username USERNAME

{: pre}

bx cs credentials-unset

{: #cs_credentials_unset}

Remove IBM Bluemix Infrastructure (SoftLayer) account credentials from your {{site.data.keyword.Bluemix_notm}} account. After removing the credentials, you cannot access the IBM Bluemix Infrastructure (SoftLayer)} portfolio through your {{site.data.keyword.Bluemix_notm}} account anymore.

Command options:

None

Example:

bx cs credentials-unset

{: pre}

bx cs help

{: #cs_help}

View a list of supported commands and parameters.

Command options:

None

Example:

bx cs help

{: pre}

bx cs init [--host HOST]

{: #cs_init}

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

Command options:

--host HOST

The {{site.data.keyword.containershort_notm}} API endpoint that you want to use. This value is optional. Examples:

<ul>
<li>US-South:

<pre class="codeblock">
<code>bx cs init --host https://us-south.containers.bluemix.net</code>
</pre></li>

<li>US-East:

<pre class="codeblock">
<code>bx cs init --host https://us-east.containers.bluemix.net</code>
</pre>
<p><strong>Note</strong>: US-East is available for use with CLI commands only.</p></li>

<li>UK-South:

<pre class="codeblock">
<code>bx cs init --host https://uk-south.containers.bluemix.net</code>
</pre></li>

<li>EU-Central:

<pre class="codeblock">
<code>bx cs init --host https://eu-central.containers.bluemix.net</code>
</pre></li>

<li>AP-South:

<pre class="codeblock">
<code>bx cs init --host https://ap-south.containers.bluemix.net</code>
</pre></li></ul>

bx cs locations

{: #cs_datacenters}

View a list of available locations for you to create a cluster in.

Command options:

None

Example:

bx cs locations

{: pre}

bx cs machine-types LOCATION

{: #cs_machine_types}

View a list of available machine types for your worker nodes. Each machine type includes the amount of virtual CPU, memory, and disk space for each worker node in the cluster.

Command options:

LOCATION: Enter the location where you want to list available machine types. This value is required. Review [available locations](cs_regions.html#locations).

Example:

bx cs machine-types LOCATION

{: pre}

bx cs subnets

{: #cs_subnets}

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

Command options:

None

Example:

bx cs subnets

{: pre}

bx cs vlans LOCATION

{: #cs_vlans}

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

Command options:

LOCATION: Enter the location where you want to list your private and public VLANs. This value is required. Review [available locations](cs_regions.html#locations).

Example:

bx cs vlans dal10

{: pre}

bx cs webhook-create --cluster CLUSTER --level LEVEL --type slack --URL URL

{: #cs_webhook_create}

Create webhooks.

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, such as slack. Only slack is supported. This value is required.
--URL URL: The URL for the webhook. This value is required.

Example:

bx cs webhook-create --cluster my_cluster --level Normal --type slack --URL http://github.com/<mywebhook>

{: pre}

bx cs worker-add --cluster CLUSTER [--file FILE_LOCATION] [--hardware HARDWARE] --machine-type MACHINE_TYPE --number NUMBER --private-vlan PRIVATE_VLAN --public-vlan PUBLIC_VLAN

{: #cs_worker_add}

Add worker nodes to your standard cluster.

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 your cluster. Instead of defining your additional worker nodes by using the options provided in this command, you can use a YAML file. This value is optional.

Note: If you provide the same option in the command as 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>
location: <location>
machine-type: <machine_type>
private-vlan: <private_vlan>
public-vlan: <public_vlan>
hardware: <shared_or_dedicated>
workerNum: <number_workers>

Table 2. 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.
`location`	Replace `<location>` with the location where you want to deploy your worker nodes. The available locations are dependent on the region that you are logged in. To list available locations, run `bx cs locations`.
`machine-type`	Replace `<machine_type>` with the machine type that you want for your worker nodes. To list available machine types for your location, run `bx cs machine-types <location>`.
`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 `bx cs vlans <location>` 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 `bx cs vlans <location>` and look for VLAN routers that start with `fcr` (front-end router).
`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.
`workerNum`	Replace `<number_workers>` with the number of worker nodes that you want to deploy.

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

The machine type that you choose impacts the amount of memory and disk space that is available to the containers that are deployed to your worker node. This value is required. To list available machine types, see [bx cs machine-types LOCATION](cs_cli_reference.html#cs_machine_types).

--number NUMBER

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

--private-vlan PRIVATE_VLAN

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

Note: The public and private VLANs that you specify must match. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). The number and letter combination after those prefixes must match to use those VLANs when creating a cluster. Do not use public and private VLANs that do not match to create a cluster.

--public-vlan PUBLIC_VLAN

The public VLAN that was specified when the cluster was created. This value is optional.

Note: The public and private VLANs that you specify must match. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). The number and letter combination after those prefixes must match to use those VLANs when creating a cluster. Do not use public and private VLANs that do not match to create a cluster.

Examples:

bx cs worker-add --cluster my_cluster --number 3 --public-vlan my_public_vlan_id --private-vlan my_private_vlan_id --machine-type u1c.2x4 --hardware shared

{: pre}

Example for {{site.data.keyword.Bluemix_notm}} Dedicated:

bx cs worker-add --cluster my_cluster --number 3 --machine-type u1c.2x4

{: pre}

bx cs worker-get WORKER_NODE_ID

{: #cs_worker_get}

View details of a worker node.

Command options:

WORKER_NODE_ID: The ID for a worker node. Run bx cs workers CLUSTER to view the IDs for the worker nodes in a cluster. This value is required.

Example:

bx cs worker-get WORKER_NODE_ID

{: pre}

bx cs worker-reboot [-f] [--hard] CLUSTER WORKER [WORKER]

{: #cs_worker_reboot}

Reboot the worker nodes in a cluster. If a problem exists with a worker node, first try rebooting the worker node, which restarts it. If the reboot does not solve the issue, then try the worker-reload command. The state of the workers does not change during the reboot. The state remains deployed, but the status updates.

Command options:

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

Example:

bx cs worker-reboot my_cluster my_node1 my_node2

{: pre}

bx cs worker-reload [-f] CLUSTER WORKER [WORKER]

{: #cs_worker_reload}

Reload the worker nodes in a cluster. If a problem exists with a worker node, first try rebooting the worker node. If the reboot does not solve the problem, try the worker-reload command, which re-loads all of the necessary configurations for the worker node.

Command options:

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

Example:

bx cs worker-reload my_cluster my_node1 my_node2

{: pre}

bx cs worker-rm [-f] CLUSTER WORKER [WORKER]

{: #cs_worker_rm}

Remove one or more worker nodes from a cluster.

Command options:

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

Example:

bx cs worker-rm my_cluster my_node1 my_node2

{: pre}

bx cs worker-update [-f] CLUSTER WORKER [WORKER]

{: #cs_worker_update}

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

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

Command options:

CLUSTER: The name or ID of the cluster where you list available worker nodes. This value is required.
-f: Use this option to force the update of the master with no user prompts. This value is optional.
WORKER: The ID of one or more worker nodes. Use a space to list multiple worker nodes. This value is required.

Example:

bx cs worker-update my_cluster my_node1 my_node2

{: pre}

bx cs workers CLUSTER

{: #cs_workers}

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

Command options:

CLUSTER: The name or ID of the cluster where you list available worker nodes. This value is required.

Example:

bx cs workers mycluster

{: pre}

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cs_cli_devtools.md

cs_cli_devtools.md

CLI reference for managing clusters

bx cs commands

bx cs cluster-config CLUSTER [--admin]

bx cs cluster-create [--file FILE_LOCATION] [--hardware HARDWARE] --location LOCATION --machine-type MACHINE_TYPE --name NAME [--no-subnet] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--workers WORKER]

bx cs cluster-get CLUSTER

bx cs cluster-rm [-f] CLUSTER

bx cs cluster-service-bind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_GUID

bx cs cluster-service-unbind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_GUID

bx cs cluster-services CLUSTER [--namespace KUBERNETES_NAMESPACE] [--all-namespaces]

bx cs cluster-subnet-add CLUSTER SUBNET

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

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

bx cs cluster-update [-f] CLUSTER

bx cs clusters

bx cs credentials-set --infrastructure-api-key API_KEY --infrastructure-username USERNAME

bx cs credentials-unset

bx cs help

bx cs init [--host HOST]

bx cs locations

bx cs machine-types LOCATION

bx cs subnets

bx cs vlans LOCATION

bx cs webhook-create --cluster CLUSTER --level LEVEL --type slack --URL URL

bx cs worker-add --cluster CLUSTER [--file FILE_LOCATION] [--hardware HARDWARE] --machine-type MACHINE_TYPE --number NUMBER --private-vlan PRIVATE_VLAN --public-vlan PUBLIC_VLAN

bx cs worker-get WORKER_NODE_ID

bx cs worker-reboot [-f] [--hard] CLUSTER WORKER [WORKER]

bx cs worker-reload [-f] CLUSTER WORKER [WORKER]

bx cs worker-rm [-f] CLUSTER WORKER [WORKER]

bx cs worker-update [-f] CLUSTER WORKER [WORKER]

bx cs workers CLUSTER

Files

cs_cli_devtools.md

Latest commit

History

cs_cli_devtools.md

File metadata and controls

CLI reference for managing clusters

bx cs commands

bx cs cluster-config CLUSTER [--admin]

bx cs cluster-create [--file FILE_LOCATION] [--hardware HARDWARE] --location LOCATION --machine-type MACHINE_TYPE --name NAME [--no-subnet] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--workers WORKER]

bx cs cluster-get CLUSTER

bx cs cluster-rm [-f] CLUSTER

bx cs cluster-service-bind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_GUID

bx cs cluster-service-unbind CLUSTER KUBERNETES_NAMESPACE SERVICE_INSTANCE_GUID

bx cs cluster-services CLUSTER [--namespace KUBERNETES_NAMESPACE] [--all-namespaces]

bx cs cluster-subnet-add CLUSTER SUBNET

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

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

bx cs cluster-update [-f] CLUSTER

bx cs clusters

bx cs credentials-set --infrastructure-api-key API_KEY --infrastructure-username USERNAME

bx cs credentials-unset

bx cs help

bx cs init [--host HOST]

bx cs locations

bx cs machine-types LOCATION

bx cs subnets

bx cs vlans LOCATION

bx cs webhook-create --cluster CLUSTER --level LEVEL --type slack --URL URL

bx cs worker-add --cluster CLUSTER [--file FILE_LOCATION] [--hardware HARDWARE] --machine-type MACHINE_TYPE --number NUMBER --private-vlan PRIVATE_VLAN --public-vlan PUBLIC_VLAN

bx cs worker-get WORKER_NODE_ID

bx cs worker-reboot [-f] [--hard] CLUSTER WORKER [WORKER]

bx cs worker-reload [-f] CLUSTER WORKER [WORKER]

bx cs worker-rm [-f] CLUSTER WORKER [WORKER]

bx cs worker-update [-f] CLUSTER WORKER [WORKER]

bx cs workers CLUSTER