StatefulSets, PersistentVolumes/Claims ਕੀ ਹਨ, ਅਤੇ ਤੁਸੀਂ Kubernetes 'ਤੇ stateful workload ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

Stateful workloads (databases, queues, clustered stores) ਨੂੰ **ਸਥਿਰ ਪਛਾਣ** ਅਤੇ **ਟਿਕਾਊ storage** ਚਾਹੀਦਾ ਹੈ — ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਇੱਕ Deployment ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ। ਇੱਕ **StatefulSet** Pod ਨੂੰ ਸਥਿਰ ਨਾਂ ਅਤੇ ਕ੍ਰਮਬੱਧ lifecycle ਦਿੰਦਾ ਹੈ; **PersistentVolumes (PV)** ਅਤੇ **PersistentVolumeClaims (PVC)** ਉਹਨਾਂ ਨੂੰ ਅਜਿਹਾ storage ਦਿੰਦੇ ਹਨ ਜੋ Pod ਤੋਂ ਵੱਧ ਜੀਵੇ।

## Deployments ਕਿਉਂ ਕਾਫ਼ੀ ਨਹੀਂ

```text
Deployment Pod INTERCHANGEABLE ਹਨ: random ਨਾਂ (web-7f9-abc), ਕੋਈ ਵੀ ਕ੍ਰਮ, ਹਰ-Pod ਕੁਝ
ਸਾਂਝਾ ਨਹੀਂ ਕਰਦੇ। ਇਹ stateless ਐਪਸ ਲਈ ਸੰਪੂਰਨ ਹੈ — ਪਰ ਇੱਕ database replica ਨੂੰ ਚਾਹੀਦਾ ਹੈ:
  → ਇੱਕ ਸਥਿਰ network ਪਛਾਣ (ਤਾਂ ਜੋ peer ਇਸਨੂੰ ਲੱਭ ਸਕਣ: db-0, db-1, db-2)
  → ਆਪਣਾ ਟਿਕਾਊ disk ਜੋ restart/reschedule ਤੋਂ ਬਚੇ
  → ਕ੍ਰਮਬੱਧ, ਨਿਯੰਤਰਿਤ startup/scaling (db-1 ਤੋਂ ਪਹਿਲਾਂ db-0 ਲਿਆਓ)
StatefulSet ਠੀਕ ਇਹੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
```

## StatefulSet ਗਾਰੰਟੀਆਂ

```text
ਸਥਿਰ NAMES     → pod-0, pod-1, pod-2 (ordinal, random ਨਹੀਂ)
ਸਥਿਰ DNS       → db-0.db.default.svc... ਇੱਕ headless Service ਰਾਹੀਂ
ਸਥਿਰ STORAGE   → ਹਰ Pod ਨੂੰ ਆਪਣਾ PVC ਮਿਲਦਾ ਹੈ (db-0 restart ਦੌਰਾਨ ਆਪਣਾ disk ਰੱਖਦਾ ਹੈ)
ਕ੍ਰਮਬੱਧ ops    → 0,1,2… ਦੇ ਕ੍ਰਮ ਵਿੱਚ create/scale up; ਉਲਟੇ ਕ੍ਰਮ ਵਿੱਚ terminate
```

## Persistent storage: PV, PVC, StorageClass

```text
StorageClass → "provision ਕਿਵੇਂ ਕਰਨਾ" ਦਾ template (ਜਿਵੇਂ AWS gp3, fast-ssd)
PVC          → storage ਲਈ ਇੱਕ REQUEST ("ਮੈਨੂੰ 20Gi, ReadWriteOnce ਚਾਹੀਦਾ")   ← app-ਪਾਸੇ
PV           → PVC ਨਾਲ bound ਅਸਲ provisioned volume                          ← cluster-ਪਾਸੇ
Dynamic provisioning: StorageClass ਦਾ ਹਵਾਲਾ ਦੇਣ ਵਾਲਾ ਇੱਕ PVC ਆਪਣੇ-ਆਪ ਇੱਕ ਮੇਲ ਖਾਂਦਾ 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)  → ਇੱਕ node ਦੁਆਰਾ read-write mount (ਬਹੁਤਾ block storage: EBS/PD)
ReadOnlyMany (ROX)   → ਕਈ node ਦੁਆਰਾ read-only
ReadWriteMany (RWX)  → ਕਈ node ਦੁਆਰਾ read-write (NFS/CephFS/EFS ਚਾਹੀਦਾ)
⚠ ਇੱਕ StatefulSet ਮਿਟਾਉਣਾ default ਤੌਰ 'ਤੇ ਇਸਦੇ PVC ਨਹੀਂ ਮਿਟਾਉਂਦਾ (data ਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ)।
⚠ Reclaim policy (Retain/Delete) ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ PVC ਹਟਾਉਣ 'ਤੇ PV ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ।
⚠ Kubernetes ਪਛਾਣ+storage ਦਿੰਦਾ ਹੈ, ਪਰ app-level clustering/replication ਤੁਹਾਡਾ ਕੰਮ ਹੈ
  (ਅਕਸਰ ਇੱਕ Operator ਰਾਹੀਂ, ਜਿਵੇਂ Postgres/Kafka ਲਈ)।
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (ਸਥਿਰ, ਕ੍ਰਮਬੱਧ)
```

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

Stateful workload ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਚਲਾਉਣਾ Kubernetes ਦੇ ਔਖੇ ਹਿੱਸਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਇਸ ਲਈ StatefulSets ਅਤੇ persistent storage ਨੂੰ ਸਮਝਣਾ ਅਸਲ production ਨਤੀਜਿਆਂ ਵਾਲਾ senior-level ਗਿਆਨ ਹੈ। ਮੁੱਖ ਸੂਝ ਇਹ ਹੈ ਕਿ Deployments *ਕਿਉਂ* ਘੱਟ ਪੈਂਦੇ ਹਨ: ਉਹਨਾਂ ਦੇ Pod interchangeable ਹਨ (random ਨਾਂ, ਕੋਈ ਵੀ ਕ੍ਰਮ, ਕੋਈ ਹਰ-Pod state ਨਹੀਂ), ਜੋ stateless services ਲਈ ਆਦਰਸ਼ ਹੈ ਪਰ databases ਅਤੇ clustered stores ਲਈ ਗ਼ਲਤ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ **ਸਥਿਰ ਪਛਾਣ** (ਤਾਂ ਜੋ peer `db-0`, `db-1`, `db-2` ਨੂੰ DNS ਦੁਆਰਾ ਲੱਭ ਸਕਣ), **ਆਪਣਾ ਟਿਕਾਊ disk** ਜੋ restart ਅਤੇ reschedule ਤੋਂ ਬਚੇ, ਅਤੇ **ਕ੍ਰਮਬੱਧ, ਨਿਯੰਤਰਿਤ** startup ਤੇ scaling ਚਾਹੀਦੀ ਹੈ। ਇੱਕ **StatefulSet** ਠੀਕ ਇਹੀ ਗਾਰੰਟੀਆਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ storage abstractions ਨਾਲ ਜੋੜੀ ਬਣਾਉਂਦਾ ਹੈ: ਇੱਕ **PersistentVolumeClaim** storage ਲਈ ਐਪਲੀਕੇਸ਼ਨ-ਪਾਸੇ ਦੀ request ਹੈ, ਇੱਕ **PersistentVolume** ਅਸਲ provisioned volume ਹੈ, ਅਤੇ ਇੱਕ **StorageClass** dynamic provisioning ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ — `volumeClaimTemplates` ਹਰ Pod ਨੂੰ ਆਪਣਾ PVC/PV ਦਿੰਦਾ ਹੈ। ਸਾਵਧਾਨੀਆਂ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ senior engineers ਆਪਣੀ ਕੀਮਤ ਕਮਾਉਂਦੇ ਹਨ: **access modes** (RWO ਬਨਾਮ RWX ਅਤੇ ਕਿਹੜੇ backend ਇਹਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ), ਇਹ ਤੱਥ ਕਿ ਇੱਕ StatefulSet ਮਿਟਾਉਣਾ default ਤੌਰ 'ਤੇ **ਇਸਦੇ PVC ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ**, **reclaim policy** ਜੋ PV ਦੀ ਕਿਸਮਤ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ, ਅਤੇ — ਅਹਿਮ ਤੌਰ 'ਤੇ — ਕਿ Kubernetes ਪਛਾਣ ਅਤੇ storage ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਪਰ **application-level replication ਅਤੇ clustering ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਰਹਿੰਦੀ ਹੈ**, ਅਕਸਰ ਇੱਕ Operator ਨੂੰ ਸੌਂਪੀ ਜਾਂਦੀ ਹੈ। ਕਿਉਂਕਿ data ਦੀ ਟਿਕਾਊਤਾ ਅਤੇ ਸਹੀ stateful ਵਿਵਹਾਰ ਬੇਰਹਿਮ ਹੁੰਦੇ ਹਨ (ਗ਼ਲਤੀਆਂ ਦਾ ਮਤਲਬ data loss ਜਾਂ split-brain), StatefulSets, PVs/PVCs, ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸਾਵਧਾਨੀਆਂ ਵਿੱਚ ਮੁਹਾਰਤ Kubernetes 'ਤੇ databases ਅਤੇ ਹੋਰ stateful systems ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਚਲਾਉਣ ਦੀ ਨੀਂਹ ਹੈ।

Deployments ਕਿਉਂ ਕਾਫ਼ੀ ਨਹੀਂ

StatefulSet ਗਾਰੰਟੀਆਂ

Persistent storage: PV, PVC, StorageClass

ਹਰ-Pod storage ਵਾਲਾ ਇੱਕ StatefulSet

Access modes ਅਤੇ ਸਾਵਧਾਨੀਆਂ

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

ਸੰਬੰਧਿਤ ਸਵਾਲ