Kubernetes DaemonSet Update Management

Kubernetes DaemonSet Update Management is the practice of safely rolling out changes to a DaemonSet's Pod template — new container images, updated resource limits, changed environment variables — across every node it covers, using the .spec.updateStrategy field to control the pace and mechanism of that rollout. Because a DaemonSet's Pods are spread across potentially every node in a cluster, an update strategy is not merely a convenience but a necessity: applying a change to all nodes simultaneously would briefly remove the daemon's function everywhere at once, which is rarely acceptable for infrastructure workloads like log collectors, network plugins, or security agents that other systems depend on continuously.

Update management for DaemonSets shares conceptual ground with Deployment rolling updates, but is scoped specifically to node-by-node progression rather than replica-count-based progression, and carries distinct operational stakes given how foundational many daemon workloads are to a cluster's basic functioning.

RollingUpdate Strategy

Default Behavior

spec.updateStrategy.type: RollingUpdate is the default and updates one node's Pod (or a bounded number, per maxUnavailable) at a time: the controller deletes the outdated Pod on a node and creates its replacement with the new template, waits for the replacement to become ready (respecting minReadySeconds), and then proceeds to the next node.

maxUnavailable

rollingUpdate.maxUnavailable bounds how many nodes may simultaneously lack a ready daemon Pod during the rollout, either as an absolute number or a percentage of total target nodes.

spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1

A conservative value like 1 is common for critical infrastructure daemons, ensuring the vast majority of the cluster retains coverage throughout the rollout, at the cost of a slower overall update across a large fleet of nodes.

maxSurge

In more recent Kubernetes versions, rollingUpdate.maxSurge permits a temporary extra Pod to be created on a node before its old Pod is removed, rather than strictly deleting first — useful for daemons where even a brief coverage gap on a given node is undesirable, at the cost of both Pods briefly coexisting and competing for that node's resources.

OnDelete Strategy

Manual Control Over Every Node

spec.updateStrategy.type: OnDelete disables all automatic propagation: the controller updates the DaemonSet's template in its own spec, but does not touch any existing Pods until an operator manually deletes them one at a time, at which point each deleted Pod's replacement uses the new template.

spec:
  updateStrategy:
    type: OnDelete

This is chosen for daemons where an unattended, automatic cluster-wide rollout is considered too risky — a CNI plugin update, for instance, where a bad rollout could disrupt Pod networking broadly, benefits from an operator verifying each node individually before proceeding to the next.

Monitoring Rollout Progress

Status Fields During a Rollout

.status.updatedNumberScheduled reports how many nodes currently have a Pod matching the latest template, which climbs toward .status.desiredNumberScheduled as a RollingUpdate progresses.

kubectl rollout status daemonset/codartium-log-agent
kubectl get daemonset codartium-log-agent -o jsonpath='{.status.updatedNumberScheduled}/{.status.desiredNumberScheduled}'

kubectl rollout status works for DaemonSets the same way it does for Deployments, blocking until the rollout completes or reporting its current progress.

Pausing a Rollout Mid-Progress

Unlike Deployments, DaemonSets do not have a native spec.paused field; halting an in-progress RollingUpdate requires either reverting the template change (which the controller will then roll out in reverse, restoring the previous version node by node) or switching updateStrategy.type to OnDelete to stop further automatic propagation while leaving already-updated nodes as they are.

Rollback

Using rollout undo

kubectl rollout undo daemonset/codartium-log-agent
kubectl rollout history daemonset/codartium-log-agent

DaemonSets maintain ControllerRevision history (bounded by spec.revisionHistoryLimit) exactly as Deployments do, allowing kubectl rollout undo to revert to a previous template version, which then propagates back out to every node using the same updateStrategy configured on the DaemonSet.

Operational Practices

Staged Rollouts Using Node Subsets

For particularly sensitive daemons, some teams stage rollouts manually by first updating the DaemonSet's nodeSelector to target only a small labeled subset of nodes, verifying the new version there, and only then widening the selector to the full node population — a workaround for the lack of a native canary mechanism specific to DaemonSets.

Coordinating Updates with Node Maintenance Windows

Because a RollingUpdate briefly removes and recreates a Pod on every node it touches, scheduling daemon updates outside of periods when the underlying infrastructure a daemon supports (logging, networking) is under unusually high load reduces the risk of an update-induced gap coinciding with peak demand.

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-update-example
spec:
  revisionHistoryLimit: 5
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
  minReadySeconds: 15
  selector:
    matchLabels:
      app: codartium-log-agent
  template:
    metadata:
      labels:
        app: codartium-log-agent
    spec:
      containers:
        - name: log-agent
          image: codartium/log-agent:1.5.0