Scaling และ Self-Healing ในทางปฏิบัติ (+ Lab)
สเกลขึ้นลงด้วยมือ และพิสูจน์ว่า K8s กู้ Pod ที่หายไปจริง
ในบทนี้เราจะมาพิสูจน์กลไกพื้นฐาน 2 อย่าง Scaling (การสเกล): คือ การเพิ่มหรือลดจำนวน Pod Self-Healing (การรักษาตัวเอง): คือ การที่ระบบตรวจพบว่าแอปมีปัญหาหรือหายไป และสร้างใหม่ขึ้นมาทดแทนโดยอัตโนมัติ
เรื่องนี้คือการเอาแนวคิดจากบทก่อนมาลองด้วยมือ — สั่งเพิ่มพนักงาน (scale up), ลองไล่พนักงานออกหนึ่งคน (ลบ Pod) แล้วดูว่าหัวหน้ากะเรียกคนใหม่มาแทนจริงไหม (self-healing)
สเกลด้วยมือ
# วิธี imperative (เห็นผลไว เหมาะทดลอง)
kubectl scale deployment/web --replicas=5
# วิธี declarative (แนะนำ): แก้ replicas ในไฟล์ แล้ว
kubectl apply -f deployment.yaml🧪 Lab: พิสูจน์ self-healing
# ดู Pod ปัจจุบัน (สมมติมี 3 ตัว)
kubectl get pods -l app=web
# ลบ Pod ทิ้งไป 1 ตัว
kubectl delete pod <ชื่อ-pod-ตัวหนึ่ง>
# ดูอีกที — จะเห็น Pod ใหม่ถูกสร้างแทนภายในไม่กี่วินาที!
kubectl get pods -l app=web -w # -w = เฝ้าดูแบบ real-timeK8s Scheduler & Self-Healing
ตั้งจำนวน Pod ที่อยากได้ (desired) แล้วดู Scheduler วางลง node ที่ว่าง · ลองปิด node เพื่อดู Pod ถูกย้ายไปที่อื่นให้ครบเสมอ
✅ Scheduler กระจาย 4 Pod ลง node ที่ว่างอย่างสมดุล — ลองกด "ปิด node" ดูว่า Pod ถูกย้ายไปที่อื่นทันที
สรุป Key Takeaways
- สเกลด้วย kubectl scale (imperative) หรือแก้ replicas ในไฟล์แล้ว apply (declarative)
- ลบ Pod ตรง ๆ ไม่ได้ผล — ReplicaSet สร้างใหม่ให้ครบ desired เสมอ
- จะลด Pod จริงต้องแก้ที่ Deployment ไม่ใช่ที่ Pod
- auto-scaling (HPA) เป็นเรื่องของโมดูลถัดไป
คำถามที่พบบ่อย
Scale ด้วยมือกับ HPA ต่างกันตอนไหน
kubectl scale = ปรับจำนวนตายตัวทันที เหมาะกับเหตุการณ์ที่รู้ล่วงหน้า ส่วน HPA = ปรับอัตโนมัติตาม metric (CPU/memory/custom) เหมาะกับโหลดผันผวน — ระวังอย่าตั้ง replicas ใน YAML ค้างไว้เมื่อใช้ HPA เพราะ apply ทุกครั้งจะดึงจำนวนกลับไปทับที่ HPA ตั้ง
Self-healing ของ K8s ครอบคลุมอะไร ไม่ครอบคลุมอะไร
ครอบคลุม: container crash (restart), pod หาย (สร้างใหม่), node ตาย (ย้าย pod ไปเครื่องอื่น), แอปค้าง (liveness probe ฆ่าให้เกิดใหม่) — ไม่ครอบคลุม: bug ในโค้ด, ข้อมูลเสีย, config ผิด — มันรักษา "จำนวนและสถานะ" ไม่ได้รักษา "ความถูกต้องของแอป"