StatefulSets, PersistentVolumes/Claims ni nini, na unaendeshaje stateful workloads kwenye Kubernetes?

Question

IT Interview Practice · Accepted Answer

Stateful workloads (databases, queues, clustered stores) huhitaji **utambulisho thabiti** na **storage ya kudumu** — vitu ambavyo Deployment haitoi. **StatefulSet** hupa Pods majina thabiti na mzunguko wa maisha wenye mpangilio; **PersistentVolumes (PV)** na **PersistentVolumeClaims (PVC)** huzipa storage inayoishi zaidi ya Pod.

## Kwa nini Deployments hazitoshi

```text
Pods za Deployment zinaBADILISHANIKA: majina ya nasibu (web-7f9-abc), mpangilio wowote, hazishiriki
chochote kwa kila Pod. Hiyo ni kamili kwa apps za stateless — lakini replica ya database huhitaji:
  → utambulisho THABITI wa mtandao (ili peers ziipate: db-0, db-1, db-2)
  → disk YAKE ya kudumu inayoishi restarts/rescheduling
  → kuanza/scaling kwa MPANGILIO, kunakodhibitiwa (leta db-0 kabla ya db-1)
StatefulSet hutoa hasa haya.
```

## Uhakikisho wa StatefulSet

```text
NAMES thabiti     → pod-0, pod-1, pod-2 (ordinal, si nasibu)
DNS thabiti       → db-0.db.default.svc... kupitia headless Service
STORAGE thabiti   → kila Pod hupata PVC YAKE (db-0 huhifadhi disk yake kwenye restarts)
Ops zenye mpangilio → unda/scale up kwa mpangilio 0,1,2…; zima kwa mpangilio wa nyuma
```

## Storage ya kudumu: PV, PVC, StorageClass

```text
StorageClass → template ya "jinsi ya kutoa" (mfano AWS gp3, fast-ssd)
PVC          → OMBI la storage ("Nahitaji 20Gi, ReadWriteOnce")   ← inayoelekea app
PV           → volume HALISI iliyotolewa iliyofungwa kwa PVC       ← inayoelekea cluster
Dynamic provisioning: PVC inayorejelea StorageClass huunda PV inayolingana kiotomatiki.

App → PVC → (StorageClass hutoa) → PV → disk halisi (EBS, PD, Ceph, NFS…)
```

## StatefulSet yenye storage kwa kila Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service kwa DNS thabiti
  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:      # kila Pod hupata PVC/PV YAKE kutoka template hii
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Headless Service inayotoa DNS thabiti kwa kila Pod (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 na tahadhari

```text
ReadWriteOnce (RWO)  → imewekwa read-write na node MOJA (block storage nyingi: EBS/PD)
ReadOnlyMany (ROX)   → read-only na nodes nyingi
ReadWriteMany (RWX)  → read-write na nodes nyingi (huhitaji NFS/CephFS/EFS)
⚠ Kufuta StatefulSet HAKUFUTI PVCs zake kwa chaguo-msingi (data huhifadhiwa).
⚠ Reclaim policy (Retain/Delete) huamua nini hutokea kwa PV wakati PVC inaondolewa.
⚠ Kubernetes hutoa utambulisho+storage, lakini clustering/replication ya kiwango cha app ni KAZI YAKO
  (mara nyingi kupitia Operator, mfano kwa Postgres/Kafka).
```

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

## Kwa nini ni muhimu

Kuendesha stateful workloads kwa usahihi ni moja ya sehemu ngumu zaidi za Kubernetes, hivyo kuelewa StatefulSets na storage ya kudumu ni maarifa ya ngazi ya juu yenye matokeo halisi ya production. Ufahamu wa msingi ni *kwa nini* Deployments hazitoshi: Pods zao zinabadilishanika (majina ya nasibu, mpangilio wowote, hakuna hali kwa kila Pod), ambayo ni bora kwa services za stateless lakini si sahihi kwa databases na clustered stores zinazohitaji **utambulisho thabiti** (ili peers zipate `db-0`, `db-1`, `db-2` kwa DNS), **disk yao ya kudumu** inayoishi restarts na rescheduling, na kuanza na scaling **kwa mpangilio, kunakodhibitiwa**. **StatefulSet** hutoa hasa uhakikisho huu, na huoana na storage abstractions: **PersistentVolumeClaim** ni ombi linaloelekea programu la storage, **PersistentVolume** ni volume halisi iliyotolewa, na **StorageClass** huwezesha dynamic provisioning — na `volumeClaimTemplates` ikipa kila Pod PVC/PV yake. Tahadhari ndipo wahandisi wa ngazi ya juu wanapopata thamani yao: **access modes** (RWO dhidi ya RWX na backends zipi huzisaidia), ukweli kwamba kufuta StatefulSet **huhifadhi PVCs zake** kwa chaguo-msingi, **reclaim policy** inayotawala hatima ya PV, na — muhimu — kwamba Kubernetes hutoa utambulisho na storage lakini **replication na clustering ya kiwango cha app hubaki jukumu lako**, mara nyingi ikikabidhiwa kwa Operator. Kwa kuwa udumu wa data na tabia sahihi ya stateful hazisamehe (makosa humaanisha kupoteza data au split-brain), kumudu StatefulSets, PVs/PVCs, na tahadhari zao ni msingi wa kuendesha databases na mifumo mingine ya stateful kwa uaminifu kwenye Kubernetes.

Kwa nini Deployments hazitoshi

Uhakikisho wa StatefulSet

Storage ya kudumu: PV, PVC, StorageClass

StatefulSet yenye storage kwa kila Pod

Access modes na tahadhari

Kwa nini ni muhimu

Maswali yanayohusiana