Architecting Kubernetes clusters — choosing a cluster size
This article discusses the pros and cons of having either many small clusters or few large clusters for running a given set of apps.
The related topic of choosing either many small or few large worker nodes for achieving a given cluster capacity is discussed in the article “Architecting Kubernetes clusters — choosing a worker node size”.
Contents
As a quick reference, here are the discussed pros (👍) and cons (👎) for the two cluster strategies.
Few large clusters:
- 👍 Ease of management
- 👍 Cost-efficient
- 👍 Optimal resource utilisation
- 👎 Single point of failure
- 👎 Lack of isolation
- 👎 Management of non-namespaced resources
- 👎 Cluster size is limited
Many small clusters:
- 👍 Strong isolation
- 👍 Reduced blast radius
- 👍 Granular access control
- 👍 Clusters can be customised
- 👎 Costly
- 👎 Inefficient resource usage
- 👎 Operational overhead
Introduction
If you want to run a given set of apps on Kubernetes, you are confronted with some fundamental questions about how you use Kubernetes clusters:
- Should I run all apps in the same cluster, or have multiple clusters?
- How large should each cluster be?
- Which apps should I run in each cluster?
In general, there are two basic directions into which you can go: large clusters (but fewer of them) in which you run a relatively large number of apps, or small clusters (but more of them) with just a few apps running in each one.
Both are valid approaches and this article discusses the strengths and weaknesses of each one. This should help you make up your mind for deciding which strategy works best for your use case.
Required capacity
To run a given set of applications you need a certain amount of compute resources, such as CPU cores and memory. We will call this required amount of resources the required capacity.
