DaemonSets

In this lesson we cover DaemonSets in Kubernetes: what they are, when to use them, how to define them, and how they schedule Pods across nodes. A DaemonSet ensures that a copy of a Pod runs on every node (or on a subset of nodes) in your cluster. Unlike ReplicaSets or Deployments, which focus on the number of Pod replicas, a DaemonSet focuses on node coverage—one Pod per node.

A dark-themed infographic titled "DaemonSets" showing five phone-shaped nodes with colored circles representing pods. A left legend compares DaemonSets, ReplicaSets, and Deployments across the nodes.

Key behaviors:

When a new node joins the cluster, the DaemonSet controller ensures the DaemonSet’s Pod is scheduled onto that node.
When a node is removed, the DaemonSet’s Pod on that node is deleted.
You can target all nodes or a subset using selectors, node affinity, or tolerations.

Common use cases:

Node-level monitoring and metrics agents (Prometheus node-exporter, Datadog agents)
Log collectors (Fluentd, Fluent Bit)
Networking agents and CNI plugins (Calico, Weave Net)
kube-proxy (commonly run as a DaemonSet)

A diagram titled "DaemonSets – Use Cases" showing a row of phone-like node icons representing instances managed by a DaemonSet, each connected by lines to higher-level boxes labeled "Monitoring Solution" and "Logs Viewer." The left side has a "DaemonSets" label spanning the nodes.

kube-proxy is a typical example of a component that must run on each worker node and is often deployed as a DaemonSet.

A dark-themed diagram titled "DaemonSets – Use Cases – kube-proxy." It shows a row of phone-shaped node icons with colored app dots and "kube-proxy" labels, illustrating a DaemonSet deploying kube-proxy instances across multiple nodes.

Networking solutions such as Calico or other CNI plugins typically deploy an agent on every node; DaemonSets are the right tool for that scenario. When to choose a DaemonSet

Use case	Why DaemonSet
Node-local logging/monitoring agents	One Pod per node ensures logs/metrics are collected from every node
Networking/CNI agents	Networking requires an agent on each node to manage packet routing and overlay networks
kube-proxy-like components	System-level services that must run everywhere to provide cluster-wide functionality
Deploying singletons per node (not fixed count)	Guarantees node coverage rather than a target replica count

Manifest structure A DaemonSet manifest follows the same top-level structure as other controllers: apiVersion, kind, metadata, and spec, with a Pod template nested under spec.template. The controller requires a spec.selector that matches the labels in the Pod template when using apps/v1. ReplicaSet (for reference):

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: monitoring-replicaset
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      containers:
      - name: monitoring-agent
        image: monitoring-agent:latest

DaemonSet example:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-daemon
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      containers:
      - name: monitoring-agent
        image: monitoring-agent:latest

Ensure the labels in spec.selector.matchLabels exactly match the labels in spec.template.metadata.labels. If they don’t match, the DaemonSet controller will not manage the Pods created from that template.

Create and manage DaemonSets

Apply a manifest file:

kubectl apply -f daemonset.yaml

Create a simple DaemonSet directly:

kubectl create daemonset monitoring-daemon --image=monitoring-agent:latest

List DaemonSets:

kubectl get daemonsets
# or shorthand
kubectl get ds

Example output:

$ kubectl get daemonsets
NAME                 DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
monitoring-daemon    3         3         3       3            3           41m

Inspect a DaemonSet:

kubectl describe daemonset monitoring-daemon

Scheduling behavior and history Historically, the DaemonSet controller created Pods with the nodeName field set so they were bound directly to nodes and bypassed the scheduler. Starting in Kubernetes v1.12, the controller changed behavior: it now creates Pods without nodeName and relies on the kube-scheduler to place them. The controller uses node-affinity-like constraints and tolerations so the scheduler places DaemonSet Pods only on the intended nodes. This aligns DaemonSet scheduling with other workloads and lets the scheduler consider node conditions, taints, and other constraints.

A dark-themed diagram titled "How Does It Work?" showing a central box comparing behavior till v1.12 (uses Default Scheduler) and from v1.12 (uses NodeAffinity and Default Scheduler). Below it are six stylized node icons labeled NodeName: node 01 through node 06.

Quick tips and references

Use DaemonSets for node-scoped agents; use Deployments/ReplicaSets for stateless application workloads that need scaling by count.
Combine nodeSelector, nodeAffinity, and tolerations to target specific subsets of nodes.
For production CNI and networking agents, consult the vendor docs (for example, Calico’s docs at https://projectcalico.docs.tigera.io/) for the recommended DaemonSet manifests and configuration.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Watch Video

Practice Lab