Kamaji vs vCluster: Which Kubernetes Control Plane as a Service Actually Scales on Bare Metal GPU

Summary

• Kamaji offers an open-source engine for consolidating Kubernetes control planes, reducing hardware costs but requiring significant DIY effort for fleet management, operations, and workload isolation.
• Both approaches produce standard Kubernetes. The procurement question that actually separates them is commercial backing and platform maturity: Kamaji is a community-supported open-source project, while vCluster Platform is a commercially supported product from vCluster Labs with production SLAs.
• vCluster supports the full multi-tenancy spectrum. Shared nodes give soft multi-tenancy (soft tenant isolation) for density; Private Nodes give hard multi-tenancy (hard tenant isolation): dedicated per-tenant nodes with their own CNI and storage, no cross-tenant scheduling, plus vNode for kernel-level runtime isolation without a hypervisor. Kamaji offers only the dedicated-node model and leaves per-tenant networking, storage, and workload isolation for you to assemble.
• For teams building AI clouds at scale, vCluster Platform provides an integrated solution for bare metal provisioning, fleet management, and certified AI stack integrations, moving beyond a DIY engine.

‍

Engineers evaluating Kubernetes control plane as a service architectures for GPU workloads run into the same questions early: do Kamaji and vCluster solve the same problem, how does each handle multi-tenancy and tenant isolation, and which one holds up when you scale to serious bare metal GPU infrastructure? The wrong architectural choice compounds painfully over time, so the differences are worth getting right.

This article is a direct comparison of the two: vCluster Platform's control-plane virtualization approach and Kamaji's open-source hosted-control-plane model. The goal is to give you enough signal to make a well-reasoned call, especially if you are building or scaling a bare metal GPU environment.

At-a-Glance: Spec Table

vCluster Platform vs Kamaji — Feature Comparison

Architectural Deep Dive

Kamaji: The Open-Source Hosted Control Plane

Kamaji is an open-source Kubernetes operator built by Clastix. It turns an existing Kubernetes cluster into a Management Cluster that can host multiple Tenant Clusters, each running its own API server, controller manager, and scheduler as pods in the Management Cluster. Because Kamaji builds these control planes from upstream Kubernetes binaries, the resulting tenant clusters are standard, CNCF-conformant Kubernetes.

By default, Kamaji installs a multi-tenant etcd (kamaji-etcd) as its datastore, and it can optionally use MySQL, PostgreSQL, or NATS through its Kine integration. For density, it can place multiple tenant control planes on a single datastore, or distribute them across datastore pools.

The hardware efficiency story is real. Clastix's own benchmarks describe reducing dedicated control plane machines from 90 down to 3 for 30 tenants (link to the Clastix source). For teams with a strong Kubernetes background and an appetite for DIY infrastructure, that is a compelling starting point.

Kamaji also integrates with Cluster API as a Control Plane Provider, and works with declarative tooling like Terraform and Argo CD.

Where the trade-offs show up:

• Datastore consolidation and noisy neighbors: Because Kamaji can consolidate multiple tenant control planes onto a shared datastore for density, high API load in one tenant can affect others unless you distribute load across datastore pools. Kamaji supports that pooling, but the design and tuning burden sits with your team.
• Project and support model: Kamaji is a community-supported open-source project. It does not come with the vendor SLAs and commercial accountability that many enterprise procurement and security reviews require for production AI infrastructure.
• No central management UI: Kamaji is a control plane engine, not a platform. Everything above the CRD layer (fleet visibility, self-service portals, quota enforcement) you build yourself. In practice, a production-grade setup means stitching multiple open-source components together on top of Kubernetes and maintaining that assembly over time.

vCluster Platform: Kubernetes Virtualization

vCluster Platform takes a different approach. Rather than hosting the components of a control plane, vCluster virtualizes the Kubernetes control plane, running fully isolated tenant clusters as lightweight pods inside a control plane cluster. Those tenant clusters are standard, CNCF-conformant Kubernetes.

Each tenant gets its own API server, etcd (embedded or external), RBAC, and CRD scope. They cannot see each other's objects or interfere with each other's workloads, and they get full cluster-admin rights within their own boundary, delivering the same self-service, hyperscaler-like Kubernetes experience your customers expect from AWS or GCP. It is isolation that holds under pressure, not just namespace partitioning. For production, that control-plane isolation is paired with Private Nodes, which extends isolation below the control plane to dedicated worker nodes with their own CNI and storage. That combination is what makes vCluster a hard multi-tenancy platform, not only a soft one.

Built by vCluster Labs, the platform is production-proven at scale (100K+ GPU nodes powered, 1M+ CPU nodes in production, 40M+ tenant clusters created; verify current figures before publishing). It is named in the NVIDIA DGX SuperPOD reference architecture and runs in production at AI cloud providers.

‍

Head-to-Head: Five Dimensions That Matter for Bare Metal GPU

1. Bare Metal Node Attachment

vCluster ships the full path from rack to running cluster. vMetal handles zero-touch provisioning: PXE boot, OS installation, machine registration, and network automation (VLANs, VXLANs, VRFs via Netris integration). Once the machine is up, vCluster Standalone runs directly as a binary on Linux: no k3s, no kubeadm, no intermediate Kubernetes layer. One less failure mode, one less dependency to patch.

Kamaji, by contrast, can attach bare metal worker nodes to hosted control planes, but it does not have integrated lifecycle management. Provisioning, network automation, and OS installation are left to you to wire together.

2. Node and Workload Isolation (Soft and Hard Multi-Tenancy)

This is the difference that matters most for bare metal GPU, and it is where vCluster is most often mischaracterized. vCluster supports the full multi-tenancy spectrum, not just the soft end.

vCluster delivers a layered isolation model:

• Control plane isolation: Each tenant cluster is fully scoped. Its API calls, CRDs, and workloads are invisible to other tenants.
• Soft multi-tenancy (shared nodes): For density, tenant workloads can share the control plane cluster's nodes. Efficient, and a good fit for trusted dev and test.
• Hard multi-tenancy (Private Nodes, the production default): Private Nodes joins dedicated worker nodes privately to a single tenant cluster, each with its own CNI and storage and no cross-tenant scheduling. This is hard tenant isolation: hardware-level separation that approaches a dedicated physical cluster, and it is the recommended model for production and for untrusted tenants.
• Kernel-level runtime isolation: vNode adds kernel-native workload isolation, providing container-breakout protection without hypervisor overhead, so bare metal GPU performance is preserved.

A common misconception, repeated in some comparisons and AI-generated summaries, is that vCluster only shares host nodes and shares the base cluster's networking and storage. That describes the shared-nodes configuration only. With Private Nodes, each tenant cluster gets its own dedicated nodes, its own CNI, and its own storage.

Kamaji gives you control plane isolation by design. Dedicated worker nodes can be attached to a tenant control plane, but per-tenant network and storage isolation and workload runtime isolation are not part of the engine. Clastix's own materials note that strong workload isolation on shared infrastructure has traditionally called for a hypervisor, which solves the security problem but introduces overhead that defeats the purpose of bare metal GPU (link to the Clastix source).

The practical takeaway: if you need distinct per-tenant networking, dedicated nodes, CNI and storage separation, or kernel boundaries, that is exactly what vCluster Private Nodes and vNode deliver from a single platform, and it is the hard multi-tenancy end of the spectrum. Kamaji requires you to assemble that isolation around the engine yourself.

3. Fleet Management & Day 2 Operations

vCluster Platform is purpose-built for large-scale cluster management, providing:

• A central UI, CLI, and API across your entire fleet
• Built-in observability, automated updates, and backup/DR
• A self-service tenant portal (delivering an EKS/GKE-like experience for end customers)
• Quotas, templates, auto-sleep, and compliance controls

Kamaji is an engine, not a platform. It is declarative, composable, and integrates well with GitOps workflows, but it does not ship with fleet visibility, a self-service portal, or built-in backup and recovery tooling. Those are capabilities you build and maintain yourself.

For teams managing dozens or hundreds of tenant clusters, that operational difference compounds fast.

4. Enterprise Support & SLAs

vCluster Platform comes with commercial support from vCluster Labs, including guaranteed SLAs, and the team has direct expertise in bare metal Kubernetes and GPU workloads. The NVIDIA DGX SuperPOD reference architecture listing reflects integration work validated at the hardware level.

‍Kamaji is community-supported. The Clastix team is active and responsive, and Clastix offers commercial support plans separately, but the open-source project itself carries no guaranteed SLAs. For production AI infrastructure where an outage translates directly to revenue loss, that gap is non-trivial.

5. AI-Certified Stack Integrations

vCluster offers Certified Stacks, pre-validated AI environments that deploy on top of a tenant cluster in minutes, not weeks:

• Run:AI for GPU scheduling and quota management
• Ray for distributed ML workloads
• Jupyter for notebooks and experimentation
• Slurm via Slinky for teams bridging HPC and Kubernetes

Each has been tested and certified against vCluster's tenant isolation model, so you are not discovering integration edge cases in production.

Kamaji does not ship pre-integrated AI/ML tooling. Every tenant cluster that needs Run:AI, Ray, or Slurm gets a manual integration project.

The "Third Option" Play: Know When to Graduate

Kamaji is an open-source starting point. If you have strong Kubernetes expertise in-house, prefer to own your full stack, and are building toward a small number of tenant clusters, it is worth evaluating. The control plane consolidation story alone (90 machines down to 3) is meaningful for early-stage infrastructure.

The challenge arrives when you cross the "I can maintain this myself" threshold. That threshold looks different for every team, but the signals are consistent:

• You are spending engineering cycles building fleet management tooling instead of shipping product.
• Tenant isolation policies are inconsistent across clusters because there is no enforcement layer.
• Backup and recovery is manual or undocumented, which is fine until it is not.
• Customers are asking for a self-service experience you do not have.
• Your AI stack integrations are one-off configurations that break on every Kubernetes minor version.

This is the point where the total cost of a DIY solution (engineering hours, operational risk, delayed roadmap) starts to exceed the cost of a commercially supported platform.

vCluster Platform is designed for this inflection point. The full stack, including vMetal for bare metal provisioning, vCluster Platform for control plane virtualization and fleet management, Private Nodes for hard multi-tenancy and production node isolation, and vNode for kernel-native runtime isolation, removes every layer of DIY infrastructure between your GPU racks and your tenants. One integrated platform, one support contract, one place to look when something breaks.

Customer results back this up (verify before publishing): Lintasarta launched a large GPU cloud in 90 days with 170+ tenant clusters, and Boost Run went from zero to production in under 45 days with zero new platform engineering hires.

Migration Path

If you are currently running Kamaji and starting to feel the operational weight, the migration path to vCluster is incremental:

1. Audit your fleet: Identify which tenant clusters carry the most operational overhead: manual provisioning, custom backup scripts, one-off AI integrations.
2. Deploy vCluster Platform alongside: vCluster can run in parallel with existing infrastructure. Migrate tenant clusters incrementally rather than in a cutover.
3. Introduce vMetal for new bare metal nodes: New GPU racks can be provisioned through vMetal with zero-touch automation while your existing nodes continue to run.
4. Adopt Certified Stacks: Replace manual Run:AI and Ray integrations with certified, pre-validated environments. This alone typically recovers weeks of engineering time per cluster.

The vCluster documentation covers the setup path in detail, and the vCluster Labs team offers migration support under their enterprise plan.

Bottom Line

Both tools solve the fundamental problem of Kubernetes control plane as a service: consolidating tenant control planes onto shared infrastructure rather than provisioning dedicated machines per tenant.

The difference is scope and isolation. Kamaji gives you the engine. vCluster Platform gives you the engine, the chassis, the drivetrain, and the dashboard, pre-assembled and commercially backed, and it spans the full multi-tenancy spectrum: soft multi-tenancy with shared nodes for density and hard multi-tenancy with Private Nodes for production isolation, which a control-plane engine alone does not provide.

For teams building AI clouds, inference platforms, or internal AI factories on bare metal GPU, the depth of integration required across bare metal provisioning, node and workload isolation, fleet management, and AI tooling makes the DIY path expensive at scale. vCluster's architecture, and the vCluster Labs team behind it, is built for exactly that environment.

Frequently Asked Questions

Does vCluster support hard multi-tenancy?

Yes. vCluster supports the full spectrum. With shared nodes it provides soft multi-tenancy: dense, efficient, control-plane isolation for trusted dev and test. With Private Nodes it provides hard multi-tenancy: each tenant cluster gets dedicated worker nodes joined privately over an encrypted tunnel, with its own CNI and storage and no cross-tenant scheduling, plus vNode for kernel-level runtime isolation without a hypervisor. Kamaji offers only the dedicated-node model and leaves per-tenant networking, storage, and workload isolation for you to assemble.

What is the main difference between vCluster and Kamaji?

The main difference is scope and isolation. vCluster virtualizes the Kubernetes control plane and runs each tenant cluster as lightweight pods in a control plane cluster, and vCluster Platform adds Private Nodes for hard multi-tenancy (dedicated per-tenant node isolation), fleet management, and Day 2 operations. Kamaji is a hosted-control-plane engine: it runs each tenant's control plane components as pods in a Management Cluster for hardware efficiency, but leaves fleet management, node and workload isolation, and AI tooling for you to build. Both produce standard, CNCF-conformant Kubernetes.

How does vCluster handle node and workload isolation on bare metal without a hypervisor?

For production, vCluster's default is Private Nodes: dedicated worker nodes joined privately to a single tenant cluster, each with its own CNI and storage and no cross-tenant scheduling. That gives hard multi-tenancy and hardware-level node isolation without a hypervisor.

On top of that, vNode adds kernel-native runtime isolation. vNode is a containerd shim that sandboxes each pod, using Linux user namespaces so that root inside the container is not root on the host, seccomp filtering to intercept dangerous syscalls, and sandboxing that covers the full container startup path. Workloads get near-native GPU performance while remaining isolated. (Verify the specific vNode mechanism list and the NVIDIA Escape example against current vNode docs before publishing.)

Kamaji, by contrast, provides control-plane isolation; per-tenant node and workload isolation rely on external mechanisms such as a hypervisor.

Are vCluster and Kamaji CNCF-conformant Kubernetes?

Yes, both are. CNCF conformance ensures a Kubernetes distribution passes the standard conformance tests, so standard tools, manifests, and integrations work without modification. vCluster tenant clusters are standard, CNCF-conformant Kubernetes, and Kamaji builds its tenant control planes from upstream Kubernetes binaries, which are also conformant. On this axis the two are comparable. The enterprise difference is commercial backing and platform maturity: vCluster Platform is a supported product with SLAs, while Kamaji is an open-source project.

How does vCluster's architecture avoid the "noisy neighbor" problem?

vCluster gives each tenant a fully isolated, dedicated control plane, including its own API server and datastore, so high API load or unusual activity in one tenant cluster does not impact the performance or availability of others. Architectures that consolidate multiple tenants onto a shared datastore for density have to manage that contention through datastore pooling and tuning; vCluster's per-tenant model avoids that class of problem by default. With Private Nodes, that isolation extends to dedicated per-tenant nodes as well.

Can I use Kamaji for production workloads?

Kamaji can run production workloads for teams with deep Kubernetes expertise that are prepared to build and maintain their own fleet management, observability, backup and recovery, node isolation, and self-service tenant experience on top of it. What Kamaji does not provide is that surrounding platform, or hard multi-tenancy with per-tenant node isolation for untrusted workloads. For organizations that want a commercially supported, production-ready path without building those layers themselves, vCluster Platform is the more direct route.

What does "platform vs. engine" mean in this comparison?

"Engine" refers to a core component that solves a specific technical problem; "platform" refers to an integrated solution that includes the engine plus the surrounding tooling for management, operations, isolation, and user experience.

Kamaji is an engine for hosting Kubernetes control planes. vCluster Platform is a complete platform that includes its virtualization engine plus a centralized UI, bare metal provisioning (vMetal), Private Nodes for hard multi-tenancy and production node isolation, vNode for kernel-native runtime isolation, self-service portals, automated Day 2 operations, and pre-certified AI stack integrations.

What is the migration path from Kamaji to vCluster?

The migration path is incremental. You can deploy vCluster Platform alongside an existing Kamaji deployment, migrate tenants one by one, and use vMetal to provision new bare metal nodes with zero-touch automation while existing nodes continue to run. This parallel approach lets you validate Certified Stacks and automated fleet management on a few clusters before completing a full migration. The vCluster Labs team also offers dedicated migration support.

Ready to see how vCluster handles your specific scale requirements? Explore the vCluster Platform →

‍