Kubernetes GPU Sharing Within Dedicated Tenant Nodes
Partition GPU capacity within each customer's dedicated nodes. vMetal provisions machines, and vCluster supplies tenant clusters with Private Nodes around hardware-supported GPU sharing.
Partition GPU capacity within each customer's dedicated nodes. vMetal provisions machines, and vCluster supplies tenant clusters with Private Nodes around hardware-supported GPU sharing.
GPU partitioning and tenant cluster isolation solve different problems. External customers still need dedicated worker capacity.
MIG and vGPU can partition capacity, but do not provide an independent Kubernetes API or tenant-owned worker networking.
Time-slicing divides access to a GPU. It does not guarantee memory or performance isolation between workloads.
Selling slices across customer clusters conflicts with a dedicated-node service. Partition GPUs within each external customer’s own nodes.
vCluster puts each external customer's GPU workloads on Private Nodes. Within those nodes, supported hardware and drivers provide GPU partitioning; vMetal provisions machines and each customer receives an independent Kubernetes control plane. vCluster Labs serves 50+ GPU clouds & Fortune 500s.
Use dedicated tenant nodes for customer workloads, supported GPU partitioning within each tenant, and separate control-plane and runtime controls.
Each tenant has an independent Kubernetes API, data store and RBAC boundary. Lightweight control-plane hosting reduces dedicated server requirements for partitioned GPU workloads; Private Nodes keep production workers tenant-specific.

Dedicate GPU workers to each tenant through Private Nodes. This removes cross-tenant workload placement from those workers for partitioned GPU workloads; network bandwidth, storage and GPU partitioning still need explicit policies.

Trusted internal development and CI can use operator-controlled worker pools with separate tenant APIs. External customers use dedicated Private Nodes. Internal GPU configuration and worker policies remain under the platform operator’s control.

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

CNCF-certified Kubernetes exposes standard APIs for GPU workloads within each tenant. On dedicated Private Nodes, tenants can configure supported operators and device plugins; validate driver, runtime and storage compatibility for the selected stack.

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.
Talk to our team about your stack
Deploy vCluster on your infra in minutes
Go live with a hyperscaler-grade tenant experience in days
GPU sharing can use hardware- and driver-supported mechanisms such as MIG, vGPU or time-slicing. DRA is the Kubernetes allocation framework for driver-supported devices or partitions, rather than a slicing mechanism itself. In a customer-facing vCluster service, partition capacity within each customer's dedicated Private Nodes. The tenant control plane provides a separate administrative boundary around those workloads.
vCluster does not partition GPU hardware itself. It provides tenant cluster and worker boundaries around the GPU capabilities your drivers expose. MIG and vGPU can provide supported partitions, time-slicing shares device execution, and DRA coordinates driver-supported allocation. For external customers, use these mechanisms within each tenant’s own Private Nodes rather than selling cross-customer slices from a dedicated-worker service.
External customers receive dedicated worker capacity through Private Nodes. Within each customer's own nodes, supported drivers can partition GPU capacity for that customer's workloads. Shared Nodes are a separate option for trusted internal development and CI environments, with operator-owned GPU configuration. Do not combine that internal worker model with a promise of dedicated production nodes for independent external customers.
GPU partitioning does not provide a universal performance guarantee. MIG and vGPU offer hardware- and driver-specific partition options, while time-slicing shares device execution without guaranteed performance isolation. DRA exposes driver-supported device allocation in Kubernetes. Keep these controls within each external customer’s dedicated Private Nodes, and validate workload throughput alongside network, storage and runtime configuration.
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.
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.
See dedicated tenant clusters with GPU partitioning inside each customer’s own worker nodes.