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

3 minutes reading time

Written by

Civo Team
Civo Team

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.

daemonset-node-coverage

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 SELECTOR
kube-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/v1
kind: DaemonSet
metadata:
name: memory-reporter
labels:
app: memory-reporter
spec:
selector:
matchLabels:
app: memory-reporter
template:
metadata:
labels:
app: memory-reporter
spec:
containers:
- name: memory-reporter
image: busybox
command:
- 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 AVAILABLE
memory-reporter 2 2 2 2 2

Check the pods — one per node:

kubectl get pods

Expected output:

NAME READY STATUS RESTARTS AGE
memory-reporter-abc12 1/1 Running 0 15s
memory-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-plane
operator: Exists
effect: NoSchedule
containers:
- name: my-daemonset-container
image: 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.

Civo Team
Civo Team

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.

View author profile