จาก Docker สู่ Kubernetes
เมื่อไหร่ที่ Docker/Compose ไม่พอ และก้าวต่อยังไง
ปูพื้นฐาน: Docker เป็นเครื่องมือที่ยอดเยี่ยม แต่มันออกแบบมาให้รันบนเซิร์ฟเวอร์แค่ 1 เครื่อง เมื่อระบบใหญ่ขึ้น ผู้ใช้มากขึ้น 1 เครื่องอาจรับไม่ไหว และถ้าเครื่องพัง ระบบเราก็จะล่มไปเลย นี่คือจุดที่ต้องหาตัวช่วย
Docker/Compose เก่งเรื่องรันบนเครื่องเดียว · พอระบบโตจนต้องรันหลายเครื่อง ทน node ล่ม สเกลอัตโนมัติ — นั่นคือจุดที่ต้องส่งไม้ต่อให้ Kubernetes (orchestrator)
ข่าวดีที่สุด: image ที่คุณ build ด้วย Docker คือสิ่งที่ Kubernetes เอาไปรันเป๊ะ ๆ — สิ่งที่เรียนมาทั้ง track Docker ไม่เสียเปล่า มันคือรากฐานของ K8s
image เดียวกันที่ Docker build → Kubernetes เอาไปรัน
Docker = เครื่องเดียว · K8s = หลายเครื่อง + self-heal + auto-scale (ใช้ image เดิม)
แนวคิด Docker → เจออีกใน K8s
- image (Docker) → K8s รัน image เดียวกันใน Pod
- docker run หลายตัว → Deployment (จัดการหลาย replica + self-heal + rolling update)
- Compose service คุยด้วยชื่อ → Service + DNS ภายในคลัสเตอร์
- volume → PersistentVolume / PVC
- compose.yaml → manifest YAML ของ K8s (แนวคิด declarative เหมือนกัน)
สรุป Key Takeaways
- Docker/Compose = เครื่องเดียว · Kubernetes = หลายเครื่อง + self-heal + auto-scale
- image ที่ build ด้วย Docker คือสิ่งที่ K8s เอาไปรัน — ความรู้ต่อยอดได้หมด
- แนวคิดข้ามไป K8s: image→Pod, run→Deployment, compose service→Service/DNS, volume→PVC
- โปรเจกต์เล็กใช้ Compose ต่อได้ ไม่จำเป็นต้องขึ้น K8s เสมอ
คำถามที่พบบ่อย
รู้ Docker แล้ว แนวคิดอะไรใน K8s ที่ต้องปรับใหม่
สามเรื่องหลัก: (1) เลิกคิดเป็น "เครื่องเดียว" — pod กระจาย/ย้ายเครื่องตลอด อย่าพึ่ง local state (2) จาก docker run เป็น declarative YAML — ประกาศสภาพที่อยากได้แทนการสั่งทีละคำสั่ง (3) network/volume เป็น abstraction ใหม่ (Service, PVC) ที่ไม่ผูกกับเครื่องใด — ส่วน image, Dockerfile, registry ใช้ความรู้เดิมได้ 100%
docker compose ที่มีอยู่ แปลงเป็น K8s ได้เลยไหม
มีเครื่องมืออย่าง kompose ช่วยแปลงร่างได้ แต่ผลลัพธ์เป็นแค่จุดตั้งต้น — ของที่ compose ไม่มี (probe, resource limits, HPA, Ingress) ต้องเติมเอง — ทางที่ดีกว่าคือใช้การแปลงเป็นแบบเรียนรู้ แล้วเขียน manifest จริงด้วยความเข้าใจ