Changing Tires on a Moving Car
A Rolling Update is the simplest deployment strategy and the default behavior in Kubernetes. The core idea is to replace old instances of your application with new ones gradually, one at a time (or in small batches), while the rest of the fleet continues serving traffic. At no point is the entire application offline.
Think of it like rotating the tires on a car while it is still moving slowly. You swap one tire at a time, and the car keeps rolling forward.
How It Works in Practice
Imagine you have 10 pods running Version 1 (v1) of your application in Kubernetes. To perform a rolling update to Version 2 (v2):
- Kubernetes takes one v1 pod out of the load balancer rotation and terminates it.
- It starts a new v2 pod in its place.
- Critical step: Kubernetes waits for the v2 pod's Readiness Probe to return healthy before it considers the pod ready to serve traffic. Only then does it proceed to the next pod.
- This process repeats until all 10 pods are running v2.
In a Kubernetes Deployment, two parameters control the pace of this process: maxUnavailable and maxSurge. Setting maxUnavailable: 1 means you always have at least 9 pods serving traffic. Setting maxSurge: 1 means Kubernetes can temporarily run 11 pods to speed up the transition — it starts a new v2 pod before terminating the old v1 pod.
Pros and Cons
Pros:
- No downtime. Traffic is always being served by some combination of v1 and v2 pods.
- No extra infrastructure required beyond a small surge capacity.
- Built-in to Kubernetes with no additional tooling needed.
Cons:
- During the rollout, users may hit either v1 or v2 depending on which pod they land on. This creates an inconsistent user experience — a problem if v1 and v2 have different API contracts or UI behavior.
- Rollbacks are slow. To revert, Kubernetes must perform the same gradual replacement in reverse.
- If v2 has a bug that only manifests under load, it may not be caught until many pods have already been replaced.
Interviewers often ask: "What happens if a rolling update gets stuck halfway?" The answer involves Kubernetes' progressDeadlineSeconds field. If the rollout does not make progress within that deadline (default: 600 seconds), Kubernetes marks the Deployment as failed. You can then run kubectl rollout undo deployment/<name> to revert. A common cause of a stuck rollout is a Readiness Probe that never passes on the new version — Kubernetes will not proceed past that pod, effectively halting the rollout without crashing the existing pods.