Deployment Rollback and Revision History

Application Deployment / Guide 19 of 44 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 15 min

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.

This guide includes

Use this when the version you need to get back to is not the previous one. This matters because rollout undo goes back exactly one step - naming a revision needs history, and history is only readable if somebody recorded a change-cause.

• making three revisions and annotating each so the history is readable at all
• inspecting a revision's Pod template with --revision=N before applying anything
• undoing to a named revision, and watching what the numbering does afterwards
• pausing a rollout, making several changes, and resuming so they ship as one

Before you start

• A cluster and kubectl.
• The session creates namespace ckad-undo and a Deployment api, moves it through three nginx versions annotating each, rolls back to the first, and then pauses it.

1. 1

   Three revisions, each one labelled

2. 2

   Look before you leap

3. 3

   Undo to a named revision, and watch the numbering

4. 4

   Pause, make several changes, resume

Official sources

• Rolling Back a Deployment
• Pausing and Resuming a rollout
• kubectl rollout