What Is a DaemonSet

You need to collect logs from every node in your cluster. You create a Deployment with three replicas. But three replicas on a five-node cluster means two nodes will not be covered. You scale to five. A sixth node joins. Now you are under-covered again. You spend your time chasing a moving target.

A DaemonSet eliminates this problem. It ensures exactly one copy of a Pod runs on every node in the cluster, automatically. When a new node joins, the DaemonSet places a Pod on it. When a node is removed, the Pod is garbage-collected. You declare the intent once. Coverage becomes a fact rather than a task.

kubectl get nodes

Look at the node count. A DaemonSet will place exactly one Pod on each of those nodes. Run that command again after creating a DaemonSet and you will see one Pod per node, correlated by the NODE column.

How it differs from a Deployment

A Deployment maintains a fixed replica count and lets the scheduler decide which nodes receive Pods. The scheduler optimizes for resource fit and spreading, but the number of Pods is fixed. A DaemonSet delegates to a different controller: instead of counting replicas, it counts nodes. The spec says nothing about how many Pods to run. It says one Pod per node.

The DaemonSet manifest

The structure closely resembles a Deployment. The key difference is the absence of replicas and the absence of a strategy section. Those fields belong to a controller that manages a fixed count. A DaemonSet has neither.

nano log-agent.yaml

Start with the outer shell:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent

The spec section requires two fields: selector and template. Their structure is identical to a Deployment.

spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      containers:
        - name: agent
          image: busybox:1.36

The full manifest:

nano log-agent.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      containers:
        - name: agent
          image: busybox:1.36

kubectl apply -f log-agent.yaml

Observing the placement

kubectl get pods -o wide

The -o wide flag adds a NODE column. Verify that one log-agent Pod appears on each node and that no node has two. This is the guarantee a DaemonSet provides.

kubectl get daemonset log-agent

The output shows DESIRED, CURRENT, READY, UP-TO-DATE, and AVAILABLE. DESIRED equals the number of nodes. There is no concept of “scale to 10” because the desired count is always derived from the node count.

Clean up before the next lesson:

kubectl delete daemonset log-agent

A DaemonSet is the right controller whenever the workload is node-scoped rather than replica-scoped: every node must run the thing, and no node should run more than one. The next lesson covers the most common real-world use cases and why they share this node-scoped requirement.