Kubernetes DaemonSet Pod Deletion Management

Kubernetes DaemonSet Pod Deletion Management is the set of circumstances and mechanisms under which the DaemonSet controller (or an operator acting directly) removes a Pod that was previously created to satisfy a DaemonSet's per-node coverage guarantee. Because DaemonSet Pods are tied to specific nodes rather than existing as fungible members of a replica pool, deletion for a DaemonSet Pod has a narrower, more specific set of causes than deletion in a Deployment, where a Pod can be freely replaced by any other interchangeable replica — a DaemonSet Pod's removal is always tied either to the node it lives on, or to an explicit change in the DaemonSet's own configuration.

Understanding the distinct triggers for DaemonSet Pod deletion — and the difference between deletion the controller performs automatically versus deletion an operator performs manually — is what allows correct interpretation of a missing daemon Pod during troubleshooting, rather than assuming it always indicates a crash or failure.

Automatic Deletion by the Controller

Node Removal

When a node is removed from the cluster (decommissioned, deleted from a cloud provider, or otherwise deregistered from the API server), any DaemonSet Pods that were running on it are removed as part of that node's own object cleanup — there is no separate DaemonSet-specific deletion event, since the Pod's existence was always tied to that specific node object.

Node Becoming Ineligible

If a node that previously satisfied a DaemonSet's scheduling constraints later becomes ineligible — a new taint added without a matching toleration, a label removed that the nodeSelector depended on — the controller removes the now-orphaned Pod from that node during reconciliation, surfaced beforehand as numberMisscheduled in the DaemonSet's status while the removal is pending.

Rolling Update Propagation

During a RollingUpdate, the controller deletes each node's existing Pod (up to maxUnavailable at a time) before creating its replacement with the updated template, which is the primary mechanism by which template changes (a new image version, updated resource limits) actually reach running Pods across the fleet.

DaemonSet Deletion

Deleting the DaemonSet object itself cascades to delete every Pod it owns across every node, exactly like deleting a Deployment cascades to its ReplicaSets and Pods, unless --cascade=orphan is used to detach the Pods while leaving them running.

Manual Deletion

Forcing a Restart on a Specific Node

kubectl delete pod codartium-log-agent-x7k2p

Deleting an individual DaemonSet Pod directly causes the controller to recreate it on the same node almost immediately, since the node remains eligible and the controller's reconciliation loop notices the missing Pod. This is a common way to force a daemon to restart on one specific node — to pick up a ConfigMap change requiring a restart, or to clear a stuck process — without affecting the daemon on any other node.

OnDelete Update Strategy

When spec.updateStrategy.type: OnDelete is configured, manual Pod deletion is not just a convenience but the only mechanism by which an updated template is actually rolled out to a given node — the controller will not proactively delete and recreate Pods under this strategy, placing full control over the timing of each node's update in the operator's hands.

for pod in $(kubectl get pods -l app=codartium-log-agent -o name); do
  kubectl delete $pod
  sleep 30
done

A deliberate, paced manual rollout like this is typical when using OnDelete, allowing an operator to verify each node's update before proceeding to the next.

Deletion During Node Maintenance

Draining Does Not Normally Remove DaemonSet Pods

kubectl drain by default skips DaemonSet-managed Pods rather than evicting them, since a DaemonSet Pod cannot be "moved" to another node the way an ordinary Pod can — evicting it would simply leave that node without daemon coverage until the node either becomes ready again or is removed entirely. Operators intentionally wanting to remove DaemonSet Pods during a drain must pass --ignore-daemonsets explicitly, which does not evict them either but rather permits the drain to proceed despite their presence, leaving them running throughout.

kubectl drain node-worker-07 --ignore-daemonsets --delete-emptydir-data

Observing Deletion Events

kubectl get events --field-selector reason=SuccessfulDelete --sort-by=.lastTimestamp

Correlating deletion events with node status changes or DaemonSet spec updates is the standard way to confirm whether a missing Pod was removed as an expected part of a rollout or node lifecycle event, versus an unexpected disappearance warranting further investigation.

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-deletion-example
spec:
  updateStrategy:
    type: OnDelete
  selector:
    matchLabels:
      app: codartium-node-agent
  template:
    metadata:
      labels:
        app: codartium-node-agent
    spec:
      containers:
        - name: agent
          image: codartium/node-agent:latest