10.15 Kubernetes DaemonSet Placement Control

Kubernetes DaemonSet Placement Control is the collection of fields and mechanisms that determine precisely which nodes within a cluster are eligible to receive a DaemonSet's Pod, allowing the otherwise cluster-wide default of one Pod per node to be narrowed, excluded, or otherwise shaped according to node characteristics, taints, and specialized scheduling requirements.

Node Selector Restriction

nodeSelector for Simple Label Matching

The nodeSelector field, defined within the DaemonSet's Pod template, restricts placement to only those nodes carrying every specified label, providing a straightforward way to target a DaemonSet at a specific class of nodes, such as those labeled to indicate a particular hardware type or role.

Effect on the Controller's Effective Scope

Because the DaemonSet controller evaluates node eligibility using this same selector, adding or removing matching labels on nodes after the DaemonSet is created dynamically changes which nodes receive the DaemonSet's Pod, expanding or contracting its placement footprint in direct response to label changes rather than requiring any change to the DaemonSet itself.

Node Affinity for Expressive Placement

requiredDuringSchedulingIgnoredDuringExecution

Node affinity rules embedded in the DaemonSet's Pod template support more expressive placement logic than simple label matching, using operators such as In, NotIn, and Exists to define eligibility conditions that cannot be captured through equality-based selectors alone.

Combining Affinity With Selector for Precise Targeting

Node affinity and nodeSelector can be used together within the same DaemonSet, allowing an operator to express both simple required labels and more nuanced conditional logic simultaneously, giving fine control over exactly which subset of a heterogeneous cluster should host the DaemonSet's Pods.

Toleration-Based Access to Tainted Nodes

Overriding Default Taint-Based Exclusion

Because many nodes, particularly control plane nodes, are tainted to repel ordinary workloads, a DaemonSet intended to run everywhere, including on those tainted nodes, must include tolerations matching each relevant taint, without which its Pods would be excluded from those nodes just like any other workload lacking a matching toleration.

Built-In Tolerations for Common System DaemonSets

Certain system-critical DaemonSets, such as those providing core networking functionality, are commonly configured with tolerations for a broad range of standard taints, including those applied to nodes that are not yet ready or are undergoing maintenance, ensuring critical infrastructure components remain scheduled even under conditions that would exclude typical application workloads.

Exclusion Through Anti-Affinity Style Conditions

Using NotIn and DoesNotExist Operators

While DaemonSets do not support Pod anti-affinity in the same sense used by other workload types, node affinity's NotIn and DoesNotExist operators can be used to explicitly exclude nodes carrying certain labels, effectively achieving a targeted exclusion pattern within the same node affinity mechanism used for inclusion.

Interaction With Node Readiness and Availability

Placement Regardless of Ordinary Readiness Gating

Unlike Pods managed by ReplicaSets or Deployments, which are scheduled based on general cluster capacity considerations, a DaemonSet's placement logic is fundamentally node-identity driven, meaning its Pod is scheduled onto every eligible node independent of broader cluster-wide load balancing or capacity optimization concerns that influence ordinary scheduler decisions.

Behavior During Node Cordoning

Cordoning a node, which marks it as unschedulable for new Pods generally, does not by itself remove an already-running DaemonSet Pod from that node, since cordoning affects new Pod placement decisions rather than retroactively evicting existing workloads, meaning a DaemonSet's Pod typically remains until the node is drained or removed entirely.