StatefulSet — workload ที่มี identity (+ Lab)
ฐานข้อมูล/คิวที่แต่ละ Pod ต้องมีชื่อและ storage คงที่
พื้นฐานที่ควรรู้: แอปพลิเคชันทั่วไปมักเป็นแบบ "Stateless" คือไม่ต้องจำสถานะใดๆ ใครจะมาแทนใครก็ได้ แต่สำหรับแอปอย่างฐานข้อมูล (Database) เราต้องการให้แอปจำได้ว่าใครเป็น Master ใครเป็น Slave และแต่อะตัวต้องมีพื้นที่เก็บข้อมูลของตัวเองไม่ปะปนกัน (Stateful)
Deployment ปฏิบัติกับ Pod เหมือนพนักงานชั่วคราวที่สลับกันได้ (ใครก็ได้) · StatefulSet เหมือนพนักงานที่มีโต๊ะประจำและชื่อประจำ — Pod-0, Pod-1, Pod-2 มีลำดับและ storage เป็นของตัวเองไม่สลับกัน
งานที่มี state (ฐานข้อมูล, Kafka, Redis cluster) ต้องการ 3 อย่างที่ Deployment ให้ไม่ได้: ชื่อ/ลำดับคงที่, storage ติดตัวแต่ละ Pod, และการสร้าง/ลบตามลำดับ · StatefulSet ให้ครบ
แต่ละ Pod มีชื่อคงที่ + PVC ของตัวเอง ไม่สลับกัน
สร้างตามลำดับ 0→1→2 · Pod สร้างใหม่ได้ PVC เดิมกลับมา
- ชื่อคงที่ — Pod ชื่อ
<name>-0,-1,-2ตามลำดับ (ไม่สุ่มเหมือน Deployment) - storage ติดตัว — แต่ละ Pod ได้ PVC ของตัวเอง ที่ผูกกลับมาแม้ Pod สร้างใหม่
- ลำดับ — สร้าง 0→1→2, ลบ 2→1→0 (สำคัญกับ cluster ที่มี leader/follower)
- มักคู่กับ Headless Service (clusterIP: None) เพื่อให้เข้าถึงแต่ละ Pod ตรง ๆ ด้วยชื่อ
สรุป Key Takeaways
- StatefulSet = workload ที่ต้องมี identity คงที่ + storage ติดตัว + ลำดับ (DB, Kafka, Redis)
- Pod มีชื่อคงที่ (name-0/1/2) และ PVC ของตัวเองที่ผูกกลับมา
- มักคู่กับ Headless Service · stateless ทั่วไปยังใช้ Deployment
- พิจารณา managed DB ของ cloud ก่อนรัน DB เองบน K8s
คำถามที่พบบ่อย
StatefulSet ต่างจาก Deployment ตรงไหน
สามอย่างที่ Deployment ไม่ให้: (1) ชื่อ pod คงที่มีลำดับ (db-0, db-1) (2) แต่ละ pod มี PVC ของตัวเองที่ตามตัวไปตลอด (3) เกิด/ตายตามลำดับ — จำเป็นกับระบบที่ replica ไม่เท่ากัน (database primary/replica, Kafka broker) ส่วนแอป stateless ใช้ Deployment เสมอ
แอปธรรมดาต่อฐานข้อมูล ต้องเป็น StatefulSet ไหม
ไม่ — แอปที่ "เรียกใช้" ฐานข้อมูลภายนอก (RDS ฯลฯ) เป็น stateless ใช้ Deployment ปกติ StatefulSet ใช้เฉพาะเมื่อ "ตัวแอปเอง" ถือ state ติดดิสก์ที่แยกตาม replica — และในทางปฏิบัติ ฐานข้อมูล production บน cloud มักใช้ managed service แทนการรันเองใน cluster