Deployments और ReplicaSets क्या हैं, और rolling updates तथा rollbacks कैसे काम करते हैं?

Question

IT Interview Practice · Accepted Answer

एक **Deployment** stateless apps चलाने का मानक controller है। यह **ReplicaSets** को प्रबंधित करता है, और एक ReplicaSet एक निर्दिष्ट संख्या में समान Pods चालू रखता है। आप Deployment को संपादित करते हैं; यह आपके लिए **rolling updates** और **rollbacks** को orchestrate करता है।

## पदानुक्रम (hierarchy)

```text
Deployment  → declares desired state + update strategy (the thing YOU manage)
   └── ReplicaSet  → ensures N identical Pods exist (one per app version)
          └── Pod  → Pod → Pod ...  (the actual running copies)

On each new version, the Deployment creates a NEW ReplicaSet and shifts Pods over.
```

## एक Deployment manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # update के दौरान अधिकतम 1 Pod बंद
      maxSurge: 1            # desired count से अधिकतम 1 अतिरिक्त Pod
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: zero-downtime version बदलाव

```bash
kubectl set image deployment/web web=myapp:2.0   # rolling update शुरू करें
kubectl rollout status deployment/web            # प्रगति देखें
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 old Pods)
      █████       spin up 1 new (v2), now 5 total (surge)
      ███ █       old down to 3, new is Ready
      ...gradually shift...
  v2: ████        (end: 4 new Pods, old ReplicaSet scaled to 0)
Traffic only goes to Pods that pass their readiness probe → no downtime.
```

## जब कोई release ख़राब हो तो rollback

```bash
kubectl rollout history deployment/web       # revisions की सूची
kubectl rollout undo deployment/web          # पिछले revision पर roll back करें
kubectl rollout undo deployment/web --to-revision=3
```

चूँकि पुराना ReplicaSet रखा जाता है (0 पर scaled), rollback तेज़ होता है: Kubernetes बस पिछले ReplicaSet को वापस ऊपर और नए को नीचे scale कर देता है।

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # desired count बदलें
```

## यह क्यों महत्वपूर्ण है

Deployments Kubernetes पर stateless applications चलाने के मुख्य कार्यकर्ता (workhorse) हैं, इसलिए उन्हें और ReplicaSets के साथ उनके संबंध को समझना आवश्यक, रोज़मर्रा का ज्ञान है। परतबंदी (layering) ही मुख्य अंतर्दृष्टि है: आप एक **Deployment** को प्रबंधित करते हैं, जो **ReplicaSets** का स्वामी है (हर version के लिए एक), और हर ReplicaSet यह सुनिश्चित करता है कि एक निर्दिष्ट संख्या में समान Pods चल रहे हों — reconciliation loops की एक श्रृंखला जो मिलकर self-healing और स्थिर replica count देती है। असली ताक़त इसमें है कि Deployment बदलाव को कैसे संभालता है: एक **rolling update** नया ReplicaSet बनाता है और Pods को पुराने से नए में धीरे-धीरे स्थानांतरित करता है, जो `maxSurge` और `maxUnavailable` द्वारा नियंत्रित होता है, इसलिए क्षमता बनी रहती है और — readiness probes के साथ मिलकर जो तय करते हैं कि कौन-से Pods को traffic मिले — release **zero downtime** के साथ होता है। चूँकि पिछला ReplicaSet रखा जाता है (मिटाने के बजाय शून्य पर scaled), एक **rollback** तेज़ और सुरक्षित होता है: `kubectl rollout undo` बस पुराने version को वापस ऊपर और ख़राब को नीचे scale कर देता है, ठीक वही जिसकी आपको किसी release के गड़बड़ाने पर ज़रूरत होती है। इन क्रियाविधियों को समझना — साथ ही scale करना (`kubectl scale`) और प्रगति जाँचना (`kubectl rollout status/history`) — Kubernetes पर सुरक्षित रूप से software भेजने की नींव है, और यह declarative, controller-चालित मॉडल को दर्शाता है जो परिभाषित करता है कि प्लेटफ़ॉर्म production में कैसे संचालित होता है।

पदानुक्रम (hierarchy)

एक Deployment manifest

Rolling update: zero-downtime version बदलाव

जब कोई release ख़राब हो तो rollback

Scaling

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न