We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A team updated all 10 application servers simultaneously. The new version had a startup bug. It crashed within 30 seconds. All 10 servers went down at once. The platform was offline for 15 minutes while the team rolled back.
Rolling deployment updates servers one at a time (or in small batches). If the new version fails on the first server, the remaining 9 are still running the old version. Users experience no downtime. The "rollback" is simply stopping the rollout, not redeploying everything.
This is the default deployment strategy in for a reason. It works for most services, requires no extra infrastructure, and Kubernetes handles the orchestration automatically.
The orchestrator (, AWS ECS, Nomad) replaces instances in waves:
| Step | State | Users See |
|---|---|---|
| Start | 10 instances running v1 | All v1 |
| Wave 1 | 9 instances v1, 1 instance v2 (health check passes) | Mostly v1 |
| Wave 2 | 8 instances v1, 2 instances v2 | Mixed v1/v2 |
| Wave 3 | 7 instances v1, 3 instances v2 | Mixed v1/v2 |
| ... | Progressive replacement continues | Gradually shifting |
| Complete | 0 instances v1, 10 instances v2 | All v2 |
Kubernetes rolling update configuration:
| Parameter | Meaning | Typical Value |
|---|---|---|
| maxUnavailable | Max instances taken offline at once | 1 or 25% |
| maxSurge | Extra instances spun up during the update | 1 or 25% |
| minReadySeconds | Wait time after health check passes before marking ready | 30-60s |
| progressDeadlineSeconds | Timeout before declaring the rollout failed | 600s (10 min) |
With maxUnavailable: 1 and maxSurge: 1, Kubernetes creates one new v2 pod, waits for it to pass health checks, then kills one v1 pod. One at a time. The cluster always has at least 10 healthy pods.
Health checks are the safety net. If the new pod fails its readiness probe, Kubernetes does not kill the next v1 pod. The rollout stalls. The cluster stays on v1 until you fix the issue or explicitly roll back with kubectl rollout undo.