Apakah itu StatefulSet, PersistentVolume/Claim, dan bagaimana anda menjalankan workload stateful pada Kubernetes?

Question

IT Interview Practice · Accepted Answer

Workload stateful (pangkalan data, baris gilir, stor berkluster) memerlukan **identiti stabil** dan **storan tahan lama** — perkara yang tidak disediakan oleh Deployment. Sebuah **StatefulSet** memberi Pod nama stabil dan kitaran hayat berturutan; **PersistentVolume (PV)** dan **PersistentVolumeClaim (PVC)** memberi mereka storan yang hidup lebih lama daripada Pod.

## Mengapa Deployment tidak mencukupi

```text
Pod Deployment BOLEH DITUKAR GANTI: nama rawak (web-7f9-abc), sebarang susunan, tidak
berkongsi apa-apa setiap Pod. Itu sempurna untuk app stateless — tetapi satu replika pangkalan data perlukan:
  → satu identiti rangkaian yang STABIL (supaya rakan boleh menemuinya: db-0, db-1, db-2)
  → cakera tahan lama SENDIRI yang bertahan restart/penjadualan semula
  → permulaan/penskalaan BERTURUTAN dan terkawal (naikkan db-0 sebelum db-1)
StatefulSet menyediakan tepat perkara ini.
```

## Jaminan StatefulSet

```text
NAMA stabil      → pod-0, pod-1, pod-2 (ordinal, bukan rawak)
DNS stabil       → db-0.db.default.svc... melalui headless Service
STORAN stabil    → setiap Pod dapat PVC SENDIRI (db-0 kekalkan cakeranya merentas restart)
Op bertutur      → cipta/scale naik ikut susunan 0,1,2…; tamatkan secara songsang
```

## Storan kekal: PV, PVC, StorageClass

```text
StorageClass → templat "cara memperuntukkan" (cth. AWS gp3, fast-ssd)
PVC          → satu PERMINTAAN untuk storan ("Saya perlu 20Gi, ReadWriteOnce")   ← menghadap-app
PV           → volume SEBENAR yang diperuntukkan terikat pada PVC                 ← menghadap-cluster
Peruntukan dinamik: satu PVC yang merujuk StorageClass mencipta-auto satu PV yang sepadan.

App → PVC → (StorageClass memperuntukkan) → PV → cakera sebenar (EBS, PD, Ceph, NFS…)
```

## Sebuah StatefulSet dengan storan setiap-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:      # setiap Pod dapat PVC/PV SENDIRI daripada templat ini
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Headless Service yang memberi DNS stabil setiap-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 mode & amaran

```text
ReadWriteOnce (RWO)  → dilekapkan baca-tulis oleh SATU node (kebanyakan block storage: EBS/PD)
ReadOnlyMany (ROX)   → baca-sahaja oleh banyak node
ReadWriteMany (RWX)  → baca-tulis oleh banyak node (perlukan NFS/CephFS/EFS)
⚠ Memadam satu StatefulSet secara default TIDAK memadam PVC-nya (data dipelihara).
⚠ Reclaim policy (Retain/Delete) memutuskan apa berlaku kepada PV apabila PVC dibuang.
⚠ Kubernetes memberi identiti+storan, tetapi clustering/replication peringkat-app ialah KERJA ANDA
  (selalu melalui Operator, cth. untuk Postgres/Kafka).
```

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

## Mengapa ia penting

Menjalankan workload stateful dengan betul ialah salah satu bahagian Kubernetes yang lebih sukar, jadi memahami StatefulSet dan storan kekal ialah pengetahuan peringkat senior dengan akibat production yang sebenar. Pandangan teras ialah *mengapa* Deployment tidak memadai: Pod-nya boleh ditukar ganti (nama rawak, sebarang susunan, tiada keadaan setiap-Pod), yang ideal untuk perkhidmatan stateless tetapi salah untuk pangkalan data dan stor berkluster yang memerlukan **identiti stabil** (supaya rakan boleh menemui `db-0`, `db-1`, `db-2` melalui DNS), **cakera tahan lama sendiri** yang bertahan restart dan penjadualan semula, dan permulaan serta penskalaan yang **bertutur dan terkawal**. Sebuah **StatefulSet** menyediakan tepat jaminan ini, dan ia berpadan dengan abstraksi storan: sebuah **PersistentVolumeClaim** ialah permintaan storan yang menghadap aplikasi, sebuah **PersistentVolume** ialah volume sebenar yang diperuntukkan, dan sebuah **StorageClass** membolehkan peruntukan dinamik — dengan `volumeClaimTemplates` memberi setiap Pod PVC/PV sendiri. Amaran ialah tempat jurutera senior membuktikan nilai mereka: **access mode** (RWO berbanding RWX dan backend mana menyokongnya), fakta bahawa memadam satu StatefulSet **memelihara PVC-nya** secara default, **reclaim policy** yang mengawal nasib PV, dan — secara kritikal — bahawa Kubernetes menyediakan identiti dan storan tetapi **replication dan clustering peringkat aplikasi kekal tanggungjawab anda**, selalu diserahkan kepada Operator. Kerana ketahanan data dan kelakuan stateful yang betul tidak berbelas kasihan (kesilapan bermakna kehilangan data atau split-brain), menguasai StatefulSet, PV/PVC, dan amarannya adalah asas untuk menjalankan pangkalan data dan sistem stateful lain dengan boleh dipercayai pada Kubernetes.

Mengapa Deployment tidak mencukupi

Jaminan StatefulSet

Storan kekal: PV, PVC, StorageClass

Sebuah StatefulSet dengan storan setiap-Pod

Access mode & amaran

Mengapa ia penting

Soalan berkaitan