MidKubernetes

How does a rolling update work in Kubernetes, and how do you do zero-downtime deploys and rollbacks?

What they are really testing: Whether you understand maxSurge/maxUnavailable, the role of readiness probes in safe rollouts, and that rollback uses ReplicaSet history. Also whether you know canary/blue-green.

A real interview question

How does a rolling update work in Kubernetes, and how do you do zero-downtime deploys and rollbacks?

What most people say

drag me

Kubernetes replaces the old pods with new ones when you update the image.

It describes the what but not the how. Without readiness gating and maxSurge/maxUnavailable, the rollout is not actually safe, and the answer says nothing about rollback or canary.

The follow-ups they ask next

  • Why are readiness probes essential for a safe rolling update?

    Without them, Kubernetes treats a pod as ready the moment it starts and sends traffic before the app can serve, causing errors during every deploy. Readiness gates traffic until the pod is actually serving and stalls a bad rollout.

  • How does kubectl rollout undo work so quickly?

    Each revision is a separate ReplicaSet kept in history. Rollback scales the previous ReplicaSet back up and the new one down, no rebuild needed, so it is near-instant.

What the interviewer is listening for

  • Explains maxSurge/maxUnavailable
  • Knows readiness gating enables zero-downtime
  • Knows rollback uses ReplicaSet history; mentions canary/blue-green

What sinks the answer

  • Only "it replaces the pods"
  • No readiness probe in the rollout
  • Unaware of rollback or progressive delivery

If you genuinely do not know

Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.

A Deployment [creates a new ReplicaSet and shifts pods gradually, controlled by maxSurge/maxUnavailable]. Zero-downtime comes from [readiness probes: new pods take traffic only when ready, old pods stay until then]. Rollback is fast because [each revision is a kept ReplicaSet, undo scales the old one back up]. For risk, [canary or blue-green via Argo Rollouts / a mesh].

Keep going with kubernetes

All 336 cloud engineer questions

Knowing the answer is not the same as recalling it under pressure

Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.

Start free