Hands-on Lab·Certified Kubernetes Administrator
Deployment Rollouts and Rollbacks
Write a Deployment, follow the ownership chain down to the Pods, roll an image forward and back, read what a revision records, and push a broken image to watch the rollout stall while the old ReplicaSet keeps serving every request.
Workloads Guide 26 of 103 Beginner
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 35 min
- Reviewed21 August 2026
Written against the versions above. ReplicaSet hashes, pod name suffixes, addresses and timings are generated per run. The manifest and the command sequence are what to copy.
| 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 with at least one worker, and
kubectlconfigured. - The Pods guide, or equivalent familiarity: a Deployment manages Pods, so the Pod is still the thing that runs.
- Nothing else in
defaultusing the labelapp=web. Everything here is removed at the end.
-
Write a Deployment, not a Pod
-
Follow the ownership chain
-
Roll the image forward
-
Read the revision history
-
Roll back
-
Scale, and watch the ReplicaSet follow
-
Break it on purpose
-
Recover
-
Clean up