Kubernetes Rolling Updates: The Default Zero-Downtime Strategy

When you update a Deployment, the Deployment controller creates a new ReplicaSet with the updated pod template and begins scaling it up while scaling down the old ReplicaSet. The `maxSurge` field controls how many extra pods can exist during the update (above the desired count), and `maxUnavailable` controls how many pods can be unavailable. With `maxSurge: 1` and `maxUnavailable: 0`, Kubernetes creates one new pod, waits for it to pass readiness checks, then terminates one old pod. This guarantees that the desired number of pods is always running and ready.

Rolling updates depend on readiness probes to determine when new pods are ready for traffic. Without readiness probes, Kubernetes considers pods ready as soon as the container starts, which can route traffic to pods that are still booting. Define an HTTP readiness probe that returns 200 only when the application is fully initialized. On the shutdown side, handle SIGTERM in your application to stop accepting new requests, finish in-flight requests, close database connections, and exit cleanly. Set `terminationGracePeriodSeconds` long enough for your application to drain: 30-60 seconds is typical for web services.

Kubernetes maintains a history of ReplicaSets for each Deployment, controlled by `revisionHistoryLimit` (default 10). To rollback, run `kubectl rollout undo deployment/my-app` to revert to the previous revision, or `kubectl rollout undo deployment/my-app --to-revision=3` for a specific version. Use `kubectl rollout status deployment/my-app` to watch a rollout in progress and detect failures. Set `progressDeadlineSeconds` (default 600) to have Kubernetes mark a deployment as failed if it has not completed within that time, triggering alerts.

For latency-sensitive services, use `maxUnavailable: 0` and `maxSurge: 25%` to ensure capacity never drops below desired. For cost-sensitive environments where you cannot afford extra pods, use `maxUnavailable: 25%` and `maxSurge: 0` to stay within the current pod count, accepting brief capacity reduction. For fast deployments of non-critical services, set `maxSurge: 50%` and `maxUnavailable: 50%` to replace half the pods at once. The `minReadySeconds` field adds a delay after a pod is ready before Kubernetes considers it available, useful for catching fast-crashing bugs that pass initial readiness checks.