Understanding Kasten by Veeam: A Technical Guide

Reading Time: 7 minutes

In my previous blog, I had a chance to talk about Kasten as a Kubernetes native data management platform. And why do we need Kasten in the first place.

In this blog, I will go a little bit deeper to talk about how Kasten works. I will provide a detailed, step-by-step exploration of how Kasten works and operates, covering its architecture, key components, workflows, and underlying technologies.

As a recap: Kasten (by Veeam) is a Kubernetes-native backup, disaster recovery, and mobility solution designed to simplify and automate the complexities of protecting Kubernetes applications. As containerized applications and microservices architectures become increasingly prevalent, the need for robust, Kubernetes-native backup and disaster recovery solutions has grown exponentially. Kasten K10 addresses this need by providing a comprehensive set of data management capabilities tailored for cloud-native environments.

The Architecture

Kasten K10 is built on a cloud-native architecture that aligns with Kubernetes principles. Its design emphasizes scalability, resilience, and extensibility. The architecture can be broken down into several key layers:

• Control Plane: The control plane (most likely the host where the etcd pod is running) is responsible for orchestrating all data management operations within the Kubernetes cluster. It consists of several microservices that work together to manage policies, schedules, and execution of data protection tasks.

• Data Plane: The data plane handles the actual data movement and storage operations. It interacts directly with the application data, persistent volumes, and storage systems.

• Catalog: The catalog serves as a metadata repository, storing information about protected resources, backup locations, and restore points.

• Plugin Framework: Kasten K10 uses a plugin architecture to support various storage systems, cloud providers, and application-specific backup methods.

Components

Below is a break down the essential components that make up the Kasten K10 system:

• K10 Dashboard: A web-based user interface that provides a centralized view of all data management activities and allows for policy configuration and manual operations.

• K10 API Server: Exposes RESTful APIs for programmatic interaction with K10 functionalities, enabling integration with external systems and automation workflows.

• Policy Engine: Defines and enforces data protection policies, including backup schedules, retention rules, and compliance requirements.

• Action Runners: Microservices responsible for executing specific data management tasks such as backups, restores, and disaster recovery operations.

• Location Profiles: Define and manage target locations for storing backup data, supporting various storage backends including object storage, NFS, and cloud-native storage services.

• Kanister: It is an extensible open-source framework used by Kasten’s K10 platform, and 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 code to modify any desired step performed for data lifecycle management.

Installation

Before installing Kasten, ensure that your environment meets the following prerequisites:

• A Kubernetes cluster (v1.14 or later)
• Helm package manager (v3 or later)
• Sufficient cluster resources (CPU, memory, storage) as per the below requirement types:

• Base Requirements: These are the resources needed for K10’s internal scheduling and cleanup services, which are mostly driven by monitoring and catalog scale requirements. The resource footprint for these base requirements is usually static and generally does not noticeably grow with either growth in catalog size (number of Kubernetes resources protected) or the number of applications protected.
• Disaster Recovery: These are the resources needed to perform a DR of the K10 install and are predominantly used to compress, deduplicate, encrypt, and transfer the K10 catalog to object storage. Providing additional resources can also speed up the DR operation. The DR resource footprint is dynamic and scales down to zero when a DR is not being performed.
• Backup Requirements: Resources for backup are required when data is transferred from volume snapshots to object storage or NFS file storage. While the backup requirements depend on your data, churn rate, and file system layout, the requirements are not unbounded and can easily fit in a relatively narrow band. Providing additional resources can also speed up backup operations. To prevent unbounded parallelism when protecting a large number of workloads, K10 bounds the number of simultaneous backup jobs (default 9). The backup resource footprint is dynamic and scales down to zero when a backup is not being performed.

Installation steps

1- Add the Kasten Helm repository:

helm repo add kasten https://charts.kasten.io/
helm repo update

2- Install K10 using Helm:

helm install k10 kasten/k10 --namespace=kasten-io --create-namespace

3- Verify the installation:

kubectl port-forward svc/gateway -n kasten-io 8080:8000

Once installed, access the K10 Dashboard by port-forwarding the K10 service to your local machine:

kubectl port-forward svc/gateway -n kasten-io 8080:8000

Open your browser and navigate to http://localhost:8080/k10/#/.

Workflow

I will talk here about basic workflow for both backup and restore.

Backup Workflow

• Policy Creation: Backup policies in Kasten are defined using CRDs. Policies specify the resources to be backed up, the frequency of backups, retention periods, and the storage targets. Here’s an example policy:

apiVersion: config.kio.kasten.io/v1
kind: Profile
metadata:
  name: daily-backup
spec:
  frequency: "@daily"
  retention:
    min: 7
    max: 30
  actions:
    - snapshot
    - backup
  storageLocation:
    s3:
      bucket: my-backup-bucket
      region: us-west-2

• Policy Trigger: A backup operation is initiated either by a scheduled policy or a manual request through the dashboard or API.
• Snapshotting: Kasten utilizes Kubernetes-native snapshots to capture the state of Persistent Volume Claims (PVCs). These snapshots are consistent and application-aware, ensuring data integrity.
• Resource Discovery: The K10 control plane identifies the resources to be protected based on the policy’s selection criteria (e.g., namespace, labels).
• Pre-Backup Actions: If configured, application-consistent snapshots are taken using Kanister blueprints or native Kubernetes mechanisms.
• Data Capture: The data plane captures the state of the selected resources, including persistent volume data, Kubernetes objects, and application-specific information.
• Data Transfer: Captured data is efficiently transferred to the designated backup location as defined in the location profile.
• Catalog Update: Metadata about the backup, including resource details and restore points, is recorded in the K10 catalog.
• Post-Backup Actions: Any cleanup or post-backup tasks defined in the policy are executed.

Restore Workflow

• Restore Initiation: A restore operation is triggered through the K10 dashboard or API, selecting the desired restore point. This is driven by restore policies that define what data to restore, where to restore it, and any transformation required (e.g., changing namespaces).
• Resource Preparation: K10 prepares the target namespace or cluster for the restore operation, ensuring no conflicts with existing resources.
• Data Retrieval: The data plane retrieves the necessary data from the backup location.
• Granular Restores: Kasten supports granular restores, allowing users to restore individual resources such as specific files, databases, or Kubernetes objects without restoring the entire backup.
• Cross-Cluster Restores: Kasten facilitates cross-cluster restores, enabling data recovery in different Kubernetes clusters. This is particularly useful for disaster recovery scenarios.
• Post-Restore Actions: Any application-specific restore actions defined in Kanister blueprints are executed to ensure application consistency.
• Validation: K10 performs checks to verify the successful restoration of all components.

Beyond backup and restore

Disaster Recovery

Application Mobility

Security and Compliance

Monitoring and Troubleshooting

Conclusion

Kasten by Veeam is a powerful and versatile solution for managing Kubernetes data protection. Its deep integration with Kubernetes, comprehensive feature set, and focus on simplicity make it an ideal choice for organizations looking to safeguard their containerized applications.

Refer to the official Veeam Kasten documentation for detailed configuration steps and best practices. You can also get started with Kubernetes data protection using Kasten lab through Veeam HOL