DaemonSets

One pod per node, automatically

Every controller you've met so far manages a count: a Deployment keeps N replicas running somewhere on the cluster, wherever the scheduler puts them. A DaemonSet manages coverage instead: exactly one matching pod on every node that qualifies, full stop — no replica count to set, no scheduler decision about placement. Add a fourth node to the cluster, and the DaemonSet controller places a pod on it within moments, with zero action from you.

DaemonSet: coverage, not count

+ Join a new node to the cluster

Node 1

daemon pod

Node 2

daemon pod

Node 3

daemon pod

You've actually been looking at DaemonSets since Module 1 without naming them: kube-proxy and kindnet/calico-node in kube-system are DaemonSets. Run kubectl get daemonsets -n kube-system right now and you'll see them — one pod per node, which is exactly why every node has its own kube-proxy and CNI agent instead of a shared pool of them somewhere.

Why coverage, not count

A DaemonSet is the right tool whenever something needs to exist on every node rather than somewhere in the cluster — a log collector reading each node's local log files, a node-level metrics exporter, a storage or networking agent. A Deployment with replicas: 3 on a 3-node cluster might coincidentally land one pod per node today, but nothing guarantees that stays true after a reschedule — and it breaks immediately the moment you add a fourth node. A DaemonSet's guarantee doesn't depend on luck.

Controlling coverage with node selectors and tolerations

By default a DaemonSet targets every node, but you can narrow that with a nodeSelector (only nodes with matching labels) — and you may need tolerations to land on nodes with taints (taints are covered properly in Module 10, but the short version: a taint on a node repels pods unless the pod explicitly tolerates it — the control-plane node in your cluster carries one by default, which is why ordinary workloads don't land there). Get a nodeSelector or toleration wrong and a DaemonSet silently covers fewer nodes than you think — no error, just quietly incomplete coverage, the same "no error, just nothing happening" failure shape you saw with Service selector mismatches in Module 4.

The infrastructure analogy

A DaemonSet is the Kubernetes-native version of a host-level agent you'd push via a configuration management tool to every box in a fleet — a monitoring agent, a security scanner, a log shipper — except enforcement is continuous: a node joins, it gets the agent; no cron-style sweep required.

In the lab, you'll deploy one and prove coverage by comparing pod count to node count directly, then diagnose a DaemonSet that's silently missing a node.