Deployment Rollout Health and Availability
A Deployment does not replace Pods; it manages two ReplicaSets and moves replicas between them under a budget. Push a broken image and that budget is what stands between a bad deploy and an outage - the rollout stalls, most of the old Pods keep serving, and nothing reports an error unless you go looking. This shows the stall, what stayed up during it, and the one command that undoes it.
Kubernetes Fundamentals Guide 9 of 46 Beginner
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- Cluster4 nodes
- TimeAbout 15 min
- Reviewed23 August 2026
Written against the versions above. `maxSurge` and `maxUnavailable` both default to 25%, which on four replicas rounds to one Pod each way. On smaller Deployments the rounding matters: at two replicas, 25% of 2 rounds `maxUnavailable` down to 0, so a stuck rollout keeps both old Pods serving.
| 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 broken image is a tag that does not exist, so the failure needs no special setup - only a registry the nodes can reach.
- The session creates namespace
kx-roll, a Deploymentwebwith four replicas ofnginx:alpine, and a Service in front of it.
-
Four replicas and the budget nobody sets
-
Ship a tag that does not exist
-
What survived, and why
-
Put it back