Bootstrapping Commands Reference

The k10multicluster tool is used to setup the primary cluster and to bootstrap secondary clusters for the K10 Multi-Cluster Manager.

The tool can be downloaded for various platforms from the K10 Tools Releases page.

Important

The version of the k10multicluster tool must match the version of K10 that it is being run against.

Usage

Usage:
  k10multicluster [command]

Available Commands:
  bootstrap     Run the bootstrap command
  disconnect    Disconnect a secondary cluster
  help          Help about any command
  kubeconfig    Commands to work with kubeconfig files
  setup-primary Run the setup-Primary command

Flags:
  -h, --help   help for k10multicluster

Setup-Primary Command

The setup-primary command sets up the primary cluster to be the global multi-cluster dashboard.

The following setup-primary command parameters will be required for the setup process:

Parameter

Required

Description

Default

context

no

name of the kubeconfig context to use for the primary cluster

(default: current context in kubeconfig)

kubeconfig

no

path to kubeconfig file to use for the primary cluster

(default: KUBECONFIG environment variable or ~/.kube/config)

name

yes

name for the primary cluster

none

k10-namespace

no

k10 namespace for the primary cluster

kasten-io

k10-release-name

no

k10 release name for the primary cluster

k10

labels

no

comma separated labels for the primary cluster, example foo=bar,foo1=bar1

none

ingress

yes **

external ingress for the primary cluster; should be a full URL, including path: https://<ingress>/<path_to_k10> or http://<ingress>/<path_to_k10>

none

The --replace flag can be used to re-bootstrap an exiting cluster in case of any changes. It replaces the config, if it already exists, with the latest configuration.

** Newer features such as License Management require the primary's ingress to be properly configured and accessible to secondary clusters.

Bootstrap Command

The bootstrap command adds a secondary cluster to the primary global manager.

The bootstrapping process saves any TLS configuration provided by the local kubeconfig file to ensure a secure connection can be established.

The following bootstrap command parameters will be required for the bootstrapping process:

Parameter

Required

Description

Default

primary-context

no

name of the kubeconfig context to use for the primary cluster

(default: current context in kubeconfig)

primary-kubeconfig

no

path to kubeconfig file to use for the primary cluster

(default: KUBECONFIG environment variable or ~/.kube/config)

primary-name

yes

name for the primary cluster

none

primary-k10-namespace

no

k10 namespace for the primary cluster

kasten-io

primary-k10-release-name

no

k10 release name for the primary cluster

k10

primary-cluster-ingress

yes **

external ingress for the primary cluster; should be a full URL, including path: https://<ingress>/<path_to_k10> or http://<ingress>/<path_to_k10>

none

secondary-context

no

name of the kubeconfig context to use for the secondary cluster

(default: current context in kubeconfig)

secondary-kubeconfig

no

path to kubeconfig file to use for the secondary cluster

(default: KUBECONFIG environment variable or ~/.kube/config)

secondary-name

yes

name for the secondary cluster

none

secondary-k10-namespace

no

k10 namespace for the secondary cluster

kasten-io

secondary-k10-release-name

no

k10 release name for the secondary cluster

k10

secondary-cluster-ingress

yes

external ingress for the secondary cluster; should be a full URL, including path: https://<ingress>/<path_to_k10> or http://<ingress>/<path_to_k10>

none

secondary-cluster-ingress-tls-insecure

no

don't verify the ingress TLS certificate (INSECURE; ONLY FOR TESTING)

false

secondary-labels

no

comma separated labels for the secondary cluster, example foo=bar,foo1=bar1

none

Note

The primary and secondary contexts must be different. This means that if primary-kubeconfig and secondary-kubeconfig are same, then at least one of primary-context and secondary-context is required.

The --replace flag can be used to re-bootstrap an exiting cluster in case of any changes.

The --setup-primary flag can be used to setup primary cluster along with bootstrapping the secondary cluster.

** Newer features such as License Management require the primary's ingress to be properly configured and accessible to secondary clusters.

Disconnect

The disconnect command disconnects a secondary cluster from the global manager in the primary cluster, cleaning up and provisioned resources in the secondary cluster.

The following command parameters will be required for the disconnect process:

Parameter

Required

Description

Default

primary-context

no

name of the kubeconfig context to use for the primary cluster

(default: current context in kubeconfig)

primary-kubeconfig

no

path to kubeconfig file to use for the primary cluster

(default: KUBECONFIG environment variable or ~/.kube/config)

primary-name

yes

name for the primary cluster

none

primary-k10-namespace

no

k10 namespace for the primary cluster

kasten-io

primary-k10-release-name

no

k10 release name for the primary cluster

k10

secondary-context

no

name of the kubeconfig context to use for the secondary cluster

(default: current context in kubeconfig)

secondary-kubeconfig

no

path to kubeconfig file to use for the secondary cluster

(default: KUBECONFIG environment variable or ~/.kube/config)

secondary-name

yes

name for the secondary cluster

none

secondary-k10-namespace

no

k10 namespace for the secondary cluster

kasten-io

Note

The primary and secondary contexts must be different. This means that if primary-kubeconfig and secondary-kubeconfig are same, then at least one of primary-context and secondary-context is required.