StatefulSet, PersistentVolume/Claim কী, এবং Kubernetes-এ আপনি কীভাবে stateful workload চালান?

Question

IT Interview Practice · Accepted Answer

Stateful workload (database, queue, clustered store)-এর **stable identity** ও **durable storage** দরকার — যা একটি Deployment সরবরাহ করে না। একটি **StatefulSet** Pod-কে stable নাম ও ordered lifecycle দেয়; **PersistentVolume (PV)** ও **PersistentVolumeClaim (PVC)** এদের এমন storage দেয় যা Pod-এর চেয়ে বেশি টিকে থাকে।

## কেন Deployment যথেষ্ট নয়

```text
Deployment Pods are INTERCHANGEABLE: random names (web-7f9-abc), any order, share
nothing per-Pod. That's perfect for stateless apps — but a database replica needs:
  → a STABLE network identity (so peers can find it: db-0, db-1, db-2)
  → its OWN durable disk that survives restarts/rescheduling
  → ORDERED, controlled startup/scaling (bring up db-0 before db-1)
StatefulSet provides exactly these.
```

## StatefulSet-এর নিশ্চয়তা

```text
Stable NAMES     → pod-0, pod-1, pod-2 (ordinal, not random)
Stable DNS       → db-0.db.default.svc... via a headless Service
Stable STORAGE   → each Pod gets its OWN PVC (db-0 keeps its disk across restarts)
Ordered ops      → create/scale up in order 0,1,2…; terminate in reverse
```

## Persistent storage: PV, PVC, StorageClass

```text
StorageClass → the "how to provision" template (e.g. AWS gp3, fast-ssd)
PVC          → a REQUEST for storage ("I need 20Gi, ReadWriteOnce")   ← app-facing
PV           → the ACTUAL provisioned volume bound to the PVC          ← cluster-facing
Dynamic provisioning: a PVC referencing a StorageClass auto-creates a matching PV.

App → PVC → (StorageClass provisions) → PV → real disk (EBS, PD, Ceph, NFS…)
```

## Per-Pod storage সহ একটি StatefulSet

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # stable DNS-এর জন্য headless Service
  replicas: 3
  selector:
    matchLabels: { app: db }
  template:
    metadata:
      labels: { app: db }
    spec:
      containers:
        - name: db
          image: postgres:16
          ports: [{ containerPort: 5432 }]
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:      # প্রতিটি Pod এই template থেকে নিজের PVC/PV পায়
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# headless Service যা stable per-Pod DNS দেয় (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Access mode ও সতর্কতা

```text
ReadWriteOnce (RWO)  → mounted read-write by ONE node (most block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only by many nodes
ReadWriteMany (RWX)  → read-write by many nodes (needs NFS/CephFS/EFS)
⚠ Deleting a StatefulSet does NOT delete its PVCs by default (data is preserved).
⚠ Reclaim policy (Retain/Delete) decides what happens to the PV when the PVC is removed.
⚠ Kubernetes gives identity+storage, but app-level clustering/replication is YOUR job
  (often via an Operator, e.g. for Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (stable, ordered)
```

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

Stateful workload সঠিকভাবে চালানো Kubernetes-এর কঠিনতর অংশগুলোর একটি, তাই StatefulSet ও persistent storage বোঝা বাস্তব production পরিণতি সহ senior-স্তরের জ্ঞান। মূল অন্তর্দৃষ্টি হলো Deployment *কেন* অপর্যাপ্ত: এদের Pod বিনিময়যোগ্য (random নাম, যেকোনো ক্রম, কোনো per-Pod state নেই), যা stateless service-এর জন্য আদর্শ কিন্তু database ও clustered store-এর জন্য ভুল যাদের **stable identity** দরকার (যাতে peer-রা DNS দিয়ে `db-0`, `db-1`, `db-2` খুঁজে পায়), **নিজের durable disk** যা restart ও rescheduling সত্ত্বেও টিকে থাকে, এবং **ordered, নিয়ন্ত্রিত** startup ও scaling। একটি **StatefulSet** ঠিক এই নিশ্চয়তাগুলো সরবরাহ করে, এবং এটি storage abstraction-এর সাথে জোড় বাঁধে: একটি **PersistentVolumeClaim** হলো storage-এর জন্য application-facing request, একটি **PersistentVolume** হলো আসল provision করা volume, এবং একটি **StorageClass** dynamic provisioning সক্ষম করে — `volumeClaimTemplates` প্রতিটি Pod-কে তার নিজের PVC/PV দেয়। সতর্কতাগুলো সেখানেই যেখানে senior ইঞ্জিনিয়াররা তাদের মূল্য অর্জন করেন: **access mode** (RWO vs RWX এবং কোন backend এদের সমর্থন করে), এই সত্য যে একটি StatefulSet মোছা ডিফল্টভাবে **এর PVC সংরক্ষণ করে**, **reclaim policy** যা PV-এর পরিণতি নিয়ন্ত্রণ করে, এবং — গুরুত্বপূর্ণভাবে — যে Kubernetes identity ও storage সরবরাহ করে কিন্তু **application-স্তরের replication ও clustering আপনার দায়িত্ব থেকে যায়**, প্রায়ই একটি Operator-কে অর্পিত। যেহেতু data durability ও সঠিক stateful আচরণ ক্ষমাহীন (ভুল মানে data loss বা split-brain), StatefulSet, PV/PVC, ও তাদের সতর্কতা আয়ত্ত করা Kubernetes-এ database ও অন্যান্য stateful সিস্টেম নির্ভরযোগ্যভাবে চালানোর জন্য ভিত্তিমূলক।

কেন Deployment যথেষ্ট নয়

StatefulSet-এর নিশ্চয়তা

Persistent storage: PV, PVC, StorageClass

Per-Pod storage সহ একটি StatefulSet

Access mode ও সতর্কতা

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

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