What is a DaemonSet, and what's a common use case?

What makes a DaemonSet different from a Deployment

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

Notice there's no replicas field — a DaemonSet doesn't have a fixed count you specify; instead, it runs exactly one Pod per eligible node, automatically. Add a new node to the cluster, and the DaemonSet controller schedules a Pod onto it immediately, with no manual action needed; remove a node (or drain and delete it), and its DaemonSet Pod goes with it. This is fundamentally different from a Deployment, whose replica count is a fixed number that has no inherent relationship to the number of nodes in the cluster.

Common use cases

• Log collection agents (Fluentd, Filebeat, Fluent Bit) — need to run on every node to read and forward container logs written to that node's local disk.
• Monitoring/metrics agents (Prometheus Node Exporter, Datadog Agent) — need node-level visibility (CPU, memory, disk) that can only be gathered by something running directly on each machine.
• CNI network plugins (Calico, Cilium, Flannel) — network configuration that must be set up identically on every node for pod-to-pod networking to work cluster-wide (see the networking topic).
• Storage daemons (Ceph, GlusterFS node agents) — some distributed storage systems need an agent on every node that might mount their volumes.

Restricting a DaemonSet to a subset of nodes

spec:
  template:
    spec:
      nodeSelector:
        disktype: ssd     # only run on nodes labeled disktype=ssd

Despite the name suggesting "every node," a DaemonSet can be scoped with a nodeSelector or node affinity rules (see the scheduling topic) to only run on a labeled subset — useful for something like a specialized storage agent that only needs to run on nodes actually equipped with the relevant hardware/disk type.

Interaction with taints and tolerations

By default, most Pods won't be scheduled onto a control-plane/master node (which is typically tainted to repel ordinary workloads — see the scheduling topic). DaemonSets commonly include a toleration for these taints specifically because infrastructure agents like log collectors and monitoring tools usually do need to run even on control-plane nodes, unlike ordinary application workloads.

spec:
  template:
    spec:
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          effect: NoSchedule

Rolling updates for DaemonSets

DaemonSets support a rolling update strategy conceptually similar to Deployments (RollingUpdate or OnDelete), updating one node's Pod at a time rather than all at once — important for infrastructure-critical DaemonSets (like a CNI plugin) where updating every node's networking agent simultaneously could cause a cluster-wide networking outage.