A while back, Veeam acquired a company called Kasten, which provides backup and disaster recovery capabilities for Kubernetes. Since I’ve been working with Veeam for a while I decided to take a closer look at the capabilities and how to deploy it against Azure Kubernetes Service (AKS).
Kasten provides direct integration with different public cloud storage vendors (AWS, GCP, and as well CSI integration. Now CSI is a standard for exposing arbitrary block and file storage systems to containerized workloads. So, storage services that are not supported as part of the native cloud deployment such as Azure NetApp Files can still use this (or use Trident)
As an example, in Microsoft Azure, Kasten plugs into the Azure Resource Manager and utilizes a Computer snapshot API under Microsoft. Compute/snapshots which is a disk snapshot.
So, if you want to try this yourself you need to have
- Access to kubectl or other means to interact with Kubernetes using either Cloud Shell, CLI or others.
- Access to a Service Principal Account in Azure (Which has Compute Read/Write on the AKS Cluster)
The easiest way to install Kasten is by using the predefined Helm Charts that are available.
Prerequisites
1: Add the Helm Chart repository
helm repo add kasten https://charts.kasten.io/
2: Create a namespace for kasten, which all the pods for Kasten will be deployed.
kubectl create namespace kasten-io
3: Run the pre-check tool.
curl https://docs.kasten.io/tools/k10_primer.sh | bash
This tool will validate if the Kubernetes settings meet Kasten requirements and will catalog the available Storage Classes to which the cluster has access. As seen here it will detect Azure Storage classes running on Azure disks.
One this is done we are ready to install Kasten. Now the deployment of Kasten is done from the helm repository that is added, and as mentioned we need to have a service principal that has access to Azure Resource Manager to be able to do the snapshot and interact with the cluster.
Installing Kasten
The installation is done using the following command.
helm install k10 kasten/k10 --namespace=kasten-io \ --set secrets.azureTenantId=<tenantID> \ --set secrets.azureClientId=<azureclient_id> \ --set secrets.azureClientSecret=<azureclientsecret>
- TenantID = Azure Active Directory Tenant
- Azure Client ID = Application ID
- Azure Client Secret = Application Secret
All these can be configured using Azure AD application registration.
Once you have run the command you can monitor the progress using, which will monitor the deployment status of the pods and the service.
kubectl get pods --namespace kasten-io --watch
Once the deployment is done you can access the Kasten dashboard by access the exposed port endpoint of the gateway
kubectl --namespace kasten-io port-forward service/gateway 8080:8000
Just remember to use the specified URL (there is URL gateway in between here) which will be exposed at HTTP://127.0.0.1:8080/k10/#/ it should be noted that this management plane is for a single AKS cluster, if you want to have a multi-cluster view you need to setup the new K10 Multi-Cluster Manager –> Kubernetes Multi-cluster and Multi-tenancy with Kasten K10 3.0
Then you should get a screen like this. (Without the predefined Policy)
It should be noted here that an application in Kasten is defined as a collection of namespaced Kubernetes resources. So for instance, if I click on applications, I will find namespaces and applications running inside them (also with grouped services, secrets, configmaps, blueprints and workloads)
Now before defining a backup policy I want also add Azure object storage to store the backups to store data outside of the cluster. Kasten supports the use of Azure blob storage to store snapshots. This can be defined by going into Settings –> Locations –> Location Profiles –> New Profile. Then defining information about a Azure Storage Account that is precreated. NOTE: You also need to define the Azure location where it is in (and I have no idea why….)
Once a storage account is defined, we can then configure backup jobs.
Setting up backup
Backup jobs can be defined using the dashboard as well. Now I have a predeployed WordPress helm chart that runs WordPress frontend and MariaDB backend which is running within its own namespace.
In this profile I want to deploy a backup profile which runs snapshot every night and also exports backup to the Azure blob storage. Then doing the backup for WordPress defined namespace
Then the policy is created, and I have the option to run it once just to verify the backup
Now to be clear, doing this by the UI which is rather good you can also define the backup policies as code as well using the defined YAML syntax.
apiVersion: config.kio.kasten.io/v1alpha1 kind: Policy metadata: name: wordpressbackup namespace: kasten-io spec: comment: Backup for WordPress Services frequency: '@hourly' retention: hourly: 24 daily: 7 actions: - action: backup selector: matchLabels: app.kubernetes.io/instance: wordpress
Then run a kubectl apply -f nameofyaml.yaml
If you want more advanced operators, you can look through the documentation here –> Policies — K10 3.0.12 documentation (kasten.io) or define a custom policy using the UI then export it from the UI using the YAML view. You can even use Terraform to deploy the Kasten policy settings using the Kubernetes provider for Terraform to build an automated backup policy that can be deployed together with the application.
So this was the first post on how to getting started with Kasten, in the next post we will take a look at some of the more advanced restore capabilities and DR features.