Kubernetes DaemonSet Update Control

Kubernetes DaemonSet Update Control is the mechanism through which a DaemonSet propagates Pod template changes to the Pods it has already placed on each node, governed by spec.updateStrategy and scoped per node rather than by an aggregate replica count, since a DaemonSet has no replicas field to reason about surge or unavailability against in the first place.

RollingUpdate Strategy

Node-by-Node Replacement

The default RollingUpdate strategy replaces the Pod on each eligible node with one running the updated template, deleting the old Pod on a node and waiting for its replacement to become ready before moving to additional nodes, bounded by maxUnavailable.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: update-control-example
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1

maxUnavailable as a Percentage or Absolute Count

maxUnavailable can be expressed as a fixed number or as a percentage of the total number of nodes the DaemonSet targets, letting large clusters update proportionally rather than requiring a fixed count that would be too slow at scale or too aggressive at small scale.

spec:
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 10%

No Surge Concept

Why maxSurge Does Not Apply the Same Way

Because exactly one Pod belongs on each eligible node, there is no equivalent of a Deployment's maxSurge in the traditional sense for most DaemonSet versions; a newer optional maxSurge setting, where supported, instead permits briefly running the old and new Pod side by side on the same node during transition, rather than creating an entirely separate extra Pod elsewhere.

spec:
  updateStrategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

OnDelete Strategy

Fully Manual, Per-Node Control

The OnDelete strategy disables automatic propagation entirely; the controller only creates a Pod using the updated template on a given node once that node's existing Pod is deleted, giving an operator explicit control over exactly when each node transitions, useful for staged rollouts across a fleet with varying risk tolerance per node group.

spec:
  updateStrategy:
    type: OnDelete

kubectl delete pod update-control-example-node1

Detecting Update Completion

Status Fields for Tracking Progress

The DaemonSet's status exposes updatedNumberScheduled and numberAvailable, letting an operator determine how many nodes have received the new template and how many are simultaneously reporting availability, distinguishing a rollout that is progressing normally from one that has stalled partway through.

kubectl rollout status daemonset/update-control-example

Waiting for daemon set "update-control-example" rollout to finish: 3 out of 5 new pods have been updated...

New Nodes During an In-Progress Update

Immediate Placement With the Current Template

A node that joins the cluster while a rolling update is in progress receives a Pod using whichever template is currently active on the controller, the new one, since the controller always creates fresh Pods from its current spec regardless of where other nodes stand in the update sequence.

Update Control Diagram

This per-node, count-agnostic approach is what makes DaemonSet updates scale naturally with cluster size without requiring any manual adjustment of pacing parameters as nodes are added or removed over time.