Getting Started

With K10 already installed in each cluster, a simple bootstrapping process enables the K10 multi-cluster manager. Through the bootstrapping process, one cluster will be setup as the primary. Additional clusters are then bootstrapped as secondaries.

The bootstrapping process is accomplished via the k10multicluster tool on a system having access to the Kubernetes clusters being bootstrapped.

Clusters

In a multi-cluster setup, one cluster is designated as primary, while all others are designated as secondaries.

Tip

To get started, just setting up a primary can be a great way to go! Secondaries can be added at any time.

Primary

The cluster from which the K10 Multi-Cluster Manager will be accessed is designated as primary.

The primary cluster defines policies and other configuration centrally. Centrally defined policies and configuration can then be distributed to designated clusters to be enacted.

The primary cluster also aggregates metrics so that they may be reported centrally.

Secondary

Non-primary clusters are designated as secondaries.

The secondary clusters receive policies and other configuration from the primary cluster. Once policies are distributed to a secondary, the local K10 installation enacts the policy. This ensures that the policy will continue to be enforced, even if disconnected from the primary.

Cluster Requirements

The primary requirement for setting up the K10 Multi-Cluster Manager is having K10 installed. This is true for primary as well as secondary clusters. See Installing K10 for instructions.

Additional Secondary Requirements

  • Authentication
  • Network

    • Secondary K10's ingress must be accessible by the primary

    • Secondary API Server must be accessible by the primary

Bootstrapping Clusters

The k10multicluster tool is used to setup primary cluster as a K10 Multi-Cluster Manager, and to add or remove secondary clusters. Additional information, including how to download the tool, can be found on the Bootstrapping Commands Reference page.

Note

The tool will use default values for things such as the K10 namespace, release name, and current Kubernetes context. These can be changed with additional flags.

The complete command reference can be found on the Bootstrapping Commands Reference page.

Tip

The k10multicluster tool uses Kubernetes contexts available on the local system. To see the contexts available, use the following command:

$ kubectl config get-contexts

Setup-Primary

To setup the primary cluster, use the setup-primary command:

$ k10multicluster setup-primary \
    --context=<primary_cluster_context_name> \
    --name=<primary_cluster_name>

Note

Clusters can be given any name, but names must be unique to a cluster and be a valid Kubernetes name. Follow Kuberenetes naming conventions while naming clusters.

At this point, the K10 Multi-Cluster Manager has been setup and can be accessed through the primary's K10 dashboard. See Dashboard Access for additional details.

Additional clusters may be added by following the bootstrapping directions for secondaries described below.

Bootstrap Secondary Cluster

To add a secondary cluster to the K10 Multi-Cluster Manager, use the bootstrap command.

$ k10multicluster bootstrap \
    --primary-context=<primary_cluster_context_name> \
    --primary-name=<primary_cluster_name> \
    --secondary-context=<secondary_cluster_context_name> \
    --secondary-name=<secondary_cluster_name> \
    --secondary-cluster-ingress=<secondary_ingress>/<k10_endpoint>

Note

Clusters can be given any name, but names must be unique to a cluster and be a valid Kubernetes name. Follow Kuberenetes naming conventions while naming clusters.

Note

The secondary ingress must be a full URL for the ingress. For example: https://my-cluster.example.com/k10/

Remove Secondary Cluster

To remove a secondary cluster from K10 Multi-Cluster Manager, use the remove command.

$ k10multicluster remove \
    --primary-context=<primary_cluster_context_name> \
    --primary-name=<primary_cluster_name> \
    --secondary-context=<secondary_cluster_context_name> \
    --secondary-name=<secondary_cluster_name>