alphaspirit - Fotolia
How many Kubernetes nodes should be in a cluster?
There's no one-size-fits-all answer in terms of how many nodes should make up a Kubernetes cluster. Instead, that number varies based on specific workload requirements.
Nodes are the core building blocks of a Kubernetes cluster. In general, the more nodes there are in a cluster, the greater a workload's performance and availability will be.
But it's important to balance node count with cost goals. Determine how many nodes -- and which type -- are necessary to meet performance and availability requirements, without setting up extraneous nodes that create unnecessary costs.
There are several key guidelines to decide how many Kubernetes nodes to include in a cluster.
Determine how many resources each node contributes to the cluster. The compute, memory and other resources on a given node vary widely, based on the hardware profile of the server that creates the node. In this sense, total node count is less important than total cluster resources for proper pod performance. A Kubernetes cluster with many lightweight nodes could have fewer total resources than one with a handful of high-powered nodes.
Editor's note: In Kubernetes, containers are grouped into pods, the smallest deployment unit within the container orchestration system. Pods provide abstractions of hosting resources for containers. Kubernetes pods reside on nodes, which provide actual resources, such as VMs.
Aim to have about 20% more resource capacity available to the cluster than you expect workloads will require. This ensures a buffer, in case application demand peaks suddenly or some nodes fail and reduce total cluster resource availability.
Although the total number of Kubernetes nodes in a cluster doesn't correlate closely with workload performance, it does have a significant effect on workload availability. A cluster with only a handful of nodes is at risk of having so many nodes fail that there are no longer enough available to host all pods. Worse, if there's only one master node -- the node that manages other nodes, called workers -- the failure of that single node critically disrupts cluster functionality.
The total number of nodes required for a cluster varies, depending on the organization's needs. However, as a basic and general guideline, have at least a dozen worker nodes and two master nodes for any cluster where availability is a priority.
Physical vs. virtual machines
Determine whether nodes are based on dedicated physical servers, VMs or a mix of both.
Nodes based on VMs could leave the cluster at greater risk of failure. For example, if several nodes run as VMs, but all those VMs are hosted on the same physical server, the failure of the latter would make all the former unavailable and decrease the total node count significantly in one fell swoop.
In contrast, a dedicated physical server for each node reduces the likelihood that multiple nodes will fail simultaneously. But it is also more expensive, in most cases, to run all nodes as physical servers. Therefore, the best approach is often to use a mix of physical and virtual machines for Kubernetes nodes.
Kubernetes performance testing tutorial: Load test a cluster
Dig Deeper on Containers and virtualization
Related Q&A from Chris Tozzi
What are hyperautomation use cases for IT operations?
Fully automated NoOps workflows might not be possible, but there's always room to further automate existing processes. An expert explains two ... Continue Reading
Why and how to use eBPF for Kubernetes scaling
Scaling Kubernetes clusters has always been a challenge -- but eBPF makes the process smoother with service-specific monitors and a lack of special ... Continue Reading
Battle of the buzzwords: AIOps vs. MLOps square up
Another -Ops has entered the arena: MLOps. Is it just another buzzword, or does the term hold its own weight? Learn more about it and how it compares... Continue Reading