Namespace, virtual cluster
or a cluster each?
Everyone argues this as one question. It is three. The answer depends first on what your tenant actually receives — a cluster, a namespace, or your product — and only then on how much isolation that requires. Four questions to place you, then six to ten more. No email needed.
Multi-tenancy is not one problem. It is three problems sharing a word.
The public argument is always namespace versus virtual cluster versus dedicated cluster, as though it had a single answer. It does not. Work out which class you are in first — everything else follows from it, and comparing tools across classes is how incoherent shortlists get made.
Provider
You supply Kubernetes to others
- Receives
- A cluster endpoint and kubeconfig
- Unit
- A cluster
Your tenants consume whole clusters. The question is not how to divide a cluster — it is how cheap you can make a cluster before you can afford to give one to every tenant.
Platform
You divide clusters you consume
- Receives
- A namespace or project, with kubectl
- Unit
- A team
You get clusters from a cloud or an internal provider and host many teams inside them. This is the argument everyone means when they say "multi-tenancy", and the only one where namespace-versus-virtual-cluster is the real question.
Product
You run your product for many customers
- Receives
- An account in your product — never Kubernetes
- Unit
- A customer
Your tenants are customers, not engineers. API-level isolation matters far less than data isolation, jurisdiction and per-customer cost — and the honest answer is often that your tenancy belongs in your application, not in Kubernetes.
A and B stack. Whoever runs your EKS is class A; you are class B on top of it. A platform organisation running hosted control planes for its business units is a provider on the outside and a platform on the inside — and both boundaries are yours to design.
13 topologies — but only within your class
Every technique the advisor can recommend, grouped by the class it belongs to and listed lightest to heaviest. Compare down a column, not across: techniques from different classes answer different questions, and comparing them against each other is the mistake this page exists to end.
- Virtual clusters
- A virtual control plane per tenant, workloads synced onto shared host nodes. Cheapest and fastest to hand out; weakest node isolation. Ideal for ephemeral and development tenants.
- Hosted control planes
- A dedicated API server, etcd and worker nodes per tenant, with the control planes themselves running as workloads in a shared management cluster. Near-full isolation at a fraction of the control-plane cost.
- Full cluster per tenant
- A complete, independently provisioned cluster per tenant. Maximum isolation, maximum cost and operational load.
- Namespace per tenant
- Soft multi-tenancy: one namespace per team, with RBAC, quotas and network policy enforced consistently. The right default for trusted internal teams.
- Hardened namespace tenancy
- Namespace tenancy plus dedicated node pools, strict NetworkPolicy and a sandboxed container runtime. Soft multi-tenancy taken as far as it goes.
- Virtual cluster per team
- Each tenant gets their own API server, so they can install CRDs, run admission webhooks and pick their own Kubernetes version — without you running a real cluster for each.
- Cluster per environment or domain
- Clusters split along an environment, jurisdiction or audit boundary, with tenants inside each. The common landing point for regulated estates.
- Cluster per tenant
- One cluster per team. Hard isolation, and a fleet to operate. Justified only where a gate genuinely demands it.
- Pooled
- One shared deployment; tenant isolation lives in your application and data model. The right answer for most high-volume products.
- Hybrid — pooled by default, siloed by exception
- Pooled for the long tail, siloed compute for enterprise or regulated customers. The most common real answer at scale.
- Siloed — namespace per customer
- A namespace per customer, giving per-customer cost attribution, blast-radius containment and a per-customer compliance boundary.
- Per jurisdiction or region
- Separate clusters per data-residency boundary, with customers pooled or siloed inside each. Driven by law, not by architecture taste.
- Cluster per customer
- A dedicated cluster per customer, normally because a contract says so. At this point you are running a cluster fleet — see the provider path.
Answer for the estate you have
Answer for the boundary you operate, not the one your cloud provider operates, and for today's estate rather than the one on the roadmap. The full rubric — every question, weight and hard constraint — is published below the result.
Every option, compared
Provider and platform topologies side by side. "Cluster-scoped API" is the column that settles most arguments: it is a capability limit, not a security preference, and no policy tooling works around it.
| Topology | Isolation | Cost | Ops load | Cluster-scoped API | Own version | Tenant ceiling | Blast radius |
|---|---|---|---|---|---|---|---|
| Class A Virtual clusters | Moderate | Lowest | Low | Yes | Yes | Very high | Shared nodes |
| Class A Hosted control planes | High | Moderate | Moderate | Yes | Yes | High | Per-tenant nodes |
| Class A Full cluster per tenant | Highest | Highest | Highest | Yes | Yes | Low | Fully separate |
| Class B Namespace per tenant | Soft | Lowest | Lowest | No | No | Very high | Shared everything |
| Class B Hardened namespace tenancy | Soft, hardened | Low | Moderate | No | No | High | Separate nodes |
| Class B Virtual cluster per team | Moderate | Moderate | Moderate | Yes | Yes | High | Shared nodes |
| Class B Cluster per environment or domain | High | High | High | Yes | Per cluster | Moderate | Per segment |
| Class B Cluster per tenant | Highest | Highest | Highest | Yes | Yes | Low | Fully separate |
Every constraint we apply, published
Each of these sets a minimum: the lightest topology it still allows. Nothing else — not cost pressure, not team size — can pull the recommendation below it, because these are capability limits rather than preferences. Where several apply, the strictest wins. You can check our work.
- Each tenant needs dedicated nodes
- Minimum · Hosted control planes
- Virtual clusters share the host cluster’s nodes and scheduler. Dedicated nodes per tenant require a real node pool joined to a control plane the tenant owns.
- The tenant picks their version and upgrade window
- Minimum · Hosted control planes
- Tenant-chosen versions and upgrade windows require a control plane whose lifecycle is independent of the host.
- External organisations, mutually untrusted
- Minimum · Hosted control planes
- Mutually untrusted external organisations sharing host nodes puts a kernel boundary between tenants, not an API boundary.
- Yes — dedicated infrastructure is contractual
- Minimum · Full cluster per tenant
- A contractual requirement for dedicated infrastructure cannot be satisfied by a shared management plane, whatever the economics.
- Tenants install their own CRDs and operators
- Minimum · Virtual cluster per team
- CustomResourceDefinitions are cluster-scoped. A namespace cannot contain one, so tenants installing their own operators need their own API server.
- Tenants need admission webhooks or API server access
- Minimum · Virtual cluster per team
- Admission webhooks and API server access are cluster-scoped concerns. No namespace-based operator can grant them safely.
- They need their own upgrade window
- Minimum · Virtual cluster per team
- Independent upgrade windows require an API server whose lifecycle the tenant controls.
- They need different Kubernetes versions
- Minimum · Virtual cluster per team
- Namespaces inherit the cluster’s Kubernetes version. Different versions per tenant require separate API servers.
- Untrusted or user-submitted code
- Minimum · Hardened namespace tenancy
- Untrusted code on a shared kernel is a container-escape away from every other tenant. Node pools and a sandboxed runtime are the minimum.
- Tenants must be assumed hostile to each other
- Minimum · Hardened namespace tenancy
- Mutually hostile tenants need a boundary stronger than RBAC and NetworkPolicy alone.
- Separate CNI or physical segmentation
- Minimum · Cluster per environment or domain
- A CNI is a cluster-wide choice. Separate CNIs or physical segmentation means separate clusters.
- A separate audit boundary is required
- Minimum · Cluster per environment or domain
- A separate audit boundary means separate control-plane audit logs, which is a cluster boundary, not a namespace one.
- Physically separate infrastructure is required
- Minimum · Cluster per tenant
- Physically separate infrastructure per tenant is a cluster per tenant by definition.
- Yes — individual customers dictate jurisdiction
- Minimum · Per jurisdiction or region
- Where a customer’s data may legally live is decided by law, not architecture. That means a deployment boundary per jurisdiction.
- Only the enterprise tier
- Minimum · Hybrid — pooled by default, siloed by exception
- A dedicated-infrastructure commitment for one tier means two shapes of deployment, not one.
- Yes — effectively all of them
- Minimum · Cluster per customer
- If every customer is owed dedicated infrastructure, the unit of deployment is a cluster per customer.
- Yes — per customer
- Minimum · Siloed — namespace per customer
- An auditor tracing one customer’s systems needs a boundary they can point at. Shared compute with row-level separation rarely survives that conversation.
- Yes — customers supply executable logic
- Minimum · Siloed — namespace per customer
- Customer-supplied code needs a compute boundary, not just a data boundary.
The arguments behind the advisor
What are the three classes of Kubernetes multi-tenancy?
Multi-tenancy on Kubernetes is three different problems that share a name, separated by what the tenant actually receives:
- Provider — the tenant receives a cluster. Your unit of tenancy is a cluster, and the tooling is Kamaji, HyperShift, Gardener, Cluster API or Rancher.
- Platform — the tenant receives a namespace in a cluster you run. Your unit is a team. Namespace tenancy is Stakater MTO, Capsule or Hierarchical Namespace Controller; where tenants need their own API server, virtual clusters (vCluster) are the step up.
- Product — the tenant receives an account in your product and never touches Kubernetes. Your unit is a customer, and tenancy usually belongs in your application rather than in the cluster.
Getting this wrong makes every downstream tool comparison incoherent: it is how Kamaji and a namespace operator end up on the same shortlist when they serve opposite sides of the same handoff.
Is a namespace enough for multi-tenancy?
For trusted internal teams running first-party code, yes — provided RBAC, resource quotas, NetworkPolicy and admission policy are enforced together and continuously, not just applied at onboarding. A namespace on its own is only a label. It stops being enough the moment any of these is true:
- tenants need to install their own CustomResourceDefinitions, operators or admission webhooks — these are cluster-scoped and cannot live in a namespace
- tenants need different Kubernetes versions or their own upgrade windows
- untrusted or user-submitted code runs in tenant workloads, putting a shared kernel between tenants
- a regulation or contract requires a separate audit boundary or physically separate infrastructure
The first two are capability limits, not security preferences — no amount of policy tooling works around them.
When should I use virtual clusters instead of namespaces?
Use virtual clusters when tenants need cluster-scoped API access that a namespace physically cannot provide: their own CRDs, their own admission webhooks, or their own Kubernetes version. A virtual cluster gives each tenant their own control plane while their workloads run on shared host nodes; vCluster (LoftLabs) is the implementation.
That last detail is also its limit: because host nodes are shared, a virtual cluster does not give you a kernel boundary between tenants. If your driver is untrusted code or node-level isolation rather than API access, hardened namespaces or hosted control planes are the better fit.
What is the difference between vCluster and Kamaji?
They are frequently listed together and they are not the same category.
- vCluster (LoftLabs) runs a virtual control plane and syncs workloads down onto the host cluster’s shared nodes.
- Kamaji (Clastix) runs each tenant’s control plane as pods in a management cluster, but the worker nodes are dedicated to that tenant and join the tenant’s own control plane.
So Kamaji — like HyperShift and Gardener — is a hosted control plane: closer to a dedicated cluster with cheaper economics than to a virtual cluster. It is the usual answer when you need per-tenant isolation but cannot afford a full cluster per tenant. Both share a consequence people miss: the management cluster those control planes run in is itself a multi-tenant cluster, and needs its own tenancy model.
How many clusters should we run?
As few as your hard constraints allow. Clusters are not free: each one is a control plane to patch, upgrade, monitor and audit, and the cost is paid per cluster, forever. A cluster is justified when a binding constraint demands it — a separate audit boundary, physically separate infrastructure, a separate CNI, or tenant-controlled Kubernetes versions — and not when it is merely convenient.
The common failure is arriving at a large cluster fleet without ever deciding to. If hard isolation requirements and a small platform team have left you operating dozens of clusters, you have become a cluster provider without a provider’s tooling, and hosted control planes are usually the way out.
Does SaaS multi-tenancy need Kubernetes multi-tenancy?
Often not. If your customers never touch Kubernetes, tenancy is a property of your application and data model — row-level scoping, per-tenant encryption, request-scoped authorisation — and no Kubernetes operator can put it there. Kubernetes-level tenancy becomes the right tool when you start siloing compute per customer, which is usually driven by:
- a per-customer compliance boundary an auditor can point at
- data-residency obligations that differ between customers
- customer-supplied code that needs a compute boundary, not just a data boundary
- infrastructure margin per customer becoming a real commercial question
At high customer counts a hybrid shape is usually the honest answer: pool the long tail, silo the customers whose obligations genuinely demand it.
Where does Stakater Multi-Tenant Operator fit?
MTO installs into each cluster and manages tenant lifecycle inside it — tenancy, golden templates, quotas, policy enforcement at admission, and per-tenant cost. It does not choose your isolation topology, and it is not a multi-cluster control plane.
So it applies on the platform path, on siloed-product paths, and — less obviously — underneath a provider running hosted control planes or virtual clusters, because those tenant control planes are workloads in a management cluster that is itself multi-tenant. It applies least on a cluster-per-tenant topology, where the cluster is already the tenant boundary. Building the provider product itself is a different job: that is Stakater Cloud Orchestrator — which includes MTO as its tenancy layer, so a provider running SCO has the management-cluster problem covered as part of the same product.
Is vCluster a product or a type of architecture?
Both, and conflating them causes confusion. "Virtual cluster" is the topology — a virtual control plane per tenant, with workloads synced onto shared host nodes. vCluster is the product that implements it, built by LoftLabs, with an open-source core and a commercial platform tier.
Worth knowing before you commit: it is effectively the only production-grade implementation of that topology. The Kubernetes SIG Multi-Tenancy VirtualCluster prototype is inactive, and kcp addresses a different problem — logical workspaces rather than conformant per-tenant clusters. Choosing virtual clusters therefore means accepting a single-vendor dependency for a load-bearing part of your platform, which belongs in the decision record rather than being discovered later.
Turn the recommendation into a platform.
A tenancy design workshop: we pressure-test the model against your estate, then implement it — whichever topology the answers pointed to.