A DaemonSet is a Kubernetes workload controller that ensures one copy of a given pod runs on every node in a cluster, or on every node that matches a selector. In Kubernetes, DaemonSets are the standard way to deploy node-level agents, such as log collectors, monitoring exporters, network plugins and storage drivers, which must be present wherever workloads run.
Unlike a Deployment, which keeps a requested number of replicas somewhere in the cluster, a DaemonSet ties its pod count to the number of eligible nodes. When a node joins, the controller adds a pod there automatically; when a node is removed, its pod is garbage-collected. The resource belongs to the apps/v1 API group.
How a DaemonSet places pods on nodes
The DaemonSet controller continuously compares the set of eligible nodes with the pods it owns. For each eligible node without a pod, it creates one with a node affinity rule that pins the pod to that node, and the default scheduler then binds it. Since Kubernetes 1.12, this path through the regular scheduler means DaemonSet pods respect priorities, preemption and resource checks like other pods.
Eligibility is controlled by three mechanisms. A nodeSelector or node affinity restricts the set to labeled nodes, such as only GPU nodes. Taints and tolerations decide whether pods may run on tainted nodes, including control-plane nodes. Finally, the controller automatically adds tolerations for conditions such as not-ready, unreachable, disk pressure and memory pressure, so node agents stay in place when a node is unhealthy, which is exactly when they are often needed.
The table below summarizes the fields that shape DaemonSet behavior.
| Field | Purpose | Typical value |
|---|---|---|
| selector | Matches the pods the DaemonSet owns | Must equal the pod template labels |
| template.spec.nodeSelector | Limits pods to labeled nodes | For example a GPU or storage node label |
| template.spec.tolerations | Allows pods on tainted nodes | Control-plane taint for cluster-wide agents |
| updateStrategy | Controls how new versions roll out | RollingUpdate (default) or OnDelete |
| priorityClassName | Protects agents from eviction | system-node-critical for essential agents |
| minReadySeconds | Delay before a new pod counts as available | 0 to 30 seconds |
Typical DaemonSet workloads
DaemonSets fit any software that must observe or extend the node itself rather than serve application traffic. Such pods often use hostPath volumes, hostNetwork or privileged mode to reach node resources, which makes them powerful and security-sensitive.
| Category | Example agents | Node resources used |
|---|---|---|
| Log collection | Fluent Bit, Fluentd, Vector, Filebeat | Container log files on the host |
| Monitoring | Prometheus node exporter, Datadog agent | Host metrics, /proc and /sys |
| Networking | Calico, Cilium, kube-proxy | Host network stack, iptables or eBPF |
| Storage | CSI node plugins | Device mounts and the kubelet directory |
| Security | Runtime threat detection, file integrity agents | Kernel events, process activity |
Rolling out updates safely
Because a DaemonSet touches every node at once, a faulty update can break logging, networking or storage across the whole cluster. The update strategy therefore deserves careful tuning.
| Strategy | Behavior | When to use it |
|---|---|---|
| RollingUpdate, maxUnavailable 1 | Replaces pods one node at a time | Default, cautious rollout |
| RollingUpdate, maxUnavailable 10-25% | Replaces pods on a share of nodes in parallel | Large clusters needing faster rollouts |
| RollingUpdate with maxSurge | Starts the new pod before stopping the old one | Agents that must not have a gap, if ports allow |
| OnDelete | Updates a pod only after it is deleted manually | Critical agents under strict change control |
Rollouts can be watched with kubectl rollout status and reversed with kubectl rollout undo. Readiness probes and minReadySeconds ensure that the controller only proceeds when the new pod on a node is actually healthy.
For critical agents such as a network plugin, many teams first test a new version on a small labeled node pool, often by running a second DaemonSet with a narrower nodeSelector, before updating the main DaemonSet. This canary approach limits the impact of a bad release to a few nodes and gives monitoring time to catch regressions.
DaemonSet compared with other workload controllers
Each Kubernetes workload controller answers a different question about where and how many pods run. Choosing the wrong one is a common design error.
| Controller | Pod count determined by | Pod identity | Typical workload |
|---|---|---|---|
| DaemonSet | Number of eligible nodes | One per node | Node agents |
| Deployment | Replica count or autoscaler | Interchangeable | Stateless applications |
| StatefulSet | Replica count | Stable name and storage | Databases, queues |
| Job | Completions and parallelism | Run to completion | Batch tasks |
| Static pod | Manifest file on a node | Managed by the kubelet | Control-plane components |
A Deployment with pod anti-affinity can approximate one pod per node, but it does not react to new nodes automatically and cannot follow node labels as precisely, so a DaemonSet remains the correct tool for agents.
Pitfalls and good practices
- Resource requests multiply by node count: a request of 200 millicores on 300 nodes reserves 60 cores, so size agents carefully.
- Missing tolerations: without them, agents silently skip tainted nodes, leaving gaps in logging or monitoring.
- Overprivileged pods: hostPath mounts, hostNetwork and privileged mode give broad node access; grant only what the agent needs.
- Eviction under pressure: without an appropriate priority class, essential agents may be evicted before ordinary workloads.
- Aggressive rollouts: a high maxUnavailable value for a network plugin can disrupt traffic on many nodes simultaneously.
Well-run clusters keep the number of DaemonSets small and deliberate, because every one consumes capacity on every node and widens the attack surface.
The short version
Picture a hotel chain that wants one security guard in every building. When a new hotel opens, a guard is assigned there automatically. When a hotel closes, its guard leaves. Nobody has to count guards by hand.
A DaemonSet does the same for a cluster of servers. It makes sure that every machine runs its own copy of a helper program, such as one that collects logs or watches performance. New machines get the helper automatically.
Where it makes a difference
A platform team runs a Kubernetes cluster that autoscales between 20 and 120 nodes during the day. To centralize logs, they deploy Fluent Bit as a DaemonSet that reads container log files from each node through a read-only hostPath volume and forwards them to a central log store. Each pod requests 100 millicores and 128 MiB of memory and tolerates the control-plane taint.
When the autoscaler adds 40 nodes during a traffic peak, each new node receives a Fluent Bit pod within seconds of becoming ready, so no log lines are lost from new application pods. A later configuration update rolls out with maxUnavailable set to 10 percent, and a faulty parser is caught on the first few nodes before reaching the rest of the cluster.