A rolling update replaces Pods gradually and waits for readiness

Study notes

• 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.

Deck map