Tenancy Models with vCluster

Introduction

Kubernetes does not make multi-tenancy easy. Platform teams need to support fast-moving engineering orgs while controlling cost, keeping workloads secure, and staying operable. SaaS vendors, service providers, and regulated enterprises face the same problem with a harder boundary, because their tenants are not colleagues.

vCluster gives every tenant a dedicated control plane, its own API server, its own CRDs, and its own RBAC. What changes from model to model is where the tenant’s workloads run, and that one choice, the worker node model, is what sets the actual isolation level.

This guide covers every tenancy model vCluster supports, from lightweight namespace-based approaches through fully isolated per-tenant infrastructure, plus platform capabilities like Auto Nodes that keep infrastructure efficient. It orders the models from weakest boundary to strongest, says plainly which ones are safe for untrusted tenants, and starts with the questions that narrow the field.

Start Here: How Much Do You Trust Your Tenants?

Nine models sounds like a lot of choices. It is really one, and three questions narrow it. Ask them about the environment you hand to a tenant, whether that tenant is another team in your company or a paying customer.

1. Are you delivering a cluster or scheduler environment to the tenant, such as Kubernetes-as-a-Service, Slurm-as-a-Service, or an inference environment they control?
2. Does the tenant get direct access to that cluster or scheduler, beyond narrowly scoped read-only visibility?
3. Can the tenant run custom workloads, whether by supplying images, code, or model artifacts, or by defining jobs, pods, or other workload resources?

If your tenants are trusted, the lighter models are open to you. Trusted means every workload owner is inside your organization, you accept that tenants share a kernel, no contract requires dedicated infrastructure, and you can enforce hardening before onboarding. Most internal developer platforms sit here, and shared nodes are the efficient answer.

If your tenants are not trusted and any of the three answers is yes, you need private nodes. Every model above that line shares a kernel between tenants, and a shared kernel is not a boundary you can put an untrusted tenant behind. That applies to external customers, resold capacity, and regulated workloads, and it applies just as much to an internal tenant your compliance team treats as separate.

That is the core decision. The rest of this guide is about picking the most efficient model on the correct side of it.

Traditional Namespaces

Use Native Namespaces for Multi-Tenancy: Fast, but Limited in Scope

This is the baseline vCluster improves on, rather than a vCluster model. Lightweight and simple, but lacks strong isolation. Ideal for small teams or environments where security boundaries aren’t a concern.

Kubernetes namespaces are the most basic and widely used model for multi-tenancy. Each team or tenant is assigned a unique namespace within a shared cluster. Platform teams can apply RBAC rules, network policies, and resource quotas to help segment access and limit usage within each namespace.

While this approach is quick to set up and uses only core Kubernetes primitives, it lacks any form of control plane or API isolation. All tenants share the same scheduler, CRDs, node pool, and cluster-wide configurations. As a result, namespaces are prone to issues like CRD conflicts, noisy neighbors, and accidental cross-tenant impacts, making them unsuitable for production-grade multi-tenancy at scale.

How It Works

Namespaces logically divide a Kubernetes cluster into smaller, scoped environments using native Kubernetes objects. Each tenant receives a namespace, and optional policies are layered on top:

• RBAC: Controls which users or service accounts can access resources in a namespace.
• ResourceQuotas: Prevent a single tenant from consuming all compute resources.
• Network Policies: Can restrict traffic between namespaces.

All tenants continue to use the same underlying control plane, scheduler, node pool, and extensions. Cluster-wide resources like CRDs and webhooks are still global, and a misconfigured tenant can easily impact others.

Why It’s Valuable

• Zero Overhead: No extra tooling or provisioning required; works in any Kubernetes cluster.
• Quick Setup: Namespaces can be created instantly and managed via GitOps or CLI.
• Low Complexity: Platform teams don’t have to manage clusters or additional isolation layers.
• Familiar to Devs: Developers often already understand namespaces from past projects.
• Resource Visibility: Cluster admins can centrally observe and manage all workloads.

Challenges with This Approach

• No Control Plane Isolation: One misconfigured tenant can affect the entire cluster.
• CRD and API Conflicts: Tenants can’t define conflicting CRDs, admission controllers, or webhooks.
• Security Gaps: Enforcing true isolation via policies is difficult and error-prone.
• Limited Customization: Tenants can’t use their own controllers, operators, or tooling.
• Noisy Neighbors: Resource spikes from one tenant can degrade performance for others.

These limitations make traditional namespaces a poor fit for environments with strong isolation, customization, or scalability requirements.

Best-Fit Use Cases

• Internal teams that do not need an enforced trust boundary
• CI/CD pipelines or ephemeral dev workloads
• Proof-of-concept environments with no regulatory or security concerns
• Organizations just getting started with Kubernetes multi-tenancy

Isolation Characteristics

Compatibility

• ✅ Works in every Kubernetes cluster out of the box
• 🔶 Can be layered with policies for soft isolation
• ❌ No CRD or API isolation, conflicts can occur
• ❌ No tenant-level access to install controllers or custom webhooks
• ❌ Shared failure domains and limited customization

Namespace Syncing

Sync Tenant Namespaces to a Tenant Cluster: Lightweight Isolation, No Infrastructure Changes

Bring existing namespaces under vCluster management without disrupting workloads or provisioning new clusters.

Namespace Syncing allows you to connect existing Kubernetes namespaces from the Control Plane Cluster to a tenant cluster, making it one of the fastest and most flexible ways to adopt vCluster without changing how workloads are deployed. This approach lets you treat an existing namespace as a fully isolated tenant cluster from an access, API, and control perspective, without relocating workloads or provisioning additional infrastructure.

With Namespace Syncing, platform teams can gradually migrate to vCluster without impacting running workloads. Tenants gain tenant cluster benefits like isolated API access, scoped RBAC, and custom CRDs, while underlying compute remains shared and existing namespace-level policies stay in place.

How It Works

When a vCluster is created with namespace syncing enabled, it establishes a logical connection between a namespace in the Control Plane Cluster and the tenant cluster’s control plane. All Kubernetes resources created within the tenant cluster are automatically synced into the specified namespace on the Control Plane Cluster.

The synced namespace continues to use the Control Plane Cluster’s node pool, network infrastructure, and storage. However, tenants interact with the tenant cluster as if it were a dedicated environment, with their own CRDs, RBAC policies, service accounts, and access controls, all enforced by vCluster.

Why It’s Valuable

• Fast Adoption Path: Migrate workloads into vCluster without moving or re-deploying anything.
• Low Infrastructure Overhead: Uses the same Control Plane Cluster and namespace structure already in place.
• Control Plane Isolation: Tenants get their own API server and control mechanisms.
• Customizability: Tenants can define their own CRDs and controllers without impacting others.
• Ideal for Gradual Migration: Enables step-by-step adoption of vCluster for existing namespace-based multi-tenancy.

Challenges with This Approach

• Shared Underlying Infrastructure: Tenants still share the same nodes, network, and storage.
• Limited Isolation Guarantees: Network and security policies must still be enforced at the namespace level.
• Potential Misalignment: Some policies applied at the host namespace may conflict with vCluster user expectations.
• No Node or Resource Pooling Separation: All workloads still compete for the same physical compute.

Namespace Syncing offers a strong improvement over traditional namespaces, but it still inherits some of the same infrastructure-level limitations.

Best-Fit Use Cases

• Teams already using namespace-based tenancy that want a real control plane boundary per tenant
• Organizations migrating to vCluster incrementally
• Workloads that don’t need node isolation but benefit from API or RBAC separation
• Internal platforms that want to give tenants full CRD/custom resource access

Isolation Characteristics

Compatibility

• ✅ Works with existing namespaces in any Kubernetes cluster
• ✅ Supports all vCluster control plane features
• ✅ No need to migrate workloads or change deployment models
• 🔶 Still requires network and quota policies for full tenant separation
• ❌ Not suitable for strict security or compliance environments without additional controls

Shared Nodes

Run Tenant Clusters on Shared Nodes: Maximum Density, No New Infrastructure

Shared nodes are how you offer nested clusters. A nested cluster is a tenant cluster whose control plane and workloads both run inside a Control Plane Cluster you already operate. Every tenant gets a dedicated API server, its own CRDs, and its own RBAC at near-zero marginal cost, with no new infrastructure to provision per tenant. That makes it the right shape for internal developer platforms, dev and test environments, CI, sandboxes, evaluation environments, and any tier where the tenants are colleagues. It is a density and cost model.

Nested clusters share the node and the kernel. That makes them a cost model, not a security boundary. They are not for external, resold, regulated, or otherwise untrusted tenants who get cluster access or can run arbitrary workloads. When an environment reaches any of those, move it to private nodes. The platform, the API, and the tenant’s experience do not change.

The Shared Nodes tenancy model allows multiple tenant clusters to run workloads on the same physical Kubernetes nodes. This configuration is ideal for scenarios where maximizing resource utilization is a top priority, especially for internal developer environments, CI/CD pipelines, and cost-sensitive use cases.

Each tenant cluster has its own isolated control plane, API server, and CRDs, but workloads are scheduled without node-level isolation. This setup helps platform teams deliver the benefits of vCluster (like per-tenant customization and faster provisioning) while minimizing infrastructure costs by sharing underlying compute across all tenants.

How It Works

All tenant clusters run in a single Control Plane Cluster and schedule pods onto the same shared node pool. The tenant cluster’s control plane enforces separation at the API, RBAC, and CRD levels, but does not restrict pod scheduling unless additional mechanisms (e.g., taints, affinities) are applied.

Tenants interact with their own tenant clusters as if they are separate environments, but their workloads run side-by-side with those from other tenant clusters at the node level. Shared infrastructure components like the container runtime, CNI, and CSI drivers are used across all tenants.

Why It’s Valuable

1. High Efficiency: Minimizes unused capacity and improves node utilization.
2. Low Cost: No need to overprovision for every tenant, compute is pooled and shared.
3. Fast Provisioning: Tenant clusters can be spun up instantly without any node-specific configuration.
4. Supports Burst Workloads: Perfect for CI, test environments, or ephemeral developer clusters.
5. Full vCluster Benefits: Tenants still receive isolated control planes, CRD freedom, and scoped access.
6. Nothing New to Provision: No new hardware, no node enrollment, no network design. If you already run a Kubernetes cluster, you can hand out isolated tenant clusters on it today.

Challenges with This Approach

1. No Node Isolation: Workloads from different tenants can impact each other’s performance (noisy neighbors). Virtual nodes can help if more isolation is a requirement.
2. Security Considerations: Tenants share the same CNI, CSI, and host OS, so security policies must be enforced manually.
3. Resource Quotas Are Optional: Without tight quota management, one tenant can consume excess compute.
4. Not Ideal for Regulated Workloads: Lacks the separation required for compliance-heavy environments.

This model is best when speed and density matter more than strict isolation guarantees.

Best-Fit Use Cases

• Internal developer environments with high churn
• CI pipelines or test jobs that run in parallel
• Shared staging environments with limited budget
• Evaluation and sandbox environments for trusted users

Isolation Characteristics

Compatibility

• ✅ Works with Sleep Mode, Auto Wakeup, and Auto Delete
• ✅ Supported in all Kubernetes clusters
• ✅ Full CRD and API isolation per tenant cluster
• 🔶 Requires quota enforcement and network policies
• ❌ Not intended for workloads requiring compute or kernel-level separation

vNode

A Kernel Boundary on Shared Nodes, with No VM and No Virtual Kubelet

vNode isolates tenant workloads on shared nodes using Linux user namespaces, FUSE-based filesystem virtualization, and targeted seccomp filtering. Tenants cannot read each other’s files, processes, or hardware information, and that holds even after a container escape.

This gives you a kernel boundary between tenants without dedicating nodes to each one. A single vNode can be shared across all pods in one tenant cluster, so tenants get a virtualized view of the node environment rather than the real one, while the underlying compute stays pooled. Each tenant cluster still receives its own control plane, CRDs, and RBAC.

How It Works

vNode runs as a container runtime layer on the shared node. Tenant workloads are placed inside Linux user namespaces, so a process that believes it is root inside the tenant cluster is an unprivileged user on the host. FUSE-based filesystem virtualization gives each tenant its own view of the filesystem, and seccomp filtering blocks the syscalls that would otherwise leak host or cross-tenant information.

From the tenant’s perspective they see one or more virtual nodes, each a scoped execution environment. They do not see or interact with the real underlying node, other tenants’ processes, or host hardware details. Compute is still pooled underneath, but the kernel-level view is not shared.

Why It’s Valuable

• Node Boundary Abstraction: Tenants can’t see or schedule outside of their virtual node scope.
• Holds After Container Escape: User namespaces mean a tenant breaking out of a container is still unprivileged on the host.
• No Cluster Duplication Needed: Offers isolation benefits without spinning up separate node pools.
• Supports Existing Kubernetes Patterns: Tenants can use scheduling features like affinities or anti-affinities.
• Improved Tenant Safety: Reduces exposure to noisy neighbors and unauthorized scheduling.

Challenges with This Approach

• Still Uses Shared Compute: Physical resources are shared; this is not a hardware-level boundary.
• Added Abstraction Layer: Virtual node logic adds complexity to scheduling and debugging.
• Resource Overlap Is Still Possible: Without proper quota controls, tenants may compete for compute.
• Needs Proper Policy Enforcement: Virtual isolation doesn’t prevent abuse unless reinforced with quota and security policies.

This tenancy mode is ideal when you need workload separation but want to avoid operational and cost overhead from dedicated infrastructure.

Best-Fit Use Cases

• Platforms that need a kernel boundary between tenants without dedicating nodes to each one
• Internal Kubernetes platforms offering self-service environments
• Environments with security-conscious tenants but shared compute models
• Mid-sized teams that need boundaries between dev, staging, and test

Isolation Characteristics

Compatibility

• ✅ Fully compatible with vCluster
• ✅ Supports Sleep Mode, Auto Wakeup, and custom CRDs
• ✅ Allows scheduling constructs like affinities and taints
• 🔶 Requires quota enforcement to prevent noisy neighbor effects
• ❌ Not a substitute for dedicated physical nodes where a hardware boundary is required

Dedicated Nodes

Assign Tenant Clusters to Specific Node Pools: Dedicated Compute, No Cluster Sprawl

Provides node-level compute separation by targeting labeled node groups within a shared cluster.

Dedicated Nodes allow platform teams to give each tenant cluster exclusive access to a set of physical nodes, without having to provision entirely separate clusters. By combining vCluster’s multi-tenant architecture with Kubernetes node selectors, workloads from each tenant cluster can be scoped to a specific group of labeled nodes, ensuring compute separation across tenants.

This approach enables strong operational boundaries and predictable performance, while maintaining all the benefits of shared infrastructure. It’s especially effective for teams who want dedicated compute for certain tenants, environments, or workloads, without duplicating every part of the platform stack.

How It Works

Each tenant cluster is configured with a Kubernetes nodeSelector (or affinity rules) that ensures all tenant workloads are scheduled only to nodes with specific labels. For example, a tenant cluster assigned to nodegroup=tenant-a will only run pods on nodes matching that label.

While compute is scoped to these dedicated nodes, all other components, including the CNI, CSI, and the underlying Control Plane Cluster, remain shared. The tenant cluster itself maintains full API isolation, separate CRDs, tenant-specific RBAC, and control plane security.

Why It’s Valuable

• Precision Scheduling: Route tenant workloads to specific node pools based on cost, workload type, or team ownership.
• Cost-Efficient Isolation: Avoids the overhead of full cluster duplication while maintaining compute separation.
• Flexible Rebalancing: Node assignments can be changed dynamically by relabeling or updating selector rules.
• Compatible with Autoscaling: Use dynamic node pools that scale up or down based on tenant cluster workload demand.
• Retains Full vCluster Benefits: Control plane isolation, tenant-level CRDs, and access control still apply.
• Answers the “We Want Our Own Nodes” Request: A team or tenant asking for dedicated hardware, whether for GPUs, licensing, latency, or noisy-neighbor reasons, usually does not need a separate cluster. Pinning their tenant cluster to a labeled node pool gives them exclusive compute out of capacity you already run.

Challenges with This Approach

• Shared Platform Layer: Tenants still share the same CNI, CSI, and Kubernetes host infrastructure.
• Label Enforcement Required: Security depends on ensuring workloads stay within their assigned nodes.
• Manual Oversight Needed: Mislabeling or skipped selectors could result in accidental cross-tenant scheduling.
• Policy Backing Recommended: Use admission controls, automation, or templates to avoid human error.
• Still Not a Security Boundary: Node labels are scheduling hints, not enforcement, and the Control Plane Cluster is still shared. Use this for capacity guarantees and noisy-neighbor control, not for tenants you do not trust.

Dedicated Nodes strike a balance between hard separation and infrastructure efficiency, but require thoughtful governance and policy design.

Best-Fit Use Cases

• Teams with predictable compute needs and tenant-specific node pools
• Production workloads needing dedicated capacity without separate clusters
• ML, GPU, or high-performance compute workloads
• Workloads where performance isolation matters but full platform duplication is overkill

Isolation Characteristics

Compatibility

• ✅ Works with Sleep Mode, Auto Wakeup, and Auto Delete
• ✅ Configurable via vcluster.yaml or Helm
• ✅ Supports taints, tolerations, affinities, and autoscaling
• 🔶 Requires label enforcement via policies or automation
• ❌ Not intended for full platform isolation (see Private Nodes instead)

Private Nodes

Dedicated Nodes Per Tenant, with Separate CNI, CSI, and Compute

Private Nodes provide the strongest isolation among vCluster tenancy models. Each tenant cluster gets its own worker nodes. Nodes join explicitly through a token-based enrollment script, then connect to the tenant’s control plane over a WireGuard tunnel. There is no cross-tenant scheduling, and each tenant gets a separate CNI and separate storage.

The tenant’s control plane runs on the Control Plane Cluster you already operate, so you get a hard node and kernel boundary per tenant without provisioning and managing a separate Kubernetes cluster for each one. From the tenant’s perspective, the environment behaves like a single-tenant Kubernetes cluster with all platform services isolated.

No tenant shares compute, networking, or storage with another. This is the model for workloads that require strict compliance or regulatory boundaries, and for any tenant you cannot place behind a shared kernel.

How It Works

Each tenant cluster is assigned its own worker nodes. A node is enrolled by running a join script that installs the node components and establishes a WireGuard tunnel back to that tenant’s control plane. The CNI, CSI, kube-proxy, and other node-level components are isolated per tenant.

From the Control Plane Cluster, a worker node that joined a tenant cluster is not visible as a Kubernetes node. No operator on the Control Plane Cluster can inspect that tenant’s workloads through the Kubernetes API. Tenants cannot interfere with one another at any layer, from API server down to the node kernel, while still keeping the benefits of the tenant cluster abstraction such as fast provisioning, CRD freedom, and sleep mode.

Why It’s Valuable

• The Only Model for Untrusted Tenants: The isolation level for anything you cannot put behind a shared kernel: external or resold tenants, regulated environments, GPU workloads that cannot share a node pool, internal tenants your compliance team treats as separate, and customers who expect hyperscaler-grade separation.
• Invisible to Your Operators: The tenant’s nodes do not appear as Kubernetes nodes on the Control Plane Cluster, and its workloads cannot be inspected from there through the Kubernetes API.
• Compliance Ready: Meets requirements for regulatory environments like finance, healthcare, or government.
• Customizable Per Tenant: Each tenant can run their own platform stack or runtime configurations.
• No Noisy Neighbors: Guaranteed performance isolation at the node and kernel level.
• Platform Hardening: Enables per-tenant upgrades, maintenance windows, or tuning.

Challenges with This Approach

• Capacity Is Planned Per Tenant: Nodes are not pooled across tenants, so utilization is planned per tenant rather than shared. Auto Nodes reduces the idle-capacity cost of this by provisioning and deprovisioning nodes on demand.
• You Own the Node Lifecycle: OS image, CNI, and CSI choices are yours per tenant cluster. That control is the point, and it is work that shared nodes does not require.
• Higher Infrastructure Overhead: Dedicated compute costs more than pooled compute. The tradeoff is that it is the only model with a real boundary between tenants.
• Slower Startup Time: New environments depend on node enrollment or automation readiness.

This model is ideal when tenant safety and independence are more important than resource efficiency.

Best-Fit Use Cases

• Highly regulated workloads (e.g., financial services, healthcare, public sector)
• Multi-tenant SaaS offerings with strict security or compliance contracts
• Internal platforms with high-value or mission-critical workloads
• Customers who need per-tenant customization, SLAs, or upgrades

Isolation Characteristics

Compatibility

• ✅ Works with hosted or standalone control planes
• ✅ Supports full vCluster feature set
• ✅ CRDs, operators, and workloads are fully tenant-scoped
• 🔶 Requires automation to manage node lifecycle and cost
• ❌ Not ideal for bursty or ephemeral workloads due to infra cost

Auto Nodes

Dynamic Node Autoscaling, Anywhere You Run Kubernetes

Unlock cloud-style elasticity across tenant clusters in public cloud, private cloud, and bare metal with embedded Karpenter.

Auto Nodes is a node lifecycle capability rather than an isolation model in its own right. It is how nodes arrive and leave, and it pairs with the worker node model you have already chosen. Auto Nodes integrates a managed instance of Karpenter directly inside each tenant cluster, transforming it into a fully isolated autoscaling unit. With dynamic provisioning and deprovisioning of compute across hybrid, multi-cloud, and even bare metal environments, platform teams can now scale workloads elastically, without over-provisioning or vendor lock-in.

Each tenant cluster can trigger the creation of NodeClaims, which the platform fulfills by dynamically scaling up the appropriate node pool, whether that means launching traditional cloud VMs, bare metal PXE-booted nodes, or virtualized environments like vNode or KubeVirt. Underutilized nodes are automatically drained and returned to the shared pool, improving efficiency and reducing cloud spend.

How It Works

The vCluster Platform runs an embedded, fully configurable instance of Karpenter that listens to scheduling pressure and provisioning needs from all connected tenant clusters. When a tenant cluster’s scheduler detects the need for more compute (e.g., due to a pending pod), it submits a NodeClaim to the platform.

The platform’s Node Manager fulfills these claims by selecting from available Node Pools, each defined by a set of instance types, node classes, or backing infrastructure (e.g., GPU, ARM, x86, bare metal). Nodes are joined dynamically and assigned to the requesting tenant cluster.

Once the workload completes or scales down, unused nodes can be automatically removed, rebalanced, or reused by other tenant clusters.

Why It’s Valuable

• Avoid Cloud Lock-In: Move workloads across providers or datacenters without changing your workload or cluster structure.
• Elastic Compute for Isolated Workloads: No more trade-offs between hard isolation and flexible scaling.
• Infrastructure-Agnostic: Supports autoscaling across cloud, private data center, GPU clusters, or hybrid setups.
• Better Cost Efficiency: Auto Nodes eliminate idle capacity by deprovisioning compute on demand.

Challenges with This Approach

• Shared Pools Add Complexity: In multi-tenant setups, you must balance fairness, priority, and scale limits.
• Requires Intelligent Node Pool Design: NodePools must be designed for tenant needs and workloads.
• Observability is Critical: Teams need visibility into node claims, scaling events, and pool usage.
• Initial Setup Involves Tuning: Configuration of Karpenter, limits, taints, and budgets requires careful planning.

Despite these, the payoff is massive in terms of scalability, efficiency, and automation.

Best-Fit Use Cases

• Large-scale environments with multiple bursty tenant clusters
• GPU and accelerator fleets where idle dedicated capacity is the main cost driver
• CI/CD workloads that fluctuate heavily
• Bare metal node management in on-prem or hybrid environments
• Environments requiring cost-effective scaling of production and dev workloads

Isolation Characteristics

Compatibility

• ✅ Works with all vCluster features: Sleep Mode, Auto Wakeup, vCluster.yaml, etc.
• ✅ Supports GPU/CPU constraints, NodeClasses, and NodePools.
• ✅ Integrates with OpenTofu/Terraform, BCM, KubeVirt, and custom providers.
• 🔶 Requires provisioning access to target infrastructure.

‍

Standalone

Run Kubernetes on Your Own Metal, with No Parent Cluster Underneath

vCluster Standalone is a complete Kubernetes distribution that runs as a self-contained binary on bare metal or VMs, with no dependency on any other Kubernetes distribution. There is no Control Plane Cluster underneath it.

This is the model when you are building a Kubernetes platform from your own hardware up rather than layering on an existing cluster. You bootstrap a Control Plane Cluster and install Platform in one pass, then provision tenant clusters on top using whichever worker node model each environment needs.

If what you want is a throwaway cluster on a laptop or in CI, that is Docker (vind), covered in the next section, not Standalone.

How It Works

Standalone runs as a self-contained binary on bare metal or VMs. It brings its own control plane components and does not require any Kubernetes cluster to exist first, which makes it the bottom layer of a stack rather than a layer on top of one.

It behaves like a regular Kubernetes control plane: custom resources, RBAC, workload scheduling, and CI/CD integrations all work as expected. Once Standalone and Platform are running, tenant clusters are provisioned on top of it with shared, dedicated, or private nodes depending on who the tenants are.

Why It’s Valuable

• No Control Plane Cluster Required: Nothing needs to exist underneath it. You are not layering a platform on someone else’s Kubernetes.
• A Full Stack from One Install: Bootstrap the Control Plane Cluster and Platform together, then provision tenant clusters on top.
• Runs Where There Is No Cluster: Suited to air-gapped, sovereign, edge, and remote sites.
• You Control the Distribution: No dependency on a managed Kubernetes service or its release cadence.

Challenges with This Approach

• You Own the Bottom of the Stack: Hardware, OS, and node lifecycle are yours. That is the tradeoff for having no dependency underneath you.
• More Setup Than Layering on an Existing Cluster: If you already run Kubernetes, shared or private nodes get you to tenant clusters faster.
• Capacity Planning Is Yours: There is no upstream cluster absorbing burst, so node provisioning has to be designed in. Auto Nodes helps here.

Standalone is the right choice when the bottom of the stack needs to be yours, and unnecessary work when it does not.

Best-Fit Use Cases

• On-premises and colocated Kubernetes platforms
• Air-gapped, sovereign, and regulated deployments
• Edge and remote sites with no upstream cluster to build on
• Service providers and AI clouds building a Kubernetes product on their own hardware
• Anyone who needs the bottom of the stack to be theirs

Isolation Characteristics

Compatibility

• ✅ Works without any pre-existing Kubernetes cluster
• ✅ Fully supports CRDs, RBAC, and tenant cluster API behavior
• ✅ Supports shared, dedicated, and private node models on top
• ✅ Runs in air-gapped and offline environments
• 🔶 Requires you to own hardware, OS, and node lifecycle

Docker (vind)

A Complete Tenant Cluster on One Docker Host

vind runs a complete tenant cluster entirely in Docker containers, with no Kubernetes dependency at all. The control plane and worker nodes run as containers on a single Docker host, which makes it the fastest way to get a real cluster in front of a developer or a CI job.

How It Works

vind starts the tenant cluster’s control plane and its worker nodes as containers on one machine. Because everything is local, startup is measured in seconds and teardown is complete. There is no Control Plane Cluster and no cloud infrastructure involved.

Why It’s Valuable

• Fast Startup: Clusters launch in seconds, which suits ephemeral use.
• No Kubernetes Required: Just Docker, so it runs on a laptop or a CI runner.
• Real Cluster Behavior: Supports CRDs, RBAC, and workload scheduling rather than simulating them.
• Clean Teardown: Nothing persists after the containers are removed.

Challenges with This Approach

• Single Host: Capacity is bounded by one machine, so this is not a scaling model.
• Not Tenant-Facing: Container-level separation on a shared Docker host is not a boundary for anyone outside your team.
• Ephemeral by Design: Not intended for long-running or production workloads.

Best-Fit Use Cases

• Local development
• CI/CD pipelines that need a cluster on demand
• Preview environments and pull request testing
• Demos, workshops, and Kubernetes onboarding

Traditional Separate Clusters

Provision a Cluster Per Tenant: Strong Isolation, Heavy Overhead

The traditional method for tenant separation. Offers full control and security at the cost of complexity, duplication, and scalability challenges.

Provisioning a fully separate Kubernetes cluster for each tenant is the most well-understood and straightforward form of multi-tenancy. Every tenant gets their own separate cluster, including a dedicated control plane, node pool, and platform services like CNI, CSI, monitoring, and logging.

While this model offers the strongest isolation guarantees, it comes with substantial operational and financial cost. It often leads to cluster sprawl, duplicated effort across environments, and growing platform complexity as the number of tenants increases. This approach remains common in regulated industries and traditional enterprise settings, but it is increasingly being replaced by more scalable, efficient alternatives, like vCluster.

How It Works

Each tenant receives its own Kubernetes cluster, either provisioned manually or via infrastructure-as-code tools (e.g., Terraform, Cluster API, cloud-native APIs). All cluster resources are isolated by design: tenants cannot interact with each other, and workloads are scheduled to entirely separate compute environments.

This isolation extends beyond compute, since each tenant also gets independent CRDs, webhooks, admission controllers, and control plane components. But because every cluster runs the full stack of infrastructure services, the cost and complexity increase linearly with the number of tenants.

Why It’s Valuable

• Complete Isolation: No resource sharing means no cross-tenant impact.
• Compliance-Ready: Meets strict regulatory, audit, or contractual requirements.
• Tenant Autonomy: Each tenant can customize CRDs, networking, upgrade schedules, and tooling.
• Minimal Policy Enforcement Needed: Isolation is inherent, reducing the need for complex rules.
• Dedicated SLAs: Easy to implement per-tenant service level agreements.

Challenges with This Approach

• High Operational Overhead: Managing dozens or hundreds of clusters increases burden on platform teams.
• Cluster Sprawl: Platform components must be duplicated across every environment: CNI, CSI, monitoring, ingress, policy, and the rest.
• Poor Resource Utilization: Underused compute is common due to rigid resource boundaries.
• Slow Provisioning: Spinning up new clusters is slower and more resource-intensive than launching a tenant cluster.
• Difficult to Scale: As tenant count grows, automation, cost, and complexity become major concerns.

While this model works for high-security workloads, most teams can achieve similar benefits with less cost and complexity using vCluster.

Best-Fit Use Cases

• Regulated workloads requiring strict physical or organizational separation
• Enterprises with highly siloed teams or business units
• Multi-tenant SaaS vendors with per-customer compliance obligations
• Environments with per-tenant billing, upgrades, or platform customization

Isolation Characteristics

Compatibility

• ✅ Works with all Kubernetes-native tools and architectures
• ✅ Easy to enforce strict per-tenant customization
• ✅ Suitable for regulated environments and dedicated SLAs
• ❌ Inefficient at scale without extensive automation
• ❌ Duplicates platform components across clusters
• ❌ Slower to provision and more costly to maintain

Closing

There is no one-size-fits-all model for Kubernetes multi-tenancy, and with vCluster you do not have to pick just one. Run internal dev environments on shared nodes and production or customer-facing environments on private nodes, from the same platform and the same API, and move a tenant between models without changing what they see.

Start with Namespace Syncing or Shared Nodes for trusted tenants. Move to Private Nodes when a tenant is external, resold, regulated, or otherwise untrusted. Use vNode where you need a kernel boundary without dedicating nodes, and Auto Nodes to keep infrastructure efficient at every step.

And when you’re ready to abstract away the Kubernetes learning curve entirely, vCluster gives you the tools to build a seamless internal platform with fast, secure, tenant-aware clusters at its core.

Start with the trust question. Everything after it is optimization.

Ready to see it in action? Try vCluster today →

Full Comparison Table