Kamaji vs vCluster: Which Tenant Isolation Model Fits Your Infrastructure

If you are building a GPU cloud, you have probably already hit the tenant isolation question: how do you give every customer their own Kubernetes environment without dedicating a physical cluster to each one? The answer determines whether your platform scales to hundreds of tenants or tops out at the first few dozen.

There are three paths. You can use Kamaji, a CNCF Sandbox project that hosts Kubernetes control planes as pods. You can build it yourself from scratch. Or you can use vCluster Platform, which delivers the full isolation stack from control plane through hardware, and is compatible with GPU-native partitioning tools like MIG, vGPU, time-slicing, and DRA.

There is a common take on this comparison that gets it backwards: Kamaji for production, vCluster for dev and test. It usually comes from old GitHub threads and AI-generated overviews that describe vCluster as it shipped in 2023, not as it works today. The reality: vCluster Platform's production default is Private Nodes: dedicated worker nodes per tenant with per-tenant CNI and per-tenant storage. That is hardware-level isolation, and it is the starting point, not an upgrade. vCluster also gives you shared nodes for dev, test, and trusted teams when you need them. Kamaji only gives you one mode.

The real comparison is not about hard versus soft. It is about which rungs of the isolation ladder each approach covers.

The Isolation Ladder: Four Layers That Matter

Every platform builder needs to think about tenant isolation in layers. A tool that handles one layer but ignores the others leaves gaps that compound as you add tenants.

Layer 1: Control-Plane Isolation

Each tenant needs their own API server, etcd, RBAC, and CRDs. Without this, tenants share a single control plane. One team installs a cluster-scoped CRD that conflicts with another team's operator. One misconfigured ClusterRole exposes cross-tenant secrets. A noisy API consumer starves everyone else's requests.

Kamaji delivers this layer. It runs tenant control planes as pods inside a management cluster, each with their own API server, scheduler, and controller manager. vCluster Platform also delivers it, with each tenant getting a fully isolated, CNCF-certified control plane. DIY can deliver it too, if you build the control-plane virtualization layer yourself.

Layer 2: Workload Isolation

Control-plane isolation prevents API-level conflicts. It does not prevent a tenant's workload from breaking out of its container and reaching another tenant's processes on the same node. Workload isolation hardens the runtime boundary.

vCluster Platform delivers this with vNode: kernel-native isolation using seccomp, cgroups, and namespaces, with no hypervisor overhead and bare metal GPU performance preserved. Kamaji does not include workload isolation. DIY can add it, if you have the kernel engineering expertise to build it.

Layer 3: Hardware-Level Isolation

Dedicated physical worker nodes per tenant. Each tenant's workloads run on their own hardware, joined directly and privately into their tenant cluster, with per-tenant CNI and storage. No shared kernel, no shared memory bus, no cross-tenant scheduling.

vCluster Platform's Private Nodes deliver this as the production default. A tenant cluster spins up in seconds with dedicated nodes assigned automatically. Kamaji users can achieve this by provisioning separate node pools per tenant manually, but Kamaji itself does not manage node lifecycle. Every new tenant is a manual infrastructure provisioning event. DIY can achieve it too, but it means building the entire node lifecycle management layer: provisioning, joining, networking, CNI assignment, tear-down.

Layer 4: GPU-Silicon Partitioning

At the hardware level, GPU sharing needs silicon-enforced boundaries between tenants. This is done by technologies like NVIDIA MIG (Multi-Instance GPU), vGPU, and time-slicing — the same GPU-native tools used with any Kubernetes cluster. These tools handle the partitioning, the quotas, and the contention prevention at the silicon level. vCluster Platform is compatible with all of them, which means you can run MIG, vGPU, time-slicing, or DRA on a tenant cluster the same way you would on any other Kubernetes environment.

What Each Approach Actually Delivers

Here is how the three paths stack up across the complete isolation ladder:

Kamaji covers one rung: control-plane isolation. But even teams that think they only need API-level separation quickly discover they must build node lifecycle management, GPU orchestration, and workload hardening themselves. Each gap becomes a project. Each project becomes a team. The building block becomes a foundation you are pouring yourself, one sprint at a time.

The Real Cost of DIY

Building a tenant isolation platform from scratch is the default path for most AI cloud providers. It is also the slowest and most expensive.

In our analysis, the build effort spans every layer of the isolation ladder. Even if you start with Kamaji for control-plane hosting, you still need to build or integrate: worker node lifecycle management, per-tenant networking and CNI assignment, GPU partitioning orchestration across MIG, vGPU, and time-slicing, workload isolation for untrusted tenants, fleet management tooling, self-service tenant portals, SSO and RBAC, observability and Day 2 operations across the fleet.

Each of these is a non-trivial engineering investment. Each compounds over time: the initial build is one cost, but the ongoing maintenance, upgrades, security patches, and feature requests from tenants add permanent operational overhead. A platform you build yourself is a platform you maintain forever.

vCluster Platform delivers the non-GPU layers of this stack as an integrated platform. Private Nodes handles hardware-level isolation. vNode handles workload isolation. The platform handles fleet management, Day 2 operations, observability, upgrades, and self-service tenant provisioning. For GPU partitioning, vCluster Platform is compatible with the same MIG, vGPU, time-slicing, and DRA tools available to any Kubernetes cluster. The platform is production-proven at 100K+ GPU nodes, 40M+ tenant clusters created, and customers like CoreWeave and Nscale running GPU clouds with tenant isolation on top of it.

vCluster Platform is validated in NVIDIA's DGX reference architecture, which vCluster authored. Lintasarta launched Indonesia's leading GPU cloud in 90 days with vCluster Platform. Boost Run launched a managed Kubernetes service in under 45 days with zero new platform engineering hires.

The build-it-yourself path does not produce those timelines.

Decision Dimensions: How the Three Paths Compare

etcd Architecture

Kamaji uses Kine by default, backing tenant control planes with a shared datastore (SQLite, MySQL, or PostgreSQL). etcd is available as an alternative, but requires additional configuration and is not the default path. With a single shared datastore, one tenant generating heavy API traffic can create a noisy-neighbor problem at the control plane. Kamaji's Datastore pools can mitigate this by provisioning separate datastores for groups of tenants, but this adds operational overhead.

vCluster Platform ships with isolated etcd per tenant cluster by default. Zero configuration required. One tenant hammering their API server has zero effect on another tenant's control plane performance. DIY means you are building and managing etcd clusters yourself.

Operational Overhead

Kamaji provides control-plane hosting but does not manage worker nodes. Every new tenant requires manual node pool provisioning. The node lifecycle (OS upgrades, scaling, patching, decommissioning) is entirely on you. This is manageable at 10 tenants. At 50, in our analysis, the compounding operational overhead becomes the primary constraint on growth.

vCluster Platform handles the full tenant cluster lifecycle from a centralized fleet management interface. Templated cluster creation, quota enforcement, auto-sleep, built-in observability, and zero-downtime upgrades allow a small platform team to manage hundreds of tenant environments. DIY means building all of this fleet tooling yourself.

Cold-Start Latency

Kamaji's tenant provisioning time is coupled to node provisioning. If you do not have a warm node pool sitting idle, a new tenant waits for machine provisioning: minutes on VMs, hours on bare metal. vCluster Platform decouples tenant creation from infrastructure provisioning. A tenant cluster is scheduled as a pod. It spins up in seconds.

For AI cloud providers offering on-demand GPU environments, this gap is structural. Inference endpoints, ephemeral training clusters, and CI/CD pipelines all need second-scale provisioning. Pre-provisioned idle capacity is not a solution, it is a cost.

GPU Workload Suitability

Kamaji dedicates worker nodes per tenant. If those nodes have GPUs, a tenant gets exclusive access to them. For a single tenant running a massive training job that needs every GPU on the node, that works. It does mean every tenant gets their own GPU hardware whether they use it fully or not. For an AI cloud provider serving dozens of tenants with inference workloads, in our analysis this model can significantly reduce GPU utilization.

vCluster Platform's production default is Private Nodes: dedicated GPU worker nodes per tenant. The difference is that vCluster Platform is compatible with GPU-native partitioning mechanisms like MIG, vGPU, time-slicing, and DRA. Multiple isolated tenant clusters can share the same physical GPUs safely through these mechanisms, while Private Nodes remain available for tenants that need dedicated hardware. Shared nodes are available for dev, test, and trusted-team environments where maximum density matters most.

What Platform Builders Actually Need

If you are building an AI cloud or GPU cloud, the question is not which tool to use. It is which isolation layers your platform needs to deliver, and how much of that you want to build and maintain yourself.

Kamaji is a control-plane hosting primitive. It does one layer well. Everything beyond that layer is your responsibility.

DIY can cover every layer. It also means building and maintaining every layer: control-plane virtualization, workload hardening, node lifecycle, GPU orchestration, fleet management, observability, self-service tooling. The platform you build is the platform you are permanently on the hook for.

vCluster Platform covers all four layers of the isolation ladder in a single integrated stack. Private Nodes delivers hardware-level isolation by default. vNode provides kernel-native workload hardening. The fleet management layer handles Day 2 operations, observability, and self-service provisioning across hundreds of tenant clusters. GPU partitioning works with MIG, vGPU, time-slicing, and DRA. And the bare metal path, from vMetal through vCluster Standalone to vCluster Platform, means you can go from rack to managed Kubernetes in one integrated platform.

You do not need to build any of it. You do not need to maintain any of it. The platform ships production-proven at 100K+ GPU nodes and 40M+ tenant clusters across 50+ GPU clouds and Fortune 500 customers.

Frequently Asked Questions

What is the main difference between Kamaji and vCluster Platform?

Kamaji is a control-plane hosting primitive. It runs tenant Kubernetes control planes as pods in a management cluster, with each tenant getting their own API server, scheduler, and controller manager. vCluster Platform also delivers control-plane isolation, but adds three additional layers: workload isolation (vNode: seccomp, cgroups, namespaces), hardware-level isolation (Private Nodes: dedicated worker nodes per tenant with per-tenant CNI and storage), and compatibility with GPU-native partitioning tools (MIG, vGPU, time-slicing, DRA). vCluster Platform also includes fleet management, Day 2 operations, and self-service tenant provisioning. Kamaji does not include any of these.

Does vCluster Platform deliver hard tenant isolation?

Yes. vCluster Platform's production default is Private Nodes: dedicated worker nodes joined directly and privately into each tenant cluster, with per-tenant CNI and storage. This is hardware-level isolation approaching a dedicated physical cluster. vCluster Platform also provides shared nodes for dev, test, and trusted-team environments where maximum density matters more than physical separation.

Why include DIY in this comparison?

DIY is the real default. Most AI cloud providers start by building their own tenant isolation platform from scratch. The comparison matters because building all four layers of the isolation ladder (control-plane, workload, hardware, GPU-silicon) is a multi-team, multi-year engineering investment, and the maintenance burden never goes away. vCluster Platform covers all four layers in one integrated stack, production-proven at scale.

How does vCluster Platform handle GPU workloads?

vCluster Platform is compatible with GPU-native partitioning tools like NVIDIA MIG, vGPU, time-slicing, and DRA. For tenants that need dedicated hardware, Private Nodes delivers dedicated GPU worker nodes per tenant. For dev, test, and trusted teams, shared nodes maximize GPU utilization across tenants.

Does Kamaji include worker node lifecycle management?

No. Kamaji hosts control planes but does not manage worker nodes. Every new tenant requires manual node pool provisioning. Node lifecycle (OS upgrades, scaling, patching, decommissioning) is the operator's responsibility. vCluster Platform includes full worker node lifecycle management with Private Nodes, Auto Nodes, and centralized fleet operations.

Can Kamaji and vCluster Platform be combined?

In our analysis, this is architecturally possible but operationally redundant. If you are already using Kamaji for control-plane hosting, you still need to build or integrate worker node lifecycle, workload isolation, GPU orchestration, fleet management, and Day 2 operations yourself. vCluster Platform delivers all of these in one stack, making Kamaji unnecessary as a separate component.

What does vCluster Platform's bare metal path include?

vCluster Platform integrates with vMetal for bare metal GPU server provisioning (PXE boot, OS installation, machine registration, network automation) and vCluster Standalone for the CNCF-certified control plane that runs directly on Linux with no k3s or kubeadm dependency. The combined path goes from GPU racks to isolated tenant clusters in one platform.

If you are building an AI cloud and you want the full isolation ladder without building it yourself, see how vCluster Platform works with a personalized demo.

‍