Probes — ตรวจสุขภาพ Pod
liveness / readiness / startup บอก K8s ว่า Pod พร้อมหรือป่วย
พื้นฐานที่ควรรู้: บางครั้งแอปพลิเคชันอาจไม่ได้ "พัง" จนโปรแกรมปิดไป แต่อาจจะแค่ "ค้าง" (Hang) หรือกำลังใช้เวลาเริ่มต้นระบบ (Booting) อยู่ K8s ต้องการวิธีตรวจสุขภาพเพื่อจะได้รู้ว่าเมื่อไหร่ควรจะส่งผู้ใช้งานเข้ามา และเมื่อไหร่ควรจะรีสตาร์ทแอปทิ้ง
เหมือนหมอตรวจคนไข้: liveness = "ยังมีชีพจรไหม" (ไม่มี → ปั๊มหัวใจ/restart) · readiness = "พร้อมทำงานรับแขกหรือยัง" (ไม่พร้อม → พักไว้ก่อน ยังไม่ส่งงานให้) · startup = "ให้เวลาฟื้นตอนเพิ่งตื่น" (แอปที่บูตนาน)
K8s รู้ว่า container "รันอยู่" แต่ไม่รู้ว่ามัน "ทำงานได้จริง" ไหม · Probes คือการตรวจสุขภาพที่เราสั่งให้ K8s ยิงเช็คเป็นระยะ
3 probe หน้าที่ต่างกัน
- livenessProbe — เช็คว่ายังมีชีวิต ถ้าล้มเหลวต่อเนื่อง K8s restart container
- readinessProbe — เช็คว่าพร้อมรับ traffic ไหม ถ้าไม่พร้อม ถอด Pod ออกจาก Service ชั่วคราว (ไม่ส่ง request มา) แต่ไม่ restart
- startupProbe — สำหรับแอปที่บูตนาน กัน liveness เช็คเร็วเกินจน restart วนไม่จบ
readinessProbe:
httpGet: { path: /healthz, port: 8080 }
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet: { path: /healthz, port: 8080 }
initialDelaySeconds: 15
periodSeconds: 20สรุป Key Takeaways
- liveness ล้มเหลว → restart container · readiness ล้มเหลว → เลิกส่ง traffic (ไม่ restart)
- startupProbe สำหรับแอปบูตนาน กัน liveness ฆ่าก่อนพร้อม
- readiness ช่วยให้ rolling update ไม่ส่ง traffic ให้ Pod ที่ยังไม่พร้อม
คำถามที่พบบ่อย
liveness กับ readiness probe ต่างกันยังไง ใช้ผิดเกิดอะไร
liveness = "ยังไม่ตายใช่ไหม" — fail แล้ว restart container ส่วน readiness = "พร้อมรับ traffic ไหม" — fail แล้วแค่ถอดจาก Service ไม่ฆ่า — ใช้ผิดที่คลาสสิก: เอาเช็คที่พึ่ง dependency ภายนอก (ต่อ DB ได้ไหม) ไปใส่ liveness แล้ว DB ล่มทีเดียว pod โดนฆ่ายกฝูง — dependency check ควรอยู่ readiness เท่านั้น
startup probe มีไว้ทำไม
สำหรับแอปที่ start ช้า (JVM, โหลดโมเดล) — ระหว่าง startup probe ยังไม่ผ่าน liveness จะไม่เริ่มนับ กันเคส liveness ใจร้อนฆ่าแอปที่กำลัง warm up วนลูปไม่จบ — ถ้าแอป start เกิน ~30 วินาทีควรมี startup probe