StatefulSets, PersistentVolumes/Claims શું છે, અને તમે Kubernetes પર stateful workloads કેવી રીતે ચલાવો છો?

Question

IT Interview Practice · Accepted Answer

Stateful workloads (databases, queues, clustered stores) ને **સ્થિર identity** અને **ટકાઉ 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
```

## 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            # સ્થિર 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 જે સ્થિર 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 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 (stable, ordered)
```

## આ શા માટે મહત્વનું છે

Stateful workloads ને યોગ્ય રીતે ચલાવવું એ Kubernetes ના વધુ કઠિન ભાગોમાંનું એક છે, તેથી StatefulSets અને persistent storage સમજવું એ વાસ્તવિક production પરિણામો સાથેનું senior-level જ્ઞાન છે. મુખ્ય સૂઝ એ છે કે Deployments *કેમ* ઓછાં પડે છે: તેમના Pods interchangeable છે (random નામો, કોઈપણ ક્રમ, per-Pod state નહીં), જે stateless services માટે આદર્શ છે પણ databases અને clustered stores માટે ખોટું છે જેમને **સ્થિર identity** (જેથી peers `db-0`, `db-1`, `db-2` ને DNS દ્વારા શોધી શકે), **પોતાની ટકાઉ disk** જે restarts અને rescheduling થી બચે, અને **ક્રમબદ્ધ, નિયંત્રિત** startup અને scaling જોઈએ છે. એક **StatefulSet** બરાબર આ જ ખાતરીઓ પૂરી પાડે છે, અને તે storage abstractions સાથે જોડાય છે: એક **PersistentVolumeClaim** એ storage માટેની application-facing વિનંતી છે, એક **PersistentVolume** એ ખરેખરું provision કરેલું volume છે, અને એક **StorageClass** dynamic provisioning સક્ષમ કરે છે — `volumeClaimTemplates` દરેક Pod ને પોતાનું PVC/PV આપતાં. ચેતવણીઓ એ છે જ્યાં senior engineers પોતાની કિંમત સાબિત કરે છે: **access modes** (RWO vs RWX અને કયા backends તેમને support કરે છે), એ હકીકત કે StatefulSet delete કરવાથી default માં **તેના PVCs જળવાય છે**, PV ના ભાવિ ને નિયંત્રિત કરતી **reclaim policy**, અને — નિર્ણાયક રીતે — કે Kubernetes identity અને storage પૂરાં પાડે છે પણ **application-level replication અને clustering તમારી જવાબદારી રહે છે**, જે ઘણી વાર Operator ને સોંપાય છે. કારણ કે data durability અને યોગ્ય stateful વર્તન ક્ષમાહીન છે (ભૂલો એટલે data loss કે split-brain), StatefulSets, PVs/PVCs, અને તેમની ચેતવણીઓ પર પ્રભુત્વ મેળવવું એ Kubernetes પર databases અને બીજી stateful systems ને reliable રીતે ચલાવવા માટે પાયાનું છે.

Deployments કેમ પૂરતાં નથી

StatefulSet ખાતરીઓ

Persistent storage: PV, PVC, StorageClass

per-Pod storage સાથે એક StatefulSet

Access modes અને ચેતવણીઓ

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો