# Review DaemonSet placement separately when cordoning a node > Account for the DaemonSet controller’s automatic unschedulable-node toleration. Keep node eligibility and the actual daemon population explicit during a maintenance plan. - Canonical URL: https://update.dsesecurity.com/updates/review-daemonset-placement-separately-when-cordoning-a-node/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T20:32:52+00:00 - Modified: 2026-10-29T20:33:35+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Account for the DaemonSet controller’s automatic unschedulable-node toleration. Keep node eligibility and the actual daemon population explicit during a maintenance plan. ## Potentially affected Kubernetes operators planning maintenance on nodes eligible for a DaemonSet; inspect the actual controller, Pod template and supported node conditions. ## DSE recommendation DSE recommends listing expected DaemonSet Pods separately in a node-maintenance placement review. ## Article Bottom line: Identify the node-local agents expected during maintenance before assuming that a scheduling restriction excludes every workload. Review the DaemonSet definition and actual Pod population alongside the node action so an essential agent is neither overlooked nor removed casually. ## Source fact: documented behavior The [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) documentation is the primary reference. The DaemonSet controller automatically adds the node.kubernetes.io/unschedulable:NoSchedule toleration, allowing its Pods to run on nodes marked unschedulable. For each eligible node, the controller creates a Pod with node affinity matching that target; the default scheduler typically binds it afterward. Changing node labels can cause the DaemonSet to add Pods to newly matching nodes and delete Pods from nodes that no longer match. ## What the source does not establish This is a DaemonSet placement review, not authorization to delete node agents or a promise that every daemon will remain available. Keep cordoning, draining, controller updates and node shutdown as separately supported operations. Confirm the installed behavior and constraints rather than turning one toleration into a universal scheduling guarantee or changing labels to force a convenient result. ## Applicability questions - Which DaemonSets are eligible for the maintenance node? - Which node-local functions must remain available? - What effective affinity and tolerations do their Pods carry? - Could a proposed label change alter the expected population? ## DSE recommendation: make node-local agents visible in maintenance DSE recommends listing expected DaemonSet Pods separately in a node-maintenance placement review. Begin with the intended maintenance outcome and node identity. Ask the network, monitoring and storage owners which node-local agents their supported procedures require. Record each relevant controller, its managed Pod template and the node’s current eligibility. Keep the operator’s intended scheduling restriction beside that population rather than calling the node empty from one administrative state alone. Inspect actual Pods and their owner references through approved tools. Reconcile the controller’s target node and effective scheduling information with the template. Treat an unexpected agent or missing required Pod as a question for its owner. Avoid substituting a manually created copy merely to make a maintenance inventory appear complete. Review label and affinity changes as explicit population changes. Determine which nodes should gain or lose the daemon before applying such a change. Preserve the original definition and identify any node-local function that needs a separate handoff. Keep an application-placement change from silently becoming a change to cluster infrastructure coverage. Have the maintenance owner accept the expected before, during and after populations. Follow the exact supported drain or shutdown procedure when those actions are required. Preserve an unresolved mismatch instead of broadening tolerations or deleting Pods until the display matches a simplified checklist. ## Verification and evidence Proposed verification, not performed: use a disposable DaemonSet and a designated nonproduction node. Record its eligibility, automatic toleration and actual Pod owner before applying the approved unschedulable-node case. Observe the resulting population without assuming that ordinary workload and daemon behavior are identical. For a separate fixture, change one reviewed node-selection label and predict which disposable daemon instance should be added or removed. Capture the actual controller and Pod observations, then restore the fixture arrangement. Retain node labels, template revision, node action and results with the maintenance plan. A passing placement exercise does not establish that a network or storage agent can be interrupted safely. ## Official references - [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) — Kubernetes. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — DaemonSet - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Review DaemonSet placement separately when cordoning a node,” DSE Security, https://update.dsesecurity.com/updates/review-daemonset-placement-separately-when-cordoning-a-node/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.