Top Container Orchestration Platforms: Kubernetes vs. Docker Swarm

When creating a cluster, one of the first questions that comes up is what type of worker nodes to use and how many of them. The total compute capacity of a cluster is the sum of all the constituent node’s capacities. There are multiple ways to achieve the desired target capacity of a cluster. For example, if you need a cluster with a total capacity of 8 CPU cores and 32 GB of RAM, you could design your cluster using 4 smaller nodes or 2 larger nodes.

There are pros and cons to both approaches. Few large nodes can result in less management overhead, as it is easier to manage a small number of machines than a large number. However, this applies primarily to bare metal servers and not to cloud instances. If you use cloud instances, you outsource the management of the underlying machines to the cloud provider.

On the other hand, many small nodes can provide higher availability. If you have a cluster with two large worker nodes and you lose one, you lose half the cluster capacity. Having multiple worker nodes reduces this risk. For example, if you have a ten-node cluster and you lose one, you lose just 10% of your cluster capacity.

There are other factors to consider as well, such as ease of scheduling containers and node auto-scaling. With a large number of resources allocated to a node, it becomes easier for Kubernetes to schedule containers on a cluster with fewer large worker nodes in comparison to smaller nodes. However, with more nodes in the picture, there is more management overhead in terms of taking care of servers, patching and updating them, and maintaining them.

Ultimately, the choice between few large nodes or many small nodes depends on your specific needs and requirements. It’s important to carefully consider all the factors when designing your Kubernetes cluster.