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.
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
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.