Kubernetes DaemonSet

A workload controller that ensures exactly one Pod runs on every eligible node in the cluster. Essential for node-level infrastructure, monitoring, and networking agents. Synthesized from CKA Day 12 — DaemonSet, Job & CronJob Explained. CNI plugins such as Calico deploy their enforcement agent (calico-node) as a DaemonSet to ensure every node can apply NetworkPolicies. Source: CKA Day 26

What is a DaemonSet?

A DaemonSet is a Kubernetes controller that guarantees a copy of a specific Pod runs on all (or a subset of) nodes in the cluster. When a new node is added, the DaemonSet automatically places a Pod on it. When a node is removed, the Pod is garbage collected. There is no manual replica count — the node count itself is the scaling dimension.

Core Difference: A Deployment scales replicas horizontally across the cluster for redundancy. A DaemonSet scales one-per-node for node-local coverage.

Why Use a DaemonSet?

Requirement	Deployment	DaemonSet
Run on every node	❌ (replicas spread randomly)	✅ (one per node by design)
Access node filesystem	❌ (requires hostPath or privileged)	✅ (natural use case)
Auto-deploy on new nodes	❌ (manual scaling or HPA)	✅ (automatic)
Node-level networking	❌ (ClusterIP is not node-local)	✅ (CNI plugins, kube-proxy)

Canonical Use Cases

• Cluster monitoring: Prometheus Node Exporter, Datadog Agent, New Relic Infrastructure
• Log collection: Fluentd, Fluent Bit, Logstash — need access to /var/log on each node Source: CKA Day 36
• Metrics Server: The in-memory metrics aggregator also runs as a cluster add-on, often deployed via a DaemonSet or Deployment in kube-system
• CNI plugins: Calico, Cilium, Flannel, Weave — install and configure node networking
• Security agents: Falco deploys as a DaemonSet (falcosecurity/falco Helm chart) so every node’s kernel is covered by runtime threat detection; custom rules ship via a ConfigMap mounted into the agent Pods. Source: Falco CKS Scenarios
• Storage daemons: Ceph OSD, Portworx, Longhorn — manage local block devices
• Node proxy: kube-proxy itself runs as a DaemonSet (or as a static Pod) on every node

YAML Structure

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  labels:
    app: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
      - name: node-exporter
        image: prom/node-exporter:latest
        ports:
        - containerPort: 9100
        volumeMounts:
        - name: proc
          mountPath: /host/proc
          readOnly: true
        - name: sys
          mountPath: /host/sys
          readOnly: true
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys

Key observations:

• apiVersion: apps/v1 — same as Deployment and ReplicaSet
• No replicas field — the DaemonSet controller derives the count from the node list
• selector.matchLabels is required and must match the Pod template labels
• hostPath volumes are common because DaemonSet Pods often need to read node-level data
• DaemonSet Pod templates should still define resource requests/limits; node agents run everywhere, so an unbounded agent can multiply resource pressure across the cluster. Source: CKA Day 16

Node Selectors and Taints

You can restrict a DaemonSet to a subset of nodes using:

• nodeSelector — simple label matching (e.g., disk: ssd)
• nodeAffinity — more expressive rules (preferred vs required)
• tolerations — allow DaemonSet Pods to run on tainted nodes (e.g., control plane nodes with node-role.kubernetes.io/control-plane:NoSchedule)

This is how kube-proxy runs on every node including masters: it tolerates the control-plane taint.

Essential Commands

Command	Purpose
kubectl get daemonset	List DaemonSets
kubectl get daemonset -o wide	List with node selector details
kubectl describe daemonset <name>	Full details including events
kubectl get pods -l <selector> -o wide	See which nodes the Pods landed on
kubectl delete daemonset <name>	Delete DaemonSet and all its Pods

DaemonSet vs Deployment

Aspect	DaemonSet	Deployment
Scaling model	One per node	N replicas across cluster
replicas field	Absent	Required
Rolling update	✅ Supported (RollingUpdate strategy)	✅ Supported
Rollback	✅ Supported	✅ Supported
Use case	Node agents, monitoring, CNI	Stateless apps, web services
Pod scheduling	Automatic per node	Scheduler picks nodes based on resources

CKA Exam Relevance

• Workloads & Scheduling (~15%): Create a DaemonSet manifest or identify why a DaemonSet Pod is missing on a node.
• Troubleshooting (~30%): If a node lacks a monitoring or CNI Pod, check kubectl get daemonset and kubectl describe for taint mismatches or image pull failures.
• Speed pattern:

  kubectl create deployment temp --image=nginx --dry-run=client -o yaml > ds.yaml
  # Edit kind: Deployment → kind: DaemonSet, remove replicas

Sources

• CKA Day 12 — DaemonSet, Job & CronJob Explained

Practical Practice

Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.

Task 1: Create a DaemonSet You are asked to create a DaemonSet named node-agent running fluent-bit on every eligible node. Requirements: Use --dry-run=client -o yaml starting from a Deployment manifest, change kind to DaemonSet, and remove replicas. Verification: kubectl get daemonset node-agent shows desired equals number of worker nodes. Solution:

kubectl create deployment node-agent --image=fluent-bit --dry-run=client -o yaml > node-agent.yaml
# Edit: change kind to DaemonSet, remove spec.replicas, ensure selector.matchLabels matches template labels
kubectl apply -f node-agent.yaml

Task 2: Exclude Control Plane Node The DaemonSet node-agent is running on the control plane node, but it should not. Add the correct node selector so it skips the control plane. Requirements: Do not delete the DaemonSet. Patch or edit it to add a node selector that targets only worker nodes. Verification: kubectl get pods -l app=node-agent -o wide shows no Pod on the control-plane node. Solution:

kubectl patch daemonset node-agent -p '{"spec":{"template":{"spec":{"nodeSelector":{"node-role.kubernetes.io/worker":""}}}}}'

Task 3: List DaemonSet Pods Across Nodes You are asked to list all Pods created by the DaemonSet node-agent across all nodes, showing their node names. Requirements: Use a single kubectl command with custom columns. Verification: Output shows one Pod per worker node. Solution:

kubectl get pods -l app=node-agent -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase

Related Pages

• Deployment, ReplicaSet & Replication Controller — the standard horizontal controller
• Pod Fundamentals — the unit managed by DaemonSets
• Kubernetes Architecture — kube-proxy runs as a DaemonSet
• Kubernetes Namespaces — DaemonSets are namespace-scoped
• Kubernetes Static Pods — kube-proxy can also run as a Static Pod on some setups
• Kubernetes Labels and Selectors — matchLabels and nodeSelector for DaemonSet targeting
• Kubernetes Manual Scheduling — nodeSelector and taint/toleration patterns
• Kubernetes Taints and Tolerations — deep-dive on tolerations for control-plane and not-ready nodes
• Kubernetes Resource Requests and Limits — CPU/memory budgets for node agents and add-ons
• CKA Certification — exam overview
• CKA Study Roadmap — 40-day learning plan
• Tech Tutorials with Piyush — course source
• Kubernetes CNI — CNI agents deploy as DaemonSets
• Kubernetes Logging and Monitoring — log collectors and Metrics Server as cluster add-ons
• Kubernetes Worker Node Troubleshooting — Day 39: DaemonSet (kube-proxy, CNI) failures as node-level symptoms

---

Tags: kubernetes daemonset workload cka devops monitoring cni node-agent