ดูแลคลัสเตอร์ในทางปฏิบัติ (+ Lab)
ตั้ง HPA + สร้างโหลด แล้วเฝ้าดูการสเกล
พื้นฐานที่ควรรู้: ทฤษฎีทั้งหมดจะมีประโยชน์ที่สุดเมื่อนำมาลองปฏิบัติจริง ในแล็บนี้เราจะจำลองสถานการณ์ที่มีผู้ใช้งานหลั่งไหลเข้ามา แล้วดูว่าระบบอัตโนมัติต่างๆ ที่เราตั้งไว้สามารถรับมือและรายงานผลออกมาให้เราเห็นภาพได้อย่างไร
บทนี้รวมทุกอย่าง: จัด namespace, ตั้ง HPA, ยิงโหลดใส่ แล้วใช้ observability เฝ้าดูว่าระบบสเกลและฟื้นตัวยังไง เหมือนจำลองเหตุไฟไหม้เพื่อซ้อมดับเพลิง
🧪 Lab: ดู HPA สเกลจริง
kubectl autoscale deployment/web --cpu-percent=50 --min=2 --max=10
# เปิดอีก terminal ยิงโหลด (busybox loop เรียก service)
kubectl run -it load --image=busybox --restart=Never -- \
/bin/sh -c "while true; do wget -q -O- http://web; done"
# เฝ้าดูจำนวน Pod เพิ่มขึ้นตามโหลด
kubectl get hpa -w
kubectl get pods -wK8s Scheduler & Self-Healing
ตั้งจำนวน Pod ที่อยากได้ (desired) แล้วดู Scheduler วางลง node ที่ว่าง · ลองปิด node เพื่อดู Pod ถูกย้ายไปที่อื่นให้ครบเสมอ
✅ Scheduler กระจาย 4 Pod ลง node ที่ว่างอย่างสมดุล — ลองกด "ปิด node" ดูว่า Pod ถูกย้ายไปที่อื่นทันที
สรุป Key Takeaways
- HPA + โหลดจริง = เห็น Pod เพิ่มอัตโนมัติ แล้วลดเมื่อโหลดหาย
- HPA มีดีเลย์และ cooldown — scale ขึ้นเร็วกว่าลงเพื่อกัน flapping
- เก็บกวาด lab เสมอ โดยเฉพาะบน cloud
คำถามที่พบบ่อย
Node ใกล้เต็ม อยากย้าย workload ออกอย่างปลอดภัยทำยังไง
สองขั้น: kubectl cordon <node> (ห้าม pod ใหม่ลง) แล้ว kubectl drain <node> --ignore-daemonsets (ค่อยๆ ไล่ pod ไปเครื่องอื่นอย่างสุภาพ เคารพ PodDisruptionBudget) — เสร็จธุระแล้ว uncordon กลับ — เป็นท่ามาตรฐานก่อน maintenance เครื่องทุกครั้ง
PodDisruptionBudget คืออะไร ทำไมควรตั้ง
สัญญาว่า "ต้องเหลือ pod อย่างน้อยกี่ตัวเสมอ" ระหว่างการรบกวนโดยสมัครใจ (drain, upgrade) — ไม่มี PDB แล้ว drain หลายเครื่องพร้อมกันอาจดับแอปทั้งฝูงได้ ตั้ง minAvailable ให้แอปสำคัญทุกตัวเป็นนิสัย