Apa itu StatefulSet, PersistentVolume/Claim, dan bagaimana menjalankan workload stateful di Kubernetes?

Question

IT Interview Practice · Accepted Answer

Workload stateful (database, queue, penyimpanan berbasis cluster) membutuhkan **identitas yang stabil** dan **storage yang tahan lama** — hal yang tidak disediakan Deployment. Sebuah **StatefulSet** memberi Pod nama yang stabil dan siklus hidup terurut; **PersistentVolume (PV)** dan **PersistentVolumeClaim (PVC)** memberi mereka storage yang bertahan melampaui umur Pod.

## Mengapa Deployment tidak cukup

```text
Pod Deployment SALING BERTUKARAN: nama acak (web-7f9-abc), urutan bebas, tak berbagi
apa pun per-Pod. Itu sempurna untuk app stateless — tapi sebuah replica database butuh:
  → identitas jaringan STABIL (agar peer bisa menemukannya: db-0, db-1, db-2)
  → disk tahan lama MILIKNYA SENDIRI yang bertahan lewat restart/rescheduling
  → startup/scaling yang TERURUT dan terkendali (nyalakan db-0 sebelum db-1)
StatefulSet menyediakan persis hal-hal ini.
```

## Jaminan StatefulSet

```text
NAMA stabil      → pod-0, pod-1, pod-2 (ordinal, bukan acak)
DNS stabil       → db-0.db.default.svc... via sebuah headless Service
STORAGE stabil   → tiap Pod dapat PVC-nya SENDIRI (db-0 menjaga disk-nya lewat restart)
Operasi terurut  → create/scale up dengan urutan 0,1,2…; terminasi terbalik
```

## Persistent storage: PV, PVC, StorageClass

```text
StorageClass → template "cara provisioning" (mis. AWS gp3, fast-ssd)
PVC          → sebuah PERMINTAAN storage ("Saya butuh 20Gi, ReadWriteOnce")  ← sisi app
PV           → volume yang SESUNGGUHNYA di-provision, terikat ke PVC          ← sisi cluster
Dynamic provisioning: PVC yang mereferensi StorageClass otomatis membuat PV yang cocok.

App → PVC → (StorageClass provisioning) → PV → disk nyata (EBS, PD, Ceph, NFS…)
```

## Sebuah StatefulSet dengan storage per-Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service untuk DNS stabil
  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:      # tiap Pod dapat PVC/PV-nya SENDIRI dari template ini
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# headless Service yang memberi DNS per-Pod stabil (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Access mode & catatan

```text
ReadWriteOnce (RWO)  → di-mount read-write oleh SATU node (kebanyakan block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only oleh banyak node
ReadWriteMany (RWX)  → read-write oleh banyak node (butuh NFS/CephFS/EFS)
⚠ Menghapus StatefulSet TIDAK menghapus PVC-nya secara default (data dipertahankan).
⚠ Reclaim policy (Retain/Delete) menentukan nasib PV ketika PVC dihapus.
⚠ Kubernetes memberi identitas+storage, tapi clustering/replikasi level-app adalah TUGAS ANDA
  (sering via sebuah Operator, mis. untuk Postgres/Kafka).
```

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

## Mengapa ini penting

Menjalankan workload stateful dengan benar adalah salah satu bagian tersulit di Kubernetes, sehingga memahami StatefulSet dan persistent storage adalah pengetahuan level senior dengan konsekuensi production yang nyata. Wawasan intinya adalah *mengapa* Deployment kurang memadai: Pod-nya saling bertukaran (nama acak, urutan bebas, tanpa state per-Pod), yang ideal untuk service stateless tapi salah untuk database dan penyimpanan berbasis cluster yang membutuhkan **identitas stabil** (agar peer bisa menemukan `db-0`, `db-1`, `db-2` lewat DNS), **disk tahan lama miliknya sendiri** yang bertahan lewat restart dan rescheduling, serta startup dan scaling yang **terurut dan terkendali**. Sebuah **StatefulSet** menyediakan persis jaminan ini, dan ia berpasangan dengan abstraksi storage: sebuah **PersistentVolumeClaim** adalah permintaan storage dari sisi aplikasi, sebuah **PersistentVolume** adalah volume yang sesungguhnya di-provision, dan sebuah **StorageClass** memungkinkan dynamic provisioning — dengan `volumeClaimTemplates` memberi tiap Pod PVC/PV-nya sendiri. Catatan-catatan itulah tempat insinyur senior membuktikan nilainya: **access mode** (RWO vs RWX dan backend mana yang mendukungnya), fakta bahwa menghapus StatefulSet **mempertahankan PVC-nya** secara default, **reclaim policy** yang mengatur nasib PV, dan — yang krusial — bahwa Kubernetes menyediakan identitas dan storage tetapi **replikasi dan clustering level-aplikasi tetap tanggung jawab Anda**, sering didelegasikan ke sebuah Operator. Karena daya tahan data dan perilaku stateful yang benar tidak mengenal ampun (kesalahan berarti kehilangan data atau split-brain), menguasai StatefulSet, PV/PVC, dan catatan-catatannya adalah fondasi untuk menjalankan database dan sistem stateful lain secara andal di Kubernetes.

Mengapa Deployment tidak cukup

Jaminan StatefulSet

Persistent storage: PV, PVC, StorageClass

Sebuah StatefulSet dengan storage per-Pod

Access mode & catatan

Mengapa ini penting

Pertanyaan terkait