คอนเทนเนอร์· ~12 นาที
ทำไมแค่ Docker ไม่พอ — ต้องมี Orchestrator
พอ container เยอะขึ้น การจัดการด้วยมือกลายเป็นฝันร้าย
รัน container ตัวเดียวด้วย docker run เหมือนเลี้ยงปลาตัวเดียวในโหล — ดูแลเองไหว · แต่พอมี container เป็นร้อยตัวกระจายหลายเครื่อง มันกลายเป็นฟาร์มปลาทั้งบ่อ ที่ต้องมีระบบให้อาหาร ควบคุมอุณหภูมิ และช้อนปลาที่ตายออกอัตโนมัติ — นั่นคืองานของ orchestrator
Docker เก่งเรื่อง "สร้างและรัน container 1 ตัว" แต่พอระบบจริงโตขึ้น คำถามที่ Docker เปล่า ๆ ตอบไม่ได้เริ่มโผล่มา:
- ถ้า container ตัวหนึ่งล่มกลางดึก ใครสตาร์ทมันขึ้นมาใหม่ให้?
- คนใช้งานพุ่งขึ้น 10 เท่า จะเพิ่มจำนวน container อัตโนมัติและกระจายโหลดยังไง?
- มี 20 เครื่อง (node) — จะตัดสินใจวาง container ตัวไหนไว้เครื่องไหนให้ทรัพยากรพอดี?
- อยากอัปเดตเวอร์ชันใหม่แบบไม่ให้เว็บล่ม (ค่อย ๆ สลับทีละตัว) ทำยังไง?
- container คุยกันข้ามเครื่องด้วยชื่อยังไง ในเมื่อ IP เปลี่ยนตลอด?
ปล่อยให้ orchestrator รับงานซ้ำ ๆ ไปทำแทน
ทำด้วยมือ (Docker เปล่า)
- 😰 container ล่ม → ต้องสตาร์ทเอง
- 😰 โหลดพุ่ง → เพิ่มเครื่องเอง
- 😰 วาง container เครื่องไหน → คิดเอง
- 😰 อัปเดต → เสี่ยงเว็บล่ม
Kubernetes
ให้ orchestrator ดูแล
- ✅ ล่มแล้วสร้างใหม่อัตโนมัติ
- ✅ สเกลตามโหลดอัตโนมัติ
- ✅ Scheduler วางให้เหมาะเอง
- ✅ rolling update ไม่ล่ม
Kubernetes (K8s) คือ orchestrator ที่รับงานพวกนี้ไปทำอัตโนมัติ เราแค่บอกว่า "อยากได้อะไร" (desired state) แล้ว K8s จะพยายามทำให้ระบบเป็นแบบนั้นตลอดเวลา
สรุป Key Takeaways
- Docker จัดการ container เดี่ยวได้ดี แต่ไม่ตอบโจทย์เรื่อง scale / self-healing / rollout
- Orchestrator ทำงานพวกนี้อัตโนมัติ: กู้คืน container ที่ล่ม, สเกล, วางลงเครื่องที่เหมาะ, อัปเดตแบบไม่ล่ม
- Kubernetes = orchestrator ที่นิยมที่สุด — เราบอก "อยากได้อะไร" แล้วมันทำให้เป็นจริงและคงไว้
- K8s มีต้นทุนความซับซ้อน — เหมาะกับระบบที่โตพอจะคุ้ม
อ่านจบแล้วอย่าลืมทำเครื่องหมาย