Apa iku StatefulSet, PersistentVolume/Claim, lan kepiyé sampeyan njalanaké workload stateful ing Kubernetes?

Question

IT Interview Practice · Accepted Answer

Workload stateful (database, antrian, penyimpen berkluster) butuh **identitas sing stabil** lan **penyimpenan sing awèt** — bab-bab sing ora diwènèhaké Deployment. Sawijining **StatefulSet** mènèhi Pod jeneng sing stabil lan siklus urip sing urut; **PersistentVolume (PV)** lan **PersistentVolumeClaim (PVC)** mènèhi dhèwèké penyimpenan sing luwih awèt tinimbang Pod.

## Kenapa Deployment ora cukup

```text
Pod Deployment iku BISA DIGANTI: jeneng acak (web-7f9-abc), urutan bébas, ora nganggo bareng
apa-apa saben-Pod. Iku sampurna kanggo app stateless — nanging replika database butuh:
  → identitas jaringan STABIL (supaya peer bisa nemokaké: db-0, db-1, db-2)
  → disk awèt DHÉWÉ sing tahan restart/rescheduling
  → wiwitan/scaling sing URUT, dikendhaléni (uripaké db-0 sadurungé db-1)
StatefulSet nyedhiyani pas iku.
```

## Jaminan StatefulSet

```text
JENENG stabil    → pod-0, pod-1, pod-2 (ordinal, dudu acak)
DNS stabil       → db-0.db.default.svc... liwat Service headless
STORAGE stabil   → saben Pod nampa PVC-né DHÉWÉ (db-0 njaga disk-é ngliwati restart)
Operasi urut     → gawé/scale up urut 0,1,2…; matèni kanthi kebalikané
```

## Penyimpenan persisten: PV, PVC, StorageClass

```text
StorageClass → tèmplat "carané nyedhiyani" (contoné AWS gp3, fast-ssd)
PVC          → sawijining PANJALUK penyimpenan ("Aku butuh 20Gi, ReadWriteOnce")   ← madhep-app
PV           → volume sing NYATA disedhiyakaké sing kaiket menyang PVC              ← madhep-cluster
Provisioning dinamis: PVC sing ngrujuk StorageClass otomatis nggawé PV sing cocog.

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

## StatefulSet kanthi penyimpenan saben-Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # Service headless kanggo 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:      # saben Pod nampa PVC/PV DHÉWÉ saka tèmplat iki
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Service headless sing mènèhi DNS saben-Pod sing stabil (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Mode akses & bab penting

```text
ReadWriteOnce (RWO)  → di-mount read-write déning SIJI node (umumé block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only déning akèh node
ReadWriteMany (RWX)  → read-write déning akèh node (butuh NFS/CephFS/EFS)
⚠ Mbusak StatefulSet ORA mbusak PVC-né kanthi default (data dilestarèkaké).
⚠ Reclaim policy (Retain/Delete) nemtokaké apa sing kedadéan marang PV nalika PVC dibusak.
⚠ Kubernetes mènèhi identitas+penyimpenan, nanging clustering/replikasi tingkat-app iku TUGAS SAMPEYAN
  (asring liwat Operator, contoné kanggo Postgres/Kafka).
```

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

## Kenapa iki penting

Njalanaké workload stateful kanthi bener iku salah siji bagéyan Kubernetes sing luwih angel, mula ngerti StatefulSet lan penyimpenan persisten yaiku kawruh tingkat senior kanthi akibat production sing nyata. Wawasan intiné yaiku *kenapa* Deployment kurang: Pod-é bisa diganti (jeneng acak, urutan bébas, ora ana state saben-Pod), sing ideal kanggo service stateless nanging salah kanggo database lan penyimpen berkluster sing butuh **identitas stabil** (supaya peer bisa nemokaké `db-0`, `db-1`, `db-2` liwat DNS), **disk awèt dhéwé** sing tahan restart lan rescheduling, lan wiwitan sarta scaling sing **urut, dikendhaléni**. Sawijining **StatefulSet** nyedhiyani pas jaminan iki, lan dhèwèké gandhèng karo abstraksi penyimpenan: **PersistentVolumeClaim** iku panjaluk penyimpenan sing madhep-aplikasi, **PersistentVolume** iku volume sing nyata disedhiyakaké, lan **StorageClass** ngaktifaké provisioning dinamis — kanthi `volumeClaimTemplates` mènèhi saben Pod PVC/PV-né dhéwé. Bab pentingé yaiku ngendi insinyur senior nunjukaké nilaine: **mode akses** (RWO vs RWX lan backend endi sing ndhukung), kanyatan yèn mbusak StatefulSet **nglestarèkaké PVC-né** kanthi default, **reclaim policy** sing ngatur nasib PV, lan — sing krusial — yèn Kubernetes nyedhiyani identitas lan penyimpenan nanging **replikasi lan clustering tingkat-aplikasi tetep tanggung jawab sampeyan**, asring didhelegasi menyang Operator. Amarga daya tahan data lan prilaku stateful sing bener ora ngapura (salah tegesé data ilang utawa split-brain), nguwasani StatefulSet, PV/PVC, lan bab pentingé iku dhasar kanggo njalanaké database lan sistem stateful liyané kanthi andal ing Kubernetes.

Kenapa Deployment ora cukup

Jaminan StatefulSet

Penyimpenan persisten: PV, PVC, StorageClass

StatefulSet kanthi penyimpenan saben-Pod

Mode akses & bab penting

Kenapa iki penting

Pitakon sing gegandhengan