Kubernetes rolling updates replace pods gradually
Two windows, maxSurge and maxUnavailable, bound how many extra or missing pods a rollout may have, so a release can proceed under capacity control. Replace a few at a time A rolling update does not swap the workload in one cut; it brings up new pods and removes old ones gradually, respecting readiness the whole way. The controller waits for a new pod to become ready before it considers the update moving, so a pod that never becomes ready stalls the rollout rather than silently serving traffic. That is the safety property: at no point does the fleet jump from the old version to the new one with nothing in between. Because readiness gates the transition, you can catch a broken image at the first new pod and stop the rollout with far less blast radius than a full swap. ...