Kubernetes nodes – the servers that provide the core infrastructure for hosting Kubernetes clusters – tend to get the short stick when it comes to discussions of Kubernetes monitoring and performance optimization.
After all, it has often been said that one of the great benefits of Kubernetes (and cloud computing in general) is that it lets you treat your servers like cattle, not pets. The implication is that we should avoid becoming overly attached to servers or investing too much time or energy on them because in a cloud native environment, servers are a commodity that you can replace at will.
Now, we're all for avoiding node attachment syndrome. Your nodes are not your furbabies, and you should not treat them as such (and yes - we also think the cattle vs. pets analogy is a bit crude, but we'll run with it because it's a widespread idea in the realm of cloud computing). One of the benefits of Kubernetes is indeed the ability to join and remove nodes from clusters at will, and to have individual servers fail without necessarily harming workload performance.
That said, problems with nodes can and often do have a deleterious effect on Kubernetes performance. Nodes provide the crucial memory and CPU resources that power your workloads, which means that underperforming nodes can quickly translate to underperforming clusters. On top of that, nodes play a central role in shaping the security of K8s-based workloads, too.
That's why managing nodes in an optimal way is an essential step toward optimizing overall Kubernetes performance and security. This article provides guidance by taking a deep dive into Kubernetes node management. We'll cover how nodes work, what runs on your Kubernetes nodes and best practices for node management.
What are Kubernetes nodes?
In Kubernetes, nodes are the servers that you use to build a Kubernetes cluster. There are two types of nodes:
• Control plane nodes, which host the Kubernetes control plane software.
• Worker nodes, which host applications that you deploy on Kubernetes.
Nodes can be either physical or virtual machines, and they can run any Linux-based operating system. (You can also use Windows machines as worker nodes – in fact, you need to if you’re going to host Windows containers in Kubernetes – although Windows doesn't support control plane nodes.)
This flexibility is part of what makes nodes in Kubernetes so powerful. You can spin up virtually any type of server to function as a node. The server's underlying configuration doesn't really matter; all that matters is that your node can join the cluster and is capable of hosting the core node components, like Kubelet, which we'll discuss later in this article.
Why are nodes important in a Kubernetes cluster?
The importance of nodes to Kubernetes is straightforward: Your cluster can't exist without nodes, because nodes are literally the ingredients out of which your cluster is constructed. The stronger and bigger your nodes are, the more powerful your cluster will be, in terms of total CPU, memory and other resources.
Going further, it's worth noting as well that part of the power of Kubernetes derives from the fact that Kubernetes can deploy workloads across multiple nodes. That makes it possible to run applications in a distributed, scale-out environment where the failure of a single server is typically not a big deal. Without nodes, the whole concept of distributed, cloud native computing in Kubernetes wouldn't work.
For clarity's sake, we should mention that it's possible to have a Kubernetes cluster that consists of just a single node (which would function as both a control plane node and a worker node in that case). But since this setup would deprive you of the important benefits of being able to deploy workloads in a distributed environment, it's basically unheard of in production to run a single-node cluster. Single-node clusters can come in handy for testing purposes, but usually not for deploying applications in the real world.
Kubernetes node components
Each worker node in Kubernetes is responsible for running several components. Let's look at them one-by-one.
Kubelet: The node agent
Kubelet is the envoy that allows worker nodes to talk to control plane nodes. In other words, Kubelet is the software that runs locally on each node and serves as an envoy between the node and the rest of the cluster.
Kubelet is responsible for executing whichever workloads the control plane tells it to. It also tracks workload operations and reports on their status back to the control plane.
In order to run workloads – which are packaged as containers in most cases, unless you're doing something less orthodox like using KubeVirt to run VMs on top of Kubernetes – you need a container runtime. A container runtime is the software that actually executes containers.
Examples of popular container runtimes include containerd and Docker Engine (although the latter is now deprecated). The runtime you choose doesn't really matter in most cases as long as it's compatible with your containers – which it probably is, because all mainstream runtimes comply with the Container Runtime Interface (CRI) standards, which Kubernetes requires as of release 1.27.
So, while there's a lot to say about the differences between the various runtimes, we're not going to go down that rabbit hole in this article. We'll just say that you should choose a CRI-compliant runtime and move on with your life.
Kube-proxy: Network management
Kube-proxy maintains network proxy rules for your nodes. These rules allow Kubernetes to redirect traffic flowing to and from Kubernetes services that operate in the cluster.
It's possible in certain environments to use Kubernetes without kube-proxy, which can help optimize performance in some cases. But unless you're worried about eliminating every single unnecessary CPU cycle, you should just stick with kube-proxy, which is the simplest and time-tested way of managing network proxies.
Node management 101: Understanding node status and conditions
Now that you know what Kubernetes nodes do and why they matter, let's talk about how to manage them.
The first thing to know about managing nodes is that you can check their status using the kubectl describe node command: