Stop 17 · CI/CD & DeploymentTopics · 6/9

Rolling Deployments

In short

You have four servers and need to ship v2 with no downtime and no extra fleet. Replace them one at a time. That's a rolling deployment, the default in Kubernetes.

A release strategy that gradually replaces old instances with new ones a few at a time, keeping the service available throughout — the default deployment strategy for most container orchestrators.

The purple blob repaints one parked bus while the rest of the fleet keeps driving.

Think of it like this

Repainting the bus fleet

The depot doesn't park all 50 buses to repaint them. It pulls out two, paints them, sends them back on the route, then takes the next two. Commuters barely notice. If the new paint peels, the depot stops before touching the rest.

Watch it happen

Four servers, one at a time

1/5Four servers behind the load balancer, all on v1. maxUnavailable is 1, so only one may be down at a time.

The big ideas

What you need to know

One batch at a time

Update a few instances, wait until they're healthy, then continue. Batch size is your speed versus safety knob.

Health checks gate each step

A new instance only gets traffic after its readiness check passes. A failing one stops the rollout.

Versions overlap

For a while v1 and v2 both serve users. API and database changes must work for both.

No double fleet

Unlike blue-green you don't need twice the servers. The trade-off: rolling back is another slow rollout.

See it in code

Walk through the code

yaml

1apiVersion: apps/v12kind: Deployment3metadata: { name: orders-api }4spec:5  replicas: 46  selector: { matchLabels: { app: orders } }7  strategy:8    rollingUpdate: { maxUnavailable: 1, maxSurge: 1 }9  template:10    metadata: { labels: { app: orders } }11    spec:12      containers:13        - name: api14          image: registry.example.com/orders-api:v215          readinessProbe:16            httpGet: { path: /health, port: 3000 }

1/3Four pods. At most one may be unavailable and at most one extra may exist during the rollout.

Change the image tag and apply. kubectl rollout status shows progress, and kubectl rollout undo deployment/orders-api rolls back.

Save yourself the pain

Common mistakes

Oops

Shipping an API change that v1 servers or clients can't understand.

Do this instead

During the rollout both versions run. Add new fields as optional first, and remove old ones in a later release.

Oops

Rolling out with no readiness check.

Do this instead

Traffic then reaches pods that are still booting. Add a readinessProbe so only ready pods join.

Your mission

Watch a rollout happen

~40 min

Quick check

With replicas: 4, maxUnavailable: 1 and maxSurge: 1, what's the most pods that can exist at once during a rollout?

Go deeper

1Read how Kubernetes performs a rolling update by default.
2Compare rolling deployments' gradual risk exposure to blue-green's all-at-once switch.
3Learn what a 'canary deployment' adds on top of rolling deployments — a small initial traffic percentage.