Kamaji vs vCluster: Hosted Control Planes Compared for GPU Clouds

Summary

• Kamaji and vCluster solve Kubernetes-as-a-Service with different architectures: Kamaji wraps kubeadm in pods, while vCluster uses true control plane virtualization, creating over 40M tenant clusters in production.
• For GPU cloud providers, the choice impacts bare metal provisioning, tenant isolation, and AI platform readiness.
• Kamaji offers a flexible control plane for teams using CAPI, while requiring you to assemble your own provisioning and isolation tools.
• The vCluster Platform provides an integrated stack purpose-built for the speed, density, and strong isolation required to run commercial AI services.

One of the most common questions that surfaces whenever Kamaji gets mentioned in the Kubernetes community is: "How does this compare to vCluster?" It's a fair question: both tools tackle the same fundamental challenge of delivering Kubernetes-as-a-Service (KaaS) at scale, and at first glance, they look suspiciously similar.

They take fundamentally different architectural approaches. Kamaji is an open-source operator that wraps kubeadm to run hosted Kubernetes control planes as pods — a design that works for general-purpose KaaS. vCluster is a CNCF-certified Kubernetes virtualization layer with 40M+ tenant clusters created in production. But they make fundamentally different architectural bets, and in the high-stakes world of GPU clouds, those bets carry real operational consequences.

This article breaks down exactly where those differences lie, and more importantly, which architecture wins across the scenarios that actually matter for AI infrastructure: bare metal provisioning, tenant isolation for GPU workloads, AI platform pre-configuration, and fleet-scale operations.

The Core Architectural Divide: Kubeadm-in-a-Pod vs. True Control Plane Virtualization

Kamaji: Wrapping kubeadm Inside a Management Cluster

Kamaji's model is efficient in concept: it runs Kubernetes control plane components (API server, controller manager, scheduler, and a datastore) as standard pods inside a central Management Cluster. The datastore typically runs Kine with SQLite by default, with etcd available as an option. It uses unmodified upstream Kubernetes components and integrates tightly with kubeadm for bootstrapping and lifecycle management. For platform engineers already fluent in the kubeadm and Cluster API (CAPI) ecosystem, this feels familiar and composable.

A common concern in the community is how a single datastore can avoid noisy neighbor issues at scale. Kamaji does address this through a Datastore pool: you're not forced to use a single datastore instance. Tenants can be spread across multiple datastores to mitigate contention. That said, this requires deliberate capacity planning and adds operational complexity when managing large fleets.

Kamaji's infrastructure provisioning model is intentionally decoupled: it manages control planes, and you bring your own worker node provisioning via CAPI providers. This is flexible, but it means bare metal deployments require assembling additional tooling.

vCluster: Lightweight K8s Virtualization as a First-Class Primitive

vCluster takes a different bet entirely. Rather than running each tenant's control plane as a discrete set of separately-bootstrapped pods (API server, controller manager, scheduler each going through their own initialization cycle) vCluster runs fully self-contained, CNCF-certified Kubernetes clusters as lightweight processes inside a control plane cluster. Each tenant gets their own isolated API server, etcd, and RBAC, which are compact control planes that run as lightweight pods per tenant, but with dramatically lower overhead than a full cluster bootstrap. The result is an EKS-like, self-service Kubernetes experience for every tenant, delivered at bare metal speed.

vCluster's architecture is designed for density and production-grade isolation. Private Nodes are the default for production workloads, giving each tenant dedicated hardware-level isolation out of the box. For high-density, lower-risk environments — such as dev and test where you control exactly which tenants are running what — shared nodes are available as an option when you want to maximize infrastructure utilization. Each tenant's control plane is isolated with its own API server, etcd, and RBAC, with no cross-tenant visibility at the Kubernetes API layer. That isolation spectrum, from shared nodes all the way to kernel-native sandboxing, is where the GPU cloud story gets interesting.

The GPU Cloud Gauntlet: Bare Metal, Isolation, and AI-Readiness

Bare Metal Provisioning

For GPU clouds building on raw hardware, the provisioning story matters as much as the cluster model itself.

vCluster has an integrated, full-stack path from rack to tenant cluster. vMetal handles zero-touch bare metal provisioning: PXE boot, OS installation, network automation via VLAN/VXLAN/VRF, and full machine lifecycle management. On top of that, vCluster Standalone runs as a lightweight binary directly on a Linux host: no k3s, no kubeadm, no intermediate K8s distribution required. This means you go from bare GPU server to a Kubernetes environment supporting tenant isolation with the fewest moving parts possible. Nscale, a GPU cloud provider, has demonstrated exactly this model in production: running vCluster on bare metal at scale. Boost Run went from strategic decision to production in under 45 days with zero new platform engineering hires on this same stack.

Kamaji is infrastructure-agnostic — it can run on bare metal, VMs, or cloud instances. But the provisioning layer is your problem to solve. You'll typically assemble a CAPI provider for your hardware, which introduces additional dependencies, potential failure points, and engineering overhead. For teams building AI clouds from scratch without an existing CAPI practice, that's a non-trivial investment.

Tenant Isolation for GPU Workloads

This is the critical fault line for any GPU cloud running AI workloads that require tenant isolation. The question isn't just "are control planes isolated?"; it's "what happens when an untrusted training job tries to break out of its container?"

Kamaji provides control-plane-level workload separation. Tenant control planes are isolated from each other, but workloads typically share a common pool of worker nodes, separated by standard Kubernetes namespaces. In our analysis, a compromised container could potentially access other tenants' processes or GPU memory on the same physical node, since namespace isolation alone does not contain the blast radius at the kernel level.

vCluster approaches this as a layered isolation problem, with a configurable spectrum:

1. Control Plane Isolation: Every tenant cluster has its own API server, CRDs, and RBAC. There's no cross-tenant visibility at the Kubernetes API layer.
2. Workload Isolation: Tenants are pinned to private nodes (including dedicated GPU nodes) by default for production workloads, delivering predictable performance and hardware-level isolation. Shared node scheduling is available as an option for high-density, lower-risk environments like dev and test.
3. Kernel-Native Isolation: vNode adds the deepest layer: container breakout protection using seccomp, cgroups, and namespaces, without hypervisor overhead. GPU performance is preserved at bare metal speed, while workloads are sandboxed at the kernel level.

This layered model delivers the kind of strong, self-service tenant isolation GPU cloud customers expect from hyperscalers like AWS and GCP, on your own bare metal infrastructure.

If you need to isolate workloads that share underlying GPU nodes, the vCluster stack (Private Nodes plus vNode's kernel-native workload isolation) gives you a concrete defense-in-depth answer: layered over GPU partitioning methods like MIG or time-slicing where used. Kamaji does not include a native workload-level isolation layer: teams must source, integrate, and maintain kernel hardening tools (seccomp, Kata Containers, etc.) separately.

AI Platform Pre-Configuration

Deploying a Kubernetes cluster on GPU hardware is table stakes. What AI cloud customers actually need is a production-ready AI platform. This includes tools like Run:AI for scheduling, Ray for distributed training, Jupyter for notebooks, and Slurm for HPC-style workloads.

vCluster addresses this through Certified Stacks: pre-validated AI environments that are tested and certified to work with vCluster's tenant isolation model. You go from a bare tenant cluster to a fully configured Run:AI, Ray, or Slurm (via Slinky) environment in minutes, not weeks, so AI cloud providers can offer the same breadth of managed AI services customers expect from hyperscalers like AWS and GCP, via partner integrations like Run:AI, without building the integration layer themselves.

Kamaji is a generic control plane manager; it's compatible with any of these tools, but the integration, configuration, validation, and ongoing maintenance are entirely your responsibility. Replicating equivalent AI-platform integration work typically requires substantial additional engineering effort compared to deploying a Certified Stack in minutes.

Operational Scenarios: Where Theory Meets Practice

Spinning Up 50 Tenant Clusters in Under an Hour

With vCluster, this is routine. Lightweight virtualized control planes instantiate in seconds, giving customers the self-service, hyperscaler-like Kubernetes experience they expect. The vCluster Platform includes templating, fleet management APIs, and automation that make spinning up dozens of tenant clusters a scripted, repeatable operation, validated across deployments powering 100K+ GPU nodes.

With Kamaji, each tenant control plane runs as a discrete set of pods (API server, controller manager, scheduler, and a datastore), all requiring their own initialization and coordination. Fleet-scale provisioning is possible but carries more operational surface area per tenant compared to vCluster's compact process model.

Upgrading Control Planes Without Downtime

The vCluster Platform handles fleet upgrades as rolling updates to the pods representing each tenant's control plane. Tenants experience zero downtime. This is a core Day-2 capability baked into the platform.

Kamaji was designed with Day-2 lifecycle management in mind: its maintainers describe it as a project focused on the lifecycle of a fleet of clusters. In our analysis, coordinating kubeadm upgrades across a large fleet typically carries more configuration surface area and higher misconfiguration risk than a pod-based rolling update model.

Isolating Untrusted GPU Training Workloads

This is where the architectural gap is most consequential. With vCluster + vNode, an untrusted workload is boxed in on three levels: isolated control plane (no cross-tenant API visibility), private GPU node assignment (no shared physical hardware), and kernel sandboxing via vNode (no container breakout path). That's a credible security posture for running untrusted third-party AI workloads at a commercial GPU cloud.

With Kamaji alone, the primary workload boundary is a Kubernetes namespace on a shared node. In our analysis, without additional kernel-level hardening, a successful container escape could compromise the entire node and potentially affect other tenants' workloads on that node.

Recommendation Matrix

Final Verdict

Kamaji and vCluster address related but distinct problems. Kamaji is designed for platform teams in the CAPI ecosystem who want to assemble their own provisioning, isolation, and AI-platform layers, but for most GPU cloud providers, that assembly tax is precisely the problem vCluster Platform is built to eliminate.

vCluster is purpose-built for the speed, density, and isolation demands of modern GPU clouds. The architecture (control plane virtualization that compresses what Kamaji runs as separate components into lightweight tenant processes) produces a fundamentally different performance profile at the operational layer: tenant clusters in seconds instead of minutes, rolling fleet upgrades instead of per-cluster bootstrap orchestration, and a layered isolation stack that can satisfy the security requirements of a commercial AI cloud with infrastructure tenancy.

For organizations building competitive GPU cloud services, the integrated stack from vCluster Labs provides a more direct path from GPU rack to production AI environment than any combination of Kamaji plus external tooling. This stack includes vMetal for bare metal provisioning, the vCluster Platform for tenant cluster orchestration, vNode for kernel-native workload isolation, and Certified Stacks for AI platform pre-configuration.

That's why GPU clouds like Nscale have demonstrated this model in production, and why it's referenced in the NVIDIA DGX SuperPOD reference architecture. When the business requirement is shipping a production AI cloud fast, without a dedicated platform engineering army, the architectural bet that wins is the one that ships fewer abstractions and more working infrastructure.

Frequently Asked Questions

What is the main architectural difference between Kamaji and vCluster?

The primary difference lies in their approach to creating control planes. Kamaji wraps kubeadm to run standard Kubernetes control plane components as pods in a management cluster, whereas vCluster uses true control plane virtualization to run lightweight, CNCF-certified Kubernetes clusters as self-contained processes.

This means vCluster creates tenant clusters with significantly lower overhead and faster startup times. While Kamaji offers a familiar model for those in the Cluster API ecosystem, vCluster's architecture is purpose-built for high-density, high-speed provisioning, making it ideal for large-scale KaaS and AI cloud environments.

Why is vCluster often preferred for building GPU clouds?

vCluster is preferred for GPU clouds because it offers an integrated, end-to-end solution for the specific challenges of AI infrastructure. This includes zero-touch bare metal provisioning with vMetal, strong tenant and workload isolation with vNode, and pre-configured AI environments with Certified Stacks for tools like Run:AI and Ray.

Kamaji, by contrast, provides the control plane management layer but requires you to assemble, integrate, and maintain separate tools for bare metal provisioning, deep workload isolation, and AI platform configuration. vCluster's integrated stack dramatically accelerates time-to-market for commercial GPU cloud providers.

How does vCluster provide stronger tenant isolation for AI workloads?

vCluster provides a multi-layered defense-in-depth isolation model that goes beyond Kamaji's namespace-based separation. Each tenant cluster has a fully isolated control plane (API server, etcd), can be pinned to dedicated nodes for physical separation, and uses vNode for kernel-native sandboxing to prevent container breakouts without hypervisor overhead.

This layered approach is critical for running untrusted third-party AI training jobs, as it secures tenants at the API, hardware, and kernel levels. Kamaji's model primarily relies on Kubernetes namespaces, which may not be sufficient to prevent a compromised container from affecting other tenants on the same physical node.

Can I use vCluster if my team already uses Cluster API (CAPI)?

Yes, vCluster can complement a CAPI-based workflow. While Kamaji integrates tightly with CAPI for worker node provisioning, vCluster can run on top of any CAPI-provisioned cluster. Teams can use CAPI to manage their underlying control plane cluster infrastructure and then deploy the vCluster Platform on top to provide a high-density, self-service KaaS layer for their developers or customers.

How does vCluster speed up AI platform deployment?

vCluster accelerates AI platform deployment through its Certified Stacks. These are pre-validated, production-ready AI environments, including tools like Ray, Slurm, and Run:AI, that can be deployed into a tenant cluster in minutes.

This eliminates weeks of complex integration, configuration, and validation work that would be required with a more generic control plane manager like Kamaji. For AI cloud providers, this means you can offer fully configured, managed AI services to customers much faster.

What does "true control plane virtualization" mean for vCluster?

True control plane virtualization means vCluster runs a fully functional, CNCF-certified Kubernetes distribution as a lightweight, self-contained process per tenant, rather than running each control plane component as separately-bootstrapped pods. Each tenant's control plane (API server, scheduler, controller manager) runs together within a compact pod architecture, using its own data store (like etcd, SQLite, or an external database) for that tenant cluster.

This approach dramatically reduces the resource footprint and startup time compared to running discrete control plane pods for every tenant, allowing for much higher density and near-instant cluster provisioning.

Ready to see how vCluster can accelerate your AI cloud deployment? Request a personalized demo today.

‍