สรุปจากที่เรียน Kube Free Class โดย JumpBox

สวัสดีครับผม, เมื่อวันก่อน ได้มีโอกาสเข้าฟังคลาส Kube Free Class โดย JumpBox ซึ่งมีประโยชน์มากๆเลยครับ ผมเลยขอนำมาสรุปเพื่อทบทวนความเข้าใจตัวเอง และเป็น output ตามที่โจโจ้แจ้ง ด้วยนะครับ สำหรับวีดีโอเต็มๆ ดูจากที่นี่นะคับ

Kubernetes Live | มาตามคำเรียกร้องงง..... "Kubernetes Live Class " เจอกันวันเสาร์ที่ 25 พ.ค. เวลา…

อนึ่ง เนื่องจากรายละเอียด มันเยอะมากๆ ผมสรุปได้บางส่วน ดังนี้นะครับ

เราจัดการกับคนที่เข้ามาในระบบเรา เยอะๆ เราจะจัดการอย่างไร

ในระบบที่พัฒนาขึ้น ถ้าคนใช้งานคนเดียว มันก็คงไม่เป็นอะไร, หรือ 1000 คน อาจจะเครื่องแรงๆได้, แต่ถ้าล้านคน จะทำไงดี

ดังนั้น จึงมีคำว่า Load Balancer

• Load = user ที่เข้ามาใช้งาน
• Balancer = ทำให้คนเข้ามาใช้งาน พอๆกัน
• ถ้ามีคนเข้ามา แล้วมีไก์ คอยชี้ว่าต้องเข้าไปที่ไหน จะดีมั้ย มีคนคอยจัดคิว
• เช่น เครื่องไหนมีคนใช้น้อย ก็เอาคนไปไว้เครื่องนั้น
• แล้วถ้าใช้งานเท่ากันแล้ว มันจะทำยังไง => มันจะใช้ random

เรารู้ได้ยังไง แต่ละเครื่อง มัน เวอชัน/spec/อื่นๆ ตรงกัน

ในจุดนี้ container เลยเข้ามาแก้ปัญหา ตรงนี้

Container จะเข้ามาแก้ไขปัญหา ได้แก่

• Library version ไม่ตรงกัน
• Application version ไม่ตรงกัน
• Runtime Version ไม่ตรงกัน

แล้วถ้าเครื่องพัง, ต้องขยายเครื่อง ทำยังไง??

อย่างไรก็ตาม ถ้าเครื่องพัง หรือ ต้องขยายเครื่อง, มันต้องมีคนมาทำ, ทีนี้ ถ้ามันเยอะมากๆ คนก็ทำไม่ไหว เราก็เลยมี Kube เข้ามาช่วยแก้ปัญหาจุดนี้ นั่นเอง

รายละเอียดที่จดมา

• ถ้าพังก็ restart ให้, ถ้าไม่พอ ก็ scale ให้
• เข้ามา on top container อีกที
• มันดังตอนปี 2016–2017, ใช้ในหลายบริษัทดังๆแล้ว
• ปัจจุบัน kube ใช้ containerd กับ run.c
• มันคอยจัดการหลายๆอย่างให้ตามสไลด์
• ความเสี่ยง deploy แทบไม่มี
• Continue Deploy = zero downtime + source code เป็นยังไง, cluster เป็นอย่างนั้น => คือ gitOps concept ครับ
• Fin Ops = Financial Operation

สรุปสิ่งที่ Kube ช่วย

• Restart, Redeploy, Create new Application, Rollback Deploy
• Deployment Risk free
• Continuous Deployment
• Scalability
• Observability
• Security & Compliance

Kube Overview

สำหรับ Kube ผมสรุป มาเป็นแผนภาพ ได้ดังนี้ โดยมันจะมีส่วนประกอบหลัก 4 ส่วน ได้แก่

1. Pod — หน่วยที่เล็กที่สุดที่จะ deploy ได้
2. Deployment
3. Service
4. Ingress

Pod

• Pod = Pea = เม็ดถั่ว ที่บรรจุฝักถั่ว
• pod = หน่วยที่เล็กที่สุดที่จะ deploy ได้ ซึ่งมันบรรจุ Container
• ปกติ 1 pod จะมี 1 หน้าที่ คือจะมี 1 Container หรือถ้ามากกว่า 1, ตัวที่ 2 3 4 จะมา support ตัวแรก เท่านั้น แต่มีข้อเสียคือ กิน performance
• ไม่ควรเอา app + db อยู่ใน pod เดียวกัน

Deployment

• ทำให้ทุก pod อยู่ในสถานะปกติ
• ตายไป restart
• หายไป ต้อง scale ให้ครบ

Service

• คล้ายๆ Virtual Load balancer
• แต่จริงๆแล้ว Actual LB จะอยู่ด้านนอก ก่อนถึง service
• ทำหน้าที่ mapping ชื่อ เข้าไปหา Pod

Ingress

• ทำหน้าที่ตั้งแต่ต้นทาง ตั้งแต่ user เลย
• ทำหน้าที่ resolve domain ให้เรา = Layer7

Kube อาจิเทคเจ้อ

มันใหญ่มาก ก็เลยขอเอาย่อๆ มา สรุปออกมาได้ ดังนี้คับ

สรุปที่จดมา

• ถ้าใช้ kubectl เป็น จะใช้ UI ไหน ก็ทำเป็น
• Controlplane = ชื่อใหม่ของ master node = พอดี มีผลมาจาก master มันจะเป็น เจ้านาย เป็นคนไม่พอใจ
• Worker Node = ชื่อใหม่คือ node, เนื่องด้วยเหตุผล ชนชั้นแรงงาน
• Kubelet = ผู้จัดการ สั่งให้คนทำงาน = ใช้ CRI ในการติดต่อสื่อสารกับ Pod ผ่าน containerd
• มันจะใช้ run.c คุยกับ ส่วนที่ล่างๆมากๆ
• Kube Client = คนทำหน้าที่ request

Kubernetes Context

• ใช้งานผ่าน user/key เสมอ อาจจะมาผ่าน sso, token หรือ อื่นๆ
• user ถือกุญแจไปไข แม่กุญแจที่ API
• ค่า Configuration มันอยู่ที่ตำ

คำสั่งที่ใช้บ่อยๆใน Kube

kubectl config view
kubectl config get-clusters
kubectl config get-users
kubectl config get-contexts
kubectl config current-context

เราแปลง yaml แบบ server ให้เป็นแบบที่อ่านง่ายขึ้น แบบที่เป็น client เจน ขึ้นมา ได้มั้ยคับ

• แปลงไม่ได้ ต้องทำให้มันสวยเอง
• ลองใช้พวก yq del ครับ => โจโจ้ ยืนยันว่า ทำได้

คำถามจากทางบ้าน

จำเป็นต้องทำ readyness + liveness มั้ย

• จำเป็นต้องทำ health check

Health check ควรทำเป็นตัวเดียว หรือ คนละตัว สำหรับ readyness + liveness

• ควรจะแยกกัน
• คนละอย่าง ก็ควรจะคนละเส้นครับ อาจจะประยุกต์ก็ได้ครับ readyness ใช้ http get liveness อาจจะใช้ shell command มาเช็ค

การจัดการ resource ใน VM ที่รัน kube

พอจะมีใครเคยเกิดกรณีที่เพิ่ม resoure vm ของเครื่องที่รัน kube แบบทำคัสเตอร์กัน 4 เครื่อง เครื่องที่เป็น master node เพิ่มได้ปกติ แต่เครื่องที่เป็น worker node เกิดเออเร่อไหมครับ

• ต้องคุม live cycle ดีๆ
• ต้องรู้ว่า node กำลังจะตาย
• พอเสร็จปุ๊ป ค่อย shutdown — เกสฟูล แปลว่า จบสวย

Stateful vs stateless

stateful — อะไรที่ต้องทำงานเป็นลำดับจนจบ เช่น

• เติมน้ำมัน
• ดึงคันเร่ง
• เครื่องทำงาน

stateless — ไม่มี state — ไม่จำเป็นต้องเรียงลำดับขั้นตอน

• จะเกิด จะตาย ตอนไหน ก็ได้

การเก็บ key

ปกติ ก็เก็บไว้ที่เครื่องของเราตรงๆ แต่ ไม่ปลอดภัย เขาก็เลยทำพวก SSO ขึ้นมา เพื่อ auth ก่อน

ผมเข้าใจว่า เวลาเรา debug pod เราจะใช้ sidecar มีท่าที่แนะนำ มั้ยครับ ว่าเราควรทำแบบไหน

• ถ้าใช้ sidecar มันกิน performance
• live reload ดีมั้ย
• อิฟิเมอรอล https://kubernetes.io/.../work.../pods/ephemeral-containers/
• debug pod — ถ้า exec ทำไม่ได้ ก็มีท่า
• 1.30 มี kubectl debug แล้ว

ปกติเราจะต้องอัพเดท Patch พวก security ของ Worker node เองมั้ยครับ เช่น apt update

• ถ้าดูแลเอง ก็ต้อง อัพเดท

kubectl version ใหม่ๆ มันต้อง compat กับ kube cluster version มั้ยครับ

• ต้อง compat

Ingress ของ Kube มัน deploy เป็น Container แยกได้มั้ยครับ เช่นไปใช้ตัวอื่นแทน เช่นพวก Envoy

• ได้, ingress เป็น container อยู่แล้ว

HAProxy มันนับเป็น ingress ด้วยมั้ย และ จำเป็นต้องใช้มั้ย

• HAProxy มี ingress controller
• เราจำเป็นหรือไม่ ต้องพิจารณาดู
• HaProxy Ingress Controller เหมือนจะใช้ external haproxy ข้างนอกได้นะ อันนี้ผมยังไม่ได้ลอง แฮ่ะๆ
• https://www.haproxy.com/.../external-mode-on-premises/