คอนเทนเนอร์· ~18 นาที
Rolling Update และ Rollback (+ Lab)
อัปเดตเวอร์ชันแบบไม่ให้เว็บล่ม และย้อนกลับได้เมื่อพัง
Rolling update เหมือนเปลี่ยนยางรถขณะรถยังวิ่ง — เปลี่ยนทีละล้อ ไม่ใช่ถอดหมด 4 ล้อพร้อมกัน · K8s ค่อย ๆ สร้าง Pod เวอร์ชันใหม่ทีละส่วน แล้วปิด Pod เก่าทีละตัว จนครบ โดยผู้ใช้ไม่รู้สึกว่าเว็บล่ม
เมื่อเราเปลี่ยน image ใน Deployment, K8s จะสร้าง ReplicaSet ใหม่ สำหรับเวอร์ชันใหม่ แล้วค่อย ๆ เพิ่ม Pod ใหม่/ลด Pod เก่าไปพร้อมกัน — เรียกว่า rolling update (เป็น strategy เริ่มต้น)
Pod ถูกสลับทีละตัว จำนวนที่พร้อมใช้ไม่ตกจนล่ม
เริ่ม: v1 ทั้งหมด
v1v1v1
ระหว่างทาง
v2v1v1
เกือบเสร็จ
v2v2v1
เสร็จ: v2 ทั้งหมด
v2v2v2
v1 (เก่า)v2 (ใหม่)
คุมความเร็ว/ความปลอดภัยด้วย 2 ค่า
- maxUnavailable — ระหว่างอัปเดต ยอมให้ Pod หายไปได้มากสุดกี่ตัว (ยิ่งน้อย ยิ่งปลอดภัย ยิ่งช้า)
- maxSurge — ยอมให้สร้าง Pod เกินจำนวนเป้าหมายชั่วคราวได้กี่ตัว (ยิ่งมาก ยิ่งเร็ว ใช้ทรัพยากรมากขึ้น)
Rolling Update Simulator
กดอัปเดตเพื่อดู Deployment สลับ Pod จาก v1 → v2 ทีละตัว · สังเกตว่า 'พร้อมใช้งาน' ไม่เคยตกถึง 0 เว็บจึงไม่ล่ม
v1
v1
v1
v1
4/4
พร้อมใช้งาน
4
v1 (เก่า)
0
v2 (ใหม่)
กด "อัปเดตเป็น v2" เพื่อเริ่ม rolling update
🧪 Lab: อัปเดตแล้วย้อนกลับ
# อัปเดต image เป็นเวอร์ชันใหม่
kubectl set image deployment/web nginx=nginx:1.28
# เฝ้าดูการสลับแบบ real-time
kubectl rollout status deployment/web
# ดูประวัติการ deploy ทั้งหมด
kubectl rollout history deployment/web# ย้อนไปเวอร์ชันก่อนหน้าทันที
kubectl rollout undo deployment/web
# หรือย้อนไป revision ที่ระบุ
kubectl rollout undo deployment/web --to-revision=2สรุป Key Takeaways
- Rolling update = ค่อย ๆ สลับ Pod เก่า→ใหม่ทีละส่วน เว็บไม่ล่ม (strategy เริ่มต้น)
- คุมด้วย maxUnavailable (ปลอดภัย/ช้า) และ maxSurge (เร็ว/กินทรัพยากร)
- kubectl rollout status/history/undo = ชุดคำสั่งดูและย้อนการ deploy
- K8s เก็บ ReplicaSet เก่าไว้ จึง rollback กลับได้ทันที
อ่านจบแล้วอย่าลืมทำเครื่องหมาย