Welcome to the NZRT Wiki Podcast. Today we’re looking at Nodes.

So, what is a node? In a Kubernetes cluster, a node is essentially a worker machine. Think of the cluster as a factory, and nodes are the individual workstations where the actual work gets done. Every node runs three key pieces of software to make that happen.

The first is the kubelet. This is an agent that sits on the node and keeps in constant communication with the Kubernetes API server. Its main job is managing the lifecycle of pods — making sure the right containers are running, healthy, and doing what they’re supposed to be doing.

The second component is kube-proxy. This one handles networking. It maintains the rules that allow network traffic to flow correctly to your services — so when something inside the cluster needs to talk to something else, kube-proxy makes sure that traffic lands in the right place.

The third component is the container runtime. For most setups you’ll see at NZRT, that’s containerd. This is what actually pulls and runs your containers at the low level.

Now, how do you check on your nodes? There are a few commands worth knowing. The first lets you list all nodes in your cluster — you get a quick overview of their names and current status. If you want more detail, you can run a wider version of that command, which also shows you IP addresses and operating system information. And if you really need to dig into a specific node — say you’re troubleshooting or checking recent events — you can describe that node by name and get a full breakdown of everything happening on it.

When you look at node status, you’ll see what are called conditions. There are five to be aware of. Ready is the one you want to see — it means the node is healthy and able to accept new pods. If you see MemoryPressure, the node is running low on memory. DiskPressure means disk space is getting tight. PIDPressure tells you there are too many processes running on that node. And NetworkUnavailable means the network isn’t configured correctly on that node. Any condition other than Ready being active is worth investigating.

The last area covered in this doc is labels and taints — two ways you can control how pods get scheduled onto nodes.

Labels are straightforward. You can tag a node with a key-value pair — for example, marking a node as belonging to a production environment. Once a node has a label, you can use that label in your pod configurations to tell Kubernetes where you want things to run.

Taints are a bit more powerful. When you taint a node, you’re essentially putting up a sign that says “pods can’t schedule here unless they explicitly say they’re okay with this.” You set a taint with a key, a value, and an effect. The effect used in this example is NoSchedule, which means Kubernetes will not place any new pods onto that node unless those pods have a matching toleration defined. This is useful for reserving nodes for specific workloads — for example, keeping a node dedicated to production traffic.

And when you’re done with a taint and want to remove it, you run the same command but add a minus sign at the end to strip it off.

So to recap — nodes are your worker machines, made up of the kubelet, kube-proxy, and a container runtime. You can inspect them with a handful of commands, watch their conditions to catch health issues early, and use labels and taints to control exactly what runs where.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.