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.
• For enterprises, CNCF certification is a critical trust signal; every vCluster tenant is fully certified, whereas Kamaji is not, which can be a blocker for adoption.
• A key architectural difference for bare metal GPU is isolation: vCluster provides both control plane and kernel-native workload isolation without hypervisor overhead, a gap in Kamaji's approach.
• 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.

If you've spent any time in Kubernetes forums lately, you've probably seen a version of this question: "Is Kamaji just vCluster with a different name?" Or the more pointed one: "I hear massive scalability, but I don't understand how a single etcd control plane can't suffer from noisy neighbors."

These aren't naive questions. They come from engineers who are actively evaluating Kubernetes control plane as a service architectures for serious workloads — GPU clusters requiring tenant isolation, bare metal AI infrastructure, and production systems where the wrong architectural choice compounds painfully over time.

This article is a direct, no-fluff comparison. We'll cover both tools honestly: vCluster Platform's CNCF-certified virtualization approach and Kamaji's open-source, etcd-based model. The goal is to give you enough signal to make a well-reasoned call — especially if you're building or scaling a bare metal GPU environment.

Let's start with the overview.

At-a-Glance: Spec Table

Architectural Deep Dive

Kamaji: The Open-Source Hosted Control Plane

Kamaji is an open-source Kubernetes operator built by Clastix. It turns any 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 on shared infrastructure, backed by a dedicated etcd instance.

The hardware efficiency story is real. Clastix's own benchmarks show reducing dedicated control plane machines from 90 down to 3 for 30 tenants. For teams with a strong Kubernetes background and appetite for DIY infrastructure, that's 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 community pushes back:

• Scalability and isolation: Reddit threads surface this directly — "I don't understand how a single etcd control plane cannot suffer from noisy neighbors." Kamaji does support Datastore pools to distribute etcd load, but the operational burden of implementing and tuning this falls entirely on you.
• No CNCF certification: This is a genuine blocker in enterprise contexts. As one user put it: "It would be hard in some enterprise cases where the product isn't CNCF incubating/graduated." CNCF conformance is the baseline trust signal procurement teams reach for.
• 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.

vCluster Platform: Kubernetes Virtualization

vCluster Platform takes a fundamentally different approach. Rather than hosting the components of a control plane, vCluster virtualizes the entire Kubernetes control plane — running fully isolated, CNCF-certified tenant clusters as lightweight pods inside a host cluster.

Each tenant gets their own API server, etcd, RBAC, and CRD scope. They can't see each other's objects, can't interfere with each other's workloads, and — critically — get full cluster-admin rights within their own boundary. It's isolation that actually holds under pressure, not just namespace partitioning.

Built by vCluster Labs (formerly Loft Labs, backed by Khosla Ventures, $28.6M raised), the platform is production-proven at real scale: 100K+ GPU nodes powered, 1M+ CPU nodes in production, 40M+ tenant clusters created. It's named in the NVIDIA DGX SuperPOD reference architecture and runs in production at CoreWeave, Nscale, and JPMorganChase.

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 K8s 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 doesn't have integrated lifecycle management. Provisioning, network automation, and OS installation are left to you to wire together.

2. GPU Workload & Tenant Isolation

This is where the gap is significant.

vCluster solves this with a layered isolation model:

• Control plane isolation: Each tenant's cluster is fully scoped — their API calls, CRDs, and workloads are invisible to other tenants.
• Workload isolation: vNode (currently in private beta) provides kernel-native isolation via seccomp, cgroups, Linux namespaces, and AppArmor. This provides container breakout protection without hypervisor overhead, so bare metal GPU performance is preserved.

Kamaji gives you control plane isolation by design, but workload isolation is a different story. For preventing a tenant's GPU job from interfering with or escaping into another tenant's environment, Clastix's own blog acknowledges the gap: traditional approaches "necessitate a hypervisor (like ESXi) for tenant isolation." Hypervisors solve the security problem but introduce overhead that defeats the purpose of bare metal GPU.

For GPU environments that require strong tenant isolation for untrusted workloads on shared hardware, that combination of control plane and kernel-native workload isolation matters.

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. While it's declarative, composable, and integrates well with GitOps workflows, it doesn't ship with fleet visibility, a self-service portal, or built-in backup and recovery tooling. As one engineer on Reddit summarized: "You can also take backups to restore from — handy if you break something." With Kamaji, that sentence describes something you need to build, not something you get.

For teams managing dozens or hundreds of tenant clusters, the operational difference between these two positions compounds fast.

4. Enterprise Support & SLAs

vCluster Platform comes with commercial support from vCluster Labs. Production customers include Fortune 500 companies and GPU cloud providers, and the team has direct expertise in bare metal K8s and GPU workloads. The NVIDIA DGX SuperPOD reference architecture listing isn't marketing — it reflects the depth of integration work validated at the hardware level.

Kamaji is community-supported. The Clastix team is active and responsive, but there are no guaranteed SLAs. For production AI infrastructure where an outage translates directly to revenue loss, that gap is non-trivial — especially given the user feedback that teams want "professionals who already worked with Kubernetes and Bare Metal, and GPUs too."

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 of these has been tested and certified against vCluster's tenant isolation model, so you're not discovering integration edge cases in production.

Kamaji doesn't 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's an option 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're spending engineering cycles building fleet management tooling instead of shipping product.
• Tenant isolation policies are inconsistent across clusters because there's no enforcement layer.
• Backup and recovery is manual or undocumented — fine until it isn't.
• Customers are asking for a self-service experience you don't have.
• Your AI stack integrations are one-off configurations that break on every K8s minor version.

This is the point where the total cost of a DIY solution — measured in engineering hours, operational risk, and delayed roadmap — starts to exceed the cost of a commercially-supported platform.

vCluster Platform is designed specifically for this inflection point. The full stack — vMetal for bare metal provisioning, vCluster Platform for control plane virtualization and fleet management, and vNode (currently in private beta) for kernel-native workload 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.

The benchmark from customers backs this up: Lintasarta launched Indonesia's leading GPU cloud in 90 days with 170+ tenant clusters. Boost Run went from zero to production in under 45 days with zero new platform engineering hires.

Migration Path

If you're 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 have 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, handled 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. Kamaji gives you the engine. vCluster Platform gives you the engine, the chassis, the drivetrain, and the dashboard — pre-assembled and commercially backed.

For teams building AI clouds, inference platforms, or internal AI factories on bare metal GPU, the depth of integration required across bare metal provisioning, 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

What is the main difference between vCluster and Kamaji?

The main difference is their architectural approach. vCluster virtualizes the entire Kubernetes control plane into a single, lightweight pod, whereas Kamaji runs the individual components (API Server, etc.) of a control plane as separate pods.

This fundamental distinction impacts isolation, compatibility, and management. vCluster creates fully isolated, CNCF-certified tenant clusters that are functionally identical to standalone clusters but far more efficient. Kamaji provides a hosted control plane engine that consolidates components, offering hardware efficiency but requiring more DIY effort for fleet management, workload isolation, and ensuring full Kubernetes API compatibility.

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

vCluster uses a component called vNode to provide kernel-native workload isolation, which secures tenant workloads without the performance overhead of a traditional hypervisor.

vNode leverages core Linux security features like seccomp, cgroups, namespaces, and AppArmor to create a strong isolation boundary around each tenant's pods. This prevents container breakout and interference between tenants on shared bare metal hardware, preserving the raw performance of the underlying GPUs for AI/ML workloads. Kamaji, by contrast, relies on external mechanisms like hypervisors for this level of security.

Why is CNCF certification important for a Kubernetes control plane?

CNCF certification guarantees that a Kubernetes distribution passes conformance tests, ensuring 100% API compatibility. This is a critical trust signal for enterprises, as it confirms that standard Kubernetes tools, manifests, and integrations will work as expected without modification.

Without CNCF certification, you risk encountering subtle API incompatibilities that can break CI/CD pipelines, monitoring tools, or third-party operators. For procurement and security teams, CNCF conformance is often a mandatory requirement. Every vCluster tenant is fully CNCF-certified; Kamaji is not.

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

vCluster avoids the "noisy neighbor" problem by providing each tenant with a fully isolated, dedicated control plane, including its own separate API server and etcd datastore. This ensures that high API load or unusual activity in one tenant cluster does not impact the performance or availability of others.

Unlike architectures that might share a single etcd instance or other components, vCluster's virtualization model creates complete encapsulation. This strong resource isolation at the control plane level is fundamental to delivering predictable performance in isolated tenant environments.

Can I use Kamaji for production workloads?

Yes, Kamaji can be used for production workloads, particularly for teams with deep Kubernetes expertise who are comfortable building and maintaining their own platform tooling. It excels at consolidating control planes for hardware efficiency in these scenarios.

The decision depends on your team's operational capacity and goals. Kamaji provides the core engine, but you are responsible for building out fleet management, observability, backup/recovery, and a self-service tenant experience. For organizations that prefer a commercially supported, all-in-one solution, a platform like vCluster is often a more direct path to production.

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

"Engine" refers to a core component that solves a specific technical problem, while "platform" refers to an integrated solution that includes the engine plus all the surrounding tooling for management, operations, 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), kernel-native workload isolation (vNode, currently in private beta), 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 and designed to minimize disruption. 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 allows you to validate the benefits of vCluster's integrated platform—such as Certified Stacks for AI tooling and automated fleet management—on a small number of 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 →

‍