StatefulSet, PersistentVolume/Claim คืออะไร และคุณรัน workload แบบ stateful บน Kubernetes อย่างไร?

Question

IT Interview Practice · Accepted Answer

Workload แบบ stateful (ฐานข้อมูล, queue, store แบบ cluster) ต้องการ **อัตลักษณ์ที่เสถียร** และ **storage ที่คงทน** — สิ่งที่ Deployment ไม่ได้ให้ **StatefulSet** ให้ Pod มีชื่อที่เสถียรและวงจรชีวิตแบบมีลำดับ; **PersistentVolume (PV)** และ **PersistentVolumeClaim (PVC)** ให้ storage ที่อยู่ได้นานกว่า Pod

## ทำไม Deployment จึงไม่พอ

```text
Pod ของ Deployment สับเปลี่ยนกันได้ (INTERCHANGEABLE): ชื่อสุ่ม (web-7f9-abc), ลำดับใดก็ได้,
ไม่แชร์อะไรต่อ Pod นั่นเหมาะกับแอป stateless — แต่ replica ของฐานข้อมูลต้องการ:
  → อัตลักษณ์เครือข่ายที่เสถียร (STABLE) (เพื่อให้ peer หากันเจอ: db-0, db-1, db-2)
  → ดิสก์คงทนของตัวเอง (OWN) ที่รอดผ่าน restart/reschedule
  → การเริ่ม/scale ที่มีลำดับ (ORDERED) และควบคุมได้ (ยก db-0 ขึ้นก่อน db-1)
StatefulSet ให้สิ่งเหล่านี้พอดี
```

## การรับประกันของ StatefulSet

```text
ชื่อที่เสถียร (NAMES)   → pod-0, pod-1, pod-2 (ตามลำดับ ไม่สุ่ม)
DNS ที่เสถียร          → db-0.db.default.svc... ผ่าน headless Service
STORAGE ที่เสถียร      → แต่ละ Pod ได้ PVC ของตัวเอง (db-0 เก็บดิสก์ของมันข้าม restart)
ops แบบมีลำดับ         → สร้าง/scale ขึ้นตามลำดับ 0,1,2…; ยุติในลำดับย้อนกลับ
```

## storage คงทน: PV, PVC, StorageClass

```text
StorageClass → template "จะจัดหาอย่างไร" (เช่น AWS gp3, fast-ssd)
PVC          → คำขอ (REQUEST) storage ("ฉันต้องการ 20Gi, ReadWriteOnce")   ← ฝั่งแอป
PV           → volume ที่จัดหาจริง (ACTUAL) ที่ผูกกับ PVC                    ← ฝั่ง cluster
dynamic provisioning: PVC ที่อ้าง StorageClass จะสร้าง PV ที่ตรงกันอัตโนมัติ

App → PVC → (StorageClass provisions) → PV → ดิสก์จริง (EBS, PD, Ceph, NFS…)
```

## StatefulSet ที่มี storage ต่อ Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service สำหรับ DNS ที่เสถียร
  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:      # แต่ละ Pod ได้ PVC/PV ของตัวเองจาก template นี้
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# headless Service ที่ให้ DNS ที่เสถียรต่อ 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 & ข้อควรระวัง

```text
ReadWriteOnce (RWO)  → mount อ่าน-เขียนโดย node เดียว (block storage ส่วนใหญ่: EBS/PD)
ReadOnlyMany (ROX)   → อ่านอย่างเดียวโดยหลาย node
ReadWriteMany (RWX)  → อ่าน-เขียนโดยหลาย node (ต้องใช้ NFS/CephFS/EFS)
⚠ การลบ StatefulSet โดยค่าเริ่มต้นไม่ลบ PVC ของมัน (ข้อมูลถูกเก็บไว้)
⚠ Reclaim policy (Retain/Delete) ตัดสินว่าเกิดอะไรกับ PV เมื่อ PVC ถูกถอด
⚠ Kubernetes ให้อัตลักษณ์+storage แต่ clustering/replication ระดับแอปเป็นงานของคุณ
  (มักผ่าน Operator เช่นสำหรับ Postgres/Kafka)
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (เสถียร, มีลำดับ)
```

## ทำไมจึงสำคัญ

การรัน workload แบบ stateful อย่างถูกต้องเป็นหนึ่งในส่วนที่ยากกว่าของ Kubernetes ดังนั้นการเข้าใจ StatefulSet และ storage คงทนจึงเป็นความรู้ระดับ senior ที่มีผลต่อ production จริง ประเด็นหลักคือ *ทำไม* Deployment จึงไม่พอ: Pod ของมันสับเปลี่ยนกันได้ (ชื่อสุ่ม, ลำดับใดก็ได้, ไม่มี state ต่อ Pod) ซึ่งเหมาะกับ service แบบ stateless แต่ผิดสำหรับฐานข้อมูลและ store แบบ cluster ที่ต้องการ **อัตลักษณ์ที่เสถียร** (เพื่อให้ peer หา `db-0`, `db-1`, `db-2` เจอผ่าน DNS), **ดิสก์คงทนของตัวเอง** ที่รอดผ่าน restart และ reschedule และการเริ่มกับ scale **แบบมีลำดับและควบคุมได้** **StatefulSet** ให้การรับประกันเหล่านี้พอดี และมันจับคู่กับชั้นนามธรรมของ storage: **PersistentVolumeClaim** คือคำขอ storage ฝั่งแอปพลิเคชัน, **PersistentVolume** คือ volume ที่จัดหาจริง และ **StorageClass** เปิดให้ dynamic provisioning — โดย `volumeClaimTemplates` ให้แต่ละ Pod มี PVC/PV ของตัวเอง ข้อควรระวังคือที่ที่วิศวกร senior พิสูจน์คุณค่า: **access mode** (RWO เทียบกับ RWX และ backend ไหนรองรับ), ข้อเท็จจริงที่ว่าการลบ StatefulSet โดยค่าเริ่มต้น **เก็บ PVC ไว้**, **reclaim policy** ที่กำหนดชะตากรรมของ PV และ — ที่สำคัญที่สุด — ว่า Kubernetes ให้อัตลักษณ์และ storage แต่ **replication และ clustering ระดับแอปพลิเคชันยังเป็นความรับผิดชอบของคุณ** ซึ่งมักมอบหมายให้ Operator เพราะความคงทนของข้อมูลและพฤติกรรม stateful ที่ถูกต้องไม่ให้อภัย (ผิดพลาดหมายถึงข้อมูลสูญหายหรือ split-brain) การเชี่ยวชาญ StatefulSet, PV/PVC และข้อควรระวังของมันจึงเป็นรากฐานของการรันฐานข้อมูลและระบบ stateful อื่น ๆ อย่างน่าเชื่อถือบน Kubernetes

ทำไม Deployment จึงไม่พอ

การรับประกันของ StatefulSet

storage คงทน: PV, PVC, StorageClass

StatefulSet ที่มี storage ต่อ Pod

access mode & ข้อควรระวัง

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง