What happens when a bad version breaks a Kubernetes rolling update?

A well-configured rolling update keeps broken Pods away from your users. Here's our starting point: a Deployment called web, with one v1 ReplicaSet owning three Ready Pods. Service web routes traffic to all three, so everything is healthy before we change anything.

maxSurge one allows a single extra Pod. maxUnavailable zero means we never drop below three Ready Pods. The readinessProbe hits slash healthz on port 8080. Then set image pushes web v2, whose healthz returns 500.

The controller creates one v2 Pod through a new ReplicaSet. The kubelet probes /healthz and gets an HTTP 500, so it reports Ready false, then keeps probing. The container is running, but it never becomes Ready. Because of that, no v1 Pod gets deleted.

The Service routes only to Ready Pods, so all traffic lands on the three v1 Pods. The v2 Pod gets nothing. And since maxUnavailable is zero, Kubernetes can't delete any v1 Pod. Users stay on v1. A rollout retires old Pods only after new ones prove Ready.

If maxUnavailable were one instead of zero, what happens to the v1 Pods when the broken rollout starts?

One v1 Pod is terminated, leaving two serving. maxUnavailable one lets the controller remove an old Pod without waiting for any new Pod to become Ready. So capacity drops to two v1 Pods, the broken v2 Pods still never pass readiness, and the rollout stalls anyway, just with less headroom.

Rollout status stalls at one new replica and eventually errors with the progress deadline exceeded. The three original Pods are still Running and Ready. The new Pod, ending 8b2d4f, shows zero of one ready. Kubernetes flags the failure, but it doesn't revert anything.

When you run rollout undo, the Deployment sets its Pod template back to the previous revision. That matches the existing v1 ReplicaSet, which already has three Pods, so nothing restarts. Then the v2 ReplicaSet scales to zero, deleting the broken Pod. The v1 Pods just keep serving.

This was harmless because the probe caught the bug and maxUnavailable 0 kept capacity. But it only works if the probe detects the problem, and someone, you or your CI, must trigger the rollback.

Old Pods stay until new Pods prove Ready. That's why the stuck state is safe: three Ready v1 Pods serving, one unready v2 Pod waiting. After every deploy, watch kubectl rollout status, and roll back yourself.