Multi-tenant Kubernetes[1] is a strcpy-level footgun IMO. It's perfectly fine as long as everyone involved does everything correctly and never makes a mistake.

Multi-tenant Kubernetes[1] is a strcpy-level footgun IMO. It's perfectly fine as long as everyone involved does everything correctly and never makes a mistake. Kubernetes itself is very complex. The "who needs a UI when you have configuration files and an API?" approach makes it even more opaque to the people who often end up responsible for it. The landscape changes very rapidly.[2] I'd trust Kelsey Hightower to set up a secure multi-tenant deployment, but probably not anyone else. Is it not practical to deploy clusters on top of virtualization? That should make efficient use of hardware while still giving each tenant their own cluster, therefore providing stronger isolation than the typical Kubernetes configuration tends to. [1] I am specifically referring to a Kubernetes deployment where different customers are running custom code on the same underlying hosts. Using Kubernetes to host a service that is multi-tenant at a higher level is not something I would recommend, but it's not as immediately dangerous as a model where customers run container-level custom code. [2] This is not surprising for a relatively new technology, especially one that's as paradigm-shifting as Kubernetes was. But most people are not going to rearchitect and redeploy everything every six months just because the Kubernetes developers decided to replace a pod security or network security model with a non-backward-compatible alternative again.