platform-eng

GPU Tenant Isolation Kubernetes with Dedicated Workers

Separate GPU tenants at the API and worker layers. vMetal provisions infrastructure, and vCluster assigns dedicated Private Nodes with optional vNode runtime hardening.

Trusted by the fastest-growing AI cloud providers
Problem

The GPU Isolation Tradeoff Is Real

Standard Kubernetes forces a painful choice between security and efficiency.

Namespace Isolation Is Too Weak

Tenants can see cluster-wide agents and other tenants' nodes. Namespace boundaries do not meet compliance requirements for shared GPU environments.

Separate Clusters Are Too Expensive

Separate control-plane servers per tenant consume capacity and increase the number of infrastructure stacks your team must operate.

GPU Performance Needs Validation

Isolation choices change the runtime and device-access design. Validate GPU drivers, networking and workload performance instead of assuming a universal VM penalty.

Solution

Tenant Isolation at the Control Plane Level

vMetal provisions machines, and vCluster provides independent tenant APIs and dedicated GPU Private Nodes. Optional vNode hardening and Netris network segmentation add boundaries alongside your GPU driver and workload policies. Lintasarta runs 170+ tenant clusters in production.

Layered GPU Tenant Isolation for Kubernetes

From control plane virtualization to kernel-level workload protection, each layer adds its own boundary.

Control Plane

Isolated Tenant Clusters as Lightweight Pods

Each tenant has an independent Kubernetes API, data store and RBAC boundary. Lightweight control-plane hosting reduces dedicated server requirements for GPU tenant boundaries; Private Nodes keep production workers tenant-specific.

  • Independent tenant API and data store
  • Tenant-scoped scheduling on Private Nodes
  • No dedicated control-plane servers per tenant
Node Isolation

Dedicated Worker Nodes Per Tenant

Private Nodes dedicate worker capacity to one tenant cluster, with its own CNI and storage configuration. For GPU tenant boundaries, select physical servers or VMs according to the required infrastructure boundary.

  • Dedicated worker nodes per tenant
  • Tenant-owned CNI and storage configuration
  • Physical servers or supported VMs
Workload Security

Kernel-Level Workload Isolation Per Tenant

vNode uses Linux user namespaces and seccomp to restrict workload privileges and system calls. It adds runtime hardening for GPU tenant boundaries without a guest kernel or hypervisor, complementing dedicated workers rather than allocating GPUs.

  • Linux user namespaces and seccomp
  • No guest kernel or hypervisor
  • Helps limit workload breakout
Defense in Depth

Layered Tenant Incident Boundaries

Combine separate tenant APIs, dedicated Private Nodes and vNode runtime hardening for GPU tenant boundaries. These boundaries help limit tenant incidents; infrastructure patching, least privilege and application security remain part of the deployment.

  • Separate tenant API boundaries
  • Dedicated production worker capacity
  • Runtime hardening complements infrastructure controls
Compatibility

CNCF-Certified Kubernetes Per Tenant

CNCF-certified Kubernetes provides standard APIs for GPU tenant boundaries. Tenants can use familiar tooling and cluster-scoped resources; validate GPU drivers, storage, networking and runtime requirements for the selected infrastructure.

  • Standard Kubernetes APIs
  • CNCF-certified per tenant cluster
  • No proprietary K8s surprises

Why vCluster

This isn’t a side project. Behind every vCluster deployment is 5+ years of deep K8s engineering, security hardening, and battle-tested infrastructure work at massive scale.

100K+
GPUs Powered
50+
GPU Clouds & F500s
<45
Days to Launch
30K
GitHub Stars

Get Started in 3 Steps

1
Schedule a Demo

Talk to our team about your stack

2
Deploy vCluster

Deploy vCluster on your infra in minutes

3
Onboard Your Tenants

Go live with a hyperscaler-grade tenant experience in days

FAQs

How does vCluster provide GPU tenant isolation in Kubernetes?

vCluster gives each tenant an independent Kubernetes API, data store and RBAC scope. Private Nodes dedicate worker capacity to that tenant, including its own CNI and storage configuration. vMetal orchestrates the machines underneath. This separates tenant administration and worker placement; shared infrastructure, application permissions and network policies still require an explicit security design.

Is this stronger than namespace-based Kubernetes isolation for GPU workloads?

Yes. Namespace isolation shares a single API server, data store, and control plane across all tenants, so one misconfigured tenant can observe or affect others. vCluster gives each tenant a separate control plane, and tenants can't see other tenants' nodes, pods, or cluster internals. For GPU environments where workloads are often untrusted or come from competing teams, that difference is critical.

Does tenant isolation in Kubernetes require VMs?

Dedicated Private Nodes remove cross-tenant workload placement from those workers. Bare metal avoids a hypervisor layer, but this is not a throughput or latency guarantee. GPU drivers, workload configuration, network fabrics and storage can still influence performance. vNode adds runtime hardening using the Linux kernel; benchmark the selected stack against the workload and service levels you intend to offer.

How many tenant clusters can one GPU platform run?

Capacity depends on control-plane sizing, tenant API activity, workload demand and available workers. Lightweight tenant control planes avoid dedicated control-plane servers for each customer, while Private Nodes still need dedicated worker capacity. Lintasarta's 170+ tenant clusters are a named deployment example, not a universal cluster limit. Size and test your fleet against its own availability and performance objectives.

Can tenants install their own CRDs and operators inside isolated clusters?

Tenants can receive cluster-admin within their own Kubernetes environment, including permission to install CRDs and supported operators. With Private Nodes, worker-level GPU tooling belongs to that tenant's dedicated nodes. Platform administrators retain infrastructure controls and define supported configurations. Private Node clusters do not sync workload resources to the control plane cluster, so integrations must support direct tenant worker operation.

Is vCluster used in production GPU cloud environments?

vCluster Labs software powers 100K+ GPUs and 1M+ CPUs, serving 50+ GPU clouds & Fortune 500s combined. In production, Lintasarta operates 170+ tenant clusters, while Boost Run completed its managed Kubernetes launch in under 45 days from the decision. These named deployments provide scale and launch examples for teams evaluating the platform for their own infrastructure.

Ready to Isolate GPU Tenants Without Overhead?

Explore independent tenant control planes, dedicated GPU workers and optional runtime hardening.