A three-replica Deployment says nothing about their distribution: all three can land on the same node, or on three different nodes, depending on what the scheduler decides (covered in the article on spread constraints). A DaemonSet answers a structurally different need: guaranteeing exactly one pod on every eligible node, no exceptions, no replica count to manage.

No replicas field, node count decides

A DaemonSet has no replicas field: its pod count is entirely dictated by how many nodes match its criteria.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      containers:
        - name: collector
          image: log-collector:1.4

Adding a node to the cluster automatically creates a new DaemonSet pod on it, with no manual step; removing a node removes its pod along with it. That property is what makes a DaemonSet fit infrastructure agents (log collection, monitoring, CNI, storage drivers): their coverage needs to follow the cluster’s real size, not a number set once and never revisited.

What this site already runs as DaemonSet, without naming it

Two components already covered on this site run as DaemonSets without the corresponding article ever making it explicit. MetalLB’s speaker component in Layer 2 mode has to run on every node capable of responding to ARP requests for an assigned IP: a DaemonSet guarantees that coverage automatically. Longhorn’s engine-image component, managing each node’s local storage, follows the same model, for an identical reason: a service that must exist on every node, no exceptions, is exactly what a DaemonSet guarantees.

Targeting a subset of nodes, not all of them

A DaemonSet doesn’t necessarily run across the whole cluster: a nodeSelector or node affinity restricts it to a precise subset.

spec:
  template:
    spec:
      nodeSelector:
        workload-type: gpu

That DaemonSet then only runs on nodes carrying the workload-type: gpu label, useful for a GPU monitoring agent with no reason to exist on a GPU-less node. Combined with a matching toleration, a DaemonSet can also target nodes normally repelled by a taint, exactly the case of an agent that needs to monitor a dedicated node despite the repulsion set for every other workload.

Updates respect order, not full parallelism

A DaemonSet update (new image, new config) follows the RollingUpdate strategy by default, one node at a time, never all at once: maxUnavailable controls how many nodes can be temporarily without the agent during the transition. For a logging or monitoring agent, a brief absence during the update is usually acceptable; for a critical network component, maxUnavailable: 1 stays the safer choice despite a slower rollout on a large cluster.

Takeaway

A DaemonSet guarantees per-node coverage rather than a fixed replica count, with no replicas field to manage and automatic adaptation to every cluster size change. It’s the model behind most infrastructure agents, including two components already covered on this site (MetalLB, Longhorn) without the underlying mechanism ever being named. nodeSelector and tolerations allow targeting a precise node subset, useful the moment a Kubernetes migration introduces specialized-purpose nodes.