platform-eng

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.

Trusted by the fastest-growing AI cloud providers
Problem

GPU Sharing Needs Clear Tenant Boundaries

GPU partitioning and tenant cluster isolation solve different problems. External customers still need dedicated worker capacity.

GPU Partitions Are Not Clusters

MIG and vGPU can partition capacity, but do not provide an independent Kubernetes API or tenant-owned worker networking.

Time Slicing Shares Device Execution

Time-slicing divides access to a GPU. It does not guarantee memory or performance isolation between workloads.

Node Ownership Defines Customer Boundaries

Selling slices across customer clusters conflicts with a dedicated-node service. Partition GPUs within each external customer’s own nodes.

Solution

Dedicated Tenant Workers Around GPU Partitions

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.

Built for Kubernetes GPU Sharing at Tenant Scale

Use dedicated tenant nodes for customer workloads, supported GPU partitioning within each tenant, and separate control-plane and runtime controls.

Control Plane

Independent Tenant Kubernetes Control Planes

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.

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

Private Nodes for Production Tenants

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.

  • Dedicated worker nodes per tenant
  • Tenant-owned CNI and storage configuration
  • Physical servers or supported VMs
Trusted Internal Use

Internal Development Environments

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.

  • Operator-owned internal worker pools
  • Trusted development and CI workloads
  • Separate from customer production workers
Workload Security

Kernel-Native Workload Hardening

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.

  • Linux user namespaces and seccomp
  • No guest kernel or hypervisor
  • Helps limit workload breakout
Standards Compliance

Standard Kubernetes for Tenant GPU Tooling

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.

  • Own GPU operator per tenant
  • Full CRD and operator support
  • Standard Kubernetes APIs

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

What is Kubernetes GPU sharing?

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.

Does vCluster do GPU sharing?

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.

Can external customers share nodes in this dedicated-worker model?

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.

Does GPU partitioning guarantee performance isolation?

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.

Can tenants install their own GPU operators and MIG profiles?

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 clouds today?

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.

Design Your Tenant GPU Service

See dedicated tenant clusters with GPU partitioning inside each customer’s own worker nodes.