คู่มือปฏิบัติการ วันที่ 6 | Deployments, Rolling Updates และการ Rollback

คู่มือปฏิบัติการ • 20–30 นาทีต่อวัน • เริ่มต้นสัปดาห์ที่ 2

ยินดีต้อนรับสู่ วันที่ 6: Deployments, Rolling Updates และการ Rollback!

วันนี้เราจะมาเรียนรู้กลไกการอัปเดตแอปพลิเคชันแบบไม่สะดุด (Zero-Downtime Deployment) การทำ Rolling Update เพื่อเปลี่ยนเวอร์ชันคอนเทนเนอร์ และวิธีสั่งย้อนกลับ (Rollback) เมื่อเกิดปัญหาระหว่างการอัปเดตครับ

5-10m

ช่วงที่ 1: สรุปแนวคิดสถาปัตยกรรม

เข้าใจความสัมพันธ์ระหว่าง Deployments & ReplicaSets, กลยุทธ์ Rolling Update และระบบบันทึก Revision สำหรับ Rollback

15-20m

ช่วงที่ 2: การลงมือปฏิบัติจริง (5 ขั้นตอน)

สร้าง Nginx 4 replicas สั่งเปลี่ยนเวอร์ชัน สังเกต ReplicaSet บน Headlamp UI จำลอง Tag เสีย และสั่ง Undo Rollback

สรุปแนวคิดและสถาปัตยกรรม (5–10 นาที)

Deployments & ReplicaSets

Deployment ไม่ได้สร้าง Pod โดยตรง แต่มันจะควบคุม ReplicaSet อีกชั้นหนึ่ง ซึ่งเป็นตัวควบคุมจำนวน Pods จริงให้ครบตามเป้าหมาย (Desired Replicas)

• Deployment → ReplicaSet → Pods

Rolling Update Strategy

เมื่อเปลี่ยน Image คอนฟิก ตัว Deployment จะสร้าง ReplicaSet ใหม่ขึ้นมา ค่อยๆ สร้าง Pod เวอร์ชันใหม่ และค่อยๆ ปิด Pod เก่าลงตามค่า maxSurge / maxUnavailable ทำให้บริการไม่ล่ม

• Zero-Downtime Deployment มาตรฐาน

Rollback (การกู้คืนระบบ)

หากเวอร์ชันใหม่มีปัญหา (เช่น Image พัง หรือ Exception) Pod เก่ายังคงทำงานรองรับผู้ใช้อยู่บางส่วน เราจึงสั่ง Rollback ย้อนกลับไปยัง Revision ก่อนหน้าที่สมบูรณ์ได้อย่างปลอดภัยทันที

• กู้คืนด้วย kubectl rollout undo

ขั้นตอนลงมือปฏิบัติจริง (15–20 นาที)

ติ๊กถูกเมื่อทำแต่ละขั้นตอนเสร็จ

ขั้นตอนที่ 1: สร้าง Deployment เริ่มต้น Step 1 of 5

เปิด Terminal แล้วสร้าง Deployment ที่ใช้ Nginx เวอร์ชัน 1.21 จำนวน 4 replicas เพื่อเป็นเวอร์ชันฐาน:

Terminal Bash • Initial Deployment (4 Replicas)

kubectl create deployment web-app --image=nginx:1.21 --replicas=4

✓ ผลลัพธ์ที่คาดหวัง: Terminal จะแสดงข้อความ deployment.apps/web-app created และ Pod ทั้ง 4 ตัวจะเริ่มทำงาน

ขั้นตอนที่ 2: สั่งอัปเดตแบบ Rolling Update Step 2 of 5

อัปเดต Image ของคอนเทนเนอร์จาก nginx:1.21 เป็น nginx:1.25 ผ่านคำสั่ง set image:

Terminal Bash • Rolling Update Image

kubectl set image deployment/web-app nginx=nginx:1.25

คำสั่งนี้จะกระตุ้นให้ Kubernetes Controller Manager เริ่มกระบวนการ Rolling Update ทันที

ขั้นตอนที่ 3: ติดตาม Rollout บน Headlamp UI Step 3 of 5

เปิด Headlamp UI เพื่อดูการสลับเปลี่ยน ReplicaSet และการทยอยสร้าง Pod แบบกราฟิก:

เปิด Headlamp UI ขึ้นมา (ผ่าน http://localhost:8080 หรือ Headlamp Desktop)
ไปที่เมนูด้านซ้าย Workloads > Deployments แล้วคลิกเข้าดูรายละเอียดของ web-app
สังเกตในส่วน ReplicaSets: คุณจะเห็น ReplicaSet เก่าค่อยๆ Scale Down (ลดจำนวนลง) และ ReplicaSet ใหม่กำลัง Scale Up (เพิ่มจำนวนขึ้นมาแทนที่) อย่างเป็นลำดับจนครบ 4 ตัว

บนหน้าจอ Headlamp คุณสามารถคลิกดูทั้ง 2 ReplicaSets เพื่อดูความต่างของ Pod Template และสถานะได้ทันที

ขั้นตอนที่ 4: จำลองการอัปเดตล้มเหลว Step 4 of 5

สั่งอัปเดต Image ไปยัง Tag ที่ไม่มีอยู่จริง (nginx:badtag) เพื่อจำลองความผิดพลาดของระบบ:

Terminal Bash • Simulate Broken Image

kubectl set image deployment/web-app nginx=nginx:badtag

• สังเกตบน Headlamp UI:

กลับมาดูที่ Headlamp UI: สังเกตว่ากระบวนการ Rollout จะชะงักลง โดย Pods ใหม่จะติดสถานะ ImagePullBackOff แต่ Pods เวอร์ชันเดิม (nginx:1.25) ยังคงทำงานเพื่อให้บริการอยู่ ระบบจะไม่ปิด Pod เก่าจนกว่า Pod ใหม่จะพร้อมใช้งาน

ขั้นตอนที่ 5: สั่ง Rollback กู้คืนระบบผ่าน CLI Step 5 of 5

ยกเลิกการอัปเดตที่มีปัญหาและถอยกลับไปเวอร์ชันล่าสุดที่ทำงานได้สมบูรณ์:

Terminal Bash • Rollback & Check Status

kubectl rollout undo deployment/web-app
kubectl rollout status deployment/web-app

✓ ผลลัพธ์ที่คาดหวัง: Terminal จะแสดงข้อความ deployment.apps/web-app successfully rolled out และสถานะ Pods ทั้งหมดบน Headlamp UI จะกลับมาเป็นสีเขียว Running ครบทั้ง 4 Replicas ตามปกติ

ภารกิจสำหรับวันที่ 6 (Day 6 Mission)

ลองทดสอบสั่ง Rolling Update และสั่ง Rollback ดูนะครับ หากสังเกตเห็นการทำงานของ ReplicaSet บน Headlamp UI เรียบร้อยแล้ว แจ้งได้เลยครับ!

ขั้นตอนถัดไป: เมื่อพร้อมแล้ว บอกผมได้เลยนะครับเพื่อไปต่อใน วันที่ 7: ระบบเครือข่าย ClusterIP และ NodePort Services