Kubernetes DaemonSet Rolling Update Management

Kubernetes DaemonSet Rolling Update Management is the detailed mechanics of the RollingUpdate strategy specifically — the default and most commonly used update mechanism for apps/v1 DaemonSets — covering exactly how the controller sequences Pod replacement across nodes, how maxUnavailable and maxSurge shape that sequencing, and how to reason about the tradeoffs between rollout speed and continuous coverage during the update. Where DaemonSet update management broadly covers the choice between RollingUpdate and OnDelete, rolling update management goes one level deeper into how RollingUpdate itself actually behaves node by node.

A rolling update's core guarantee is that at any point during the rollout, only a bounded subset of nodes are without a ready daemon Pod — the size of that bound, and how the controller selects which nodes to update first, are the central mechanics that determine how disruptive and how fast a given rollout will be.

The Rollout Algorithm

Node Selection Order

The DaemonSet controller does not guarantee any particular ordering (such as alphabetical by node name, or oldest-node-first) when selecting which nodes to update next; it processes eligible outdated nodes up to the maxUnavailable (and maxSurge, if configured) budget in whatever order its internal reconciliation happens to encounter them. Operators needing a specific, deliberate ordering (updating a canary subset of nodes before the rest) must implement that ordering externally, typically by temporarily narrowing the DaemonSet's nodeSelector.

The Unavailable Budget in Practice

With maxUnavailable: 1, the controller deletes exactly one outdated node's Pod, waits for its replacement to become ready (respecting minReadySeconds), and only then proceeds to the next node — Pod-by-Pod rather than batch-by-batch. With maxUnavailable: 3, up to three nodes may be mid-update simultaneously, trading a larger instantaneous coverage gap for faster overall rollout completion across a large node population.

spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 3
  minReadySeconds: 20

Percentage-Based maxUnavailable

maxUnavailable also accepts a percentage (e.g., "10%"), which is recalculated against the current desiredNumberScheduled count, making the effective unavailable-Pod budget scale automatically as the cluster's node count grows or shrinks, rather than requiring the absolute number to be manually retuned as the fleet changes size.

Readiness Gating Between Nodes

minReadySeconds

spec.minReadySeconds requires a newly created Pod to remain ready for at least this many seconds before it counts toward "successfully updated" and the controller proceeds to the next batch of nodes. This acts as a built-in soak period, catching a daemon version that starts healthy but crashes shortly after (a delayed initialization failure, a slow memory leak surfacing quickly under load) before the rollout has propagated too far.

Readiness Probes as the Underlying Signal

minReadySeconds is only as effective as the Pod's own readiness probe configuration — a daemon container without a meaningful readiness probe (or one that trivially always reports ready) provides the rolling update mechanism no real signal to gate on, effectively making the update proceed at full speed regardless of the daemon's actual functional health on each node.

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

Interrupting and Recovering from a Bad Rollout

Detecting a Stalled Rollout

A rollout stalls when a newly created Pod on some node fails to become ready — CrashLoopBackOff, a failing readiness probe — since the controller will not proceed past its maxUnavailable budget while that Pod remains unready, effectively pausing progress on all subsequent nodes.

kubectl rollout status daemonset/codartium-log-agent --timeout=120s
kubectl get pods -l app=codartium-log-agent --field-selector status.phase!=Running

Rolling Back

kubectl rollout undo daemonset/codartium-log-agent

Because a stalled forward rollout has already updated some nodes but not others, kubectl rollout undo triggers the same rolling mechanics in reverse — restoring the previous template and propagating it back out to the already-updated nodes, subject to the same maxUnavailable and minReadySeconds constraints as any other rollout.

Sizing Guidance

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-rolling-update-example
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: "10%"
  minReadySeconds: 30
  selector:
    matchLabels:
      app: codartium-log-agent
  template:
    metadata:
      labels:
        app: codartium-log-agent
    spec:
      containers:
        - name: log-agent
          image: codartium/log-agent:1.6.0
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 10