This article is based on reporting originally published by The New Stack.
The Problem Kasten Was Built to Solve
Like many successful startups, Kasten emerged from direct, personal experience with a hard problem. Co-founders Niraj Tolia and Vaibhav Kamra joined EMC through the 2014 acquisition of Maginatics, a company that provided a secure global namespace across storage platforms. When Tolia’s team began migrating their product’s control plane to Google Cloud and Kubernetes in 2015, the experience was painful enough to spark an idea.
“We were discovering integration issues much earlier in the lifecycle of product development than what we’ve traditionally seen,” Tolia explained. “This is five years ago, so that’s when the lightbulb went off in my head that this is going to be the future.”
At EMC, the team was working within the data protection group and found that existing tooling simply didn’t scale to Kubernetes workloads. Scripts were hand-crafted, brittle, and impractical at any meaningful scale. Kasten was founded in 2017 — its name taken from the German word for “box” or “container” — to build data management tooling that was truly cloud-native from day one.
Why Traditional Backup Tools Fail in Kubernetes Environments
Traditional data management platforms were designed for virtual machines with relatively static configurations. Kubernetes changes the fundamental assumptions those tools rely on:
- Component explosion: Tolia describes a roughly 100x increase in the number of discrete components that need to be captured compared to VM-based workloads.
- Frequent rescheduling: Pods are ephemeral and can be rescheduled at any time, making point-in-time snapshots taken at the infrastructure layer incomplete or inconsistent.
- No VM-to-application mapping: Legacy backup tools rely on VM identity to understand application boundaries. In Kubernetes, that mapping doesn’t exist.
- Network policy conflicts: Some legacy vendors require firewall exceptions or open network policies to access cluster internals — an approach that directly conflicts with Kubernetes security models.
- Constantly changing applications: Microservice architectures deploy frequently, so backup tooling must continuously rediscover application topology rather than relying on static configuration.
The K10 Platform: Architecture and Key Concepts
Kasten’s K10 platform is itself deployed as a Kubernetes application — what Tolia describes as a “critical cluster” pattern. K10 installs into its own namespace and uses a Kubernetes service account to discover and orchestrate other applications running on the same cluster. It also integrates with the underlying physical storage infrastructure.
Application Auto-Discovery
K10 uses Kubernetes-native APIs to automatically discover containerized applications, their components, startup processes, and associated policies. Rather than requiring manual inventory or agent installation on each workload, discovery is driven by the Kubernetes control plane itself.
Restore Points: More Than a Data Snapshot
A core K10 concept is the restore point — an atomic unit that captures not just volume data but the complete application state within a Kubernetes namespace, including:
- Kubernetes resource definitions (Deployments, Services, StatefulSets, etc.)
- Secrets and ConfigMaps
- Container image references
- Service account bindings
- Networking configuration
This dependency tree means a restore point can be used to fully reconstruct an application on a different cluster, region, or cloud provider without manual reconfiguration.
CSI Integration and Storage Agnosticism
K10 uses the Kubernetes Container Storage Interface (CSI) abstraction layer to interact with block and object storage systems. This means K10 does not need to understand the proprietary APIs of individual storage arrays. It works with a wide variety of storage backends and is designed to be storage-agnostic — it is not a storage system itself but a data management layer on top of existing infrastructure.
Blueprints: Agentless Extension for Complex Workloads
For workloads that require coordination across multiple services before a backup can be taken consistently — such as flushing a database write-ahead log — K10 provides an agentless extension mechanism called blueprints. Blueprints allow operators to define pre-backup preparation steps and post-restore transformation steps without modifying the application itself or its deployment pipeline.
Blueprint transforms are particularly useful during migrations: for example, updating DNS names, regenerating TLS certificates (such as those issued by Let’s Encrypt), or adjusting environment-specific configuration values as an application moves from production to a test environment.
Typical Backup and Migration Workflow
The K10 workflow for backup and cross-cluster migration follows a consistent pattern:
- Scope a namespace — select the Kubernetes namespace representing the application to protect.
- Run a backup action — K10 creates a restore point capturing data and all associated Kubernetes resources.
- Run an export action — the restore point is exported to an object store (for example, Amazon S3 or a compatible endpoint).
- Apply a backup policy — schedule the above steps on an hourly, daily, or weekly cadence.
- Create an import policy on the destination cluster — the import action retrieves the exported restore point.
- Run a restore action — the namespace, data, and configuration are recreated on the destination cluster, optionally with blueprint transforms applied.
This workflow applies equally to disaster recovery, environment promotion (production to staging), and full cluster migration.
Real-World Use Case: Sopra Steria’s OpenShift Migration
Sopra Steria, a UK-based IT consultancy, used K10 when migrating close to 200 applications from OpenShift 3.11 to OpenShift 4.3. Lead DevOps architect Michael Courcy described the process in a webinar, noting that K10’s restore-point model — combining data snapshots with full Kubernetes resource state — made it practical to migrate applications at scale while accommodating infrastructure differences between the source and destination clusters, including DNS name changes handled via blueprint transforms.
Balancing Operator and Developer Needs
K10 is designed to serve two audiences with different priorities:
- Operations teams get policy-driven automation, global visibility across multiple clusters, alerting, and compliance management without manual per-application configuration.
- Development teams are largely unaffected — K10 requires zero changes to application code or deployment pipelines. Developers who want finer control can optionally use blueprints to customise backup and restore behaviour for their specific workloads.
Cloud Native Transformation Framework
Kasten introduced the Cloud Native Transformation Framework as part of its Application Transformation Engine. According to the company, this layer adds capabilities including:
- Capture of underlying data and additional metadata
- Lock-free algorithms to reduce backup contention
- Pluggable encryption and compression
- Advanced deduplication to reduce storage consumption
- Smaller fault domains to improve backup reliability
Deployment and Scalability
K10 runs both on-premises and in public cloud environments. Because it is itself a Kubernetes application, it scales with the workload and does not require dedicated backup infrastructure separate from the cluster it protects. This can reduce overall IT infrastructure footprint compared to traditional backup appliances or agents.
Summary
Kasten K10 addresses a genuine gap: the mismatch between Kubernetes’ dynamic, namespace-scoped application model and the VM-centric assumptions baked into legacy backup tools. By treating a Kubernetes namespace as the unit of protection — capturing data, configuration, and resource state together — K10 makes backup, restore, disaster recovery, and cross-cluster migration operationally tractable for teams running stateful workloads on Kubernetes at scale.