DaemonSet, node-level work as a controller

Document contract

Role: concept

Truth boundary: portable Kubernetes behavior observed through devata

Last verified: Kubernetes documentation, 2026-07-26

Prerequisites: kubernetes

Most workload controllers ask for a replica count and let the scheduler place Pods where capacity and policy allow. A DaemonSet expresses a different intent: run one copy of this Pod on every eligible node.

That shape fits software whose responsibility is attached to the node itself:

CNI agents that program each node’s network;
log collectors that read node-local container logs;
node metrics exporters;
storage node agents;
hardware device plugins.

flowchart TB
  ds[DaemonSet spec]
  n1[Eligible node A] --> p1[Pod A]
  n2[Eligible node B] --> p2[Pod B]
  n3[Ineligible node<br/>taint or selector mismatch]
  ds --> p1
  ds --> p2
  ds -. no Pod .-> n3

“One per node” is shorthand. Node selectors, affinity, taints, tolerations, and controller behavior determine eligibility. A new matching node causes a new Pod to appear. A node that no longer matches loses its DaemonSet Pod.

Observe the controller relationship

These commands are read-only:

kubectl config current-context
kubectl -n kube-system get daemonsets
kubectl -n kube-system get pods -l k8s-app=cilium -o wide
kubectl -n kube-system describe daemonset cilium

Compare desired, current, ready, and available counts with the eligible node count. Then compare the Pod-to-node placement. describe shows selectors, update strategy, tolerations, and recent scheduling events.

In devata, Cilium runs as a DaemonSet because every node needs the local dataplane. Promtail uses the same shape to collect node-local logs. Longhorn node components also need node-local access. One healthy copy does not prove the cluster-wide responsibility is covered; the desired and ready counts must agree across eligible nodes.

Failure reasoning

If one DaemonSet Pod is missing, ask in order:

Is the node Ready and eligible?
Does the DaemonSet selector match it?
Do taints require a missing toleration?
Can the Pod mount or access its node-local dependencies?
Did an update stall on an image, resource, or admission error?

Deleting the missing Pod is not a durable fix. The controller will recreate it from the same spec and encounter the same unresolved condition.

Check yourself

Why is a DaemonSet a better fit for Cilium than a three-replica Deployment?
What would make the desired Pod count smaller than the total node count?
Which evidence proves node-wide coverage rather than one healthy Pod?

Reference

DaemonSet