Cluster Multi-Tenancy
also called Soft Multi-Tenancy, Namespace Tenancy
Multiple teams or workloads sharing one cluster, isolated by namespaces, quotas and policy rather than by separate infrastructure.
The decision is the classic isolation-versus-efficiency trade, and the honest framing is that a shared cluster provides cost and operational efficiency while separate clusters provide isolation you can explain to an auditor.
Namespace isolation is real but partial, and knowing its limits is the mark of someone who has operated it. The node kernel is shared, so a container escape crosses tenants. The control plane is shared, so one tenant's runaway controller degrades everyone. Cluster-scoped resources — custom resource definitions, admission webhooks, node-level agents — are genuinely global and cannot be namespaced. And noisy-neighbour effects on network and storage persist even with CPU and memory quotas set.
The controls that make shared clusters defensible: resource quotas and limit ranges per namespace, network policies denying cross-namespace traffic by default, pod security standards, separate node pools for workloads with different trust levels, and per-tenant cost attribution.
The line most organisations settle on: shared clusters within a trust and compliance boundary, separate clusters across them — so production and non-production, and regulated and unregulated workloads, do not share a kernel.