Kubernetes DaemonSets explained: What they are and when to use them
Learn how Kubernetes DaemonSets work with a working YAML example. Covers log collection with Fluentd, node monitoring with node-exporter, CNI plugins, nodeSelector, and taints and tolerations.
9 lessons · 27 min · Intermediate
Written by
Marketing Team at Civo
Written by
Marketing Team at Civo
A DaemonSet ensures that one copy of a pod runs on every node in the cluster. When a new node joins, the DaemonSet pod is automatically scheduled on it. When a node is removed, the pod is cleaned up. The DaemonSet controller handles all of this without any manual intervention.
This makes DaemonSets the right choice for node-level infrastructure components that need to run everywhere: log collectors, monitoring agents, CNI plugins, and storage drivers.
Real-world use cases
Log collection with Fluentd or Filebeat
A log-shipping DaemonSet runs one collector per node, reading from /var/log/containers and forwarding logs to a centralised backend like Elasticsearch or a cloud logging service. Without a DaemonSet, you would need to manually deploy a log collector every time a node is added.
Node monitoring with Prometheus node-exporter
node-exporter reads hardware and OS-level metrics from /proc and /sys on each node and exposes them for Prometheus to scrape. It must run on every node to provide complete cluster coverage. A DaemonSet ensures this automatically.
CNI plugins like Flannel and Calico
Your cluster already uses DaemonSets for core networking. Run the following to see them:
kubectl get ds -A
Expected output:
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTORkube-system kube-flannel 3 3 3 3 3 <none>kube-system kube-proxy 3 3 3 3 3 kubernetes.io/os=linux
Flannel and kube-proxy run on every node including control plane nodes. This is because they have tolerations for the control plane taint. More on this below.
Working example
This DaemonSet runs a memory-reporting script on every node, logging free memory every five seconds:
apiVersion: apps/v1kind: DaemonSetmetadata:name: memory-reporterlabels:app: memory-reporterspec:selector:matchLabels:app: memory-reportertemplate:metadata:labels:app: memory-reporterspec:containers:- name: memory-reporterimage: busyboxcommand:- sh- -c- while true; do free -m; sleep 5; done
kubectl create -f ds.yaml
Verify the DaemonSet was created:
kubectl get ds
Expected output:
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLEmemory-reporter 2 2 2 2 2
Check the pods — one per node:
kubectl get pods
Expected output:
NAME READY STATUS RESTARTS AGEmemory-reporter-abc12 1/1 Running 0 15smemory-reporter-def34 1/1 Running 0 15s
View logs from one of the pods:
kubectl logs -f memory-reporter-abc12
See which nodes each pod is running on:
kubectl get pods -o wide
See selector and image details for the DaemonSet:
kubectl get ds -o wide
Running a DaemonSet on specific nodes
By default a DaemonSet runs on all schedulable nodes. Use nodeSelector to restrict it to a subset of nodes:
spec:template:spec:nodeSelector:disktype: ssd
This is useful for DaemonSets that only make sense on nodes with specific hardware. Label nodes with kubectl label node <node-name> disktype=ssd and the DaemonSet will only run there.
Running a DaemonSet on control plane nodes
By default, DaemonSets do not run on control plane nodes because they carry a node-role.kubernetes.io/control-plane:NoSchedule taint. This taint prevents regular pods from being scheduled there.
To run a DaemonSet on control plane nodes as well, add a toleration for that taint in the pod spec:
spec:template:spec:tolerations:- key: node-role.kubernetes.io/control-planeoperator: Existseffect: NoSchedulecontainers:- name: my-daemonset-containerimage: busybox
This is how system DaemonSets like Flannel and kube-proxy run on every node including control plane nodes. Without the toleration, the DaemonSet would skip control plane nodes entirely.

Marketing Team at Civo
Civo is the Sovereign Cloud and AI platform designed to help developers and enterprises build without limits. We bridge the gap between the openness of the public cloud and the rigorous security of private environments, delivering full cloud parity across every deployment. As a team, we are dedicated to providing scalable compute, lightning-fast Kubernetes, and managed services that are ready in minutes. Through CivoStack Enterprise and our FlexCore appliance, we empower organizations to maintain total data sovereignty on their own hardware.
Our mission is to make the cloud faster, simpler, and fairer. By providing enterprise-grade NVIDIA GPUs and streamlined model management, we ensure that high-performance AI and machine learning are accessible to everyone. Built for transparency and performance, the Civo Team is here to give you total control over your infrastructure, your data, and your spend.
Share this lesson