Rolling Deployments
A rolling deployment updates a fleet of running instances incrementally instead of all at once. Instead of taking every server or pod down and bringing up the new version simultaneously, the orchestrator (Kubernetes, an ASG-based tool, Nomad, or a custom script) takes a small slice of the fleet out of rotation, replaces it with the new version, waits for it to pass health checks, and then repeats the process for the next slice. Because a portion of the fleet is always serving traffic on either the old or new version, users experience no downtime window, and the blast radius of a bad release is naturally limited to whatever fraction of the fleet has been updated when a problem is detected.
Cricket analogy: Like a team rotating bowlers through a spell one at a time rather than resting the entire attack simultaneously — while one bowler warms up and swaps in, the others keep bowling, so a bad over from the new bowler only affects that one over.
How the Rollout Progresses
Most implementations expose two tunable knobs: maxUnavailable (how many instances can be offline at once) and maxSurge (how many extra instances can be created above the desired count while the rollout is in progress). A conservative rollout sets maxUnavailable to zero and relies on surge capacity so capacity never drops below the steady-state level; an aggressive rollout allows a larger maxUnavailable to finish faster at the cost of momentarily reduced capacity. The orchestrator only proceeds to the next batch once the previous batch's instances report healthy via readiness probes, which is what makes the strategy self-pausing when something is wrong.
Cricket analogy: Like a captain deciding how many fielders can be off the field at once — conservative never drops below a full unit, bringing a substitute first, while aggressive pulls two off at once for speed at the cost of a weaker field, waiting for fitness before the next swap.
Rollback Behavior
If new instances start failing health checks partway through, the deployment controller stops advancing and, depending on configuration, either holds at the current mixed state or automatically reverts by rolling the old version back over the batches that were already updated. Because both versions of the application are live simultaneously during the rollout, rolling deployments only work safely when the new version is backward compatible with the old version's data formats, API contracts, and database schema for the duration of the transition.
Cricket analogy: Like a team testing a new batting order and, if the first overs go badly, the captain reverts to the old sequence for the rest; because the new opener and old middle order bat together, the opener's running calls must stay compatible with the team's calling system.
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout-service
spec:
replicas: 12
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 2
minReadySeconds: 15
template:
spec:
containers:
- name: checkout-service
image: registry.example.com/checkout-service:1.9.0
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5Think of a rolling deployment like repaving a highway lane by lane while traffic keeps moving — one lane closes, gets resurfaced, reopens, and only then does the next lane close. The road (service) is never fully shut, but drivers briefly experience reduced capacity in whichever lane is under work.
A common mistake is setting readiness probes too permissive (e.g., only checking that the process is listening on a port) so the orchestrator marks a broken instance healthy and keeps rolling forward, propagating the bad version through the entire fleet before anyone notices.
Rolling vs. Blue-Green vs. Canary
Rolling deployments trade the instant, all-or-nothing cutover of blue-green for lower infrastructure cost — you never need two full parallel environments — but you also lose the ability to test the new version against a controlled slice of real traffic the way a canary release does. In practice many teams layer strategies: a canary phase validates the new version on a small percentage of traffic first, and once it passes, a rolling update finishes deploying it across the rest of the fleet.
Cricket analogy: Like a gradual net-to-match transition for a young player instead of an instant World Cup debut — cheaper on morale than fielding two full XIs, but you lose a warm-up match's controlled trial; many setups do both, blooding the player in a low-stakes match, then expanding their role.
- Rolling deployments replace instances in small batches, keeping the service available throughout the release.
- maxUnavailable and maxSurge control how aggressively the rollout proceeds and how much spare capacity is used.
- Progress halts automatically when new instances fail readiness checks, limiting blast radius.
- The strategy requires backward-compatible APIs and data formats since old and new versions run concurrently.
- It costs less infrastructure than blue-green but offers less controlled traffic isolation than canary releases.
- minReadySeconds and health probe accuracy directly determine how safely and how fast a rollout can proceed.
Practice what you learned
1. What does maxUnavailable control in a rolling deployment?
2. Why must the new and old application versions be backward compatible during a rolling deployment?
3. What typically happens if new instances fail their readiness probes mid-rollout?
4. Compared to blue-green deployment, what is a key advantage of rolling deployments?
5. What does maxSurge allow during a rolling update?
Was this page helpful?
You May Also Like
Blue-Green Deployments
Understand the blue-green deployment pattern for near-instant, low-risk releases and rollbacks by running two full environments and switching traffic between them.
Canary Releases
Learn how canary releases gradually expose a small percentage of real traffic to a new version, using metrics to decide whether to expand or abort the rollout.
Feature Flags and Progressive Delivery
Feature flags decouple deploying code from releasing it to users, enabling progressive delivery techniques like percentage rollouts and targeted exposure controlled at runtime.
Anatomy of a CI/CD Pipeline
A CI/CD pipeline is a series of automated stages — source, build, test, package, deploy — that a code change flows through, each acting as a quality gate before the next.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics