Deployment Rollback and Revision History
`kubectl rollout undo` goes back one step, which is rarely the step you want. This builds three labelled revisions, inspects one without applying it, rolls back to a named revision, and shows the renumbering that follows - the detail that makes people think the rollback did not work. It finishes with pause and resume, which turn three edits into one rollout.
Application Deployment Guide 19 of 44 Intermediate
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 15 min
- Reviewed23 August 2026
Written against the versions above. `CHANGE-CAUSE` comes from the `kubernetes.io/change-cause` annotation and nothing sets it for you. Setting it after each change, as here, is what makes `rollout history` worth reading; without it every row says `<none>` and the history tells you only how many times something changed.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A cluster and kubectl.
- The session creates namespace
ckad-undoand a Deploymentapi, moves it through three nginx versions annotating each, rolls back to the first, and then pauses it.
-
Three revisions, each one labelled
-
Look before you leap
-
Undo to a named revision, and watch the numbering
-
Pause, make several changes, resume