คู่มือปฏิบัติการ วันที่ 5 | Pod Lifecycle, Logs และการวินิจฉัยปัญหา (Diagnostics)

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

ยินดีต้อนรับสู่ วันที่ 5: Pod Lifecycle, Logs และการวินิจฉัยปัญหา (Diagnostics)!

วันนี้เราจะมาทำความเข้าใจวงจรชีวิตของ Pod (Pod Lifecycle) เรียนรู้วิธีการสตรีม Logs แบบเรียลไทม์ และฝึกจำลองสถานการณ์เมื่อเกิดข้อผิดพลาดเพื่อวินิจฉัยและแก้ไขปัญหาผ่าน Headlamp UI และ CLI ครับ

5-10m

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

เข้าใจ 4 สถานะหลักของ Pod Lifecycle และ 2 เสาหลักของการวินิจฉัยปัญหา: Logs (stdout/stderr) และ Events

15-20m

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

สร้างแอปส่ง log สตรีมผ่าน CLI & UI จำลอง error แบบ ImagePullBackOff และแก้ปัญหาด้วยปุ่ม Delete บน UI

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

Pod Lifecycle Phases (วงจรชีวิตของ Pod)

Pod ใน Kubernetes จะเปลี่ยนสถานะตามขั้นตอนการทำงานดังนี้:

• Pending กำลังรอจัดสรรโหนด หรือกำลังดาวน์โหลด Image

• Running คอนเทนเนอร์ถูกสร้างและทำงานปกติอย่างน้อย 1 ตัว

• Succeeded ทำงานเสร็จสมบูรณ์ (Exit 0) มักพบใน Jobs/Batch

• Failed คอนเทนเนอร์หยุดทำงานด้วยข้อผิดพลาด (Non-zero)

• Headlamp จะไฮไลต์สีตามสถานะเหล่านี้ให้สังเกตเห็นได้ง่ายในหน้าต่าง Workloads

การวินิจฉัยปัญหา (Diagnostics: Logs vs Events)

เมื่อ Pod ค้างอยู่ในสถานะผิดปกติ เช่น ImagePullBackOff หรือ CrashLoopBackOff เราจะใช้ 2 แหล่งข้อมูลคู่กัน:

1. Logs (stdout/stderr): ตรวจดูสิ่งที่โปรแกรมใน Container พ่นออกมา เหมาะสำหรับดูข้อผิดพลาดระดับ Code, Exception, หรือ Database Connection

2. Events: ตรวจดูข้อความจาก Cluster Control Plane เหมาะสำหรับดูปัญหาโครงสร้างพื้นฐาน เช่น ไม่มี Image, โหนดหน่วยความจำเต็ม หรือ Probe ล้มเหลว

• Headlamp นำแถบ Logs และ Events มาวางไว้คู่กัน ทำให้หาสาเหตุได้รวดเร็วกว่าการพิมพ์ CLI ซ้ำหลายคำสั่ง

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

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

ขั้นตอนที่ 1: สร้าง Pod สำหรับส่ง Logs ต่อเนื่อง Step 1 of 5

เปิด Terminal แล้วรัน Pod ที่ใช้ Image busybox ซึ่งจะรันลูปพิมพ์ข้อความออกมาทุกๆ 2 วินาที:

Terminal Bash • Run Log Producer

kubectl run log-producer --image=busybox -- sh -c "while true; do echo 'Processing batch task...'; sleep 2; done"

✓ ผลลัพธ์ที่คาดหวัง: Terminal จะแสดงข้อความ pod/log-producer created และสถานะจะเปลี่ยนเป็น Running

ขั้นตอนที่ 2: สตรีม Logs ผ่าน CLI Step 2 of 5

ทดลองใช้คำสั่งสตรีม Logs แบบเรียลไทม์ผ่าน Terminal โดยใส่แฟล็ก -f (follow):

Terminal Bash • Stream Logs

kubectl logs -f log-producer

คุณจะเห็นข้อความ Processing batch task... ไหลออกมาเรื่อยๆ กดแป้นพิมพ์ Ctrl + C เพื่อหยุดสตรีม

ขั้นตอนที่ 3: สตรีม Logs ผ่าน Headlamp UI Step 3 of 5

เปิด Headlamp เพื่อทดลองใช้ฟังก์ชันดูบันทึกของคอนเทนเนอร์แบบ Graphic:

เปิด Headlamp UI ขึ้นมา (ผ่าน http://localhost:8080 หรือ Headlamp Desktop)
ไปที่เมนูด้านซ้าย Workloads > Pods แล้วคลิกเลือก Pod ชื่อ log-producer
คลิกเข้าไปที่แถบ Logs (หรือไอคอนเอกสาร/บันทึกด้านบน)
สังเกต Logs ที่ไหลลงมาอย่างต่อเนื่อง ทดลองเปิดสวิตช์ Auto-scroll และพิมพ์คำว่า batch ในช่องตัวกรอง (Filter) เพื่อค้นหาข้อความเฉพาะ

ข้อดีบน UI คือคุณสามารถดาวน์โหลด Logs หรือสลับ Container เพื่อดูได้ง่ายโดยไม่ต้องจำ Flag เพิ่มเติม

ขั้นตอนที่ 4: จำลองสถานการณ์เกิดข้อผิดพลาด (ImagePullBackOff) Step 4 of 5

สร้าง Pod ใหม่โดยจงใจพิมพ์ชื่อ Image ที่ไม่มีอยู่จริงบน Registry (invalid-image-name) เพื่อจำลองปัญหาคลาสสิกของ Kubernetes:

Terminal Bash • Simulate Broken Pod

kubectl run failing-pod --image=invalid-image-name

เมื่อรันแล้ว ตัว Kubelet จะพยายาม Pull image หลายครั้งแต่ไม่สำเร็จ จนเข้าสู่ช่วง Back-off delay

ขั้นตอนที่ 5: วินิจฉัยและลบ Pod ผ่าน Headlamp UI Step 5 of 5

ดูการแจ้งเตือนความผิดพลาดบน UI และสั่งเคลียร์ Pod ที่มีปัญหา:

สังเกตสถานะของ failing-pod บน Headlamp UI ซึ่งจะเปลี่ยนเป็น ErrImagePull หรือ ImagePullBackOff (แสดงเป็นแท็กเตือนสีแดง/ส้ม)
คลิกเข้าไปที่ failing-pod แล้วเลื่อนลงไปดูที่แถบ Events เพื่ออ่านสาเหตุที่แท้จริง (คุณจะเห็นข้อความแจ้งเตือน เช่น Failed to pull image ... manifest unknown)
ลบ Pod ที่มีปัญหานี้ออก โดยคลิกที่ ไอคอนถังขยะ (Delete) บริเวณมุมขวาบนของหน้า Headlamp UI และกดยืนยัน
สลับกลับมาที่ Terminal แล้วรันคำสั่งตรวจสอบ:

Terminal Bash • Verify Deletion

kubectl get pods

✓ ผลลัพธ์ที่คาดหวัง: คุณจะเห็นว่า failing-pod หายไปจากระบบแล้ว โดยเหลือเพียง log-producer (หรือ Pod อื่นๆ ที่สร้างไว้ก่อนหน้า) แสดงว่าการสั่งลบผ่าน Web UI มีผลสมบูรณ์

ภารกิจสำหรับวันที่ 5 • สิ้นสุดสัปดาห์ที่ 1

ลองทำตามขั้นตอนแล้วแจ้งผลได้เลยครับว่าพบบันทึก Logs และข้อผิดพลาดบน UI ชัดเจนหรือไม่! เมื่อทำเสร็จเรียบร้อย เราก็ผ่านสัปดาห์แรก (Days 1–5) ของ Level 1 แล้ว พร้อมไปต่อใน วันที่ 6: Deployments, Rolling Updates และการ Rollback ได้ทันทีครับ!

ขั้นตอนถัดไปในสัปดาห์ที่ 2: เตรียมพบกับการอัปเกรดเวอร์ชันแอปพลิเคชันแบบ Zero-downtime และการสั่งย้อนกลับ (Rollback) ใน วันที่ 6