What is a Kubernetes DaemonSet?
Learn what a Kubernetes DaemonSet is, how it runs one Pod per node, and when to use it for logging and monitoring agents.
Expected Interview Answer
A DaemonSet ensures that a copy of a specific Pod runs on every node (or a selected subset of nodes) in a cluster, automatically adding that Pod to new nodes as they join and removing it when a node leaves.
Unlike a Deployment, which schedules a fixed number of replicas wherever the scheduler finds capacity, a DaemonSet is tied one-to-one with the node topology: one Pod instance per matching node, no more and no less. This makes it the natural choice for node-level infrastructure agents such as log collectors (Fluentd, Fluent Bit), metrics exporters (node-exporter), and network or storage plugins (CNI, CSI drivers) that must observe or serve every node individually. A `nodeSelector`, node affinity rule, or taint/toleration can restrict the DaemonSet to a subset of nodes, such as only GPU nodes. Rolling updates to a DaemonSet are controlled by an `updateStrategy` of `RollingUpdate` or `OnDelete`, letting operators control how many node-agents are replaced at once.
- Guarantees exactly one agent Pod per matching node
- Automatically extends to newly joined nodes with zero manual steps
- Ideal for log shippers, monitoring agents, and network/storage plugins
- Supports node selectors and tolerations to target a subset of nodes
AI Mentor Explanation
A DaemonSet is like assigning exactly one groundskeeper to every single practice net in a stadium complex, no matter how many nets exist. When a new net is built, a groundskeeper is automatically assigned to it without anyone filing a request. When a net is dismantled, that groundskeeper moves on rather than sitting idle. This is different from having a fixed squad of ten groundskeepers scattered wherever needed — here the count always exactly matches the number of nets.
Step-by-Step Explanation
Step 1
Define the DaemonSet spec
Write a Pod template under kind: DaemonSet, e.g. a log-collector or metrics agent container.
Step 2
Optionally scope with selectors
Add nodeSelector, affinity, or tolerations to target only specific nodes such as GPU or edge nodes.
Step 3
Kubernetes reconciles nodes
The DaemonSet controller creates exactly one matching Pod per eligible node, bypassing normal scheduler placement logic.
Step 4
Handle node churn and updates
New nodes automatically get the Pod; removed nodes drop it; updateStrategy controls rolling replacement of agent Pods.
What Interviewer Expects
- Understanding that DaemonSets tie one Pod per node, not a fixed replica count
- Knowledge of typical use cases: logging agents, monitoring exporters, CNI/CSI plugins
- Awareness of nodeSelector/affinity/tolerations to scope a subset of nodes
- Ability to contrast DaemonSet placement with Deployment scheduling
Common Mistakes
- Confusing a DaemonSet with a Deployment set to a high replica count
- Forgetting that DaemonSet Pods bypass normal scheduler resource-based placement by default
- Not knowing tolerations are needed to run on tainted nodes like control-plane nodes
- Assuming DaemonSets can be scaled with kubectl scale like a Deployment
Best Answer (HR Friendly)
“A DaemonSet makes sure a specific helper Pod, like a log collector, runs on every single node in the cluster automatically — one copy per node, always. So if we add ten new servers to the cluster, we do not have to remember to deploy monitoring agents on them; Kubernetes does it for us the moment the node joins.”
Code Example
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit-agent
spec:
selector:
matchLabels:
app: fluent-bit
template:
metadata:
labels:
app: fluent-bit
spec:
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
containers:
- name: fluent-bit
image: fluent/fluent-bit:2.2
volumeMounts:
- name: varlog
mountPath: /var/log
volumes:
- name: varlog
hostPath:
path: /var/log
updateStrategy:
type: RollingUpdateFollow-up Questions
- How does a DaemonSet differ from a Deployment in scheduling behavior?
- How would you run a DaemonSet only on GPU-labeled nodes?
- What happens to a DaemonSet Pod when its node is drained?
- How does RollingUpdate differ from OnDelete for DaemonSets?
MCQ Practice
1. What is the defining behavior of a Kubernetes DaemonSet?
A DaemonSet ties Pod count to node count, ensuring one Pod per eligible node rather than a fixed replica total.
2. Which use case is a classic fit for a DaemonSet?
Node-level agents like log shippers and monitoring exporters need one instance per node, which is exactly what DaemonSets guarantee.
3. How can a DaemonSet be restricted to run only on a subset of nodes?
nodeSelector, affinity rules, and tolerations let a DaemonSet target only matching or tainted nodes instead of the whole cluster.
Flash Cards
What is a DaemonSet? — A controller that runs exactly one Pod copy on every eligible node in a cluster.
DaemonSet vs Deployment? — DaemonSet ties Pod count to node count; Deployment runs a fixed replica count anywhere.
Typical DaemonSet use case? — Node-level agents: log collectors, metrics exporters, CNI/CSI plugins.
How to scope a DaemonSet to some nodes? — nodeSelector, node affinity, or tolerations for tainted nodes.