Rolling Deployment

Rolling deployment replaces service instances in batches, keeping the application available while old and new versions overlap, with pause and rollback controls.

delivery

Definition

Rolling deployment updates a service incrementally: the orchestrator replaces a configured number of instances at a time, waits for each batch to become healthy, and continues until every instance runs the new version.

Context and scope

It is the default strategy for stateless services on Kubernetes and similar orchestrators, where capacity and health checks can be automated.

Common misconceptions

Zero downtime is automatic — without readiness probes and enough surge capacity, users hit instances that are not ready.
All users see one version at a time — during the rollout, old and new versions serve traffic concurrently.
Rollback is instant — reverting a rollout takes as long as the original rollout and may not undo data migrations.

Anti-patterns

Rolling with maxUnavailable set to 100% so the whole fleet restarts at once
Skipping readiness probes and sending traffic to pods that are still starting
Shipping a breaking API or schema change without a compatibility window

Related concepts

Authoritative source

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment

Replace in batches

A rolling deployment keeps a pool of instances and replaces them in controlled batches. The orchestrator creates new instances with the updated image, waits for readiness checks, then terminates an equal number of old ones, repeating until the fleet converges. Two parameters usually govern the pace: how many extra instances may exist (surge) and how many may be unavailable. Halting and resuming the rollout lets operators inspect metrics between batches.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

When to use it

Use rolling deployment for stateless services with health checks and horizontal capacity, especially when infrastructure cost matters. Compared with blue-green, it avoids duplicating the entire environment; compared with recreate, it preserves availability. It is a deployment mechanism, not a release strategy: if you need user-level exposure control, pair it with feature flags.

Trade-offs

The main cost is version mixing. During the rollout, requests may hit both old and new code, so APIs, caches, and database schemas must stay compatible in both directions. Rollout duration grows with fleet size; large fleets need careful probe tuning to avoid stalls. Observability must distinguish versions, or a regression looks like random noise.

Example and misconceptions

A team runs twelve pods with maxSurge 1 and maxUnavailable 0. Kubernetes adds one pod, waits for readiness, removes one old pod, and repeats, so the rollout takes roughly twelve probe cycles with no capacity dip. A common misconception is that rolling deployment is inherently zero downtime; without readiness probes and spare capacity it drops requests. Another is that a rollback restores data. It only restores code. Related concepts: blue-green deployment and progressive delivery.