Kubernetes rolling update simulator

The Deployment starts with all replicas on version v1, and at time 0 its image is changed to v2. The simulator runs the rollout to the end and shows the pods at any moment (drag the slider or press Play), the number of pods in each state over time, and the events the deployment controller records, worded as kubectl describe deployment shows them.

Things to try:

• With 10 replicas, compare maxSurge 1, maxUnavailable 0 (never below full capacity) with maxSurge 0, maxUnavailable 1 (never above it).
• Set maxSurge to 100% and maxUnavailable to 0: a full set of new pods comes up beside the old ones, close to a blue-green switch.
• Choose Never becomes ready: the rollout stops, and the old version keeps serving.
• Set both to 0 to see the validation error, and try Recreate to see the gap with no pods.

A rolling update replaces the pods of an application with pods of a new version gradually, so that the application keeps serving traffic throughout. In Kubernetes it is the default way a Deployment changes version: edit the pod template (usually the image tag) and the deployment controller takes it from there.

A Deployment does not manage pods directly. It owns ReplicaSets, one per version of the pod template, and each ReplicaSet keeps a given number of identical pods running. A rollout creates a ReplicaSet for the new template and shifts replicas from the old one to the new one, while the ReplicaSet controller creates and deletes the actual pods. The old ReplicaSet is kept at zero replicas afterwards, which is what makes kubectl rollout undo possible.

Every time something changes, the deployment controller runs the same two checks, in pkg/controller/deployment/rolling.go:

1. Scale up the new ReplicaSet if the total of all ReplicaSets’ replicas is below replicas + maxSurge, by the difference, but never above replicas.
2. If it did not scale up, scale down old ReplicaSets, but only as far as availability allows. It first removes old pods that are not available anyway, then removes available old pods until the number of available pods across all ReplicaSets would drop below replicas − maxUnavailable. New pods that are not available yet are counted against the budget, so unhealthy new pods cannot cause old ones to be removed.

Each scale-up therefore waits for room under the surge limit, and each scale-down waits for new pods to become available. The Kubernetes documentation shows the events for a 3-replica Deployment with the defaults; the simulator, set to 3 replicas, produces the same sequence:

maxSurge limits how many pods may exist above the desired count; maxUnavailable limits how many of the desired pods may be unavailable. Each is a number or a percentage of replicas, and both default to 25%. A percentage is rounded up for maxSurge and down for maxUnavailable, so small Deployments get at least one extra pod and never lose capacity by rounding. Both cannot be zero, since the rollout could then never start; if rounding makes both zero, the controller uses maxUnavailable 1. For the defaults:

A rolling update is only as safe as the signal that a new pod works. A pod counts as ready when its containers are running and its readiness probe passes; only ready pods receive traffic from Services. It counts as available once it has been ready for minReadySeconds (0 by default). The controller scales the old version down only as new pods become available, so a readiness probe that checks real dependencies, and a minReadySeconds long enough to catch pods that crash soon after starting, are what stop a bad version from replacing a good one.

Without a readiness probe, a pod is ready as soon as its containers start, before the application may be listening, and a rollout can replace every pod with a broken one.

If new pods never become available, because the image does not exist, the container crashes, or the readiness probe never passes, the rollout stops: the controller has already scaled the old ReplicaSet down by maxUnavailable and will go no further. The application keeps running on the remaining old pods. After progressDeadlineSeconds (600 by default) without progress, the Deployment’s Progressing condition becomes false with reason ProgressDeadlineExceeded, and kubectl rollout status exits with an error. Kubernetes does not roll back automatically; CI pipelines usually watch for that status and run kubectl rollout undo, which scales the previous ReplicaSet back up with the same rolling rules.

A zero-downtime rollout also needs old pods to stop gracefully. When a pod is deleted, Kubernetes marks it terminating, removes it from Service endpoints, runs any preStop hook, and sends SIGTERM to its containers. It waits up to terminationGracePeriodSeconds (30 by default) and then sends SIGKILL. Endpoint removal happens in parallel with SIGTERM, so for a short time load balancers and kube-proxy may still send new requests to a pod that is shutting down. Applications should keep serving for a few seconds after SIGTERM (a short preStop sleep is a common way), finish in-flight requests, and then exit.

A PodDisruptionBudget limits voluntary evictions, such as node drains, rather than rollouts; the Deployment’s own maxUnavailable governs rollouts.

The Recreate strategy scales the old ReplicaSet to zero, waits for its pods to terminate, and only then creates the new pods. There is downtime, but two versions never run at the same time, which matters when they cannot share a database schema or a lock.

A rolling update sends traffic to old and new pods at once, in proportion to their numbers, and cannot pause on its own to check metrics. Teams that need more control use blue-green deployments (bring up a full new set, then switch the Service selector) or canary releases (send a small share of traffic to the new version, watch error rates, then increase). Argo Rollouts and Flagger automate both on Kubernetes, with automatic rollback on failing metrics. kubectl rollout pause and resume give a manual version of the same idea.

Platform and SRE interviews ask how Kubernetes rolls out a new version without downtime. A good answer covers Deployments and ReplicaSets, the meaning and rounding of maxSurge and maxUnavailable, readiness probes as the gate for each step, graceful termination with SIGTERM and the endpoint removal race, what happens when the new version is broken, and how to roll back. Follow-ups often ask when you would choose Recreate, blue-green or canary instead, and how database migrations fit in: make schema changes backward compatible so that old and new versions can run side by side during the rollout.