You have NVIDIA DGX hardware racked and Kubernetes running. The NVIDIA deployment guides got you through GPU Operator setup. Now you are looking at the next decision: what infrastructure software sits between bare metal and your tenant workloads.
This is not a question of "which Kubernetes distribution." It is a question of whether you assemble a stack from individual components or deploy an integrated platform. The answer shapes everything downstream: how fast you onboard new tenants, what your security boundaries look like, how much operational overhead your team absorbs, and whether you can prove isolation to a customer auditor.
This guide evaluates the two architectural approaches that matter for production DGX deployments. It is written for the platform architect who has moved past proof-of-concept and is selecting infrastructure software that will run paying customer workloads.
Before evaluating the two real approaches, we can quickly dispatch the third one that sometimes comes up in these discussions.
Namespace isolation uses Kubernetes namespaces, ResourceQuota objects, and network policies to separate tenants within a single shared cluster. It is what the Kubernetes documentation calls "soft" tenancy. All tenants share one API server, one etcd, one controller-manager. Secrets and ConfigMaps for every tenant are commingled in the same datastore. A single misconfigured RBAC rule creates cluster-wide blast radius. Tenants cannot be cluster-admins, cannot manage their own CRDs, and have no isolation for cluster-scoped resources.
For DGX production environments, namespace isolation fails on every dimension that matters. Customer contracts that require proof of hardware-level data separation are a non-starter. Regulated workloads cannot pass an audit. The platform team becomes a permanent bottleneck for every permission escalation and CRD request.
If your current deployment uses namespaces, treat it as a development setup with a planned migration. The two approaches below are what production looks like.
Once you rule out namespaces, the infrastructure software landscape for DGX Kubernetes narrows to two distinct architectures:
The component approach. You select a control plane manager, then assemble the surrounding stack yourself: fleet management, observability, backup and disaster recovery, GPU scheduling tooling, and the provisioning layer underneath. Kamaji is, in our analysis, one of the most widely discussed open-source control plane managers in this category. It focuses on control plane management as a single component. Everything else is your team's responsibility.
The platform approach. You deploy an integrated stack that covers the full operational surface area: tenant cluster orchestration, fleet management, GPU quota enforcement, Day 2 operations, bare metal provisioning, and workload isolation. vCluster Platform represents this model. It delivers what the component approach requires you to build.
The decision between them is not about features in a vacuum. It is about whether your team's engineering capacity is better spent building platform plumbing or building your AI cloud product.
Kamaji is a CNCF Sandbox project from Clastix. It runs tenant Kubernetes control planes (API server, controller-manager, scheduler) as pods inside a central admin cluster, as documented in the Kamaji architecture overview. Each tenant gets their own control plane, with per-tenant RBAC and CRD isolation. It runs on a shared datastore by default (Kine with SQLite, MySQL, or PostgreSQL; external etcd is available) and integrates with GitOps workflows through Flux or Argo CD.
As a control plane manager, Kamaji focuses on one part of the stack. If you need dedicated worker nodes per tenant, you configure and manage those yourself. If you need fleet-wide observability, coordinated upgrades across hundreds of tenant clusters, or a self-service portal for your internal teams, those are separate projects. GPU scheduling, NVIDIA MIG partitioning, bare metal provisioning: all outside Kamaji's scope. None of this is hidden. It is simply what happens when you choose a component rather than a platform.
vCluster Platform takes the opposite approach. Instead of providing one component and expecting you to assemble the rest, it delivers the full operational surface area as an integrated platform.
Tenant cluster orchestration. vCluster virtualizes the Kubernetes control plane itself. Each tenant gets a fully isolated, CNCF-certified Kubernetes cluster with its own API server, etcd, RBAC, and CRDs. Tenant secrets and Kubernetes objects are isolated per tenant. Every tenant can be a full cluster-admin within their own environment, managing their own CRDs, operators, and security policies without touching other tenants or the underlying infrastructure.
Flexible data plane isolation. The default production model is Private Nodes: dedicated worker nodes per tenant with per-tenant CNI and storage. This is hardware-level isolation without provisioning separate physical clusters. For dev, test, and CI/CD environments, shared nodes are available. For the strongest isolation tier, vNode provides kernel-native workload isolation using seccomp, cgroups, and Linux namespaces, delivering container breakout protection without hypervisor overhead and without sacrificing bare metal GPU performance. This gives you a single platform that scales from internal dev environments to regulated customer workloads with auditable hardware boundaries.
Fleet management at scale. A central UI, CLI, and API manage every tenant cluster in the fleet. Cluster templates ensure consistent configuration. SSO integrates with existing identity providers. Auto-sleep reduces infrastructure cost by pausing idle tenant clusters. The self-service tenant portal gives end customers an EKS-like or GKE-like provisioning experience. Terraform and Argo CD integrations make the platform GitOps-compatible.
Built-in Day 2 operations. Observability, backup, disaster recovery, and centralized upgrades are part of the platform, not bolt-ons. Tenant clusters can be upgraded from a central interface through zero-downtime rolling updates.
GPU-aware resource management. Each tenant cluster gets dedicated GPU resources through Private Nodes, eliminating noisy-neighbor contention. Auto Nodes dynamically provisions GPU nodes through the platform's Terraform module when tenants schedule workloads, then releases them when idle — so GPU capacity scales with demand rather than pre-allocation.
The full stack, pre-integrated. vMetal handles bare metal provisioning (PXE boot, OS installation, machine registration, network automation) so DGX servers go from rack to production without manual setup. vCluster Standalone provides a CNCF-certified control plane binary that runs directly on Linux with no k3s or kubeadm dependency. Certified Stacks for Run:AI, Ray, and Jupyter give tenants pre-validated AI environments that work with vCluster isolation out of the box.
Production provenance. vCluster powers 100K+ GPU nodes and has created 40M+ tenant clusters across 50+ AI cloud and Fortune 500 customers including CoreWeave and Nscale. vCluster Platform is validated in NVIDIA's DGX reference architecture. Boost Run launched their AI cloud platform on vCluster in 45 days.
The component vs. platform decision comes down to three questions that every platform architect evaluating DGX infrastructure software should answer:
1. What does your team want to build?
If your company's product is the AI cloud platform itself and you have a dedicated platform engineering team that wants to build and maintain fleet management, observability, backup tooling, and tenant isolation logic, the challenge is not whether Kamaji can serve as a starting point. It is that every layer you build on top of it (fleet management, observability, backup, GPU scheduling, tenant isolation) is something vCluster Platform already ships as an integrated whole, with the same architectural depth. The question is whether your team's competitive advantage comes from assembling infrastructure or from shipping AI cloud capabilities.
If your company's product is AI compute, inference services, or GPU capacity sold to customers, then assembling and maintaining infrastructure software is overhead. vCluster Platform handles that layer so your team focuses on what your customers actually pay for: GPU performance, AI tooling, and service reliability.
2. What is your timeline?
Building a production-grade platform around Kamaji means integrating control plane management with fleet tooling, GPU scheduling, observability, backup, disaster recovery, and a self-service portal. Experienced teams can do this, but it takes months of engineering effort before the first customer workload goes live.
vCluster Platform ships as an integrated stack. Boost Run went from contract to production in 45 days. For AI cloud providers operating in a market where speed to revenue determines whether you capture or lose customers, this timeline difference is the difference between leading and chasing.
3. What isolation proof do your customer contracts require?
Kamaji provides control plane isolation. For data plane isolation, you build it: dedicated node pools, network policy enforcement, runtime security tooling. Whether the result satisfies a customer auditor depends on your implementation.
vCluster Platform provides an auditable isolation spectrum. Private Nodes deliver hardware-level isolation with per-tenant dedicated worker nodes, directly addressing the common contract requirement of "proof that data is isolated at the hardware level." vNode provides kernel-native workload isolation for defense-in-depth without VM overhead. For architects who need to point at a specific isolation architecture during a customer security review, this is a meaningful difference.
The component approach is worth understanding because it clarifies what a platform like vCluster Platform actually replaces. If you are considering Kamaji as a starting point, ask what you are really evaluating. Kamaji handles control-plane management alone. But every layer you would need to build around it (fleet management, observability, backup, GPU scheduling, a self-service portal) is exactly what vCluster Platform already ships as an integrated stack. In our analysis, the DIY path built around Kamaji is a detour for teams whose priority is shipping an AI cloud product rather than assembling infrastructure.
Choose the platform approach (vCluster Platform) if building and maintaining infrastructure software is a means to an end rather than the end itself. This describes most AI cloud providers, inference services, and enterprise AI factories: organizations whose customers pay for GPU compute and AI capabilities, not for custom Kubernetes platform engineering. vCluster Platform delivers the full operational surface area (tenant cluster orchestration, fleet management, GPU quotas, Day 2 operations, bare metal provisioning, workload isolation) as an integrated stack, so your team ships your AI cloud product instead of building the plumbing underneath it.
Kamaji is a control plane manager. It runs tenant Kubernetes control planes as pods in a central admin cluster, giving each tenant their own API server, RBAC, and CRD isolation. vCluster Platform virtualizes the Kubernetes control plane itself and includes fleet management, built-in Day 2 operations, GPU-aware scheduling, and bare metal provisioning as part of an integrated stack. The comparison table above shows the full breakdown.
Namespace isolation shares a single control plane and kernel across all tenants. Secrets and ConfigMaps are commingled in a shared etcd. Tenants cannot be cluster-admins or manage their own CRDs. For DGX production environments where customer contracts require proof of hardware-level data separation, namespace isolation does not meet the bar. It is a development setup, not a production architecture.
Private Nodes are dedicated worker nodes per tenant with per-tenant CNI and storage. They deliver hardware-level isolation without provisioning separate physical clusters. vCluster Platform makes Private Nodes the production default because customer workloads with contractual isolation requirements need auditable hardware boundaries. Shared nodes remain available for dev, test, and CI/CD environments.
Each tenant cluster receives dedicated GPU resources through Private Nodes, which eliminate noisy-neighbor contention by giving each tenant their own worker nodes. Auto Nodes dynamically provisions GPU nodes through the platform's Terraform module when tenants schedule workloads, then releases them when idle — so GPU capacity scales with actual demand rather than pre-allocation.
Yes, through vMetal. vMetal handles PXE boot, OS installation, machine registration, and network automation, so DGX servers go from rack to production without manual setup. vCluster Standalone provides a CNCF-certified control plane binary that runs directly on Linux with no k3s or kubeadm dependency.
vNode provides kernel-native workload isolation using seccomp, cgroups, and Linux namespaces. It delivers container breakout protection without hypervisor overhead and without sacrificing bare metal GPU performance. vNode is the strongest isolation tier in the vCluster Platform spectrum, sitting above Private Nodes for defense-in-depth in regulated environments.
vCluster authored the DGX reference architecture, which NVIDIA validated. vCluster Platform is documented in NVIDIA's deployment guidance for DGX infrastructure, alongside the supported Slurm and Run:AI paths.
The infrastructure software you choose for NVIDIA DGX Kubernetes is a decision about engineering allocation, not just technology. The component approach gives you control and demands your team's time. The platform approach gives you velocity and lets your team focus on the product your customers actually pay for.
For most AI cloud providers and enterprise AI factories operating DGX infrastructure, the math is straightforward. The market is moving fast. Customer contracts increasingly require demonstrable tenant isolation. Platform engineering headcount is scarce and expensive. Every month spent building infrastructure software is a month not spent shipping product.
If you are ready to go from DGX hardware to a production AI cloud without assembling the infrastructure layer yourself, schedule a demo or try vCluster.
Deploy your first virtual cluster today.
