What Are Common Use Cases for DaemonSets?

beginner|daemonsetsdevopssrebackend developerCKACKAD
TL;DR

DaemonSets are used for workloads that must run on every node: log collection (Fluentd, Fluent Bit), monitoring (Prometheus node-exporter, Datadog), networking (CNI plugins, kube-proxy), storage drivers (CSI node plugins), and security agents (Falco, runtime scanners).

Detailed Answer

DaemonSets are the go-to controller for any workload that needs to be present on every node (or a targeted set of nodes). Here are the most common production use cases.

1. Log Collection

Every node generates logs from containers, the kubelet, and the container runtime. A DaemonSet ensures a log collector runs on each node to ship logs to a central system.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit
  template:
    metadata:
      labels:
        app: fluent-bit
    spec:
      containers:
        - name: fluent-bit
          image: fluent/fluent-bit:3.0
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: true
            - name: containers
              mountPath: /var/log/containers
              readOnly: true
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
      volumes:
        - name: varlog
          hostPath:
            path: /var/log
        - name: containers
          hostPath:
            path: /var/log/containers

Common tools: Fluentd, Fluent Bit, Filebeat, Vector, Promtail

2. Node Monitoring

Monitoring agents collect hardware and OS metrics (CPU, memory, disk, network) from each node:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      hostNetwork: true
      hostPID: true
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.7.0
          args:
            - "--path.rootfs=/host"
          ports:
            - containerPort: 9100
              hostPort: 9100
          volumeMounts:
            - name: rootfs
              mountPath: /host
              readOnly: true
          resources:
            requests:
              cpu: "50m"
              memory: "64Mi"
            limits:
              cpu: "200m"
              memory: "128Mi"
      volumes:
        - name: rootfs
          hostPath:
            path: /

Common tools: Prometheus node-exporter, Datadog agent, New Relic infrastructure agent

3. Networking (CNI Plugins)

Container Network Interface (CNI) plugins run as DaemonSets to configure Pod networking on each node:

# Simplified Calico node DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: calico-node
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: calico-node
  template:
    metadata:
      labels:
        k8s-app: calico-node
    spec:
      hostNetwork: true
      tolerations:
        - operator: Exists
      containers:
        - name: calico-node
          image: calico/node:v3.27.0
          securityContext:
            privileged: true
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"

Common tools: Calico, Cilium, Flannel, Weave Net, AWS VPC CNI

4. Storage Drivers

CSI (Container Storage Interface) node plugins run as DaemonSets to mount volumes on each node:

Common tools: EBS CSI driver, EFS CSI driver, GCE PD CSI driver, Longhorn, Rook-Ceph

5. Security Agents

Runtime security tools need to monitor syscalls and container behavior on every node:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: falco
  namespace: security
spec:
  selector:
    matchLabels:
      app: falco
  template:
    metadata:
      labels:
        app: falco
    spec:
      tolerations:
        - operator: Exists
      containers:
        - name: falco
          image: falcosecurity/falco:0.37.0
          securityContext:
            privileged: true
          volumeMounts:
            - name: dev
              mountPath: /host/dev
            - name: proc
              mountPath: /host/proc
              readOnly: true
          resources:
            requests:
              cpu: "100m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"
      volumes:
        - name: dev
          hostPath:
            path: /dev
        - name: proc
          hostPath:
            path: /proc

Common tools: Falco, Sysdig, Aqua, Twistlock, Trivy operator

6. kube-proxy

The built-in kube-proxy runs as a DaemonSet in most clusters, managing iptables or IPVS rules for Service routing:

kubectl get daemonset kube-proxy -n kube-system
# NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE
# kube-proxy   5         5         5       5            5

Checklist: Is a DaemonSet Right for Your Workload?

Use a DaemonSet if your workload:

  • Needs to run on every node (or a specific subset)
  • Accesses node-level resources (hostPath, hostNetwork, hostPID)
  • Collects data that is local to each node
  • Provides infrastructure services (networking, storage)
  • Should scale automatically with the cluster

Why Interviewers Ask This

Interviewers ask this to verify you can identify real-world scenarios where DaemonSets are the right controller and distinguish them from workloads better served by Deployments.

Common Follow-Up Questions

Why can't you use a Deployment for log collection?
Log collectors need hostPath access to /var/log on each node. A Deployment might skip nodes or place multiple collectors on one node, missing logs and wasting resources.
Is kube-proxy a DaemonSet?
Yes, in most clusters kube-proxy runs as a DaemonSet in the kube-system namespace, ensuring every node has the networking rules needed for Service routing.
Can DaemonSets use hostNetwork?
Yes, many DaemonSets use hostNetwork: true to bind directly to node ports — common for monitoring exporters and CNI plugins.

Key Takeaways

  • DaemonSets are the standard pattern for node-level infrastructure in Kubernetes.
  • The five main categories are: logging, monitoring, networking, storage, and security.
  • Most DaemonSets run in the kube-system namespace with elevated privileges.

Related Questions

You Might Also Like