Kubernetes multi-tenancy: namespaces, virtual control planes or dedicated clusters?

Two kinds of tenancy

The Kubernetes documentation distinguishes two broad use cases¹:

• Multiple teams in one organisation share a cluster. There is some trust between them, members often have direct access through tools or GitOps, and workloads frequently talk to each other.
• Multiple customers, where a vendor runs workload instances per customer. Customers never touch the cluster, cost matters a great deal, and isolation must be strong.

The documentation also cautions that "hard" and "soft" multi-tenancy are better seen as a spectrum than two categories. Hard multi-tenancy usually describes tenants that don't trust each other, which demands particular attention to data-plane isolation¹.

The building blocks

Control plane isolation stops tenants seeing or changing each other's API resources. Namespaces scope names and many policies; RBAC enforces least privilege, which the docs call the most important type of control-plane isolation, because a tenant who can modify another's resources can disable every other protection¹². Resource quotas cap what each namespace can consume⁵.

Data plane isolation protects workloads at runtime: network policies to restrict traffic³, storage isolation, sandboxed containers using virtual machines or userspace kernels for untrusted code, and node isolation that dedicates nodes to a tenant¹.

Fairness matters too. API Priority and Fairness prevents one tenant's controllers from overwhelming the API server⁴.

The three models compared

This follows the documentation's own description: namespace isolation is well supported with negligible resource cost but can be difficult to configure and doesn't cover non-namespaced resources, while control plane virtualisation isolates those at the cost of somewhat higher resource use¹.

How I decide

1. Who writes code that runs? If tenants can run arbitrary code, assume it may be hostile, and favour sandboxing, dedicated nodes or clusters.
2. Do tenants need cluster-level resources? Teams that ship their own operators and CRDs push towards virtual control planes.
3. What do regulators and contracts require? Data residency and customer contracts may require dedicated infrastructure in a region, as in UAE health data localisation.
4. What can the platform team operate? Fifty clusters run badly are riskier than five run well.
5. Mix models. Shared clusters for most tenants, dedicated ones for the few that need them, mirroring the hybrid pattern in multi-tenant SaaS on MongoDB.

Practical rules for shared clusters

• A namespace per workload, with names unique across the whole fleet, which the docs recommend so you can move between shared and dedicated clusters later¹.
• Default-deny networking, with explicit allows.
• Quotas and limit ranges on every tenant namespace.
• Guardrails as policy, such as the CEL policies in Kubernetes admission policies, so tenants can't weaken their own isolation.
• Cost allocation by tenant, using labels and the approaches in Kubernetes FinOps.
• Separate GPU pools where AI workloads from different tenants compete, with the scheduling controls in gang scheduling.

How I can help

I design Kubernetes platforms for internal teams and SaaS products, choosing the tenancy model that fits the trust, cost and compliance picture. As a fractional CTO I can own the platform roadmap. Or analyse your challenge and bring the result to a call.