Deployment Rollouts and Rollbacks

Workloads / Guide 26 of 103 / Beginner

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

ReplicaSet hashes, pod name suffixes, addresses and timings are generated per run. The manifest and the command sequence are what to copy.

This guide includes

Use this when a workload has to be updated in place and stay recoverable if the update is bad. This matters because a Deployment keeps each revision as its own ReplicaSet, which is what makes an undo cheap rather than a redeploy.

• writing a Deployment rather than a bare Pod, which does not come back
• following the ownership chain from one object you wrote down to three kinds
• rolling an image forward and watching a new template hash produce a new ReplicaSet
• reading rollout history, inspecting a single revision, and rolling back with rollout undo
• scaling to watch the ReplicaSet follow, then breaking it with a tag that does not exist and recovering

Before you start

• A cluster with at least one worker, and kubectl configured.
• The Pods guide, or equivalent familiarity: a Deployment manages Pods, so the Pod is still the thing that runs.
• Nothing else in default using the label app=web. Everything here is removed at the end.

1. 1

   Write a Deployment, not a Pod

2. 2

   Follow the ownership chain

3. 3

   Roll the image forward

4. 4

   Read the revision history

5. 5

   Roll back

6. 6

   Scale, and watch the ReplicaSet follow

7. 7

   Break it on purpose

8. 8

   Recover

9. 9

   Clean up

Official sources

• Deployments
• ReplicaSet
• Configure liveness, readiness and startup probes
• kubectl rollout