Deployment ও ReplicaSet কী, এবং rolling update ও rollback কীভাবে কাজ করে?

Question

IT Interview Practice · Accepted Answer

একটি **Deployment** হলো stateless অ্যাপ চালানোর জন্য প্রমিত controller। এটি **ReplicaSet** পরিচালনা করে, এবং একটি ReplicaSet একটি নির্দিষ্ট সংখ্যক অভিন্ন Pod চালু রাখে। আপনি Deployment সম্পাদনা করেন; এটি আপনার জন্য **rolling update** ও **rollback** orchestrate করে।

## স্তরক্রম

```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 চলাকালীন সর্বোচ্চ ১টি Pod বন্ধ
      maxSurge: 1            # desired count-এর উপরে সর্বোচ্চ ১টি অতিরিক্ত Pod
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: zero-downtime সংস্করণ পরিবর্তন

```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       # revision তালিকা
kubectl rollout undo deployment/web          # আগের revision-এ ফিরে যান
kubectl rollout undo deployment/web --to-revision=3
```

যেহেতু পুরনো ReplicaSet রাখা হয় (0-তে scale করা), একটি rollback দ্রুত: Kubernetes কেবল আগের ReplicaSet-কে আবার scale up করে এবং নতুনটিকে down করে।

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # desired count পরিবর্তন করুন
```

## এটি কেন গুরুত্বপূর্ণ

Deployment হলো Kubernetes-এ stateless অ্যাপ্লিকেশন চালানোর মূল কর্মশক্তি, তাই এগুলো এবং ReplicaSet-এর সাথে তাদের সম্পর্ক বোঝা অপরিহার্য, প্রতিদিনের জ্ঞান। স্তরায়নই মূল অন্তর্দৃষ্টি: আপনি একটি **Deployment** পরিচালনা করেন, যা **ReplicaSet**-এর মালিক (প্রতি সংস্করণে একটি), এবং প্রতিটি ReplicaSet নিশ্চিত করে একটি নির্দিষ্ট সংখ্যক অভিন্ন Pod চলছে — reconciliation loop-এর একটি শৃঙ্খল যা একসাথে self-healing ও একটি stable replica count সরবরাহ করে। আসল শক্তি রয়েছে Deployment কীভাবে পরিবর্তন সামলায় তাতে: একটি **rolling update** একটি নতুন ReplicaSet তৈরি করে এবং Pod-কে পুরনো থেকে নতুনে ধীরে ধীরে সরায়, `maxSurge` ও `maxUnavailable` দ্বারা নিয়ন্ত্রিত, তাই ধারণক্ষমতা সংরক্ষিত থাকে এবং — কোন Pod ট্রাফিক পায় তা নিয়ন্ত্রণকারী readiness probe-এর সাথে মিলিত হয়ে — release **zero downtime**-এ ঘটে। যেহেতু আগের ReplicaSet ধরে রাখা হয় (মুছে না-ফেলে 0-তে scale করা), একটি **rollback** দ্রুত ও নিরাপদ: `kubectl rollout undo` কেবল পুরনো সংস্করণকে আবার scale up করে এবং খারাপটিকে down করে, ঠিক যা আপনি একটি release বিগড়ে গেলে ব্যবহার করেন। এই প্রক্রিয়াগুলো বোঝা — সাথে কীভাবে scale করবেন (`kubectl scale`) এবং অগ্রগতি পরিদর্শন করবেন (`kubectl rollout status/history`) — Kubernetes-এ নিরাপদে সফটওয়্যার ship করার ভিত্তিমূলক, এবং সেই declarative, controller-চালিত মডেল প্রতিফলিত করে যা সংজ্ঞায়িত করে প্ল্যাটফর্মটি production-এ কীভাবে চলে।

স্তরক্রম

একটি Deployment manifest

Rolling update: zero-downtime সংস্করণ পরিবর্তন

একটি release খারাপ হলে rollback

Scaling

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন