Deployments અને ReplicaSets શું છે, અને rolling updates તથા rollbacks કેવી રીતે કામ કરે છે?

Question

IT Interview Practice · Accepted Answer

**Deployment** એ stateless apps ચલાવવા માટેનું પ્રમાણભૂત controller છે. તે **ReplicaSets** ને manage કરે છે, અને એક ReplicaSet નિર્ધારિત સંખ્યાના એકસરખા Pods ને ચાલુ રાખે છે. તમે Deployment ને edit કરો; તે તમારા માટે **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 down
      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 પર પાછા ફરો
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 ચલાવવા માટેનું મુખ્ય કાર્યબળ છે, તેથી તેમને અને ReplicaSets સાથેના તેમના સંબંધને સમજવું આવશ્યક, રોજિંદું જ્ઞાન છે. સ્તરરચના (layering) એ મુખ્ય સૂઝ છે: તમે એક **Deployment** manage કરો છો, જે **ReplicaSets** (દરેક version દીઠ એક) ધરાવે છે, અને દરેક ReplicaSet ખાતરી કરે છે કે નિર્ધારિત સંખ્યાના એકસરખા Pods ચાલી રહ્યા છે — reconciliation loops ની એક સાંકળ જે સાથે મળીને self-healing અને સ્થિર replica count આપે છે. અસલી શક્તિ Deployment ફેરફારને કેવી રીતે handle કરે છે તેમાં છે: એક **rolling update** નવું ReplicaSet બનાવે છે અને Pods ને જૂનાથી નવા તરફ ધીમે ધીમે ખસેડે છે, `maxSurge` અને `maxUnavailable` દ્વારા નિયંત્રિત, જેથી capacity જળવાઈ રહે અને — કયા Pods traffic મેળવે તે નક્કી કરતા readiness probes સાથે મળીને — release **zero downtime** સાથે થાય છે. કારણ કે પાછલું ReplicaSet જાળવી રખાય છે (delete કરવાને બદલે zero પર scaled), એક **rollback** ઝડપી અને સલામત છે: `kubectl rollout undo` માત્ર જૂના version ને પાછું ઉપર અને ખરાબ version ને નીચે scale કરે છે, જે તમે release બગડે ત્યારે બરાબર માંગો છો. આ કાર્યપ્રણાલી સમજવી — સાથે scale કેવી રીતે કરવું (`kubectl scale`) અને પ્રગતિ કેવી રીતે તપાસવી (`kubectl rollout status/history`) — એ Kubernetes પર software સલામત રીતે ship કરવા માટે પાયાનું છે, અને એ declarative, controller-driven મોડલને પ્રતિબિંબિત કરે છે જે પ્લેટફોર્મ production માં કેવી રીતે કામ કરે છે તે નક્કી કરે છે.

વંશવેલો (hierarchy)

એક Deployment manifest

Rolling update: zero-downtime version ફેરફાર

Release ખરાબ થાય ત્યારે rollback

Scaling

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો