Kubernetes has made it simple to create another cluster. That simplicity is useful, but it can also hide the real enterprise question: Should every team, application or customer have its own cluster, or should the platform provide a governed way to share infrastructure?

Kubernetes multi-tenancy is the practice of allowing multiple tenants, such as teams, applications, environments, business units or customers, to consume Kubernetes infrastructure while maintaining appropriate boundaries for access, network traffic, resource usage, workload security and cost allocation. The Kubernetes project itself recognizes that there is no single definition of a tenant and that tenancy patterns vary significantly between multi-team and multi-customer environments. It also distinguishes between soft isolation, where tenants share more of the platform, and hard isolation, where the blast radius is intentionally reduced through dedicated infrastructure or stronger separation.

The practical answer is not "one cluster for everything" or "one cluster for every team." The right answer is a portfolio of tenancy models. Namespace-based tenancy, vCluster-based tenancy and dedicated cluster tenancy each solve a different problem. The goal is to align the isolation model to the trust boundary, operating model, regulatory requirements and the economics of the workload.

The important point for platform leaders is that the tenancy model is only the starting point. No model works without well-designed RBAC, network policy, resource management, admission control, workload security and chargeback or showback. Multi-tenancy is not just a Kubernetes feature. It is a platform operating model.