> K8S done right is literally designed for multi tenancy No it is not. Not in the way they are using it. There are two main use-cases. One is multiple teams,

> K8S done right is literally designed for multi tenancy No it is not. Not in the way they are using it. There are two main use-cases. One is multiple teams, in which case they are bound by their company's policies and guardrails The second is multiple customers. But that also assumes they have no direct access to the cluster. A vendor would, instead, deploy multiple instances of a workload; the customers would not. Straight from the horse's mouth: https://kubernetes.io/docs/concepts/security/multi-tenancy/ https://kubernetes.io/docs/concepts/security/multi-tenancy/ There's also nothing that says that multiple clusters need to be expensive, if they are sized right. They can be as small as you need both in number of instances and instance size. The overhead here is the control plane but, for small clusters, the resource requirements are similarly small. That said, if hard multi tenancy is what you need, then you need to use things like this: https://github.com/kubernetes-sigs/cluster-api-provider-nested/tree/main/virtualcluster https://github.com/kubernetes-sigs/cluster-api-provider-nest... (for the control plane - you still need to worry about the data plane)