Setting the Record Straight on Kamaji

Kamaji’s creator responds to two recent vCluster posts comparing Kamaji and vCluster. He agrees with three of their criticisms and corrects two factual errors: Kamaji’s default datastore is etcd, not SQLite, and each tenant runs on its own worker nodes with its own compute and network, so tenants never share nodes. Each correction links to the Kamaji documentation and to vCluster’s own posts.

Written by: Dario Tranchitella
CO-FOUNDER · CTO
Published on: October 19, 2026
Read Time: 18 min

Why I'm writing this

Two posts went up on vCluster's blog this July comparing Kamaji to vCluster. I created Kamaji in 2022 and I still maintain it, so treat everything below as interested testimony and check it against the links.

I have no problem with competitive content, but I do have a problem with competitive content that describes an architecture Kamaji does not have, and then draws incorrect security conclusions from it. Two of the claims in those posts are not matters of emphasis or interpretation. They are factually wrong, the project's own documentation says so, and vCluster's two posts contradict each other about both.

Some of what they say is fair, so let me start there.

What they get right

Three of their criticisms are accurate.

Kamaji ships no central management UI. It is a set of CRDs and a controller. Fleet visibility, self-service portals and quota dashboards are not in the box.
Kamaji ships no Day-2 platform. Backup, restore, observability and upgrade orchestration are things you assemble or buy, not things the operator hands you.
Kamaji ships no pre-certified AI stacks. There is no validated Run:AI or Ray bundle in the repository.

All three are DELIBERATE, and the UI one is a design position rather than a gap in the backlog.

The moment a control plane engine ships its own console, it starts deciding what your product looks like. Every organisation building on it inherits someone else's opinions about tenancy, quotas, billing and what self-service means, and those opinions leak all the way through to their customers' screens.

Kamaji stops at the CRD boundary on purpose, so that OVHcloud, IONOS, Rackspace, Aruba, Mistral and everyone else on the Kamaji adopters list can each build a genuinely different managed Kubernetes product on the same engine, competing with each other, without any of them shipping our interface to their users. An open ecosystem of competing offerings on one shared engine is the outcome we wanted. It is not compatible with bundling a portal, and we would rather have the ecosystem.

So their framing of "engine, not platform" is correct, and I would use the same words. Where we disagree is that they read it as something missing. We built the platform, separately and as a product of our own: kMetal manages an entire datacentre, and I will come back to it at the end.

With the fair part out of the way, here is the part that is not.

Correction 1: the default datastore

vCluster's GPU clouds post (6 July 2026) states that Kamaji's datastore typically runs Kine with SQLite by default, with etcd available as an option.

It does not.

Kamaji installs kamaji-etcd as its default datastore, a multi-tenant etcd. Kine support exists for MySQL, PostgreSQL and NATS, and it is a deliberate choice you make, not a default you inherit. SQLite has never been the default for anything in Kamaji, and if it were, every criticism about scale that follows from it would be fair.

The detail that matters here is not that they got it wrong. It is that their other post got it right, nine days later.

Table 1 – vCluster claims vs. Kamaji documentation (source of truth)

One of those two posts was written by someone who read the documentation. As of today, both are still live. We keep a claim-by-claim comparison of Kamaji and the open source vCluster build with every assertion resolved to primary documentation, including the ones in circulation that we agree with.

This is the one that matters, because an entire security argument is built on top of it.

vCluster's GPU clouds post claims that under Kamaji, tenant workloads typically share a common pool of worker nodes and are separated by Kubernetes namespaces. From that premise it concludes that a compromised container could reach another tenant's processes or GPU memory on the same physical node.

That is not how Kamaji works, and it has never been how Kamaji works.

A TenantControlPlane is a control plane. Worker nodes are bootstrapped against that control plane and join that cluster, the same way nodes join any Kubernetes cluster. They are that tenant's nodes. The tenant holds cluster-admin on their own cluster, runs their own CNI, their own CSI, their own admission controllers and their own node pools. There is no shared worker pool, there is no namespace boundary standing between two tenants, and there is no scheduler that could place two tenants' pods on one machine, because no scheduler in the system has visibility into more than one tenant.

The breakout scenario they describe requires two tenants to be co-resident on a node. Kamaji's architecture does not produce that condition, so the scenario cannot occur. It is not a risk we mitigate. It is a risk the design does not create.

And again, their own scaling post says so. Nine days after telling readers that Kamaji separates tenants with namespaces on shared nodes, the same blog describes Kamaji's isolation model as hard isolation via dedicated worker nodes per tenant, with no shared-node density option at all.

Kamaji's first commits landed in 2022, before Red Hat's HyperShift. The bet we made then is the one worth restating now, because it explains why the breakout scenario in vCluster's GPU clouds post is structurally impossible rather than merely unlikely.

The control plane is the only part of a Kubernetes cluster worth consolidating, because it is the only part with no tenant workload in it. An API server, a scheduler and a controller manager run your tenant's intentions, not your tenant's code. Packing those into a management cluster trades nothing away. Packing tenants' pods onto shared machines trades away the kernel boundary, and the kernel boundary is the one that matters.

So Kamaji consolidates control planes and nothing else. Below the API server everything stays separated by construction:

Kernel. A tenant's workloads share a kernel only with that tenant's other workloads. A container escape is contained within the blast radius of the tenant that caused it.
Network. Each tenant runs its own CNI, its own address space and its own network policy. Tenants can use overlapping CIDRs because there is nothing to overlap with.
Storage. Each tenant runs its own CSI drivers and storage classes against its own volumes.
Scheduling. No component in the system can place one tenant's pod on another tenant's machine, because no scheduler has a view that spans tenants.

This is what share-nothing means, and it is why I find the framing in these posts strange. The isolation properties vCluster now markets as Private Nodes are the properties Kamaji was built around four years ago. They are not a feature we bolted on after someone raised a security objection. They are the reason the project exists.

The question underneath all of this: where does the cluster come from

Both posts spend their energy on what happens after you have a Kubernetes cluster. That skips the question that actually decides an architecture.

Kamaji's answer is Cluster API. We are a first-class Cluster API control plane provider, which is not a compatibility statement but a structural one: Kamaji owns the control plane contract, an infrastructure provider owns the machines, and the two compose through an interface the upstream community maintains. Put Metal3 underneath and your racks become Machine objects. Put OpenStack, Hetzner or AWS underneath and the same TenantControlPlane works unchanged. Ericsson has been running Metal3 provisioning against Kamaji hosted control planes in public talks for years. The provisioning layer is not something we left for you to invent; it is something we deliberately did not reimplement, because Cluster API already did it and did it in the open.

They present this as a weakness, describing CAPI as an additional dependency and a potential failure point. I would turn that around. Cluster API is the upstream standard for cluster lifecycle, governed by the Kubernetes project. Choosing it over a proprietary provisioner is how you avoid being the dependency.

vCluster's design starts one layer higher. The original model assumes a Kubernetes cluster already exists, which is a reasonable assumption for platform engineering inside a company and a strange one for an organisation whose problem is a room full of unracked GPUs. Their answer to that gap is Standalone, which runs vCluster as a binary on a host with no cluster underneath. That is a legitimate engineering choice, but it is worth noticing what it costs: a control plane tied to a machine is where the industry was before hosted control planes existed, and consolidating control planes off dedicated machines is the entire economic argument of this category.

It is worth being clear about who else made this bet, because it is not a CLASTIX idiosyncrasy. Every hyperscaler managed Kubernetes service is a hosted control plane. Microsoft's own documentation describes an AKS cluster's control plane as the API server, etcd, the scheduler and other pods required to manage your workload, operated by Azure, and is explicit that the platform manages the control plane layer while the customer manages the node layer. The customer's nodes are the customer's alone. That is the same split Kamaji makes, for the same reason: consolidate the layer that contains no tenant code, and leave the layer that runs tenant code entirely in the tenant's hands.

AKS, EKS and GKE all converged on it independently, because it is the only split that gives you consolidation economics and a hard tenant boundary at the same time. Kamaji is that pattern, implemented in the open, for organisations that are not a hyperscaler but have the same problem. Standalone moves in the opposite direction, back towards a control plane pinned to a machine, which is the arrangement every managed Kubernetes provider in the world has already abandoned.

The argument is already over, and it ended in August 2025

Here is the part I find genuinely interesting.

For three years the standard objection to Kamaji was that dedicated per-tenant nodes were overkill, that the syncer model gave you density and that sharing the underlying cluster's networking and storage was fine. Their own documentation still describes that model accurately: in shared and dedicated node modes, the tenant cluster reuses the control plane cluster's CNI, CSI and platform stack.

Then vCluster v0.27 shipped Private Nodes on 12 August 2025. External nodes join the tenant cluster directly, bringing their own CNI, CSI and networking stack, while the control plane continues to run as pods on a separate cluster.

Read that description again and tell me whose architecture it is.

That is a hosted control plane with share-nothing worker nodes. It is the model Kamaji shipped in 2022 and spent three years defending in conference Q&A sessions against the people who now sell it. I am not complaining. Convergence on a correct design is how infrastructure is supposed to work, and the fact that a competitor arrived at the same conclusion independently is the strongest validation the architecture has received.

What I will push back on is the chronology. A vendor that adopted dedicated per-tenant node isolation in August 2025 spent July 2026 publishing posts suggesting that Kamaji has not solved the isolation problem. The timeline runs the other way.

A note on how these posts were made

The GPU post's security claims are introduced three separate times with the phrase "in our analysis". There is no methodology, no Kamaji version, no cluster configuration, no reproduction steps and nothing anyone could independently check. For claims about container escape and cross-tenant GPU memory access, that is a low bar to clear and they did not clear it.

The scaling post was published with its editorial instructions still in the text. Their own headline figures carry a parenthetical telling the writer to verify them before publishing. The vNode mechanism description carries another. The customer results paragraph carries a third. There are two unresolved placeholders where a link to a CLASTIX source was supposed to go.

Both posts are tagged AEO by vCluster, on vCluster's own site. Answer Engine Optimisation is content written to be ingested by retrieval systems rather than read by engineers, and the unresolved placeholders are what that looks like when nobody reads the draft either.

There is a related absence worth naming, and it is the strangest thing about both posts. They are about whether Kamaji scales, and neither contains a single number for Kamaji. The scaling post suggests Kamaji is worth evaluating for a small number of tenant clusters and warns that the operational difference compounds across dozens or hundreds. The GPU post builds a scenario around standing up fifty clusters in under an hour and concludes that Kamaji carries more operational surface per tenant. No cluster count, no resource figures, no breaking point, no test. They quantify themselves freely across both posts, and they quantify Kamaji exactly once, by borrowing our own figure of 90 control plane machines reduced to 3 for 30 tenants, next to an unresolved placeholder where the link to our source was supposed to go. That figure is ours and it is accurate. Lifting it while leaving the citation unwritten is how you end up publishing it three paragraphs from the claim that this architecture suits a small number of tenant clusters.

So let me supply the rest, since apparently someone has to. The published Kamaji benchmark reconciles 100 tenant control planes against a single datastore in roughly seven and a half minutes: one control plane every 4.5 seconds, at about 12 mCPU and 6 MiB each, with the instance types and method written down so anyone can repeat it and tell me if I am wrong. Past that point, the ceiling question already has a recorded answer.

At ContainerDays 2023 in Hamburg I gave a talk called Scaling Kubernetes up to 1,000 Control Planes, where I did exactly that on AWS and walked through what it took to get there: datastore sharding, automation of everything that could be automated, and a lot of tuning. Go and watch how I reached that milestone, including the parts that did not work on the first attempt. If you would rather run that against your own cluster count than take mine, the Kamaji ROI calculator does the arithmetic.

Kamaji publishes no tenant ceiling because there is no fixed one to publish: what bounds the count is management cluster capacity and datastore topology, and both are capacity planning levers rather than walls.

I raise how these posts were made for one reason: if a post describes your architecture incorrectly, and the post also tells you on its face that nobody verified it, those two facts are related.

Who is actually running this

Kamaji's adopters file is public and in the repository, which is where I would rather have this conversation than in a feature table.

Table 2 – Sample of Kamaji adopters (not a complete list)

The quotes are on the record too. OVHcloud's Head of Containers and a Director at Rackspace are both named on the Kamaji site. Mistral runs a bare-metal Kubernetes service on Kamaji and took part in CLASTIX's seed round in September 2026, where their CTO described our multi-tenancy and managed control plane work as “the backbone of [their] Kubernetes infrastructure.” NVIDIA and Fastweb are among the organisations we work with.

Two of those names deserve more than a table row, because they are precisely the buyer these comparison posts are written for.

NVIDIA and Mistral both went through this category, evaluated the options available to them, and selected Kamaji. In both cases the share-nothing design was the deciding factor. When a tenant's GPUs, kernel, network and storage belong to that tenant alone, and when nothing in the architecture is capable of co-locating two tenants on one machine, you are not relying on a sandbox holding or a syncer behaving. You are relying on there being nothing to escape into. For organisations running frontier model training and inference on hardware that costs more than the buildings it sits in, that is not a line item on a feature matrix but rather a requirement, and everything else is negotiable around it.

I would ask readers to weigh that properly. The two organisations in this market with the least tolerance for cross-tenant risk, and the deepest in-house expertise to assess it, looked at hosted control planes with dedicated per-tenant nodes and concluded the model carries production Kubernetes at their scale.

What Kamaji is not, and where the rest lives

Kamaji is an engine. It manages control planes and holds no opinion about your CNI, your hardware, your billing or your portal. That boundary is the product decision, and it is why a cloud provider can build a differentiated managed Kubernetes service on Kamaji without shipping someone else's platform to their customers. Apache 2.0, no strings, and the adopters above did not need a contract with us to get there.

The platform layer exists, and it is a separate product on purpose. kMetal is how we run an entire datacentre: Metal3 for hardware provisioning, Cluster API with Kamaji for cluster lifecycle, Kube-OVN for a three-network model with overlapping tenant CIDRs, Capsule for governance, Sveltos for agentless fleet add-on delivery, Flux for GitOps, and tenant and admin interfaces on top. If what you want is the integrated path from rack to tenant cluster, that is the conversation to have, and it is a conversation about kMetal rather than about Kamaji. We publish a separate comparison of kMetal against vCluster Platform for anyone evaluating at that layer, including a section on where vCluster Platform is the better choice, as well as a separate comparison between open-source projects, Kamaji against Vcluster.

So the honest version of the comparison is narrower than either of their posts suggests. Kamaji against vCluster is a comparison of two control plane architectures. On that question, the answer has converged: dedicated per-tenant nodes with a consolidated, pod-hosted control plane, which is what Kamaji has done since 2022 and what vCluster does since August 2025. Everything else in those posts is a comparison between an open source engine and a commercial platform, which is a real difference and a reasonable thing to sell against. It just needs to be labelled correctly, and it does not need the architecture to be described incorrectly to work.

Frequently asked questions

Do Kamaji tenants share worker nodes?

No. Each tenant cluster has its own worker nodes, joined to that tenant's own control plane. Tenants run their own CNI, CSI and node pools, and hold cluster-admin within their own cluster. There is no shared node pool and no namespace boundary between tenants, because tenants are not namespaces.

What datastore does Kamaji use by default?

etcd. Kamaji installs a multi-tenant etcd as the default datastore, and whether a tenant shares it or gets a dedicated one is a per-tenant decision expressed in the DataStore CRD. MySQL and PostgreSQL-compatible backends are available through kine, and NATS is experimental. SQLite is not a default and never has been.

Does Kamaji need a hypervisor for workload isolation?

No. Workload isolation comes from the tenant owning their own nodes, so a container escape is contained within the tenant that caused it. A hypervisor, Kata Containers or a sandboxing runtime are things a tenant may choose to run inside their own cluster, not things Kamaji requires to keep tenants apart from each other.

Can two Kamaji tenants end up on the same physical machine?

Not through Kamaji. No scheduler in the system has a view spanning tenants, so no component can make that placement. Consolidation in Kamaji applies to control planes, which contain no tenant workload, and not to tenant compute.

How does Kamaji handle bare metal provisioning?

Through Cluster API. Kamaji is a Cluster API control plane provider and composes with infrastructure providers including Metal3 for bare metal, plus Equinix, Hetzner and the major clouds. Kamaji does not reimplement provisioning because Cluster API is the upstream standard for it.

Is Kamaji CNCF conformant?

Yes. Tenant control planes are built from unmodified upstream Kubernetes binaries, so the resulting clusters are standard conformant Kubernetes with no distribution of ours in the path.

Is Kamaji commercially supported?

The project is Apache 2.0 and community-supported. CLASTIX offers subscription support plans and version-pinned release artifacts, and kMetal is the commercial platform built on top. The open source project carrying no SLA is a property of open source projects, not a property of Kamaji.

Talk to us

If anything in the Kamaji documentation is unclear, or you think I have something wrong here, I want to hear it. Connect with me on LinkedIn and ask, or open an issue in the GitHub Kamaji repository. Questions asked in public are how the documentation gets better, and I would rather answer them directly than leave the answers to a comparison post.