Chapter 37 of 47 · More workload types

DaemonSets: one Pod on every node

A Deployment asks "how many copies of my app do users need?". Some programs do not care about users at all. They look after the machine: collect its logs, measure its CPU, set up its network. Those need exactly one copy on every node, and that is what a DaemonSet gives you.

The idea: a caretaker in every building

Imagine a company with many office buildings. Each building needs its own caretaker who checks the heating and empties the bins. You never want two caretakers in one building, and you never want a building without one. When the company buys a new building, a caretaker moves in on day one. When a building is sold, its caretaker leaves with it.

Nodes are the buildings. A DaemonSet is the rule "every building gets one caretaker".

DaemonSet vs Deployment

Try it: nodes come and go

Add and remove nodes, then try the two switches. Watch the DaemonSet keep "one per matching node" without you ever choosing a number:

• A new node gets its copy right away.
• The control-plane node is skipped because it carries a taint ("no ordinary Pods here"). A toleration lets the DaemonSet in anyway (chapter 40 explains taints).
• With a nodeSelector, only labelled nodes get a copy.

The YAML

It looks like a Deployment without replicas. Click the highlighted parts:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
          effect: NoSchedule
      containers:
        - name: agent
          image: fluent/fluent-bit:3.0
          resources:
            requests: { cpu: 50m, memory: 64Mi }
            limits:   { memory: 128Mi }
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: true
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

$ kubectl get daemonset -n kube-system
NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR
log-agent    3         3         3       3            3           <none>
kube-proxy   3         3         3       3            3           kubernetes.io/os=linux

DESIRED is not something you typed: it is the number of matching nodes. Note that kube-proxy itself runs as a DaemonSet.

What people run as DaemonSets

Your blog app's services do not belong here. posts and comments serve users, so they stay Deployments.

Only some nodes

Not every agent belongs everywhere. A GPU monitor only makes sense on GPU machines:

spec:
  template:
    spec:
      nodeSelector:
        accelerator: nvidia          # only nodes with this label get a copy

$ kubectl label node node-4 accelerator=nvidia     # node-4 now gets one
$ kubectl label node node-4 accelerator-           # remove the label: its copy is deleted

Node affinity works too, for more complex rules. Both are covered in chapter 40.

Talking to a DaemonSet Pod

Most DaemonSets push data out (to a log server, to Prometheus) and nobody calls them. When something does need to reach one, there are three common ways:

containers:
  - name: agent
    ports:
      - containerPort: 24224
        hostPort: 24224          # open this port on the node's own IP

apiVersion: v1
kind: Service
metadata:
  name: node-exporter
spec:
  clusterIP: None              # headless
  selector: { app: node-exporter }
  ports: [{ port: 9100 }]

Updating a DaemonSet

Change the image and apply, just like a Deployment. Two update strategies:

$ kubectl set image daemonset/log-agent agent=fluent/fluent-bit:3.1 -n kube-system
$ kubectl rollout status daemonset/log-agent -n kube-system

Static Pods

A static Pod is a Pod file placed directly in a folder on the node, usually /etc/kubernetes/manifests/. The node's kubelet runs it by itself, without the API server or any controller. That is how many clusters start the control plane: the API server cannot schedule itself before it exists. You will see these Pods (with the node name added to their names) in kube-system, but for your own agents, use a DaemonSet.

Which one?

Recap

• A DaemonSet runs one Pod on every node, or on every node you select.
• No replicas: the count follows the nodes automatically.
• Used for node agents: logs, metrics, networking, storage drivers.
• Tolerations let it run on tainted nodes; nodeSelector limits it to some nodes.
• Keep its requests small: they are paid on every node.
• Updates: RollingUpdate node by node, or OnDelete for manual control.

Quick check