CloudCasa on Mirantis k0rdent: Composable, Self-Service Resilience for Kubernetes Platforms

How Mirantis k0rdent and CloudCasa together make Kubernetes-native backup and disaster recovery a first-class building block — for containers, VMs, and KubeVirt-based virtualization alike

Platform engineering needs more than provisioning

Modern platform teams are being asked to do something genuinely hard: deliver self-service infrastructure to developers — clusters, namespaces, virtual machines, AI workloads — while still enforcing the governance, security, and resilience an enterprise demands. The friction shows up everywhere. Tickets pile up. Tooling proliferates. Each new workload type seems to bring its own backup tool, its own RBAC model, its own console.

Mirantis k0rdent was built to collapse that complexity. It is an open source, Kubernetes-native management platform that gives platform engineers a single control point for clusters, services, and now virtual machines — across data centers, public clouds, and the edge. The premise is simple: if you can describe your platform declaratively, and compose it from validated building blocks, you can deliver self-service without losing control.

Provisioning, though, is only half the job. The other half — the half that defines whether a platform is actually production-ready — is recovery. That is where CloudCasa joins the k0rdent catalog.

Composability is the point

k0rdent’s architecture is built around three Kubernetes-native abstractions: ClusterTemplates, ServiceTemplates, and a curated catalog. Together they let a platform team define what a “good cluster” looks like in their organization — which CNI, which CSI, which observability stack, which security policies — and then hand that definition to developers as a reproducible, governed building block.

The k0rdent catalog is where this composability becomes tangible. It is a discovery surface for Mirantis-validated services and partner integrations that platform engineers can pull into their stacks declaratively. Every entry ships with ready-to-use templates, so adding a capability to a fleet of clusters is a YAML change, not a project.

That model is exactly why a backup and disaster recovery service belongs in the catalog, not bolted on the side. Resilience should be a composable capability — something a platform team enables once, governs centrally, and exposes to developers through the same self-service experience as everything else.

Unifying VMs and containers under one control plane

One of the most consequential things k0rdent does is treat virtual machines as first-class workloads on Kubernetes. With KubeVirt, VMs run as pods, are described by VirtualMachine custom resources, and inherit the same scheduling, networking, RBAC, and GitOps workflows as containerized applications. For organizations migrating off legacy hypervisors — or simply tired of paying for two parallel operations stacks — this is a meaningful simplification.

But unifying the runtime exposes a gap in the tooling around it. Traditional VM backup products were never designed to understand Kubernetes objects: they do not know what a VirtualMachine CRD is, they cannot see PVCs or storage snapshots the way Kubernetes does, and they have no concept of namespace-scoped policy or multi-cluster fleet operations. Bolting them onto a KubeVirt environment recreates the very silo k0rdent is trying to eliminate.

A Kubernetes-native protection layer solves this from the right side of the problem. CloudCasa understands VirtualMachine CRDs, the PVCs and storage snapshots that back them, namespace metadata, and cluster-level state — which means VMs running on k0rdent-managed clusters get the same protection model as everything else on the platform.

What the integration looks like from the k0rdent side

Listing CloudCasa in the k0rdent catalog turns backup-as-a-service into a deployable component of the platform. From a platform engineer’s point of view, the experience is the one they already know:

• Declarative deployment. Enable CloudCasa across clusters using a ServiceTemplate, the same way you would deploy ingress, observability, or storage which enables you to deliver a managed backup-as-a-service either through CloudCasa’s Self-hosted or SaaS control plane.

• Fleet-wide reach. k0rdent’s MultiClusterService model lets a platform team apply a protection service to every cluster matching a label selector. Onboard a new cluster, and policy follows it automatically — no per-cluster install runbook.

• Governed self-service. Developers consume protection through the same self-service surface they use to deploy a VM or a workload. Platform admins keep policy authorship; developers get on-demand backup and restore inside their namespaces.

• GitOps-friendly. Because everything is a Kubernetes object — templates, services, policies — protection configuration lives in Git alongside the rest of the platform definition. Drift detection, audit trails, and continuous reconciliation come along for free.

• RBAC and multi-tenancy alignment. k0rdent’s hard multi-tenancy and namespace isolation model carries through to backup operations. Tenants see and manage their own protected workloads; platform admins retain fleet-level visibility.

A self-service VM scenario, end to end

Consider what a developer’s experience looks like once a platform team has composed CloudCasa into their k0rdent stack:

• Provision. A developer requests a VM from the k0rdent catalog. The VirtualMachine CRD is created in their namespace, with networking, storage, and policies inherited from the cluster template.

• Protect. A protection policy — authored once by the platform admin, scoped by namespace or label — automatically attaches to the new VM. There is no separate ticket, no separate console.

• Recover. When the developer needs a restore — to roll back a bad change, clone an environment, or recover from a failure — they trigger it themselves, into the same namespace, a different namespace, or even a different cluster managed by the same k0rdent control plane.

Same control plane. Same RBAC. Same templates. The data protection layer disappears into the platform — which is exactly what good platform engineering is supposed to do.

Why this matters for platform leaders

There is a larger pattern here. Every capability that lives outside the platform — backup, observability, secrets, identity, cost — is a place where governance leaks, complexity accrues, and self-service breaks down. The composable architecture k0rdent enables is, at its core, a thesis that those capabilities should be modular, declarative, and validated, then assembled by the platform team to fit their organization.

Bringing CloudCasa into the catalog is one expression of that thesis. So is unifying VMs and containers under a single control plane. So is treating fleet-wide policy as code. The common thread is that platform engineers should be able to deliver a complete, resilient, governed environment — not a provisioning tool with a backlog of integrations still to come.

Self-service should not just mean deploy fast. It should mean deploy fast, govern by default, and recover faster. With k0rdent and CloudCasa, that is now a single, composable platform decision — not a multi-quarter integration project.

Learn more

Explore the k0rdent catalog at catalog.k0rdent.io to see the full set of validated services and solutions available to platform engineering teams. To see how Mirantis k0rdent AI Enterprise unifies containers, VMs, and AI workloads under one declarative control plane, visit mirantis.com.

Read more about optimizing your infrastructure by reading the full breakdown on the CloudCasa blog.