Step 7.1 Multicluster Manager
The K10 multi-cluster manager simplifies K10 operations across multiple Kubernetes clusters.
Administrators define primary-secondary relationships between their K10 instances. Primary K10 instances provide a single entrypoint and dashboard for administrators to manage secondary instances. Additionally, Primary K10 instance can distribute the licenses to the secondary instances through license leasing, eventually reducing the overhead to manage licenses in multiple places.
K10 resources, like Policies and Profiles, are defined in the primary instance and distributed to secondary instances. Secondary instances enact their policies and the secondaries' actions and metrics are summarized in the primary instance.
There are multiple ways to bootstrap K10 instances for the multicluster setup, we will be using `k10multicluster` tool to show an example on how to setup multicluster manager with K10.
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.
Bootstrap the primary K10 instance
To setup the primary cluster, use the setup-primary command
k10multicluster setup-primary \
--context=<primary_cluster_context_name> \
--name=<primary_cluster_name> \
--ingress=<primary_cluster_ingress>/<k10_endpoint>Clusters can be given any name, but names must be unique to a cluster and be a valid Kubernetes name. Follow Kubernetes 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.
Bootstrap the secondary k10 instance
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_cluster_ingress>/<k10_endpoint>The flag –primary-name must match the name of the primary k10 instance that we bootstrapped in the previous step. Apart for K10multicluster tool, Secondary K10 instances can be bootstrapped from the Primary cluster K10 UI. Below interactive demo shows how to bootstrap the secondary k10 from the UI.
Step 7.2 Kanister Blueprints
Kanister, an extensible open-source framework used by Kasten's K10 platform, can be used for application-level data management on Kubernetes. It allows domain experts to capture application specific data management tasks in blueprints which can be easily shared and extended. The framework takes care of the tedious details around execution on Kubernetes and presents a homogeneous operational experience across applications at scale. Further, it gives you a natural mechanism to extend the K10 platform by adding your own code to modify any desired step performed for data lifecycle management.
K10 defaults to volume snapshot operations when capturing data, but there are situations where customization is required. For example, the best way to protect your application's data may be to take a logical dump of the database. Or in some cases, the databases need quiescing to prepare for backups. This requires using tools specific to that database.
Kanister uses Blueprints to define these database-specific workflows and open-source Blueprints are available for several popular applications. It is also simple to customize existing Blueprints or add new ones.
When configured to do so, K10 will automatically use Kanister Blueprints and manage the resulting application-level Kanister artifacts.
This documentation has a few examples on how to extend K10 workflows with logical or application consistent blueprints.
Kanister blueprints can be leveraged to customize the way your applications or databases are backed up to ensure consistency.
Read the blog here for an example of using an application consistent blueprint to backup a Pacman application.
Protecting Openshift Virtualization VMs (Virtual Machine)
OpenShift Virtualization is an add-on to the OpenShift Container Platform that allows the creation and execution of Virtual Machine workloads alongside container workloads. Once installed on the OpenShift Container Platform, OpenShift Virtualization introduces some custom resources that can be used to manage Virtual Machine workloads. Read the official documentation to learn more about OpenShift Virtualization.
K10 natively supports protecting such VMs and the block devices that these VMs use.
Step 7.4 GitOps Deployment Strategy
Veeam Kasten K10 empowers you to streamline Kubernetes data protection by embracing GitOps workflows. This powerful combination allows you to leverage familiar GitOps tools like ArgoCD and FluxCD. By deploying K10 Helm charts stored in your Git repository, you establish a single source of truth for your deployments.
Kasten K10 further enhances this approach by supporting declarative creation of custom resources like Policies, Profiles, TransformSets, Blueprints, and so on. These resources offer the flexibility of being templated and versioned within your Git repository. This ensures consistent, auditable deployments across your clusters, always reflecting the desired state for your K10 data protection strategy.
K10 takes GitOps integration a step further by allowing you to create data management actions like backup, export, restore, and import declaratively. This declarative approach empowers you to seamlessly incorporate these actions into your Continuous Deployment (CD) workflows and GitOps model.
For example, you can configure K10 to trigger pre-deployment backups using preSync hooks. This ensures that a recent backup is created before any deployment changes are applied to your environment, providing a critical safety net in case of unforeseen issues.
By embracing K10's declarative data management capabilities, you can establish a robust and automated data protection strategy that aligns perfectly with your GitOps practices. This not only simplifies management but also enhances the reliability and consistency of your Kubernetes deployments.
With the major release of K10 version 6.5, Multicluster Manager deployment and bootstrap is also simplified to use GitOps based deployment pattern.
Please refer K10s API documentation for more information around creating these custom resources.
Step 7.5 Transforms in "Veeam Kasten for Kubernetes"
Overview:
This guide explains how to leverage transforms to modify Kubernetes resources during a restore using Kasten K10. Transforms allow you to customize restored resources to fit your target environment before they are recreated.
What are Transforms?
Transforms are loosely modeled on JSON Patch and act as instructions for modifying most of Kubernetes resources before they are deployed in the target environment. They offer functionalities similar to JSON Patch, enabling you to:
- Add new elements to a resource
- Remove unwanted elements from a resource
- Copy or move existing elements within a resource
- Replace existing elements with new values
Transforms can also be used to conditionally modify resources based on the existence of specific elements.
Commands:
- test: Checks for element existence or matches.
- add: Inserts new elements.
- remove: Deletes elements.
- copy: Duplicates elements.
- move: Relocates elements.
- replace: Replaces elements.
Here are some examples of resources that can be modified:
- ConfigMaps
- CronJobs
- DaemonSets
- Deployments
- Ingresses
- ClusterRoles/Roles
- ClusterRoleBindings/RoleBindings
- PersistentVolumeClaims (PVC)/PersistentVolumes (PV)
- Pods
- Secrets
- ServiceAccounts
- Services
- StatefulSets
How to Create a Transform
Transforms are loosely modeled on JSON Patch. And can be created using the "Veeam Kasten" GUI json Here's a basic structure:
- Define the Subject: Specify the resource to be transformed, such as persistentvolumeclaims.
- Create Transform Name: Choose a name that describes the transformation, like editStorageClassName.
- Defines a JSON Patch operation, using paths and values.
Example: Transform to change the storage class on a persistent volume claim (pvc):
transforms:
- subject:
resource: persistentvolumeclaims
name: persistentvolumeclaims
json:
- op: replace
path: /spec/storageClassName
regex: ^ssd$
value: gp2Additionally, you can create a TransformSet, a custom resource (CR) used to save and reuse a set of Transforms for use in RestoreActions and Policies.
It is recommended to create from “Veeam kasten” GUI
Example:
apiVersion: config.kio.kasten.io/v1alpha1
kind: TransformSet
metadata:
creationTimestamp: "2024-06-26T15:04:56Z"
generation: 1
name: replace-sc
namespace: kasten-io
resourceVersion: "373426"
uid: d1868d65-6fb9-4a2d-b321-4f21e6dd7e18
spec:
transforms:
- json:
- op: replace
path: /spec/storageClassName
value: storage-sc
name: replace-sc
subject:
resource: persistentvolumeclaims
status:
observedGeneration: 1
validation: Success
If you need more help getting started, you can post your question in the comments section below or contact us at veeam.university@veeam.com any time and a representative from the Customer Success team will be there to assist you.