เริ่มต้น Troubleshoot Deployments บน kubernetes ยังไงนะ
สวัสดีครับทุกคน ต้องขอเล่าก่อนว่าบทความนี้เกิดจาก เมื่อเดือนธันวาคมที่ผ่านมาผมได้รับโอกาสจากทาง ODDS| ไปร่วมงาน “Kubeday Singapore 2023” ซึ่งก็มีหลาย section ที่น่าสนใจครับ แต่ในบทความนี้ผมจะมาเล่าเกี่ยวกับ section ที่ชื่อว่า
“Keep Calm and Troubleshoot Your Deployments”
ซึ่ง section นี้ speaker คือ
section นี้ได้พูดถึง guideline การ troubleshooting ตอนที่เราทำการ deploy แล้วเจอปัญหาต่างๆ
โดยใน section ได้พูดถึงส่วนประกอบของสิ่งที่เรา deploy บน kubernetes โดยยกตัวอย่างจากการ deploy static web ตามปกติ ถ้า เรา deploy แล้ว user เข้า web ก็จะเป็นตามรูป คือมี traffic จาก user วิ่งเข้าไปสู่ web
แต่ถ้าหลังจากนั้น ถ้าเราต้องการเพิ่มจำนวน web เพื่อมารองรับ traffic ที่เข้ามา ซึ่งถ้าเรามีการเพิ่มจำนวน web ก็ต้องมีคนมาค่อยจัดการ traffic ที่เข้าถึงเว็บซึ่งสิ่งนั้นโดยปกติแล้วเรียกว่า load balancer
แล้วถ้าหลังจากนั้น เราไม่ได้ต้องการ deploy แค่ web แต่ยังต้องการ deploy api ด้วย api นั้นก็ต้องมี load balancer เพื่อจัดการ traffic ที่เข้ามา
แล้วใครเป็นคนจัดการ traffic ที่วิ่งเข้ามาถึง loadbalance แต่ละตัว สิ่งนั้นก็คือ load balancer หรือ route
ซึ่งใน kubernetes สิ่งที่ web หรือ api ที่เรา deploy เราจะ deploy ไว้ในสิ่งที่เรียกว่า pod ซึ่งเมื่อ pod อยู่ใน area เดียวกันจะเรียกว่า deployment และ load balancer ที่ใช้จัด traffic ที่อยู่ระหว่าง pod กับ load balancer เรียกว่า service และ load balancer ที่อยู่นอกสุดเรียกว่า ingress
เมื่อเรารู้จักส่วนต่างที่ของ ของที่เรา deploy บน kubernetes คร่าวๆ แล้วใน ต่อมาจะมีการพูดถึง guideline ของการทำ troubleshooting เมื่อเรา deploy แล้วพบปัญหา โดยมีการแบ่ง 3 ส่วน คือ
- troubleshooting pod
คือ การดูปัญหาที่เกี่ยวข้องกับ pod โดยอาจจะใช้คำสั่ง
“kubectl get pods” เพื่อดู status ของ pod
“kubectl describe <pod name>” เพื่อดู event ที่เกิดขึ้นในของ pod
“kubectl logs <pod name>” เพื่อดู log ใน pod
2. troubleshooting service
คือ การ check หลังจากที่ check แล้วว่า status ของ pod running แต่เราไม่สามารถเข้าไปที่ application ที่ deploy อยู่ได้โดยอาจจะดู config เกี่ยวกับการจัดการ traffic ของ service ว่าส่ง traffic ไปยัง pod ได้ถูกไหม ซึ่งอาจจะใช้คำสั่ง
“kubectl describe service <service name>” เพื่อดู config ต่างๆ เช่น port , TargetPort ที่ container ใน pod listening อยู่ , Endpoints เป็นต้น
3. troubleshooting ingress
ซึ่งเป็นการ check หลังจากที่เรารู้ว่า status ของ pod running และ service ว่าส่ง traffic ไปยัง pod ได้ถูกต้อง ซึ่งนั้นอาจจะหมายความว่า ingress อาจจะมีปัญหา ซึ่ง อาจจะ check ว่า ingress สามารถส่งไป traffic ต่อกับ service ได้ถูกต้องไหม โดยอาจจะใช้คำสั่ง
“kubectl describe ingress <ingress name>” เพื่อดูข้อมูลและปัญหาของ ingress เช่น host , part , error เป็นต้น
โดยสรุปสิ่งที่ผมได้จาก section นี้คือเมื่อเราเจอปัญหาตอน deploy บน kubernetes แล้วไม่รู้ว่าจะเริ่ม check จากจุดไหน จาก section นี้แนะนำว่าเราควรจะเริ่ม troubleshooting จาก bottom to up คือ ควรค่อยๆดู ปัญหาจากข้างล่างก่อนก็คือ pod โดยดูจาก status, log แล้วค่อยขึ้นมาดูที่ service แล้วค่อยไล่ขึ้นไปดูที่ ingress
แหล่งอ้างอิงข้อมูล
