Menene StatefulSets, PersistentVolumes/Claims, kuma yaya kake gudanar da stateful workloads a kan Kubernetes?

Question

IT Interview Practice · Accepted Answer

Stateful workloads (databases, queues, clustered stores) suna buƙatar **tantancewa mai ƙarko** da **storage mai dorewa** — abubuwan da Deployment ba ya bayarwa. **StatefulSet** yana ba Pod sunaye masu ƙarko da tsari na tsawon rayuwa; **PersistentVolumes (PV)** da **PersistentVolumeClaims (PVC)** suna ba su storage da ke rayuwa fiye da Pod.

## Me ya sa Deployments ba su isa ba

```text
Pod na Deployment ana iya MUSANYA su: sunaye bazuwar (web-7f9-abc), kowane tsari, ba sa raba
komai ga kowane Pod. Wannan cikakke ne ga app masu stateless — amma replica na database yana buƙatar:
  → tantancewar hanyar sadarwa MAI ƘARKO (don takwarorinsa su same shi: db-0, db-1, db-2)
  → NASA diski mai dorewa da ke rayuwa a sake kunnawa/sake tsarawa
  → farawa/scaling MAI TSARI, mai sarrafawa (kunna db-0 kafin db-1)
StatefulSet yana bayar da ainihin waɗannan.
```

## Tabbatattun StatefulSet

```text
SUNAYE masu ƙarko  → pod-0, pod-1, pod-2 (na jere, ba bazuwar ba)
DNS mai ƙarko      → db-0.db.default.svc... ta headless Service
STORAGE mai ƙarko  → kowane Pod yana samun NASA PVC (db-0 yana riƙe diski a sake kunnawa)
Ayyuka masu tsari  → ƙirƙira/scale up cikin tsari 0,1,2…; dakatarwa a baya
```

## Storage mai dorewa: PV, PVC, StorageClass

```text
StorageClass → template na "yadda ake samarwa" (misali AWS gp3, fast-ssd)
PVC          → BUƘATA ta storage ("Ina buƙatar 20Gi, ReadWriteOnce")   ← na app
PV           → ainihin volume da aka samar wanda ke ɗaure da PVC          ← na cluster
Dynamic provisioning: PVC da ke nuni ga StorageClass yana ƙirƙira PV mai daidaituwa kai tsaye.

App → PVC → (StorageClass yana samarwa) → PV → ainihin diski (EBS, PD, Ceph, NFS…)
```

## StatefulSet mai storage ga kowane Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service don DNS mai ƙarko
  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:      # kowane Pod yana samun NASA PVC/PV daga wannan template
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# headless Service da ke ba da DNS mai ƙarko ga kowane 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 & gargaɗi

```text
ReadWriteOnce (RWO)  → an ɗora read-write ta node ƊAYA (yawancin block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only ta nodes da yawa
ReadWriteMany (RWX)  → read-write ta nodes da yawa (yana buƙatar NFS/CephFS/EFS)
⚠ Share StatefulSet BA ya share PVC nasa ta tsoho (ana kiyaye bayanai).
⚠ Reclaim policy (Retain/Delete) yana yanke abin da ke faruwa ga PV lokacin da aka cire PVC.
⚠ Kubernetes yana ba da tantancewa+storage, amma clustering/replication na matakin app ALHAKINKA ne
  (galibi ta Operator, misali ga Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (mai ƙarko, mai tsari)
```

## Me ya sa yake da muhimmanci

Gudanar da stateful workloads daidai yana ɗaya daga cikin mafi wuyar ɓangarorin Kubernetes, don haka fahimtar StatefulSets da storage mai dorewa ilimi ne na matakin senior mai ainihin sakamakon production. Ainihin fahimta shine *me ya sa* Deployments suka gaza: Pod ɗinsu ana iya musanya su (sunaye bazuwar, kowane tsari, babu yanayin kowane Pod), wanda cikakke ne ga service masu stateless amma kuskure ne ga databases da clustered stores waɗanda ke buƙatar **tantancewa mai ƙarko** (don takwarorinsa su sami `db-0`, `db-1`, `db-2` ta DNS), **nasu diski mai dorewa** da ke rayuwa a sake kunnawa da sake tsarawa, da farawa da scaling **masu tsari, masu sarrafawa**. **StatefulSet** yana bayar da ainihin waɗannan tabbatattu, kuma yana haɗuwa da abstraction na storage: **PersistentVolumeClaim** shine buƙatar storage da ke fuskantar aikace-aikace, **PersistentVolume** shine ainihin volume da aka samar, kuma **StorageClass** yana ba da damar dynamic provisioning — da `volumeClaimTemplates` da ke ba kowane Pod nasa PVC/PV. Gargaɗin su ne inda injiniyoyi na senior ke samun ladarsu: **access modes** (RWO da RWX da wanne backend ke tallafa musu), gaskiyar cewa share StatefulSet yana **kiyaye PVC nasa** ta tsoho, **reclaim policy** da ke shiryar da makomar PV, kuma — mafi muhimmanci — cewa Kubernetes yana ba da tantancewa da storage amma **replication da clustering na matakin aikace-aikace na ci gaba da zama alhakinka**, galibi ana wakilta shi ga Operator. Saboda dorewar bayanai da hali na stateful daidai ba su gafarta ba (kurakurai na nufin asarar bayanai ko split-brain), ƙware StatefulSets, PV/PVC, da gargaɗinsu na tushe ne don gudanar da databases da sauran tsarin stateful cikin aminci a kan Kubernetes.

Me ya sa Deployments ba su isa ba

Tabbatattun StatefulSet

Storage mai dorewa: PV, PVC, StorageClass

StatefulSet mai storage ga kowane Pod

Access modes & gargaɗi

Me ya sa yake da muhimmanci

Tambayoyi masu alaƙa