Rolling Update และ Rollback (+ Lab)
อัปเดตเวอร์ชันแบบไม่ให้เว็บล่ม และย้อนกลับได้เมื่อพัง
Rolling Update: คือ กลยุทธ์การอัปเดตเวอร์ชันของแอปพลิเคชันแบบค่อยเป็นค่อยไป ทำให้ระบบยังสามารถให้บริการผู้ใช้ได้ต่อเนื่องไม่มีสะดุด (Zero Downtime)
Rolling update เหมือนเปลี่ยนยางรถขณะรถยังวิ่ง — เปลี่ยนทีละล้อ ไม่ใช่ถอดหมด 4 ล้อพร้อมกัน · K8s ค่อย ๆ สร้าง Pod เวอร์ชันใหม่ทีละส่วน แล้วปิด Pod เก่าทีละตัว จนครบ โดยผู้ใช้ไม่รู้สึกว่าเว็บล่ม
เมื่อเราเปลี่ยน image ใน Deployment, K8s จะสร้าง ReplicaSet ใหม่ สำหรับเวอร์ชันใหม่ แล้วค่อย ๆ เพิ่ม Pod ใหม่/ลด Pod เก่าไปพร้อมกัน — เรียกว่า rolling update (เป็น strategy เริ่มต้น)
Pod ถูกสลับทีละตัว จำนวนที่พร้อมใช้ไม่ตกจนล่ม
เริ่ม: v1 ทั้งหมด
ระหว่างทาง
เกือบเสร็จ
เสร็จ: v2 ทั้งหมด
คุมความเร็ว/ความปลอดภัยด้วย 2 ค่า
- maxUnavailable — ระหว่างอัปเดต ยอมให้ Pod หายไปได้มากสุดกี่ตัว (ยิ่งน้อย ยิ่งปลอดภัย ยิ่งช้า)
- maxSurge — ยอมให้สร้าง Pod เกินจำนวนเป้าหมายชั่วคราวได้กี่ตัว (ยิ่งมาก ยิ่งเร็ว ใช้ทรัพยากรมากขึ้น)
Rolling Update Simulator
กดอัปเดตเพื่อดู Deployment สลับ Pod จาก v1 → v2 ทีละตัว · สังเกตว่า 'พร้อมใช้งาน' ไม่เคยตกถึง 0 เว็บจึงไม่ล่ม
กด "อัปเดตเป็น 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 กลับได้ทันที
คำถามที่พบบ่อย
maxSurge กับ maxUnavailable คุมอะไร
คุมจังหวะ rolling update: maxSurge = สร้างตัวใหม่เกินจำนวนเป้าได้กี่ตัว (เร่งความเร็ว แลก resource ชั่วคราว) ส่วน maxUnavailable = ยอมให้ตัวเก่าหายไปพร้อมกันกี่ตัว (0 = ผู้ใช้ไม่สะดุดเลย) — ค่า default 25%/25% พอสำหรับงานทั่วไป งาน critical ตั้ง maxUnavailable: 0
Rollback ทำยังไง แล้วมันย้อนอะไรกลับบ้าง
kubectl rollout undo deployment/<name> — ย้อน spec ของ pod template (image, env, resource) กลับ revision ก่อน แต่ "ไม่" ย้อนข้อมูลในฐานข้อมูลหรือ schema — ถ้า deploy ใหม่มี migration ไปแล้ว การ undo อย่างเดียวอาจไม่พอ ต้องวางแผน migration ให้ backward compatible
Deploy แล้วอยากรู้ว่าสำเร็จหรือค้าง ใช้อะไรดู
kubectl rollout status deployment/<name> — ค้างมักเพราะ pod ใหม่ไม่ผ่าน readiness probe หรือ resource ไม่พอ (ดู describe pod ของตัวใหม่) — Deployment จะไม่ฆ่าตัวเก่าจนกว่าตัวใหม่พร้อม จึงปลอดภัยแต่ต้องรู้ว่ามันค้างอยู่