What is a DaemonSet in Kubernetes? Explained Simply (2026)
A DaemonSet ensures one pod runs on every node in your cluster. Here's what it is, how it works, and when to use it — explained simply with examples.
Some tools need to run on every node in your cluster — log collectors, monitoring agents, network plugins. You don't want to manually deploy them to each node. DaemonSet does this automatically.
The Problem DaemonSet Solves
Imagine you have a 10-node Kubernetes cluster and you need a log collector (like Fluent Bit) on every node to ship logs to Elasticsearch.
Without DaemonSet:
- Deploy 10 pods manually, one per node
- Add a new node → remember to deploy a pod on it
- Remove a node → clean up the pod manually
With DaemonSet:
- Define it once
- Kubernetes automatically runs one pod on every node
- New node added → pod automatically appears
- Node removed → pod automatically cleaned up
What Is a DaemonSet?
A DaemonSet is a Kubernetes object that ensures exactly one pod runs on each node (or each node that matches a selector).
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: log-collector
namespace: kube-system
spec:
selector:
matchLabels:
app: log-collector
template:
metadata:
labels:
app: log-collector
spec:
containers:
- name: fluent-bit
image: fluent/fluent-bit:2.2
resources:
requests:
cpu: "100m"
memory: "100Mi"
limits:
cpu: "200m"
memory: "200Mi"
volumeMounts:
- name: varlog
mountPath: /var/log
readOnly: true
volumes:
- name: varlog
hostPath:
path: /var/logkubectl apply -f daemonset.yaml
# One pod per node — automatically
kubectl get pods -n kube-system -l app=log-collector -o wide
# NAME NODE
# log-collector-abc12 node-1
# log-collector-def34 node-2
# log-collector-ghi56 node-3How It Differs from a Deployment
| Deployment | DaemonSet | |
|---|---|---|
| Replicas | You set a number | One per node (automatic) |
| Scaling | Manual or HPA | Scales with nodes |
| Pod placement | Scheduler decides | One on each node |
| Use case | Stateless apps | Node-level daemons |
| New node | No action | Pod automatically created |
A Deployment says "run 3 replicas anywhere." A DaemonSet says "run 1 pod on every node."
Real-World Use Cases
1. Log Collection
# Fluent Bit on every node → ships logs to Elasticsearch
- image: fluent/fluent-bit:2.2
volumeMounts:
- mountPath: /var/log # read host's /var/log
name: varlog2. Monitoring / Metrics
# Prometheus Node Exporter — metrics from every node
- image: prom/node-exporter:v1.7.0
ports:
- containerPort: 9100
hostPort: 9100 # accessible directly on node IP3. Network Plugin (CNI)
Calico, Cilium, Flannel — all installed as DaemonSets. They configure networking on each node.
# Cilium DaemonSet
kubectl get daemonset cilium -n kube-system4. Storage Plugin (CSI)
Container Storage Interface drivers run as DaemonSets to mount volumes on each node.
5. Security Agent
Falco (runtime security) runs as a DaemonSet to monitor every node's syscalls.
Running Only on Specific Nodes
You don't always want the DaemonSet on every node. Use nodeSelector or nodeAffinity.
Node Selector
spec:
template:
spec:
nodeSelector:
node-type: gpu # only on GPU nodes# Label a node
kubectl label node node-1 node-type=gpu
# DaemonSet pod will appear only on labeled nodesNode Affinity (more flexible)
spec:
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linuxDaemonSet vs System Nodes (tolerations)
By default, DaemonSets don't run on control plane (master) nodes because they have taints. To run on control plane too:
spec:
template:
spec:
tolerations:
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoScheduleUpdating a DaemonSet
Two update strategies:
RollingUpdate (default)
Updates pods one at a time:
spec:
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # update 1 pod at a timeOnDelete
Pods only update when manually deleted:
spec:
updateStrategy:
type: OnDelete# Trigger update
kubectl set image daemonset/log-collector fluent-bit=fluent/fluent-bit:2.3
# Check rollout
kubectl rollout status daemonset/log-collector -n kube-systemUseful Commands
# List all DaemonSets in cluster
kubectl get daemonsets -A
# See which nodes have the pod
kubectl get pods -l app=log-collector -o wide
# Describe DaemonSet
kubectl describe daemonset log-collector -n kube-system
# How many pods should be running vs actually running
kubectl get daemonset log-collector -n kube-system
# NAME DESIRED CURRENT READY UP-TO-DATE
# log-collector 3 3 3 3
# Check DaemonSet pods on a specific node
kubectl get pods --field-selector spec.nodeName=node-1 -n kube-systemSummary
| What | DaemonSet |
|---|---|
| Runs | One pod per node |
| Scales with | Number of nodes |
| Used for | Logging, monitoring, networking, security |
| Node selector | Optional — target specific nodes |
| Update strategy | RollingUpdate or OnDelete |
If your tool needs to be on every node and access node-level resources — DaemonSet is the answer. Don't manage per-node pods manually.
Learn More
- KodeKloud Kubernetes for Beginners — DaemonSet hands-on labs
- CKA on Udemy — DaemonSets are tested on CKA
Stay ahead of the curve
Get the latest DevOps, Kubernetes, AWS, and AI/ML guides delivered straight to your inbox. No spam — just practical engineering content.
Related Articles
Build a Kubernetes Cluster with kubeadm from Scratch (2026)
Step-by-step guide to building a real multi-node Kubernetes cluster using kubeadm — no managed services, no shortcuts.
How to Build a DevOps Home Lab for Free in 2026
You don't need expensive hardware to practice DevOps. Here's how to build a complete home lab with Kubernetes, CI/CD, and monitoring using free tools and cloud free tiers.
How to Migrate from Ingress-NGINX to Kubernetes Gateway API in 2026
Step-by-step guide to migrating from Ingress-NGINX to Kubernetes Gateway API. Includes YAML examples, implementation choices, testing strategy, and cutover plan.