ทวน Day 1 สั้นๆ

• Container = แอป + ของที่มันต้องใช้ แพ็กรวมไว้ในกล่องเดียว
• docker ps -a ดูสถานะ · docker logs ดูว่ามันบ่นอะไร
• อ่าน exit code เป็น: 0 ปกติ · 1 แอปพัง · 137 OOM
• Compose = ไฟล์เดียวที่บอกว่าระบบมี service อะไร ต่อกันยังไง

Agenda — Day 2

ปัญหาที่ Docker เดี่ยวๆ แก้ไม่ได้

Kubernetes คืออะไร

Container Orchestration คืออะไร

K8s ในภาษาคน: ร้านกาแฟหนึ่งเชน ☕

คำศัพท์ทั้งวันนี้ ถ้าเทียบกับร้านกาแฟจะเข้าใจง่ายขึ้นเยอะ — เดี๋ยวจะอ้างถึงภาพนี้ตลอด

หัวใจของ K8s: Desired State

• เราไม่ได้สั่งว่า "ทำ ก ข ค" — เราบอกแค่ว่า ผลลัพธ์ที่อยากได้คืออะไร
• K8s จะพยายามทำให้สถานะจริง = สถานะที่เราต้องการ ตลอดเวลา
• ☕ เหมือนสั่งหัวหน้าร้านว่า "กะนี้ขอพนักงาน 3 คน" — ใครลาป่วย หัวหน้าร้านหาคนมาแทนเองโดยไม่ต้องถามเรา

โครงสร้างแบบง่ายที่สุด

Pod — หน่วยที่เล็กที่สุด

• Pod คือที่อยู่ของ container — ปกติ 1 pod = 1 container
• Pod มี IP ของตัวเอง แต่ เปลี่ยนทุกครั้งที่เกิดใหม่
• Pod เป็นของชั่วคราว — ตายแล้วไม่ฟื้น ระบบจะสร้างตัวใหม่ขึ้นมาแทน (ชื่อจะเปลี่ยน)
• ☕ เทียบร้านกาแฟ: pod = พนักงานชงกาแฟ 1 คน · ลาออกแล้วร้านจ้างคนใหม่มาแทน ไม่ใช่คนเดิมกลับมา ชื่อจึงเปลี่ยน

my-api-7d4b8c9f5-x2k9p
└─ deployment ─┘└hash┘└id┘   ← ชื่อลงท้ายสุ่ม = ปกติ

Deployment — คนคุม Pod

• บอกว่า "อยากได้ pod แบบนี้ จำนวน 3 ตัว จาก image tag นี้"
• Pod ตาย → Deployment สร้างใหม่ให้อัตโนมัติ
• เปลี่ยน image tag → ทยอยเปลี่ยน pod ทีละตัว (rolling update) ระบบไม่ดับ
• ใน Rancher จะเห็นเป็น Workload — และนี่คือระดับที่เรามักจะไป restart หรือ scale
• ☕ เทียบร้านกาแฟ: Deployment = หัวหน้าร้านที่สั่งไว้ว่า "กะนี้ต้องมีพนักงาน 3 คนเสมอ"

Service — ที่อยู่ถาวรของแอป

• Pod IP เปลี่ยนตลอด → ถ้าเรียก pod ตรงๆ จะพังทันทีที่ pod เกิดใหม่
• Service = ชื่อ/IP ที่ไม่เปลี่ยน แล้วกระจาย traffic ไปยัง pod ที่ยังไหว
• ☕ เทียบร้านกาแฟ: Service = เคาน์เตอร์รับออเดอร์ · ลูกค้าสั่งที่เดิมทุกครั้ง ไม่ต้องรู้ว่าวันนี้ใครเป็นคนชง

เส้นทางของ request จากลูกค้า

Namespace, ConfigMap & Secret

Pod Status ที่เจอบ่อย — ตัวที่ปกติ

Pod Status ที่เจอบ่อย — ตัวที่มีปัญหา

การ์ดอาการ 6 แบบ 🩺

จำ 6 ใบนี้ได้ = ไล่เคสได้เกือบทุกเคสที่จะเจอ · บ่ายนี้จะได้ใช้จริงในคลินิก

Rancher คืออะไร

• หน้าจอเว็บสำหรับจัดการ Kubernetes — ทำแทน kubectl ได้เกือบทั้งหมด
• ☕ เทียบร้านกาแฟ: Rancher = จอ CCTV + รีโมตของผู้จัดการ นั่งดูได้ทุกสาขาจากที่เดียว
• ดูได้หลาย cluster จากที่เดียว
• มีระบบสิทธิ์ — เห็นเฉพาะ project/namespace ที่ได้รับสิทธิ์

3 อย่างที่ต้องเลือกให้ถูกก่อนทุกครั้ง

ดู Workload และ Pod ใน Rancher

• Workloads → เห็นทุก service ในหน้าเดียว พร้อมสถานะสี
• ตัวเลข 3/3 = พร้อมใช้ 3 จาก 3 ตัวที่ต้องการ · 0/2 = ไม่มีตัวไหนพร้อมเลย
• คลิกชื่อ workload → เห็นรายชื่อ pod ข้างใน

ดู Log ผ่าน Rancher

Events — จุดที่คนมองข้ามบ่อยที่สุด

• Events บอกว่า K8s พยายามทำอะไรและติดตรงไหน — ต่างจาก log ที่เป็นเสียงจากตัวแอป
• ดูได้ที่หน้า pod ส่วน Events หรือเมนู Cluster → Events

Exec, Restart และ Scale ใน Rancher

ล่ารหัสลับใน Kubernetes

เปิดไฟล์ k8s-clinic-simulator.html ที่แจกให้ (ดับเบิลคลิกได้เลย ไม่ต้องต่อ VPN) · ข้างในมี workload 5 ตัว ซ่อนรหัสลับไว้ 4 คำ คนละที่กัน

รหัสลับทั้ง 4 คำ

ทำไมต้องรู้ kubectl ทั้งที่มี Rancher

• เร็วกว่ามากเวลาต้องดูหลาย pod พร้อมกัน
• ก๊อป output แนบ ticket ได้เลย — ชัดเจนกว่า screenshot
• บางข้อมูล UI ไม่แสดง (เช่น describe แบบเต็ม)
• เวลา Rancher เองมีปัญหา ยังเข้าถึง cluster ได้

kubectl get — ดูว่ามีอะไรอยู่บ้าง

kubectl get pods -n k8s-clinic            # ดู pod ใน namespace
kubectl get pods -n k8s-clinic -o wide    # เห็น node และ IP ด้วย
kubectl get pods -A                       # ดูทุก namespace
kubectl get deploy,svc -n k8s-clinic      # ดูหลายชนิดพร้อมกัน

# หา pod ที่มีปัญหาเร็วๆ
kubectl get pods -A | grep -v Running

describe & logs — สองตัวที่ใช้บ่อยสุด

# ดูรายละเอียด + Events ของ pod (สำคัญมาก)
kubectl describe pod <pod> -n payment

# ดู log
kubectl logs <pod> -n payment --tail 200
kubectl logs -f <pod> -n payment              # real-time
kubectl logs <pod> -n payment --previous      # ← รอบที่มันพังไป
kubectl logs -l app=payment-api -n payment    # ดูทุก pod ของ service

คำสั่งที่เหลือ

# เข้าไปข้างใน pod
kubectl exec -it <pod> -n payment -- sh

# ดู events เรียงตามเวลา ← ใช้ตอน pod ไม่ยอมขึ้น
kubectl get events -n payment --sort-by=.lastTimestamp

# restart ทั้ง deployment แบบ rolling
kubectl rollout restart deploy/payment-api -n payment
kubectl rollout status  deploy/payment-api -n payment

# ทดสอบต่อเข้า service จากเครื่องตัวเอง
kubectl port-forward svc/payment-api 8080:80 -n payment

Cheat Sheet — kubectl

kubectl get pods -n <ns>
kubectl get pods -n <ns> -o wide
kubectl get pods -A | grep -v Running
kubectl top pods -n <ns>

kubectl describe pod <pod> -n <ns>
kubectl get events -n <ns> \
  --sort-by=.lastTimestamp

kubectl logs <pod> -n <ns> --tail 200
kubectl logs <pod> -n <ns> --previous
kubectl logs -f <pod> -n <ns>

kubectl exec -it <pod> -n <ns> -- sh
kubectl rollout restart deploy/<name>
kubectl rollout undo deploy/<name>

อ่าน output ของ kubectl ให้เป็น

ถ้าวันหนึ่งได้สิทธิ์ใช้ kubectl ผลลัพธ์จะหน้าตาแบบนี้ — ลองตอบ 3 ข้อจากภาพนี้

$ kubectl get pods -n k8s-clinic
NAME                             READY   STATUS             RESTARTS   AGE
bean-grinder-5f9c7d8b6-mn4tq     0/1     ImagePullBackOff   0          12m
cash-register-7d4b8c9f5-x2k9p    1/1     Running            0          3h
ice-maker-8b7d6c5f4-r7t2m        1/1     Running            14         52m
menu-screen-4d5e6f7a8-q9z1c      0/1     Running            0          41m
steam-wand-6c8f9d7a5-k2p9w       0/1     CrashLoopBackOff   7          18m

เคส 1 — CrashLoopBackOff

แปลว่า: แอปเริ่มทำงานแล้วพังทันที K8s จึงสร้างใหม่วนไปเรื่อยๆ

เคส 2 — ImagePullBackOff

แปลว่า: ดึง image ไม่ได้ pod เลยยังไม่เริ่มรัน (ยังไม่มี log ให้ดู)

เคส 3 — Pod ค้างที่ Pending

แปลว่า: K8s หา node ให้ pod ไปรันไม่ได้

kubectl get nodes            # node ไหน NotReady บ้าง
kubectl describe node <node> # ดูว่าเหลือทรัพยากรเท่าไหร่

เคส 4 — "ระบบใช้ได้บ้างไม่ได้บ้าง"

อาการแบบสุ่ม มักแปลว่า pod บางตัวเสีย แต่บางตัวยังดี

เคส 5 — "หลัง deploy แล้วพัง"

# ดูประวัติการ deploy
kubectl rollout history deploy/<name> -n <ns>

# ดูว่า rollout ค้างอยู่หรือเปล่า
kubectl rollout status deploy/<name> -n <ns>

# ย้อนกลับเวอร์ชันก่อนหน้า ← ต้องได้รับอนุมัติก่อนเสมอ
kubectl rollout undo deploy/<name> -n <ns>

• เทียบเวลาที่ deploy กับเวลาที่ลูกค้าเริ่มแจ้ง — ตรงกันไหม
• ใน Rancher ดูได้ที่ tab Recent Changes / Revision History ของ workload

Checklist — ไล่ปัญหาบน K8s

สิ่งที่ทำได้เอง vs ต้องส่งต่อ

ส่งเคสต่อยังไงให้ dev แก้ได้เร็ว

ข้อควรระวังบน Production

• อย่ากดอะไรก่อนอ่านชื่อ cluster บนหัวจอ
• อย่าแก้ไฟล์หรือ config ข้างใน pod — หายทันทีที่ pod เกิดใหม่
• อย่า screenshot หน้า Secret หรือแปะค่าลง ticket
• อย่าลบ pod เพื่อ "ลองดู" — ใช้ Redeploy ตาม runbook แทน
• อย่า restart ก่อนเก็บ log — หลักฐานจะหายไปพร้อมกัน

สรุป 2 วัน