This message was deleted.

IMO teams should never operate their own clusters. The platform team should be in charge of all central ops and infra related configs. Dev teams can take over more or less (depending on their level of expertise) application centric configs and workflows.

Agree with Luka though the challenge with K8s is that teams that are working on a new service may need to change shared services in order to test their new service. This can be dangerous but is sometimes necessary. There are patterns for fixing this and I think products like Loft.sh and I assume Humanitec also probably is meant to help. Part of the challenge is that a K8s/microservice-native platform is going to have to look different than a platform for a monolith product.

i think the first question is "why am i using kubernetes"

I'm generally strongly leaning toward multi-tenancy because it is cheaper and much easier to manage larger central clusters than 100s of cluster all over the org. However, sometimes folks need more than just a few namespaces and in that case, you could use virtual clusters if needed, which run inside a namespace but give the user technically full admin access to the virtual cluster while not elevating any privileges in the underlying, "real" cluster. Just gave a talk about this at KubeCon. Let me know if you have any questions 🙂

I think one good question to ask is "why do they want to create and operate their own clusters"? Based on that, you can define a strategy going forward. I've seen that scenario when the platform team is centralizing services and the platform in a specific provider or cluster version and specific teams want their clusters on a different provider or version, because they want to have access to specific services I think more than just using namespaces for multi tenancy, the platform team should have a flexible enough platform that can be used to deliver the services and providers needed while keeping controls using things such as namespaces, specific policies and more The one thing I've seen teams be successful as platform teams is to offer enough flexibility while keeping control using the right (and scalable) policy modes

i agree with Lukas bigger cluster are easier to handle than lots of small. Why you dont use different namespaces instead for the teams?