Kubernetes DaemonSet Revision Management

Kubernetes DaemonSet Revision Management is the tracking and use of ControllerRevision objects that Kubernetes automatically maintains for a DaemonSet, recording a history of its Pod template over time so that past versions can be inspected, compared, and rolled back to. Every time a DaemonSet's template changes in a way that would affect the Pods it creates, the DaemonSet controller records the new template as a distinct revision, building up a sequential history analogous to the revision tracking Deployments and StatefulSets maintain through the same underlying ControllerRevision mechanism.

Revision management gives operators a durable, queryable record of "what did this DaemonSet's template look like at each point in time," which is the foundation both for kubectl rollout undo and for auditing when and how a daemon's configuration has changed historically.

How Revisions Are Created

Template Hash Comparison

Each time a DaemonSet's spec.template is modified, the controller computes a hash of the new template and compares it against the most recent stored revision. If the hash differs, a new ControllerRevision object is created recording the full template at that point; if the hash matches an existing revision exactly (for instance, a change was applied and then reverted back to the prior state before ever being rolled out), no new revision is created.

Association with Pods

Each Pod created by the DaemonSet carries a label (controller-revision-hash) identifying which revision it was created from, which is how the controller knows, at any point during a RollingUpdate, which nodes are running the current template versus an older one.

kubectl get pods -l app=codartium-log-agent -L controller-revision-hash

Bounding Revision History

revisionHistoryLimit

spec.revisionHistoryLimit (default 10) caps how many old ControllerRevision objects are retained once they are no longer referenced by any currently running Pod. Once the limit is exceeded, the oldest excess revisions are garbage collected automatically, similar to how successfulJobsHistoryLimit bounds Job history for CronJobs.

spec:
  revisionHistoryLimit: 5

Balancing Auditability Against Object Growth

A larger revisionHistoryLimit supports rolling back further into the past and provides a longer audit trail of template changes, at the modest cost of additional ControllerRevision objects persisted in etcd; for most DaemonSets the default is more than adequate, but daemons undergoing frequent, rapid template iteration (during active development of a new node agent) sometimes raise this limit temporarily to preserve a longer change history during that period.

Using Revision History

Listing Revision History

kubectl rollout history daemonset/codartium-log-agent

This surfaces each retained revision's number and, if annotated at apply time via kubectl annotate or a CI pipeline's --record-equivalent practice, a change-cause message describing what that revision changed.

Inspecting a Specific Revision

kubectl rollout history daemonset/codartium-log-agent --revision=3

Viewing a specific revision's full template is useful for confirming exactly what a past version looked like before deciding whether rolling back to it is appropriate, rather than relying on memory or external change logs alone.

Rolling Back to a Specific Revision

kubectl rollout undo daemonset/codartium-log-agent --to-revision=3

Specifying --to-revision targets a particular historical revision rather than simply the immediately preceding one, which is useful when a bad rollout was not caught immediately and the last-known-good version is more than one revision back.

Revision Management and Update Strategy Interaction

RollingUpdate Uses Revisions to Track Progress

Under RollingUpdate, the controller's status fields (updatedNumberScheduled) are computed by counting Pods whose controller-revision-hash label matches the current revision, making revision tracking not just a historical record but an active input to how the controller measures rollout completion in real time.

OnDelete Still Records Revisions

Even under OnDelete, where propagation is entirely manual, the controller still creates a new revision the moment the template is changed — revision history tracking is independent of which update strategy is configured, only the propagation mechanism to actual running Pods differs.

Example

kubectl set image daemonset/codartium-log-agent log-agent=codartium/log-agent:1.6.0
kubectl rollout history daemonset/codartium-log-agent
kubectl rollout history daemonset/codartium-log-agent --revision=2
kubectl rollout undo daemonset/codartium-log-agent --to-revision=1

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-revision-example
spec:
  revisionHistoryLimit: 8
  updateStrategy:
    type: RollingUpdate
  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