[CKAD] DaemonSet: Guaranteed Deployment and Management of Node-Level Infrastructure Agents

May 30, 2026

—

Hello everyone! Today, it’s time to meet a special friend among the four major workload managers in Kubernetes. This isn’t a web server or an API server that scales up and down with traffic. It’s a silent guardian at the infrastructure level, one that must exist on every node (server): the DaemonSet. 🛡️

In the CKAD exam, questions often appear in the form of “Deploy a log collector only on specific nodes,” so let’s invest 15 minutes today to firmly grasp the concept!

###

1. Introduction: Why do we need a Pod on every node? 🤔

When we use a typical Deployment, if we request “Spin up 3 Pods for our service!”, the scheduler automatically places them on nodes with available resources. Two Pods might land on one node, or all three might land on different nodes.

But what if we change the scenario?

Imagine you have a Kubernetes cluster consisting of 100 servers (nodes). Let’s say you need to collect all system logs generated on these 100 servers.

Would setting `replicas: 100` with a Deployment work?
👉 No! If you’re unlucky, some nodes might have two log collectors, while others have none.

This is where DaemonSet comes in, a controller that “ensures a copy of a Pod runs on exactly one node (or a node satisfying specific conditions) across the cluster.”

2. Key Missions of DaemonSet (Use Cases) 🛠️

DaemonSets are typically used for infrastructure-level tasks rather than application logic. Their primary role is that of an “Agent” that manages or monitors the nodes themselves.

Typical use cases include:

📝 Running Log Collection Daemons:

Collects container logs or system logs generated on each node and sends them to a central log storage (e.g., Elasticsearch, Loki).
Examples: Fluentd, Fluent Bit, Filebeat

📊 Running Monitoring Daemons:

Collects node-specific status information such as CPU, memory, and disk usage for each node.
Examples: Prometheus Node Exporter, Datadog Agent

🌐 Cluster Storage Daemons and Network Plugins:

Helps mount storage on each node or runs CNI plugins responsible for network communication between nodes.
Examples: Glusterd, Ceph, Calico, Flannel

💡 Key Summary: When a new node is added to the cluster, DaemonSet automatically creates a Pod, and when a node is removed, it cleans up the Pod. It’s a truly reliable guardian, isn’t it?

3. CKAD in Practice! DaemonSet with YAML 📄

Seeing is believing! Let’s look at the actual code and see how it differs from a Deployment.

The biggest difference is the absence of the `replicas` field. The number of Pods is determined by the number of nodes!

Below is a simple DaemonSet example that deploys a log collector called fluentd on all nodes.

apiVersion: apps/v1
kind: DaemonSet  # 👈 The type is DaemonSet.
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system # Infrastructure-related deployments are usually in kube-system.
  labels:
    k8s-app: fluentd-logging
spec:
  # replicas: 3 👈 Unlike Deployment, this field is not present!
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template: # From here, it's the same as a Pod template.
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      # Setting to mount the node's system log path to the Pod (example)
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
      # To deploy on master nodes (control plane) as well, tolerations for taints might be needed.
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule

4. CKAD Advanced: “I want to deploy only on specific nodes!” (Node Selector) 🎯

In the CKAD exam, rather than just creating a DaemonSet, there are often cases where conditions are given.

“Deploy a monitoring agent as a DaemonSet only on nodes with GPUs.”

While DaemonSets are deployed on all nodes by default, you can use `nodeSelector` or `affinity` to deploy Pods only on nodes with specific labels.

Example Scenario: What if you want to deploy only on nodes with the label `type=gpu-node`?

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: gpu-monitor
spec:
  selector:
    matchLabels:
      app: gpu-monitor
  template:
    metadata:
      labels:
        app: gpu-monitor
    spec:
      # 👇 This part is key!
      nodeSelector:
        type: gpu-node
      containers:
      - name: nvidia-gpu-exporter
        image: nvidia/gpu-monitoring-tools
        # ... omitted ...

With this setting, the DaemonSet controller selects only nodes with the `type=gpu-node` label in the cluster and creates one Pod on each. Very smart, isn’t it? 🧠

5. DaemonSet Update Strategies (RollingUpdate vs OnDelete) 🔄

What happens if you change the image of a Pod deployed by a DaemonSet? Like Deployments, DaemonSets also have update strategies.

RollingUpdate (default):
This is the most recommended method. Like Deployments, it doesn’t kill all Pods at once; instead, it sequentially deletes old version Pods and creates new version Pods, one node at a time. This allows you to update infrastructure agents without service interruption.
The `maxUnavailable` setting allows you to control how many nodes can be updated simultaneously (how many Pods can be temporarily unavailable) (default is 1).
OnDelete:
As the name suggests, it updates “when deleted.” Even if the template is modified, already running Pods do not change.
The operator must manually delete the Pods on the respective nodes using `kubectl delete pod …` for the DaemonSet controller to create new version Pods. Use this when you want complete manual control over the update timing.

6. Conclusion: CKAD Exam Tips 🍯

DaemonSet is as easy as Deployment once you firmly grasp the concept.

Remember the purpose: Its purpose is “infrastructure management per node,” not “service scaling.”
YAML structure: Be sure to remember that there is no `replicas` field.
Node selection: If the exam asks you to “deploy only on specific nodes,” don’t panic; just add `nodeSelector` inside the Pod template (`spec.template.spec`).
Toleration: If it needs to be deployed on master nodes, you might need `tolerations` settings to tolerate the master node’s Taint. (While newer versions sometimes add this automatically, explicit declaration is better.)

How was today’s lesson on DaemonSet? Doesn’t it feel like a reliable supporter working hard behind the scenes to keep the cluster stable? 👮‍♂️

If you have any questions while preparing for the CKAD exam, please feel free to ask. I sincerely wish you success! Good luck! 💪