10.16 Kubernetes DaemonSet Update Control
Kubernetes DaemonSet Update Control ensures consistent node coverage by managing how updates propagate across nodes in a cluster.
Kubernetes DaemonSet Update Control is the configuration governing how a DaemonSet propagates changes to its Pod template across the potentially large number of nodes it manages, balancing the goal of eventually running an updated configuration everywhere against the operational risk of updating too many nodes simultaneously.
updateStrategy Field
RollingUpdate as the Default
The RollingUpdate strategy automatically replaces each node's existing DaemonSet Pod with one reflecting the current template, proceeding across the set of managed nodes according to the configured concurrency limit, rather than requiring any manual action to trigger each individual node's update.
OnDelete Strategy
The OnDelete strategy withholds automatic propagation entirely, updating a given node's Pod only once that specific Pod is manually deleted, which grants complete control over the timing and sequencing of updates at the cost of requiring explicit manual action for every single node.
Controlling Update Concurrency
maxUnavailable Field
The maxUnavailable field, expressible as either an absolute number or a percentage of total eligible nodes, bounds how many nodes can simultaneously have their DaemonSet Pod in an unavailable, mid-update state, directly controlling how much of the cluster's node-level daemon coverage is allowed to be temporarily absent during a rollout.
Sequencing Node Updates Within the Limit
As nodes complete their update and their new Pod becomes ready, the controller proceeds to select additional nodes for update, always respecting the maxUnavailable ceiling, meaning the overall update duration scales with the total number of nodes divided by this concurrency limit, rather than proceeding across all nodes at once.
minReadySeconds for Update Stability
Confirming Stability Before Continuing
The minReadySeconds field requires a newly updated Pod to remain ready for a specified duration before the controller considers that node's update complete and proceeds to select further nodes, guarding against a scenario where a briefly ready Pod masks an underlying instability that would only become apparent slightly later.
Interaction With Node-Specific Failures
Isolated Failure Impact
Because DaemonSet updates proceed independently per node, a failure updating one specific node, whether due to a resource constraint or an incompatibility unique to that node's hardware or configuration, does not directly block the update from proceeding on other, unaffected nodes, unlike ordinal-dependent update logic used by StatefulSets.
Diagnostic Isolation of Problematic Nodes
This per-node independence also aids diagnosis, since a DaemonSet update that succeeds broadly but stalls or fails on a small subset of nodes points clearly toward node-specific conditions, such as an incompatible kernel version or a local resource constraint, rather than a systemic problem with the updated Pod template itself.
Update History Tracking
ControllerRevision Objects
DaemonSets track their update history using ControllerRevision objects, each capturing a snapshot of the Pod template at a given point, analogous in purpose to the ReplicaSet-based revision tracking used by Deployments, though implemented through this distinct underlying object type specific to DaemonSets and StatefulSets.
Revision History Limit
The revisionHistoryLimit field bounds how many of these historical ControllerRevision objects are retained, balancing the ability to reference or roll back to a prior configuration against the ongoing accumulation of historical objects that serve no purpose once sufficiently outdated.
Rollback Considerations
Manual Reapplication as the Rollback Path
Unlike Deployments, DaemonSets do not expose a dedicated rollback command that automatically reverts to a previous revision; reverting an unwanted DaemonSet update generally requires manually reapplying a previous template configuration, which then triggers the same rolling update mechanics used for any other template change, now directed toward restoring the earlier state.