10.14 Kubernetes DaemonSet Controller

Kubernetes DaemonSet Controller is the workload controller responsible for ensuring that exactly one copy of a specified Pod runs on every node, or on a defined subset of nodes, within the cluster, automatically adding Pods as new nodes join and removing them as nodes leave, making it the standard mechanism for deploying node-level infrastructure agents rather than horizontally scaled application replicas.

Node-Bound Replication Model

One Pod Per Eligible Node

Unlike a ReplicaSet, which maintains an arbitrary desired count of Pods independent of any specific node, a DaemonSet's desired state is defined entirely in terms of nodes: it ensures exactly one matching Pod exists on every node that satisfies its node selection criteria, with the total Pod count automatically following the number of eligible nodes rather than an explicitly configured number.

Automatic Response to Cluster Topology Changes

As nodes are added to the cluster, the DaemonSet controller automatically schedules a new Pod onto each qualifying node, and as nodes are removed, their corresponding DaemonSet Pods are cleaned up along with them, meaning the DaemonSet's effective scale grows and shrinks in direct response to the cluster's own node topology.

Common Use Cases

Node-Level Infrastructure Agents

DaemonSets are the standard mechanism for deploying agents that must run on every node to fulfill infrastructure-level responsibilities, such as log collection agents that gather output from all Pods on a node, node monitoring agents that report hardware and system metrics, or network plugin components that must be present on every node to enable Pod networking.

Storage and Networking Daemons

Certain storage drivers and network plugins rely on a DaemonSet to ensure their node-local components, such as a CSI driver's node plugin or a CNI plugin's per-node agent, are present and running on every node capable of hosting Pods requiring that particular storage or networking capability.

Node Selection and Exclusion

nodeSelector and Node Affinity

A DaemonSet's Pod template can include a nodeSelector or node affinity rules to restrict its scope to a subset of nodes rather than the entire cluster, such as deploying a specialized monitoring agent only to nodes carrying a specific hardware label, rather than requiring every node in the cluster to run it.

Toleration-Based Scheduling on Tainted Nodes

Because DaemonSets frequently need to run on nodes that are otherwise cordoned off from ordinary workloads through taints, such as control plane nodes, their Pod templates commonly include tolerations matching those taints, allowing the DaemonSet's Pods to be scheduled there while regular application Pods remain excluded.

Update Strategies

RollingUpdate Strategy

The RollingUpdate strategy for DaemonSets replaces Pods on each node incrementally, controlled by a maxUnavailable setting that determines how many nodes can simultaneously have their DaemonSet Pod unavailable during the update, allowing the rollout to proceed across the cluster without requiring every node's daemon to go down at once.

OnDelete Strategy

The OnDelete strategy requires manual deletion of each existing DaemonSet Pod before the controller will replace it with one reflecting the updated template, giving an operator complete control over exactly when each node's daemon is updated rather than having the process proceed automatically.

Scheduling Without the Default Scheduler Path

Direct Node Assignment

DaemonSet Pods are scheduled through logic that directly considers each node's eligibility against the DaemonSet's node selection criteria, ensuring the fundamental one-Pod-per-node guarantee is maintained consistently as nodes join, leave, or become tainted, distinguishing this from the general-purpose scheduling logic applied to ordinary Deployment- or ReplicaSet-managed Pods.

Bypassing Standard Scaling Operations

No Direct Replica Count Field

Unlike ReplicaSets or Deployments, a DaemonSet has no replicas field to manually scale, since its effective replica count is derived entirely from the number of eligible nodes, meaning scaling a DaemonSet's footprint is accomplished by adjusting node selection criteria or the cluster's own node membership rather than any direct numeric input.