CertGrid CertGrid
Hands-on Lab·Kubernetes and Cloud Native Associate

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

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.

Four replicas across three schedulable workers, so a rollout genuinely moves Pods between nodes rather than restarting them in place.
Server NameIP AddressOSRolesCPURAMHDD
CKA1001192.168.0.175Ubuntu 26.04 LTSControl Plane Node2 Core4 GB50 GB
CKA1001-NODE01192.168.0.176Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE02192.168.0.177Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE03192.168.0.178Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

This guide includes

Use this when a rollout is stuck and you need to know whether users are affected yet. This matters because a Deployment moves replicas between two ReplicaSets under a budget you never set, and that budget is what keeps the site serving while the rollout fails.

Before you start

  1. Four replicas and the budget nobody sets

  2. Ship a tag that does not exist

  3. What survived, and why

  4. Put it back

Official sources

← All KCNA guides