StatefulSets، PersistentVolumes/Claims کیا ہیں، اور آپ Kubernetes پر stateful workloads کیسے چلاتے ہیں؟

Question

IT Interview Practice · Accepted Answer

Stateful workloads (databases، queues، clustered stores) کو **مستحکم شناخت** اور **پائیدار storage** کی ضرورت ہوتی ہے — وہ چیزیں جو ایک Deployment فراہم نہیں کرتا۔ ایک **StatefulSet** Pods کو مستحکم نام اور ترتیب وار lifecycle دیتا ہے؛ **PersistentVolumes (PV)** اور **PersistentVolumeClaims (PVC)** انہیں ایسا storage دیتے ہیں جو Pod سے زیادہ عرصہ باقی رہتا ہے۔

## Deployments کیوں کافی نہیں

```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
```

## پائیدار 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…)
```

## فی-Pod storage کے ساتھ ایک StatefulSet

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # مستحکم 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 جو مستحکم فی-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 modes اور تنبیہات

```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 (مستحکم، ترتیب وار)
```

## یہ کیوں اہم ہے

Stateful workloads کو درست طریقے سے چلانا Kubernetes کے مشکل تر حصوں میں سے ایک ہے، اس لیے StatefulSets اور persistent storage کو سمجھنا حقیقی production نتائج کے ساتھ ایک سینئر-سطح کا علم ہے۔ مرکزی بصیرت یہ ہے کہ Deployments *کیوں* ناکافی ہیں: ان کے Pods باہم قابلِ تبادلہ ہوتے ہیں (بے ترتیب نام، کوئی بھی ترتیب، کوئی فی-Pod حالت نہیں)، جو stateless services کے لیے مثالی ہے مگر databases اور clustered stores کے لیے غلط ہے جنہیں **مستحکم شناخت** (تاکہ peers `db-0`، `db-1`، `db-2` کو DNS سے تلاش کر سکیں)، **اپنی پائیدار disk** جو restarts اور rescheduling سے بچ نکلے، اور **ترتیب وار، کنٹرول شدہ** startup اور scaling چاہیے۔ ایک **StatefulSet** بالکل یہی ضمانتیں فراہم کرتا ہے، اور یہ storage abstractions کے ساتھ جوڑا بنتا ہے: ایک **PersistentVolumeClaim** storage کے لیے ایپلی کیشن-رخی request ہے، ایک **PersistentVolume** اصل مہیا کیا گیا volume ہے، اور ایک **StorageClass** متحرک provisioning کو ممکن بناتا ہے — جہاں `volumeClaimTemplates` ہر Pod کو اپنا PVC/PV دیتا ہے۔ تنبیہات وہ جگہ ہیں جہاں سینئر انجینئرز اپنی قدر ثابت کرتے ہیں: **access modes** (RWO بمقابلہ RWX اور کون سے backends انہیں سہارا دیتے ہیں)، یہ حقیقت کہ ایک StatefulSet کو حذف کرنا بطورِ default اس کے **PVCs کو محفوظ رکھتا ہے**، **reclaim policy** جو PV کے انجام کو کنٹرول کرتی ہے، اور — نہایت اہم — یہ کہ Kubernetes شناخت اور storage فراہم کرتا ہے مگر **ایپلی کیشن-سطح کی replication اور clustering آپ کی ذمہ داری رہتی ہے**، جو اکثر کسی Operator کو سونپی جاتی ہے۔ چونکہ ڈیٹا کی پائیداری اور درست stateful رویہ بے رحم ہیں (غلطیوں کا مطلب ڈیٹا کا ضیاع یا split-brain)، StatefulSets، PVs/PVCs، اور ان کی تنبیہات پر عبور Kubernetes پر databases اور دیگر stateful نظاموں کو قابلِ اعتماد انداز میں چلانے کے لیے بنیادی ہے۔

Deployments کیوں کافی نہیں

StatefulSet کی ضمانتیں

پائیدار storage: PV، PVC، StorageClass

فی-Pod storage کے ساتھ ایک StatefulSet

Access modes اور تنبیہات

یہ کیوں اہم ہے

متعلقہ سوالات