Why We Built kMetal: Taking years of multi-tenant Kubernetes expertise down to the metal

TL;DR – for busy executives

What it is: kMetal is a single platform that takes a powered-on, bare server all the way to a fully governed, isolated, multi-tenant cluster fleet – covering bare metal, virtual machines, networking, the operating system, governance, and add-ons in one consistent model. It is designed for organisations that operate – or are building toward – Kubernetes at fleet scale: internal cloud platforms for large enterprises, sovereign or regional cloud providers, and managed service operators running infrastructure on hardware they control.

Why it exists: It is the natural next step of years of CLASTIX open source work on Kubernetes multi-tenancy – first Capsule, then Kamaji – now applied to the hardware itself. The shift away from proprietary hypervisors made the timing right, but the direction was set long before that shift happened.

What it gives you:

• Lower total cost of ownership – no proprietary hypervisor licensing, no networking appliances or external load balancers to buy, and dense shared infrastructure instead of dedicated control-plane hardware per cluster.

• Faster time to market – tenants self-serve production-grade clusters in minutes, not weeks; every new cluster arrives fully equipped automatically.

• Less operational toil – everything is declared once and reconciled forever, so a fleet of thousands of clusters runs without a headcount to match it.

• No lock-in – built on independently governed open source standards, and extensible with your own logic (billing, authorisation) without forking the platform.

The road that led us here

CLASTIX has spent years in the open source world with a single obsession: making Kubernetes genuinely multi-tenant. That obsession produced two projects that shaped how we think.

Project Capsule came first. It solved tenancy inside a single cluster – governance and workloads – letting multiple teams share one cluster safely, with policies and guardrails instead of trust.

Then came Kamaji, and with it a stronger conviction: real multi-tenancy in Kubernetes means hard multi-tenancy. Every tenant must get their own infrastructure; the control plane cannot be shared. It was a contrarian intuition at the time, and it turned out to be the right one – the rest of the ecosystem followed us into hosted control planes.

kMetal is what happens when you take that same expertise – years of open source, years of wrestling multi-tenancy into Kubernetes – and point it at the hardware. It is built for organisations that want to run a cloud of their own: an internal platform for their teams, a sovereign or regional cloud, or a multi-tenant service they sell to their own customers – all on hardware they control. If you are evaluating kMetal for a small number of clusters today, Kamaji OSS is the right starting point; kMetal's value is a function of fleet size, and it is designed for organisations where that fleet is already large, or growing fast enough that it soon will be.

A quick word on the name. The k in kMetal is Kamaji. We wanted to bring the experience Kamaji brought to Kubernetes – no control planes to manage – down to the metal – no hypervisor to manage. Kamaji Metal. A small play on words, but it captures the whole thesis: strip away the heavy management layer at every level of the stack.

And yes – the Broadcom licensing upheaval helped. When the cost of a proprietary hypervisor suddenly becomes a board-level line item, organisations start looking hard for alternatives. But we are not jumping on a trend. kMetal is the natural continuation of work we had been doing for years. The timing simply made the conversation easier to have.

Below is what is inside kMetal, and – more importantly – why each piece is there. One principle runs through all of it: everything is a Kubernetes resource. No Ansible, no bash scripts, no awkward glue. If you can describe it, the platform can reconcile it.

1. Bare metal management with Metal3

A platform is only as solid as the layer it stands on, and provisioning bare metal has traditionally meant runbooks, scripts, and a lot of manual touch. We refused to build on that.

We chose Metal3 for two reasons. It is Cluster API compatible, so bare metal fits the same declarative model as everything else we do. And it is independently governed – not owned by a single vendor – which protects our customers from the kind of lock-in we built the company to avoid. With Metal3, a physical server stops being something you configure by hand and becomes a Kubernetes resource you declare: described as state, then reconciled automatically.

For the platform team

Bare metal provisioning becomes a declarative Kubernetes resource – the BareMetalHost CRD – driven by Ironic over IPMI and Redfish. No runbooks, no SSH scripts. The Cluster API lifecycle hooks handle everything from firmware validation to OS install to cluster registration. Drift is detected and corrected continuously; a server that has fallen out of its expected state is driven back to it without human intervention.

For the business

Infrastructure becomes reconcilable state instead of a collection of brittle, error-prone runbooks. Fewer hands on hardware, fewer mistakes, and a server that goes from rack to cluster-ready without a single manual script. The operational risk that lives in undocumented provisioning procedures disappears.

2. Multi-cluster management with Cluster API and Kamaji

As an open source company, we had no interest in inventing yet another standard for multi-cluster management. So kMetal is built entirely on Cluster API, the de facto standard – which also gives us access to its broad ecosystem of Infrastructure Providers. In kMetal we deliberately target two: our own KVM provider for virtualisation, and Metal3 for bare metal. One platform, one model, spanning everything from raw hardware to virtual machines.

There is a catch with Cluster API, though: it has a steep usability curve. Standing up a cluster the vanilla way means gluing together a sprawl of manifests. So we built our own Cluster Topologies on top of it – an easy-to-use API where a tenant creates a single object and everything is provisioned, reconciled, and operated for them, including Day 2 operations like upgrades. The hard part – keeping a fleet healthy over time – is handled by the platform, not the tenant.

For the platform team

ClusterClass defines the golden template – OS image, Kubernetes version, CNI, add-ons, storage class – once. Every tenant cluster is an instance of that class. Mutations and patches apply declaratively; rolling an upgrade across the fleet means updating the class, not touching each cluster individually. Kamaji hosts all tenant control planes as pods on the management cluster – no VMs or dedicated nodes allocated per control plane, no separate etcd clusters to operate outside the management plane.

For the business

One platform spanning bare metal to VMs, and a full production-grade cluster from a single declaration. Tenants go from request to running cluster in minutes rather than weeks, and the Day 2 work – upgrades, patching, certificate rotation – moves from the platform team's sprint board into automated reconciliation.

3. Lightweight virtualisation with KVM and our KubeVirt distribution

The industry spent years artificially splitting two worlds apart: infrastructure people doing infrastructure, Kubernetes people doing Kubernetes. We think that split is a mistake. KubeVirt lets us reunite them, because it matches our core idea – Kubernetes is the layer, the single common language for both worlds. A virtual machine becomes just another Kubernetes resource, managed with the same tools, skills, and workflows as a container.

Our KubeVirt distribution is ready-to-use, not hardened-and-handed-over. It ships with images, so nobody has to agonise over how to import a VM image – you build images as Kubernetes objects, and they connect directly to our immutable OS pipeline (more on that next). It runs on KVM, the hypervisor already living inside the Linux kernel, so there is no proprietary appliance layer to license or maintain.

For the platform team

KubeVirt runs as a Kubernetes operator. VM lifecycle – create, start, stop, delete, resize – is driven through VirtualMachine and VirtualMachineInstance CRDs. Our distribution ships pre-integrated image pipelines using ContainerDisk or DataVolume, pre-configured for the networking and storage drivers used elsewhere in the platform. No manual KVM setup, no libvirt configuration by hand. Tenant worker nodes are KVM VMs; their compute isolation is at the kernel level – a separate kernel per tenant, a separate attack surface – not at the container or namespace level.

For the business

One platform, one skill set, and one toolchain for both VMs and containers – plus a clean escape from proprietary hypervisor licensing. Teams stop maintaining two parallel operational worlds. The procurement conversation about hypervisor renewal disappears from the budget entirely.

4. Immutable OS lifecycle management with Kairos

A platform that calls itself truly multi-tenant has to back that claim up at the operating-system level. We use immutable OS images to get reproducible artefacts and a smaller attack surface – two properties that are central to the trust story a multi-tenant platform has to tell.

We chose Kairos because it gives us that without imposing it. Kairos does not force an opinionated operating system on anyone: customers can bring their own OS and customise it directly inside the platform. That means no Packer, no Ansible, no slow provisioning at the init process – all of which quietly consume bandwidth and time. Instead, OS management becomes one unified, declarative pipeline, which also makes rolling out patched versions across the whole estate straightforward.

For the platform team

Kairos builds immutable OS artefacts as OCI-compatible images. Node upgrades are atomic – the running OS is replaced as a unit, not patched in place. Image customisation happens at build time via a layered container image model, not at runtime via configuration management. The result is a reproducible, version-controlled OS layer with no configuration drift possible at the node level. Patching the fleet means building a new image and rolling it – the same model for one node or ten thousand.

For the business

A stronger security and compliance posture, fully reproducible builds, and a single mechanism for patching the entire fleet – without the provisioning overhead that traditionally eats into both time and infrastructure. An auditor asking for evidence of consistent OS configuration across every node gets a version-controlled image tag, not a spreadsheet of patch records.

5. Governance and multi-tenancy with Capsule

Here the story comes full circle, because Capsule is where kMetal's lineage began. Capsule is a framework that lets us offer a secure self-service platform: tenants provision their own namespaces, collected under a single Tenant abstraction, and share quotas in a fully Kubernetes-native way.

It is worth being precise about Capsule's role. Capsule is governance – not workload isolation. The hard isolation comes from the dedicated-infrastructure model. Capsule is how we collect resources and design the infrastructure with policies and quotas. This matters most for expensive, contended resources. Infrastructure-level tenancy and Kubernetes-level tenancy are usually disconnected, so quotas get inherited blindly. Capsule reunites them – which is exactly what you need for GPUs and storage. GPUs are costly and scarce; they have to stay available to everyone, not get reserved wholesale by a single tenant.

For the platform team

Capsule introduces the Tenant CRD as a first-class grouping primitive. Namespace creation, resource quotas, network policies, and admission rules are all scoped to the Tenant object – not scattered across individual namespaces. Quota inheritance between infrastructure-level resources (GPU node pools, storage classes) and Kubernetes-level tenant namespaces is declared and reconciled; the gap that usually requires manual coordination between infrastructure and platform teams is closed by the platform itself.

For the business

Tenants self-serve safely without the platform team becoming a bottleneck, and expensive resources like GPUs stay available to all tenants under enforced quotas – turning unpredictable spend into something planned and governed. The usual trade-off between speed and control does not apply here; both are built in.

6. Multi-tenant networking with our kube-OVN distribution

Networking is where multi-tenancy usually either succeeds or quietly leaks, so this is the area where we invested the most original engineering. Our distribution is built on kube-OVN – and the OVN/OVS foundation – and is designed around a three-network model: public, tenant, and management planes that are independent by construction. Isolation is not a policy we hope holds; it is the topology itself. The design also supports overlapping CIDRs across clusters, so tenants get genuine network autonomy with no central IP-range coordination.

The clever part is how we keep tenants fully sealed off from one another while still letting their workloads work. Each tenant's workloads live in their own isolated network, with no access to the shared management backbone – yet they still reach their own control plane seamlessly, through a dedicated private path we built for exactly that purpose. Tenants stay completely separated, and nothing ever has to cross the shared backbone to get there.

On top of this sits our own Cloud Provider Interface, which lets tenants create public-facing load balancers – with a preallocated IP or one drawn from a pool, governed by a policy tied to tenant usage – again, without traffic ever crossing the management network. We are already shipping beta VPC peering, with a self-service model built around the concept of a Peering Request.

For the platform team

The three-plane separation – public, tenant, management – is enforced at the OVN logical topology level, not as iptables rules or Kubernetes NetworkPolicies that require ongoing maintenance and can silently drift. Overlapping CIDRs are supported natively; no central IPAM service or manual coordination between tenant operators is needed. The Cloud Provider Interface watches for LoadBalancer Service objects in tenant clusters and provisions OVN NAT and EIP resources automatically, keeping tenant traffic entirely within the OVN data plane and completely off the management network. VPC peering is mediated through a Peering Request CRD – tenant-initiated, operator-approved, platform-enforced.

For the business

Cloud-grade, genuinely isolated networking on bare metal – with no appliances or external load balancers to purchase. Tenants get their own virtual private cloud, load balancer capabilities, and – in beta – the ability to peer with other tenant networks, all within policy limits. The network isolation is structural, not rule-based, which means it holds even when the unexpected happens.

7. Fleet-wide add-on delivery with Project Sveltos

Once you are running many clusters, keeping them consistently equipped becomes its own problem. Project Sveltos solves it in a way that fits Kamaji perfectly: it is agentless, sits on the management layer, and constantly reconciles the add-ons deployed across every cluster. Because it is built around the concept of clusters – CRDs and labels – the moment you create a cluster, Sveltos installs everything it needs: CSI, CNI, the monitoring stack, and so on. The cluster is production-equipped the instant it exists, not days later via a manual checklist.

Sveltos was designed for fleet management at the scale of thousands of clusters – which happens to be exactly the scale Kamaji supports. Its Event Framework adds another dimension we care about: it gives customers hook points for their own automations – billing, authorisation, whatever their domain demands – without forking or modifying our platform. kMetal stays open to customisation while remaining a product you adopt, not a fork you are trapped maintaining.

For the platform team

Sveltos uses ClusterProfile CRDs to declare which add-ons – Helm charts, Kustomize overlays, raw manifests – should be present on clusters matching a given label selector. Label a cluster, Sveltos does the rest. The reconciliation loop is continuous: if an add-on is removed or drifts from the expected state, Sveltos restores it. The Event Framework exposes cluster-lifecycle hooks – cluster-created, cluster-deleted, health-state-changed – that customers can bind to their own controllers for billing triggers, audit events, or authorisation callbacks, all without modifying platform code.

For the business

Fleet-wide consistency from day one, with no per-cluster setup and no headcount that grows with the fleet. Customers can also extend the platform with their own business logic – billing hooks, custom authorisation – without maintaining a fork.

8. GitOps installation with FluxCD, and UIs for everyone

Underneath, kMetal installs and runs the GitOps way. We chose FluxCD over Argo CD, which we find brings unnecessary complexity and quirks of its own. GitOps is our installation mechanism: customers fork our repository, add their own values, and the GitOps engine performs constant reconciliation – quietly correcting drift and minimising the toll of human error.

But a deeply API- and CRD-driven platform should not require everyone to live in YAML, so we ship two UIs. Tenants can interact with kMetal however they prefer – GitOps, APIs, or the tenant UI, which gives customers a way to offer their own tenants the look and feel of a cloud platform. And because kMetal is a fully fledged infrastructure solution, platform administrators get a dedicated management UI that provides a nine-thousand-mile overview of the entire stack.

For the platform team

The kMetal installation is a FluxCD app-of-apps – a root HelmRelease referencing component HelmReleases with pinned versions and compatibility-validated values. Drift in platform components is detected and reconciled continuously, not just at install time. Both UIs are built on the same API surface as the CLI; there is no state accessible only through the UI and invisible to automation.

For the business

Installations that are reproducible, auditable, and self-healing – and a cloud-like self-service experience that lowers the barrier to adoption. Tenants do not need deep Kubernetes fluency to be productive, and operators get fleet-wide visibility at a glance without piecing it together from separate monitoring systems.

Why it all adds up

One thread runs through every component: everything is a Kubernetes resource, declared once and reconciled forever – bare metal, VMs, the OS, the network, governance, and the platform's own installation, all operated the same way. That consistency is what turns a collection of parts into a platform you can run as a business.

When you put a price on it, the payoff lands in three places.

You save on hardware

Because control planes are hosted rather than provisioned, the control-plane VMs a traditional multi-cluster setup demands simply do not exist – there is nothing to size, run, or pay for per cluster. Combined with no hypervisor licensing and no networking appliances to buy, a large recurring line item disappears from the budget: the same hardware does more, and you buy less of it.

You save on operations

Every layer of the stack – bare metal, OS, networking, clusters, add-ons, and the platform's own installation – is driven by automation with continuous drift detection. The platform notices when reality diverges from declared state and corrects it, so a fleet of thousands of clusters does not require a team that scales with it. Operational toil stops being a function of how many clusters you run.

You save on time – without losing control

Self-service onboarding takes the time to stand up a new tenant toward zero: teams move at their own pace instead of queuing behind a central platform group. The usual trade-off – speed or control – does not apply here, because governance is built in. Capsule's policies and quotas mean that handing teams the keys never means handing over the guardrails. And the largest time saving comes before day one: you do not build any of this yourself. Assembling a true multi-tenant, bare-metal cloud in-house is a multi-year project plus a permanent team to keep it alive – the exact work we have already done in the open. With kMetal you start from a finished platform, not a roadmap.

Put those together – hardware you do not buy, operations that do not grow with the fleet, and onboarding that drops toward zero behind real guardrails – and you have what it takes to run a cloud of your own rather than rent one.

Whether that is an internal platform, a sovereign or regional cloud, or a service you offer your own customers, kMetal hands you the machinery to be the provider.

We built kMetal because it is where years of open source work on Kubernetes multi-tenancy were always going to lead – down to the metal.

Talk to us

Wondering whether kMetal fits your environment? Every stack, scale, and set of constraints is different, so the best next step is a conversation. Talk to Sales → and we will walk through your setup, map kMetal to it, and work out together whether there is a fit.