Deployments ਅਤੇ ReplicaSets ਕੀ ਹਨ, ਅਤੇ rolling updates ਤੇ rollbacks ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ?

Question

IT Interview Practice · Accepted Answer

ਇੱਕ **Deployment** stateless ਐਪਸ ਚਲਾਉਣ ਲਈ ਮਿਆਰੀ controller ਹੈ। ਇਹ **ReplicaSets** ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਇੱਕ ReplicaSet ਇੱਕ ਨਿਰਧਾਰਿਤ ਗਿਣਤੀ ਦੇ ਇੱਕੋ-ਜਿਹੇ Pod ਚੱਲਦੇ ਰੱਖਦਾ ਹੈ। ਤੁਸੀਂ Deployment ਨੂੰ ਸੋਧਦੇ ਹੋ; ਇਹ ਤੁਹਾਡੇ ਲਈ **rolling updates** ਅਤੇ **rollbacks** ਨੂੰ orchestrate ਕਰਦਾ ਹੈ।

## ਲੜੀਵਾਰ ਬਣਤਰ

```text
Deployment  → desired state + update strategy ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ (ਉਹ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਸੰਭਾਲਦੇ ਹੋ)
   └── ReplicaSet  → ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ N ਇੱਕੋ-ਜਿਹੇ Pod ਮੌਜੂਦ ਹਨ (ਹਰ app version ਲਈ ਇੱਕ)
          └── Pod  → Pod → Pod ...  (ਅਸਲ ਚੱਲ ਰਹੀਆਂ ਕਾਪੀਆਂ)

ਹਰ ਨਵੇਂ version 'ਤੇ, Deployment ਇੱਕ ਨਵਾਂ ReplicaSet ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ Pod ਨੂੰ ਉਸ ਵੱਲ ਖਿਸਕਾਉਂਦਾ ਹੈ।
```

## ਇੱਕ 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 change

```bash
kubectl set image deployment/web web=myapp:2.0   # ਇੱਕ rolling update trigger ਕਰੋ
kubectl rollout status deployment/web            # progress ਵੇਖੋ
```

```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       # revision ਸੂਚੀਬੱਧ ਕਰੋ
kubectl rollout undo deployment/web          # ਪਿਛਲੇ revision 'ਤੇ roll back ਕਰੋ
kubectl rollout undo deployment/web --to-revision=3
```

ਕਿਉਂਕਿ ਪੁਰਾਣਾ ReplicaSet ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ (0 'ਤੇ scale ਕੀਤਾ), ਇੱਕ rollback ਤੇਜ਼ ਹੁੰਦਾ ਹੈ: Kubernetes ਬਸ ਪਿਛਲੇ ReplicaSet ਨੂੰ ਵਾਪਸ ਉੱਪਰ ਅਤੇ ਨਵੇਂ ਨੂੰ ਹੇਠਾਂ scale ਕਰ ਦਿੰਦਾ ਹੈ।

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # desired count ਬਦਲੋ
```

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

Deployments Kubernetes 'ਤੇ stateless ਐਪਲੀਕੇਸ਼ਨ ਚਲਾਉਣ ਲਈ ਮਿਹਨਤੀ ਘੋੜਾ ਹਨ, ਇਸ ਲਈ ਇਹਨਾਂ ਨੂੰ ਅਤੇ ReplicaSets ਨਾਲ ਇਹਨਾਂ ਦੇ ਰਿਸ਼ਤੇ ਨੂੰ ਸਮਝਣਾ ਜ਼ਰੂਰੀ, ਰੋਜ਼ਾਨਾ ਦਾ ਗਿਆਨ ਹੈ। ਪਰਤਾਂ ਵਾਲੀ ਬਣਤਰ ਮੁੱਖ ਸੂਝ ਹੈ: ਤੁਸੀਂ ਇੱਕ **Deployment** ਸੰਭਾਲਦੇ ਹੋ, ਜੋ **ReplicaSets** ਦਾ ਮਾਲਕ ਹੈ (ਹਰ version ਲਈ ਇੱਕ), ਅਤੇ ਹਰ ReplicaSet ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਇੱਕ ਨਿਰਧਾਰਿਤ ਗਿਣਤੀ ਦੇ ਇੱਕੋ-ਜਿਹੇ Pod ਚੱਲ ਰਹੇ ਹਨ — reconciliation loops ਦੀ ਇੱਕ ਲੜੀ ਜੋ ਮਿਲ ਕੇ self-healing ਅਤੇ ਇੱਕ ਸਥਿਰ replica count ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਅਸਲ ਤਾਕਤ ਇਸ ਵਿੱਚ ਹੈ ਕਿ Deployment ਬਦਲਾਅ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ: ਇੱਕ **rolling update** ਇੱਕ ਨਵਾਂ ReplicaSet ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ Pod ਨੂੰ ਪੁਰਾਣੇ ਤੋਂ ਨਵੇਂ ਵੱਲ ਹੌਲੀ-ਹੌਲੀ ਖਿਸਕਾਉਂਦਾ ਹੈ, `maxSurge` ਅਤੇ `maxUnavailable` ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ, ਇਸ ਲਈ ਸਮਰੱਥਾ ਬਚੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ — readiness probe ਨਾਲ ਮਿਲ ਕੇ ਜੋ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੇ Pod traffic ਪ੍ਰਾਪਤ ਕਰਨ — release **zero downtime** ਨਾਲ ਹੁੰਦਾ ਹੈ। ਕਿਉਂਕਿ ਪਿਛਲਾ ReplicaSet ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ (ਮਿਟਾਉਣ ਦੀ ਬਜਾਏ 0 'ਤੇ scale ਕੀਤਾ), ਇੱਕ **rollback** ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ: `kubectl rollout undo` ਬਸ ਪੁਰਾਣੇ version ਨੂੰ ਵਾਪਸ ਉੱਪਰ ਅਤੇ ਖ਼ਰਾਬ ਨੂੰ ਹੇਠਾਂ scale ਕਰ ਦਿੰਦਾ ਹੈ, ਜੋ ਠੀਕ ਉਹੀ ਹੈ ਜਿਸ ਵੱਲ ਤੁਸੀਂ ਹੱਥ ਵਧਾਉਂਦੇ ਹੋ ਜਦੋਂ ਕੋਈ release ਗ਼ਲਤ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਵਿਧੀਆਂ ਨੂੰ ਸਮਝਣਾ — ਨਾਲ ਹੀ scale ਕਿਵੇਂ ਕਰੀਏ (`kubectl scale`) ਅਤੇ progress ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰੀਏ (`kubectl rollout status/history`) — Kubernetes 'ਤੇ software ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ship ਕਰਨ ਦੀ ਨੀਂਹ ਹੈ, ਅਤੇ ਉਸ declarative, controller-driven ਮਾਡਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਪਲੇਟਫਾਰਮ production ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਲੜੀਵਾਰ ਬਣਤਰ

ਇੱਕ Deployment manifest

Rolling update: zero-downtime version change

ਜਦੋਂ ਕੋਈ release ਖ਼ਰਾਬ ਹੋ ਜਾਵੇ ਤਾਂ rollback

Scaling

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ