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.
For vCluster tenant clusters, see vCluster Integration. To choose between per-namespace and per-pod vNode isolation, see Deployment Options.