DaemonSets: One Pod Per Node

In one line

A DaemonSet guarantees exactly one copy of a pod runs on every (or every matching) node in the cluster — the correct tool for genuinely per-node infrastructure like log collectors and monitoring agents.

0/5 · 0%

Think of it like this

A smoke detector installed in every single room of a building, rather than one central smoke detector for the whole building — some things genuinely need a presence in EVERY location, not just some centrally-managed number of copies wherever the scheduler happens to put them.

Key ideas

01
A DAEMONSET ensures that EXACTLY ONE copy of a pod runs on every node in the cluster (or every node matching a specific selector) — critically, this is a fundamentally different scaling model from a Deployment's 'N copies, wherever the scheduler decides' behavior; a DaemonSet's count is always tied directly to the number of matching nodes, not to any independently-set replica number.
02
The classic real use cases: a LOG COLLECTOR agent (reading container logs from every node and shipping them to a central system, directly connecting to Phase 7's observability topics on Linux's own course, now applied cluster-wide), a MONITORING/METRICS agent (like Prometheus's Node Exporter, gathering per-node hardware metrics), or a NETWORKING component (a CNI plugin often runs as a DaemonSet, since every node genuinely needs its own copy to handle that node's own networking).
03
When a NEW node joins the cluster, a DaemonSet automatically schedules its pod onto that new node immediately, with zero manual action required — and when a node is removed, that node's DaemonSet pod is naturally removed along with it. This automatic, always-exactly-one-per-node behavior is precisely what makes a DaemonSet the right tool for genuinely per-node infrastructure.
04
You can restrict a DaemonSet to only a SUBSET of nodes using a node selector or affinity rules (Phase 4 covers these mechanisms in depth) — for instance, a specialized monitoring agent that only needs to run on nodes with a GPU, rather than genuinely every single node in the cluster.
05
kubectl get daemonsets shows, per DaemonSet, how many nodes it's scheduled on (DESIRED) versus how many are actually running successfully (CURRENT/READY) — a mismatch here (fewer running than desired) is a genuinely useful, fast signal that something is preventing the DaemonSet's pod from starting on one or more specific nodes.

Code & diagrams

DaemonSetPerNodediagram

Unlike a Deployment, a DaemonSet's pod count is tied directly to the node count, not an independent replica number.

Rendering diagram…

daemonset.yamlmarkdown

A realistic log-shipping agent, running on every node.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      containers:
        - name: log-agent
          image: fluent/fluent-bit:latest
          volumeMounts:
            - name: varlog
              mountPath: /var/log
      volumes:
        - name: varlog
          hostPath:
            path: /var/log     # reads directly from the NODE's own log directory

daemonsets.shmarkdown

Confirm exactly one pod per node, and watch it follow the cluster automatically.

kubectl apply -f daemonset.yaml

# DESIRED and CURRENT should match the number of nodes in your cluster
kubectl get daemonset log-agent
kubectl get nodes
# compare the counts — should be identical (unless a node selector restricts it)

# See exactly which pod is on which node
kubectl get pods -l app=log-agent -o wide

# If your cluster can add a node (e.g. cloud autoscaling), the new node
# gets its own log-agent pod automatically — no action needed from you

Explain it without notes

Why is a DaemonSet's scaling model fundamentally different from a Deployment's, in terms of what determines the pod count?

Why is a log-collection agent a genuinely good real-world fit for a DaemonSet, rather than just a regular Deployment with a large replica count?

Practice

Create the example DaemonSet and confirm with kubectl get daemonset that DESIRED and CURRENT match your cluster's actual node count.

Use kubectl get pods -o wide to confirm there's exactly one DaemonSet pod scheduled on each node, never two on the same node or any node with none.

Trade-offs

↔
A DaemonSet's automatic per-node coverage is exactly right for genuinely per-node infrastructure, but using one for something that doesn't actually need a presence on every node wastes real resources across the whole cluster for no benefit — the correct default question is always 'does this genuinely need to run on every node, or would a normal Deployment with an independent replica count serve the same purpose more efficiently.'

Done when you can

I understand a DaemonSet's pod count is tied to node count, not an independent replica setting.
I can name genuine real-world use cases for a DaemonSet (log agents, monitoring agents, CNI plugins).
I can create a DaemonSet and confirm it's running exactly one pod per matching node.