Skip to main content

Tenancy Models

vNode fills a specific position in the Kubernetes isolation spectrum. It delivers strong workload isolation without requiring dedicated nodes. In this spectrum, vNode is the only model that adds strong workload isolation while keeping tenants on shared worker nodes.

vNode is the right choice when:

  • Isolation must exceed namespace boundaries, but dedicated nodes are too expensive
  • Tenants run privileged workloads such as Docker-in-Docker, nested Kubernetes, or GPU workloads on shared infrastructure
  • Compliance requirements rule out namespace-only isolation but don't require fully dedicated nodes

vNode is not a replacement for dedicated nodes when tenants require fully separate infrastructure, dedicated CNI/CSI, or independent node lifecycle control.

The isolation spectrum​

Kubernetes offers several approaches to isolating tenants on shared infrastructure. Each trades off isolation strength, cost, node utilization, and operational complexity differently. The spectrum below uses vCluster Platform tenancy models. Virtual Nodes in this table represents shared worker nodes protected by vNode.

Traditional
Namespaces		Shared
Nodes		Virtual
Nodes		Dedicated
Nodes		Private
Nodes		Auto
Nodes		Standalone
Tenant autonomy
Cost effectiveness
High node utilization
Low complexity
Infrastructure isolation
Dedicated control plane
Dedicated nodes
Dedicated CNI & CSI

Traditional Namespaces share both nodes and the Kubernetes control plane. They offer the highest utilization and lowest cost. Use this model for trusted internal teams sharing infrastructure, not for untrusted or external tenants.

Shared Nodes give each tenant a dedicated control plane on shared worker nodes. Tenants get a full Kubernetes API and namespace-level isolation. Use this model when tenant trust is moderate and namespace boundaries are sufficient.

Virtual Nodes layer vNode isolation on top of shared worker nodes. Tenant workloads run in hardened sandboxes that contain container escapes at the vNode boundary. Virtual Nodes provide strong workload isolation on shared nodes, but do not provide fully dedicated infrastructure.

Dedicated Nodes reserve physical nodes per tenant. Isolation is strong at the node level, though CNI and CSI components are still shared with the control plane cluster. Use this model when workloads require dedicated infrastructure but full network and storage independence is not needed.

Private Nodes fully decouple tenant workloads from the control plane cluster. No components are shared between tenant nodes and the platform. Use this model for tenants that require fully independent infrastructure, dedicated CNI/CSI, and separate node lifecycle control.

Auto Nodes provision and remove nodes on demand, scaling automatically with workload demand. Each tenant gets dedicated nodes, which provides node-level isolation. Use this model when workloads have unpredictable demand and infrastructure cost should scale with usage.

Standalone runs a tenant cluster as a binary, independent of any platform. It can pair with Private Nodes or Auto Nodes for full infrastructure independence. Use this when tenant clusters must operate outside of any shared management plane.

Moving left on the spectrum toward Shared Nodes or Traditional Namespaces gains utilization but weakens isolation. Moving right toward Dedicated or Private Nodes strengthens infrastructure isolation but increases cost and complexity. In this spectrum, vNode is the only model that adds strong workload isolation while keeping tenants on shared worker nodes.

Inference provider workloads​

Inference providers sell managed model endpoints on GPU infrastructure. They usually combine several models from this spectrum rather than choosing one. The Inference Provider production path in the vCluster docs covers the full journey. The isolation tiers map onto this spectrum as follows:

  • Shared serving tier runs provider-owned models for many customers. This sits near Traditional Namespaces or Shared Nodes, with high utilization and weaker tenant isolation. Use it only for trusted, provider-owned workloads, never for customer-supplied code.
  • Tenant cluster per customer gives each customer a dedicated Kubernetes API boundary for their endpoints, secrets, and lifecycle.
  • Private GPU nodes give a customer dedicated worker-node infrastructure for predictable performance and stronger isolation.

vNode adds a boundary the others do not cover. It wraps workloads in a hardened sandbox that contains a container escape at the vNode boundary rather than the host node. For inference providers, this matters when a customer runs code you do not fully trust, such as:

  • custom or customer-supplied serving containers.
  • model adapters, plugins, or extensions loaded at runtime.
  • fine-tuning or training jobs that run alongside serving.
  • privileged GPU workloads that need device access beyond namespace boundaries.

Run this code on private GPU nodes and add vNode for the runtime sandbox. Private nodes give the infrastructure boundary an external customer's code needs, and vNode contains a container escape on top of that. Shared GPU nodes are for a provider-owned shared serving tier or for internal, trusted teams, not for an external customer's untrusted code.

vNode does not replace private GPU nodes. It layers onto them. Use private GPU nodes for the infrastructure boundary, and add vNode where the workload running on those nodes is untrusted or privileged. For how vNode layers onto a tenant cluster, see vCluster Integration.

Next steps​

For vCluster tenant clusters, see vCluster Integration. To choose between per-namespace and per-pod vNode isolation, see Deployment Options.