Daemonsets

Right, so you’ve got a DaemonSet. It’s happily deploying its pod on every single node in your cluster. That’s its job. But what if you don’t want it on every node? What if your brilliant log-collector pod needs a specific filesystem mount that only exists on your workhorse compute nodes, or your gpu-model-inferencer has absolutely no business running on the cheap little spot instances handling your web traffic? This is where we stop the DaemonSet’s tyrannical reign of “one for all” and introduce some democracy. We use the bouncers of the Kubernetes club: nodeSelectors, Taints and Tolerations, and if we’re feeling fancy, nodeAffinity. Let’s break it down.

Right, so you’ve got your DaemonSet deployed. It’s happily running its little pod on every node, doing whatever thankless infrastructure task you assigned it. But now you need to change its spec. Maybe you’re updating the container image to patch a vulnerability, or perhaps you’re adding a new volume mount. This is where the updateStrategy rears its head, and you need to understand it because, trust me, the default behavior will bite you when you least expect it.

Right, so you’ve got your DaemonSet humming along, deploying its pod to every node in your cluster. It’s a beautiful thing. But then you run into the real world, and the real world has problems. Some of your nodes are, shall we say, special. Maybe they’re GPU-equipped beasts that cost more than your car, reserved for machine learning workloads. Maybe they’re edge nodes with spotty connections, or they’re just old and cranky and you don’t trust anything but a specific monitoring agent to run on them.

Right, so you’ve got your DaemonSet humming along, deploying its little pod on every node. That’s great, until you realize you don’t actually want it on every node. Maybe you’ve got a special node reserved for massive batch jobs and your logging sidecar would just get in the way. Or perhaps you only want your fancy GPU monitoring agent on the nodes that actually have, you know, GPUs. This is where we stop the blunt-force “deploy everywhere” approach and start getting surgical. The two primary tools for this are nodeSelector and nodeAffinity. One is a simple, no-nonsense hammer; the other is a finely-tuned scalpel. You need to know how to wield both.

Alright, let’s talk about why you’d actually use a DaemonSet. You don’t just deploy them for fun; they solve a very specific, infrastructure-level problem: when you need a piece of software running on every single node in your cluster, come hell or high water. It’s the Kubernetes way of saying, “I don’t care what’s scheduled here, this pod is non-negotiable.” Think of them as the mandatory background services of your operating system, but for your cluster.