What is a DaemonSet and when do you pick one over a Deployment?

Think of a DaemonSet like the janitorial staff in an office building. You don't want 3 janitors all cleaning the same floor — you want exactly one janitor per floor, and whenever a new floor is added to the building, a janitor is automatically assigned to it. If a janitor leaves, a replacement is immediately placed on that specific floor. The key difference from a regular team (Deployment) is that the distribution is per-floor, not a pool of workers that get assigned randomly.

A DaemonSet guarantees that a copy of a specific Pod runs on every node (or every node matching a nodeSelector). When a new node joins the cluster, the DaemonSet controller automatically schedules a Pod on it. When a node is removed, the Pod on that node is garbage collected. You never have to manually think about placement — the DaemonSet handles it.

The most common DaemonSet use cases are all infrastructure-level concerns: log collection agents (Fluentd or Fluent Bit that reads /var/log from every node and ships to Elasticsearch), monitoring agents (Prometheus node-exporter that exposes node-level CPU, memory, and disk metrics), network plugins (Calico or Cilium that set up the Pod network on each node), and storage drivers (CSI node plugins that enable Pods on each node to mount cloud volumes). These are all cases where you need exactly one agent per node — not more, not fewer.

The DaemonSet controller bypasses the normal scheduler by default. While a Deployment creates Pods and the scheduler decides which node they land on, DaemonSet Pods are pre-assigned to specific nodes by the DaemonSet controller setting the nodeName field. This means they run even on nodes that are tainted or unschedulable (like control plane nodes) if you add the right tolerations. This is intentional — you usually want your monitoring agent running on control plane nodes too.

A common question is 'why not just use a Deployment with replicas equal to the node count?' Three reasons: first, a DaemonSet automatically adapts when nodes are added or removed — a Deployment with a fixed replica count would need manual adjustment. Second, a DaemonSet guarantees one Pod per node — a Deployment might schedule two Pods on the same node and zero on another. Third, DaemonSets support rolling updates with maxUnavailable per node, so you can update the log collector on every node without losing log coverage anywhere.