✦ For everyone, free.

Practical knowledge for real and everyday life

Home

14 Kubernetes Daemon Workloads

Kubernetes Daemon Workloads are critical background processes that run on every node, ensuring system stability, monitoring, and essential services across the cluster.

Kubernetes Daemon Workloads is the pattern of running exactly one instance of a Pod on every node, or on a defined subset of nodes, in a cluster, implemented through the DaemonSet controller and typically used for infrastructure-level agents rather than application logic.


The DaemonSet Controller

One Pod per Node

A DaemonSet guarantees that a copy of its Pod template runs on each eligible node in the cluster. As new nodes join the cluster, the DaemonSet controller automatically schedules a matching Pod onto them, and as nodes are removed, their associated DaemonSet Pods are cleaned up along with them.

Different from Replica-Based Controllers

Unlike a Deployment or ReplicaSet, a DaemonSet does not have a configurable replica count; the desired number of Pods is implicitly determined by the number of nodes that match its node selector or tolerations, not by an explicit number set by the user.

DaemonSet Pods = | { n Nodes : eligible(n) } |

Common Use Cases

Node-Level Monitoring and Logging

Log collection agents and metrics exporters are commonly deployed as DaemonSets, since they need to run on every node to gather logs or metrics originating from that specific node's containers and system processes.

Networking and Storage Plugins

Container Network Interface (CNI) plugins and Container Storage Interface (CSI) node drivers are frequently deployed as DaemonSets, because networking and storage attachment operations must be performed locally on each node where Pods requiring them are scheduled.

Security and Compliance Agents

Runtime security scanners and compliance agents often run as DaemonSets to provide consistent visibility and enforcement across every node in the cluster without depending on scheduling decisions made for regular application workloads.


Targeting a Subset of Nodes

Node Selectors and Affinity

A DaemonSet can be restricted to a subset of nodes using node selectors or node affinity rules, allowing specialized agents, such as those requiring particular hardware, to run only where appropriate rather than on every node in the cluster.

Tolerations for Control Plane Nodes

Because control plane nodes are often tainted to prevent regular workloads from being scheduled there, a DaemonSet intended to run cluster-wide, including on control plane nodes, must include tolerations matching those taints.


Updating DaemonSets

RollingUpdate Strategy

DaemonSets support a rolling update strategy similar to Deployments, replacing Pods on each node one at a time, or in small batches, as the DaemonSet's Pod template changes, minimizing simultaneous disruption across the fleet.

OnDelete Strategy

Alternatively, the OnDelete strategy leaves existing Pods untouched when the template changes, requiring an operator or external process to manually delete old Pods before new ones are created with the updated specification.


DaemonSet Interaction Diagram

Node A agent Pod Node B agent Pod Node C agent Pod

This uniform, one-per-node placement guarantee is what makes DaemonSets the natural fit for cluster-wide infrastructure concerns that must observe or act on every node individually, rather than being aggregated behind a single load-balanced endpoint.