Updated 25 October 2026 · Published by Zoorik
A DaemonSet in Kubernetes runs one copy of a pod on each node. A new node gets its copy. When a node leaves, Kubernetes removes its copy.
Some nodes get no copy:
- A node that doesn’t match its node selector or node affinity.
- A node with a NoSchedule or NoExecute taint the pod doesn’t tolerate. A taint keeps pods away.
The use of a DaemonSet is to run a helper on each node. The docs name three:
- cluster storage
- log collection
- node monitoring
A Kubernetes DaemonSet example
The docs’ example runs the fluentd-elasticsearch image. Each copy requests 100m of CPU, or 0.1 CPU, and 200Mi of memory, or 200 mebibytes.
DaemonSet vs Deployment
Both keep pods running.
- A Deployment runs as many copies as you set, on whatever nodes fit.
- A DaemonSet suits a helper that must run on all nodes, or on some.
Why it matters for your bill
The scheduler counts each pod’s request against its node, so a DaemonSet’s request takes room on every node you pay for. A container with only a limit usually gets that limit as its request.
Say the docs’ example runs on 10 nodes. Its requests total 1 CPU and 2,000Mi, or 0.6 CPU and 1,200Mi on 6 nodes.
- Coral rebalances CPU and memory requests on AKS and EKS to match real use, so the same pods fit on fewer nodes.
- It drains spare nodes so your autoscaler can remove them, and it never moves DaemonSet pods.
- The free assessment works out your own figure.
Read next: Kubernetes node size best practices: large or small nodes
Sources: Kubernetes, “DaemonSet” (opens in a new tab); Kubernetes, “Resource Management for Pods and Containers” (opens in a new tab); Kubernetes, “Taints and Tolerations” (opens in a new tab); Kubernetes, “Kubelet Configuration (v1beta1)” (opens in a new tab).