riteshatri/deploymentrollingupdate repository overview

⁠🚀 Kubernetes Deployment – RollingUpdate Strategy

⁠🔥 COMPLETE & ULTRA IN-DEPTH HANDS-ON PRACTICAL (v1 → v2 → v3)

⁠🧠 Pehle Dimag Set Karo (Context Clear Karo)

Kubernetes Deployment ke andar mainly 2 strategies hoti hain:

⁠❌ Recreate Strategy

• Saare pods ek saath delete
• Phir naye pods create
• Guaranteed downtime

⁠✅ RollingUpdate Strategy

• Pehle naya pod banta hai
• Phir purana pod delete hota hai
• Zero downtime (agar sahi config ho)

👉 Is poore lab me hum RollingUpdate ko andar tak khol ke samjhenge.

⁠🎯 Learning Objective (Is lab ka goal)

Is lab ke baad tum confidently ye bol paoge:

• RollingUpdate strategy exactly kaise kaam karti hai
• Pod pehle banta hai ya pehle delete hota hai
• ReplicaSet ka role kya hota hai
• kubectl get rs kyun sabse important command hai
• maxSurge aur maxUnavailable ka real maths
• Zero downtime ka proof kaise milta hai

⁠🧩 Prerequisites

• Kubernetes cluster (AKS / EKS / GKE / Minikube)
• kubectl configured
• Docker basics
• ReplicaSet & Recreate labs (recommended but optional)

⁠🐳 Docker Images Used (Already Pushed)

docker push riteshatri/deploymentrollingupdate:v1
docker push riteshatri/deploymentrollingupdate:v2
docker push riteshatri/deploymentrollingupdate:v3

👉 Har image ke andar alag index.html hai
taaki browser me clearly pata chale kaunsa version chal raha hai.

⁠📁 Files Used in This Lab

⁠📄 deployment.yaml (REFERENCE – DHYAAN SE PADHO)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploymentrollingupdate
spec:
  replicas: 20
  selector:
    matchLabels:
      humhai: rollingupdate

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

  template:
    metadata:
      labels:
        humhai: rollingupdate
    spec:
      containers:
      - name: ritcontainer
        image: riteshatri/deploymentrecreate:v1
        ports:
        - containerPort: 80

⁠📄 service.yaml

apiVersion: v1
kind: Service
metadata:
  name: ritservice
spec:
  selector:
    humhai: rollingupdate
  ports:
  - port: 6541
    targetPort: 80
  type: LoadBalancer

⁠🧠 YAML KA DIMAAG (Isko tod-tod ke samjho)

Tumne Kubernetes ko ye bola:

• 🔢 20 pods hamesha running hone chahiye
• ⚠️ Ek time pe sirf 1 pod unavailable ho sakta hai
• ➕ Ek extra pod temporary allow hai

⁠Iska matlab:

Minimum pods alive = 20 - 1 = 19
Maximum pods allowed = 20 + 1 = 21

👉 Isi maths ki wajah se downtime nahi hota.

⁠🔹 STEP 1: Base Deployment (Version-1)

kubectl apply -f deployment.yaml
kubectl get deployment
kubectl get pods
kubectl get rs

⁠Observe karo:

• Sirf 1 ReplicaSet
• Uske andar 20 pods
• Sab pods me v1 image

Browser me open:

http://<EXTERNAL-IP>:6541

⁠🔹 STEP 2: Image Update v1 → v2 (ASLI GAME)

Deployment file me image update karo:

image: riteshatri/deploymentrecreate:v2

Apply:

kubectl apply -f deployment.yaml

Ab turant check karo:

kubectl get pods
kubectl get rs

⁠💥 YAHI CORE CONCEPT HAI (ANDAR TAK)

⁠❓ Pehle kya hota hai?

👉 PEHLE NAYA POD BANTA HAI

⁠Proof:

Old RS → 20 Pods
New RS → 1 Pod
Total  → 21 Pods (maxSurge allow karta hai)

Website UP Rehti hai ✅

⁠🔹 STEP 3: Ab Kubernetes purana pod delete karta hai

Old RS → 19 Pods
New RS → 1 Pod
Total  → 20 Pods

👉 Minimum availability maintained.

⁠🔁 STEP 4: Ye cycle repeat hoti hai

+1 New Pod → -1 Old Pod
+1 New Pod → -1 Old Pod
...
(20 times)

⁠👀 LIVE PROOF (AANKHON KE SAAMNE)

kubectl get pods -w
kubectl get rs -w

Tum literally dekhoge:

• New pods create ho rahe hain
• Old pods delete ho rahe hain
• Pods count kabhi 19 se neeche nahi jata

Browser refresh karte raho → ❌ downtime nahi

⁠🔹 STEP 5: Image Update v2 → v3 (FINAL CONFIRMATION)

image: riteshatri/deploymentrecreate:v3

kubectl apply -f deployment.yaml
kubectl get pods
kubectl get rs

⁠Final State:

• Old ReplicaSet replicas = 0
• New ReplicaSet replicas = 20
• Sab pods v3 image pe

Browser me: 👉 RollingUpdate – Version 3

⁠❌ Kab pehle delete hota hai? (TRICKY PART)

Sirf is case me:

maxSurge: 0
maxUnavailable: 1

Flow:

-1 Old Pod → +1 New Pod

⚠️ Ye risky hota hai.

⁠📊 FINAL FLOW TABLE (YAAD RAKHNE KE LIYE)

⁠🧠 ONE-LINE LIFE-TIME RULE

⁠🏆 FINAL VERDICT

Agar:

• Application production me hai
• Downtime acceptable nahi
• Users real hain

👉 RollingUpdate hi use hota hai.

⁠❤️ Author ❤️

RITESH SHARMA

Created for Kubernetes Hands-on Learning
Happy Learning ☸️🔥