Kubernetes DaemonSet Placement Control

Kubernetes DaemonSet Placement Control is the specific mechanism by which a DaemonSet determines exactly which nodes qualify to receive its Pod, and how that determination is actually carried out through the standard scheduler rather than through any custom placement logic of the DaemonSet controller itself. This is a narrower concern than the DaemonSet controller's overall behavior: it is the precise rules governing eligibility and the scheduling pathway used to enforce them.

Node Affinity Generation, Not Direct Assignment

The Controller Delegates to the Scheduler

Rather than assigning spec.nodeName directly for each target node, the DaemonSet controller generates a required node affinity term matching that specific node's identity and lets the standard scheduler perform the actual binding. This design allows DaemonSet Pods to benefit from the same resource-fit and admission checks applied to any other Pod, rather than bypassing them.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchFields:
              - key: metadata.name
                operator: In
                values:
                  - node-1

Why This Matters for Resource Pressure

Because scheduling still passes through the normal admission path, a node lacking sufficient allocatable resources for a DaemonSet Pod will show that Pod stuck in Pending with a FailedScheduling event, exactly as it would for any other workload, rather than the DaemonSet controller silently overriding resource constraints.

kubectl describe pod placement-control-example-node1

Selecting the Eligible Node Set

nodeSelector and Node Affinity in the Template

The nodes eligible to receive a DaemonSet Pod at all are first filtered by any nodeSelector or custom nodeAffinity terms declared in the Pod template, evaluated against every node in the cluster; only nodes matching these criteria are considered candidates for the controller's per-node Pod creation.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: placement-control-example
spec:
  template:
    spec:
      nodeSelector:
        kubernetes.io/os: linux

Taint Tolerance as a Placement Gate

Built-In Tolerations for Standard Node Conditions

Because DaemonSets often need to run even on nodes experiencing conditions that would repel ordinary Pods, the controller automatically tolerates several standard taints, including node.kubernetes.io/not-ready and node.kubernetes.io/unreachable, without requiring the Pod template to declare them explicitly, though custom taints such as control-plane taints still require an explicit toleration.

spec:
  template:
    spec:
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
          effect: NoSchedule

Unschedulable and Cordoned Nodes

Cordoning Does Not Remove Existing Placement

Marking a node unschedulable (cordoning) prevents new Pods, including new DaemonSet Pods, from being scheduled to it, but does not affect a DaemonSet Pod already running there; placement, once established, persists until the node itself is removed or the DaemonSet's selection criteria change.

kubectl cordon node-1
kubectl get pods -o wide --field-selector spec.nodeName=node-1

Placement Control Diagram

Routing DaemonSet placement through the ordinary scheduler rather than a bespoke assignment path keeps the entire cluster's resource accounting consistent, ensuring DaemonSet Pods are counted correctly against node capacity alongside every other workload competing for the same resources.