DaemonSets

A DaemonSet runs exactly one copy of a Pod on every node (or every node matching a selector). It is the controller for node-level agents — log collectors, monitoring exporters, the CNI network plugin, storage daemons — anything that must be present on each machine.

Where a Deployment thinks in terms of "how many replicas," a DaemonSet thinks in terms of "which nodes." As nodes join and leave the cluster, the DaemonSet adds and removes Pods to keep its one-per-node guarantee.

The Per-Node Guarantee

A DaemonSet's controller watches the set of nodes and ensures its Pod runs on each eligible one. Add a node and a Pod appears on it automatically; drain a node and its DaemonSet Pod goes too. You never set a replica count — the count is "however many nodes there are." This is exactly the model node-level infrastructure needs.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      tolerations:
        - operator: Exists          # run on tainted nodes too
      containers:
        - name: agent
          image: log-agent:1.0

Selecting Which Nodes

By default a DaemonSet targets all nodes, but you can scope it with a nodeSelector or node affinity — for example, a GPU monitoring agent only on GPU nodes. Crucially, control-plane and specialized nodes often carry taints that repel ordinary Pods; a DaemonSet that must run there needs matching tolerations. Missing tolerations is the usual reason an agent silently skips some nodes.

Update Strategy

DaemonSets support two update strategies. RollingUpdate (the default) replaces Pods node by node, bounded by maxUnavailable, so the agent is briefly absent on a few nodes at a time. OnDelete updates a node's Pod only when you delete it manually — useful for agents where you want tight control over when each node is touched.

When to Use One

Reach for a DaemonSet whenever the workload is about the node, not the application: log and metrics agents, security and compliance daemons, the CNI plugin, and node-local storage providers. If you find yourself writing a Deployment with node anti-affinity to spread one Pod per node, that is a DaemonSet trying to be born. Conversely, do not use a DaemonSet for application replicas — that is a Deployment's job.