In this article
Rollout undo restores an earlier Pod template, but a mutable tag in that template may now point to another image. A Deployment rollback can therefore start new bytes under an old name. Inspect digest and actual imageID, not only revision number.
Rollout undo restores an earlier Pod template, but a mutable tag in that template may now point to another image. A Deployment rollback can therefore start new bytes under an old name. Inspect digest and actual imageID, not only revision number.
Reconstruct revision history
Preserve the Deployment, older ReplicaSet and image references for each release. Obtain imageIDs from running containers. A revision records template changes; a registry tag is an external reference with its own lifecycle. If both revisions use one mutable tag, their difference may not define image contents. Retain old ReplicaSets during investigation because revision retention affects standard rollback availability. An archived name without a verified digest is insufficient for exact restoration.
Include imagePullPolicy
Node cache and pull policy affect tag-based retrieval. Nodes can therefore run different actual versions when publishing changed a tag and policy permits cached content. A digest identifies content, while registry access and object availability remain separate requirements. Always is not a universal rollback mechanism: resolving a mutable tag again may select the new image. Check effective policy established when the object was created.
Examine reuse of stable
Suppose releases A and B are both published as worker:stable. After publication, the registry tag points to B. Rollout undo restores a template that still contains worker:stable, which does not express a requirement to run A. A correct release artifact should connect revision A to its verified digest. This illustrates identity rather than providing a real repository or asserting unverified registry behavior.
| Layer | What it records |
|---|---|
| Deployment revision | Pod template contents |
| Image tag | Mutable registry reference |
| Image digest | Content identity |
| Running imageID | Actual created instance |
Prepare a verifiable rollback
Pin the verified digest in the release manifest and retain the previous complete manifest. Check whether registry cleanup preserves old images. Record configuration and other artifacts separately: restoring a container does not automatically restore ConfigMaps, Secrets or external data. Verify their compatibility before rollout. Digest pinning also needs managed security updates; publisher tag changes do not automatically patch pinned content.
Confirm the actual restoration
Perform rollout and rollback in a test environment, comparing imageID, launch options and a control result. Preserve revision-to-digest mapping and a usable retrieval path. If some Pods remain on the new version, inspect rollout state and instances separately. A successful command response does not prove byte identity across every node. Repeat after registry-retention changes so an archived manifest does not become a reference to unavailable content. This turns rollback from a remembered command into a tested relationship between deployment history and retrievable artifacts.
Related operational reading: software stack reproducibility; model update canary.