Changing Tires on a Moving Car
How do you upgrade your application from v1 to v2 without any downtime? Killing all v1 Pods and then starting v2 Pods would leave a gap where no Pods are available. The default Deployment strategy — RollingUpdate — avoids this by replacing Pods incrementally.
You control the rollout speed with two parameters in spec.strategy.rollingUpdate:
maxUnavailable: The maximum number (or percentage) of Pods that can be below the desired count during an update. Setting this to 0 means Kubernetes will never terminate an old Pod until a new one is confirmed healthy. This guarantees full capacity but slows the rollout.
maxSurge: The maximum number (or percentage) of extra Pods that can exist above the desired count during an update. Setting this to 1 means Kubernetes can create one new v2 Pod before terminating a v1 Pod. Higher values speed up the rollout at the cost of temporarily using more resources.
With 10 replicas, a maxSurge of 2 and maxUnavailable of 1: Kubernetes creates 2 new v2 Pods (total: 12), waits for them to pass readiness probes, then terminates 2 old v1 Pods (total: 10), and repeats until all 10 are v2 — never dropping below 9 available Pods at any point.
The alternative strategy is Recreate: kill all old Pods first, then start new ones. This causes downtime but is useful when two versions of your app cannot safely run simultaneously (e.g., they would conflict over a database schema migration).