In this blog post I’m going to cover setting up the Multi-cluster support for Kasten when you’ve installed the software to multiple Kubernetes clusters.
One K10 cluster you have deployed will become the primary node. You will use this node and dashboard interface to access the cluster UI.
- The primary cluster defines policies and other configuration centrally. Centrally defined policies and configuration can then be distributed to designated clusters to be enacted.
Additional clusters are then added in and are called 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.
- Token Authentication must be used
- Secondary K10’s ingress must be accessible by the primary
- Secondary API Server must be accessible by the primary
- Run the tool on a bastion host that has connectivity using kubectl to all of the clusters you want to bring together.
Download the appropriate version of the tool to match your K10 versions
Set the tool as executable
Move the tool to your /usr/local/bin/ folder
curl -LJO https://github.com/kastenhq/external-tools/releases/download/4.0.9/k10multicluster_4.0.9_linux_amd64 chmod +x k10multicluster_4.0.9_linux_amd64 sudo mv k10multicluster_4.0.9_linux_amd64 /usr/local/bin/k10multicluster
Next let’s list out our available clusters we can connect to from our node
kubectl config get-contexts
Now we are ready to setup our primary cluster by running the following command:
k10multicluster setup-primary \ --context=<primary_cluster_context_name> \ --name=<primary_cluster_name> # My Demo example k10multicluster setup-primary --context=tkg-wld-01-admin@tkg-wld-01-admin --name=tkg-wld-01-admin
If I visit the UI on the Primary Cluster dashboard, I will see the cluster option:
Now we continue to configure my secondary clusters using the bootstrap argument:
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> # My Demo Example k10multicluster bootstrap \ --primary-context=tkg-wld-01-admin@tkg-wld-01 \ --primary-name=tkg-wld-01-admin \ --secondary-context=tkg-wld-02-admin@tkg-wld-02 \ --secondary-name=tkg-wld-02-admin \ --secondary-cluster-ingress=http://192.168.200.58/k10
Now when you visit your Primary Cluster Dashboard, you will see the clusters added. You may have a message about setting up the permissions to a second cluster if the tool has been unsuccessful in its initial configuration. This can be rectified in the UI as per the below screenshot, Kasten even helpful populates the configuration for you.
You can also add clusters in directly in the UI by uploading your kubeconfig file.
By creating the multi-cluster configuration, we enable the ability to have centralised global configurations. Above we touched on the first Global configuration, permissions. Other areas that can be configured Globally are:
- These are the location and infrastructure profiles to define where data is held externally from the Kubernetes cluster, and the platform hosting the Kubernetes cluster.
- This is the protection policy configuration to select artifacts and set the schedule, and where the protected data is stored.
- Provide a way to describe the relationship between globally defined resources and the clusters to which they should be distributed
We can also see on the home screen the data usage across all clusters as well as recent activity.
For my example, I’m going to configure a location and infrastructure policy, a protection policy, then a distribution to push this two of my clusters. As the first policies are the same as configuring on a local k10 cluster. I will simply show the screenshots, you can find more details here.
Now to configure a distribution policy to push these settings to my K10 clusters, one Tanzu Kubernetes Grid Cluster and one OpenShift Cluster.
- Select your clusters from either labels or the cluster objects
- Select the resources available as necessary and click “Add Distribution”
You will then see the policy object, and the status will change once the sync has completed to each of the clusters.
If I click into each of my clusters, I can now see the policies have been pushed.
Removing a cluster from the Multi-Cluster dashboard is quite easy, but can only be completed using the CLI Tool.
k10multicluster disconnect \ --primary-context=<primary_cluster_context_name> \ --primary-name=<primary_cluster_name> \ --secondary-context=<secondary_cluster_context_name> \ --secondary-name=<secondary_cluster_name> # My Demo Example k10multicluster disconnect \ --primary-context=tkg-wld-01-admin@tkg-wld-01 \ --primary-name=tkg-wld-01-admin \ --secondary-context=tkg-wld-02-admin@tkg-wld-02 \ --secondary-name=tkg-wld-02-admin
Setting up the Multi-Cluster feature for Kasten is quite easy. I like how it’s proxied via a primary cluster as well. Meaning I only need to make one UI externally accessible to my users. If needed, I could setup an “empty” K10 instance that is used as the primary, to connect to all my K10 instances for each cluster which is deployed to protect data.
As usual, the Kasten documentation is simple and easy to follow. I only created this post to add some colour, images, and examples.
You can find my other Kasten Blog posts & recordings below:
- How to Install and Configure Kasten:
- How to backup and restore your container workloads using Kasten
- How to update Kasten to the latest version
- VMUG Recording – Protecting your Tanzu Kubernetes Workload with Kasten by Veeam
- Tanzu Mission Control – Using custom policies to ensure Kasten protects a deployed application
The post Configuring Kasten Multi-Cluster Manager across Tanzu and OpenShift appeared first on vEducate.co.uk.