Multi-tenancy: Best practices for shared Kubernetes clusters
Some of the key questions that platform teams have to think about very early on in their K8s journey are:
- How many clusters should I have? What is the right number for my organization?
- Should I set up dedicated or shared clusters for my application teams?
- What are the governance controls that need to be in place?
The model that customers are increasingly adopting is to standardize on shared clusters as the default and create a dedicated cluster only when certain considerations are met.
graph LR
A[Request for compute from Application teams] --> B[Evaluate against list of considerations] --> C[Dedicated or shared clusters];A few example scenarios for which Platform teams often end up setting up dedicated clusters are:
- Application has low latency requirements (target SLA/SLO is significantly different from others)
- Application has specific requirements that are unique to it (e.g. GPU worker nodes, CNI plugin)
- Based on Type of environment - ‘Prod’ has a dedicated clusters and 'Dev', 'Test' environments have shared clusters
With shared clusters (which is the most cost efficient and therefore the default model in most customer environments), there are certain challenges that platform teams have to solve for around security and operational efficiencies.
