🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

⚽ धडा 11 — Rollouts आणि rollbacks: सामना सुरू असतानाच खेळाडू बदलणे

📍 तुम्ही इथे आहात: 13 पैकी धडा 11 · मागचा: lesson-10-ingress · पुढचा: lesson-12-storage

📦 या ब्रँचमध्ये काय आहे

धडे 01–10, आणि: rolling updates आणि rollbacks — zero downtime ने नवे versions पाठवणे, आणि release खराब निघाला तर सुटकेचा मार्ग. खऱ्या files:

k8s/deployment.yaml — strategy: block
.circleci/config.yml — जिथे kubectl rollout status pipeline चे फाटक आहे

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

फुटबॉलचा सामना ⚽. तुमच्या 2 खेळाडूंचा संघ मैदानावर आहे आणि तुम्हाला ताजे खेळाडू आणायचे आहेत — पण खेळ कधीच थांबत नाही. म्हणून प्रशिक्षिका एका वेळी एकच खेळाडू बदलतात:

ताजी खेळाडू बाजूला warm-up करते 🏃 (नवा pod सुरू होतो).
पंच ती तयार आहे का ते तपासतात — नाड्या बांधल्या, warm-up झाले 🙋 (readiness probe, धडा 07!).
मगच दमलेली खेळाडू मैदानाबाहेर जाते (जुना pod संपतो).
पुढच्या खेळाडूसाठी तेच पुन्हा.

प्रत्येक क्षणी पूर्ण संघ मैदानावर असतो. प्रेक्षकांना काहीच कळत नाही — हाच rolling update.

आणि नवी खेळाडू अगदीच वाईट खेळली तर? 😬 प्रशिक्षिका घाबरत नाहीत आणि नव्या खेळाडूच्या करारासाठी थांबत नाहीत — जुनी खेळाडू अजून बेंचवर आहे. एक हाक: "परत ये!" — हाच rollback. Kubernetes नेमके यासाठीच जुनी संघ-यादी (ReplicaSet) जपून ठेवतो.

🗺️ आकृती

flowchart TB
    subgraph before["⏱️ during rollout - never below full team"]
        o1["v1 pod ✅ playing"]
        o2["v1 pod ✅ playing"]
        n1["v2 pod 🏃 warming up<br/>waiting for /readyz"]
    end
    subgraph after["✅ rollout done"]
        n2["v2 pod ✅"]
        n3["v2 pod ✅"]
        bench["old ReplicaSet v1<br/>scaled to 0 — kept on the bench<br/>for rollback"]
    end
    before -->|"v2 ready → v1 leaves,<br/>repeat for next"| after
    after -.->|"kubectl rollout undo<br/>= bring v1 back on"| before

❓ काय

दोन knobs असलेली strategy: RollingUpdate:
- maxUnavailable: 0 — कधीच एक खेळाडू कमी ठेवून खेळू नका (desired replicas च्या खाली कधीच जाऊ नका). सर्वात सुरक्षित setting.
- maxSurge: 1 — बदलाच्या वेळी 1 जादा खेळाडूला परवानगी (थोड्या वेळासाठी 3 pods).
प्रत्येक नवी image = एक नवा ReplicaSet; जुने rollback साठी ठेवले जातात (0 वर scale केलेले) — हाच बेंच.
kubectl rollout status — "बदल व्यवस्थित पूर्ण झाला का?" — CI च्या फाटकासाठी अगदी योग्य. kubectl rollout undo — तात्काळ rollback.
Readiness probes हे पंच आहेत: /readyz नाही, तर traffic नाही — बिघडलेल्या v2 ला चेंडू कधीच मिळत नाही, आणि maxUnavailable: 0 मुळे site बंद पाडण्याऐवजी rollout फक्त थांबून राहतो.

🤔 का

पूर्वी deploy म्हणजे "मध्यरात्री maintenance window" 🌙. Rolling updates मुळे deploys कंटाळवाणे होतात: मंगळवारी दुपारी 2 वाजता पाठवा, users ना काहीच कळत नाही. आणि खराब releases कधी येणार हा प्रश्न असतो, येतील का नाही, म्हणून बेंच (rollback) production मधल्या आगीला 10 सेकंदांच्या खांदे उडवण्यात बदलतो. या धड्यात धडे 03 (desired state), 07 (readiness) आणि 04 (फक्त ready pods कडे route करणाऱ्या services) एकत्र जुळतात.

🔧 कसे (या repo मध्ये)

k8s/deployment.yaml:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0   # full team on the field, always
    maxSurge: 1         # one warming-up player allowed

CI मध्ये (.circleci/config.yml), kubectl apply नंतर: kubectl rollout status deployment/school-api — बदल पूर्ण झाला तरच pipeline हिरवी होते.

🧪 करून पाहा

# Ship a "new version" (any image change triggers a rollout):
kubectl -n school set image deployment/school-api school-api=nginxdemos/hello:latest
kubectl -n school rollout status deployment/school-api   # watch the substitutions
kubectl -n school get replicasets                        # old RS at 0 = the bench

# Ship a BROKEN version — and watch Kubernetes protect you:
kubectl -n school set image deployment/school-api school-api=busybox:1.36
kubectl -n school get pods                # new pod crash-loops, old pods still serve!

# The 10-second shrug:
kubectl -n school rollout undo deployment/school-api
kubectl -n school rollout history deployment/school-api  # the team sheet history

🔧 या धड्यासाठी kubectl

kubectl rollout status/history/undo · kubectl set image

🔗 यावर आधारित: 🤖 ArgoCD शाळा L10 (rollback = git revert)

✅ तपासा — तुम्हाला काय दिसायला हवे

kubectl rollout status pods एका वेळी एक बदलले जात असल्याचे दाखवते; बिघडलेल्या image ला कधीच traffic मिळत नाही; kubectl rollout undo काही सेकंदांत पूर्ववत करते.

🧹 साफसफाई

local cluster: kubectl delete -f k8s/ (किंवा तुम्ही apply केलेली file) — EKS वर चालू राहिलेल्या प्रत्येक गोष्टीचे तासाप्रमाणे बिल लागते

⚠️ नेहमीच्या चुका

maxUnavailable खूप जास्त — तुम्ही संघच मैदानाबाहेर काढला
readiness probe नाही — rollout बिघडलेल्या app वर 'यशस्वी' होतो

⏭️ पुढे

Pods टाकाऊ आहेत — मग जो data टिकायलाच हवा त्याचे काय होते? Volumes, PersistentVolumeClaims, आणि आपला database cluster च्या बाहेर का राहतो: storage आणि state.

git checkout lesson-12-storage

⚽ Lesson 11 — Rollouts & rollbacks: substituting players mid-game

📍 You are here: Lesson 11 of 13 · Previous: lesson-10-ingress · Next: lesson-12-storage

📦 What's in this branch

Lessons 01–10, plus: rolling updates and rollbacks — shipping new versions with zero downtime, and the escape hatch when a release is bad. Real files:

k8s/deployment.yaml — the strategy: block
.circleci/config.yml — where kubectl rollout status gates the pipeline

🧒 Explain like I'm 5

A football match ⚽. Your team of 2 players is on the field and you want to bring in fresh players — but the game never stops. So the coach substitutes one at a time:

Fresh player warms up on the sideline 🏃 (new pod starts).
Referee checks they're ready — laces tied, warmed up 🙋 (readiness probe, lesson 07!).
Only then does the tired player walk off (old pod terminates).
Repeat for the next player.

At every moment, a full team is on the field. The crowd never notices a thing — that's a rolling update.

And if the new player plays terribly? 😬 The coach doesn't panic and doesn't wait for a new signing — the old player is still on the bench. One shout: "come back on!" — that's a rollback. Kubernetes keeps the old team sheet (ReplicaSet) exactly for this.

🗺️ Diagram

flowchart TB
    subgraph before["⏱️ during rollout - never below full team"]
        o1["v1 pod ✅ playing"]
        o2["v1 pod ✅ playing"]
        n1["v2 pod 🏃 warming up<br/>waiting for /readyz"]
    end
    subgraph after["✅ rollout done"]
        n2["v2 pod ✅"]
        n3["v2 pod ✅"]
        bench["old ReplicaSet v1<br/>scaled to 0 — kept on the bench<br/>for rollback"]
    end
    before -->|"v2 ready → v1 leaves,<br/>repeat for next"| after
    after -.->|"kubectl rollout undo<br/>= bring v1 back on"| before

❓ What

strategy: RollingUpdate with two knobs:
- maxUnavailable: 0 — never play a player short (never drop below desired replicas). Safest setting.
- maxSurge: 1 — allowed 1 extra player during the swap (briefly 3 pods).
Each new image = a new ReplicaSet; old ones are kept (scaled to 0) as rollback targets — the bench.
kubectl rollout status — "did the substitution finish cleanly?" — perfect for CI gates. kubectl rollout undo — instant rollback.
Readiness probes are the referee: no /readyz, no traffic — a broken v2 never gets the ball, and with maxUnavailable: 0 the rollout simply stalls instead of taking the site down.

🤔 Why

Deploying used to mean "maintenance window at midnight" 🌙. Rolling updates make deploys boring: ship at 2 PM on a Tuesday, users notice nothing. And because bad releases are a when, not an if, the bench (rollback) turns a production fire into a 10-second shrug. This lesson is where lessons 03 (desired state), 07 (readiness) and 04 (services routing only to ready pods) all click together.

🔧 How (in this repo)

k8s/deployment.yaml:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0   # full team on the field, always
    maxSurge: 1         # one warming-up player allowed

In CI (.circleci/config.yml), after kubectl apply: kubectl rollout status deployment/school-api — the pipeline goes green only when the substitution completed.

🧪 Try it

# Ship a "new version" (any image change triggers a rollout):
kubectl -n school set image deployment/school-api school-api=nginxdemos/hello:latest
kubectl -n school rollout status deployment/school-api   # watch the substitutions
kubectl -n school get replicasets                        # old RS at 0 = the bench

# Ship a BROKEN version — and watch Kubernetes protect you:
kubectl -n school set image deployment/school-api school-api=busybox:1.36
kubectl -n school get pods                # new pod crash-loops, old pods still serve!

# The 10-second shrug:
kubectl -n school rollout undo deployment/school-api
kubectl -n school rollout history deployment/school-api  # the team sheet history

🔧 kubectl for this lesson

kubectl rollout status/history/undo · kubectl set image

🔗 Builds on: 🤖 ArgoCD school L10 (rollback = git revert)

✅ Verify — what you should see

kubectl rollout status shows pods replaced one at a time; a broken image never receives traffic; kubectl rollout undo restores in seconds.

🧹 Clean up

local cluster: kubectl delete -f k8s/ (or the file you applied) — on EKS, anything left running bills by the hour

⚠️ Common mistakes

maxUnavailable too high — you took the team off the field
no readiness probe — the rollout 'succeeds' onto a broken app

⏭️ Next

Pods are disposable — so what happens to data that must survive? Volumes, PersistentVolumeClaims, and why our database lives outside the cluster: storage & state.

git checkout lesson-12-storage

← Previousingress Next →storage

This page is the lesson's README from the lesson-11-rollouts branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.