alphaspirit - Fotolia
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.
Dig Deeper on Managing Virtual Containers
Related Q&A from Chris Tozzi
Red Hat OpenShift and Kubernetes share a lot of similarities -- including the same underlying container orchestration technology. So how are they ... Continue Reading
How can you approach container orchestration on AWS? Learn the basics about ECS, EKS, DIY Kubernetes and Fargate before you choose an application ... Continue Reading
AIOps tools can reduce overhead for IT staff, but first, enterprises must decide how they will use the tool to know which features to budget for. Continue Reading