maxSurge adds capacity first; maxUnavailable lets old Pods leave; readiness gates every step.

With 3 replicas, maxSurge: 1 and maxUnavailable: 1, v1 becomes v2 without ever dropping below 2 ready Pods.

0 Start

v1v1v1

old 3, new 0

1 Surge

v1v1v1v2

4 total: surge allows 1 extra

2 New is Ready

v1v1gonev2 ready

only now is an old Pod removed

3 Repeat

v1gonev2v2

old 1, new 2

4 Done

v2v2v2

old ReplicaSet scaled to 0

The speed and safety dial

Higher surge uses more resources briefly. Higher maxUnavailable gives up spare capacity. Both at 0 would deadlock the rollout.

No readiness probe, no safety

Without it a broken new Pod looks "ready" at once and healthy old Pods are replaced by it.

Observe and stop

kubectl rollout status, pause, undo. progressDeadlineSeconds marks a stuck rollout as failed.

A rolling update replaces Pods gradually and waits for readiness

Press the right arrow to step through a rolling update of a three-replica Deployment. At the start the old ReplicaSet has three v1 Pods. With maxSurge 1 the controller may exceed the desired count by one, so it creates a v2 Pod first. It then waits for that Pod to pass its readiness probe. Only when the new Pod is Ready does it remove an old Pod, and then repeats until all Pods are v2 and the old ReplicaSet is at zero.

The two settings are a trade-off, not defaults to ignore. maxSurge controls how much extra capacity you are willing to use briefly (faster, costs more). maxUnavailable controls how much capacity you may lose (faster, less margin). Percentages are allowed. Setting both to zero makes progress impossible because a new Pod could never be started without removing an old one first.

Readiness probes are what make this safe. The controller advances only when new Pods report Ready. If the new version is broken and never becomes Ready, the rollout stalls with the old Pods still serving, which is the desired failure mode; progressDeadlineSeconds eventually marks the rollout as failed so tools can alert.

Strategy alternatives: Recreate stops all old Pods first (downtime but no version mixing, useful for incompatible schema changes). For canary or blue-green with traffic weights, use Gateway API weighted routes or Argo Rollouts, covered in Deck 7.