ทำความรู้จักกับ Kubernetes Architecture: หัวใจสำคัญของระบบจัดการ Container
หากน้อง ๆ กำลังก้าวเข้าสู่โลกของ DevOps หรือการพัฒนาซอฟต์แวร์ระดับองค์กร คำว่า Kubernetes Architecture คือสิ่งที่หลีกเลี่ยงไม่ได้เลยครับ เปรียบเทียบง่าย ๆ ว่าถ้า Container (หน่วยบรรจุแอปพลิเคชัน) คือกล่องพัสดุ Kubernetes ก็คือ "ระบบจัดการคลังสินค้าอัตโนมัติ" ที่คอยดูว่ากล่องไหนต้องวางตรงไหน ถ้ากล่องไหนเสียหายต้องรีบเปลี่ยนใหม่ หรือถ้ามีออเดอร์เข้ามาเยอะขึ้นต้องเพิ่มพนักงานยกของอย่างไร
การเข้าใจโครงสร้างของมันจะช่วยให้เราเลิกมองว่าแอปพลิเคชันเป็นแค่ไฟล์โค้ด แต่เห็นภาพว่ามันรันอยู่บนโครงสร้างพื้นฐานที่ซับซ้อนได้อย่างไร Kubernetes ทำงานในรูปแบบของ Cluster (กลุ่มของเครื่องคอมพิวเตอร์ที่ทำงานร่วมกัน) ซึ่งแบ่งหน้าที่ออกเป็นสองส่วนหลักคือ Control Plane (สมองสั่งการ) และ Worker Nodes (แรงงานผู้ปฏิบัติงาน) โดยแต่ละส่วนมีหน้าที่เฉพาะตัวที่ต้องทำงานประสานกันตลอดเวลา
ส่วนสมองสั่งการ: Control Plane (Master Node)
Control Plane คือศูนย์กลางการควบคุมทั้งหมดของคลัสเตอร์ เปรียบเสมือนผู้จัดการคลังสินค้าที่คอยรับคำสั่งและวางแผนงานต่าง ๆ ภายในนี้ประกอบด้วยส่วนประกอบสำคัญอย่าง API Server (ประตูหน้าด่านที่รับคำสั่งจากเรา), Scheduler (ตัวตัดสินใจว่าจะเอาแอปไปวางไว้ที่เครื่องไหน), Controller Manager (ผู้คอยตรวจสอบว่าระบบยังทำงานปกติไหม) และ etcd (ฐานข้อมูลเก็บสถานะของระบบ)
เวลาที่เราต้องการสั่ง Deploy แอปพลิเคชัน เราจะคุยผ่าน kubectl (เครื่องมือสั่งการผ่าน Terminal) ซึ่งคำสั่งนั้นจะวิ่งเข้าหา API Server เป็นที่แรก หากคำสั่งถูกต้อง Scheduler จะคำนวณหาเครื่องที่เหมาะสมที่สุดโดยดูจาก CPU และ Memory ที่เหลืออยู่ ส่วน etcd จะทำหน้าที่บันทึกทุกอย่างไว้ว่า ณ เวลานี้ แอปเรากี่ตัวกำลังรันอยู่ ถ้ามีตัวไหนตายไป Controller Manager จะรู้ทันทีและสั่งให้ระบบกู้คืนกลับมาครับ
ตัวอย่าง: สมมติเราสั่งให้รันเว็บแอปฯ 3 ชุด ระบบจะบันทึกสถานะนี้ลงในetcdหากมีชุดใดหนึ่งพังลงมาController Managerจะพบความผิดปกติและแจ้งให้Schedulerหาที่ว่างเพื่อรันตัวใหม่ขึ้นมาแทนทันทีโดยอัตโนมัติ
ส่วนแรงงานผู้ปฏิบัติงาน: Worker Nodes
Worker Nodes คือเครื่องคอมพิวเตอร์ที่แอปพลิเคชันของเราไปรันอยู่จริง ๆ ครับ ในแต่ละโหนดจะมีกระบวนการทำงานหลัก 3 อย่างคือ Container Runtime (ตัวรัน Container เช่น containerd), Kubelet (ตัวแทนผู้จัดการที่คุยกับ Control Plane), และ Kube-proxy (ตัวจัดการเครือข่าย) ทั้งหมดนี้ต้องติดตั้งอยู่บนทุกโหนดเพื่อให้ระบบทำงานได้อย่างราบรื่น
Kubelet คือหัวใจสำคัญของโหนด มันคอยรายงานสถานะกลับไปยัง Control Plane ว่า "ตอนนี้งานที่สั่งทำเสร็จแล้วนะ" หรือ "เครื่องนี้เริ่มเต็มแล้วนะ" ส่วน Kube-proxy ทำหน้าที่เหมือนพนักงานรับส่งเอกสาร คอยจัดการเรื่อง IP Address และ Load Balancing (การกระจายงาน) เพื่อให้ผู้ใช้งานเข้าถึงแอปพลิเคชันของเราได้ถูกต้องไม่ว่าจะรันอยู่บนโหนดไหนก็ตาม
# ตัวอย่างคำสั่งพื้นฐานในการตรวจสอบสถานะของ Node
kubectl get nodes
# คำสั่งนี้จะแสดงรายชื่อ Worker Nodes ทั้งหมดในคลัสเตอร์
# ถ้าสถานะเป็น Ready แปลว่า Kubelet ทำงานปกติและพร้อมรับงาน
ข้อควรระวังสำหรับมือใหม่: อย่าพยายามไปแก้ไขไฟล์คอนฟิกของโหนดโดยตรงผ่าน SSH หากไม่จำเป็น เพราะ Kubernetes ถูกออกแบบมาให้จัดการตัวเอง หากเราไปปรับเปลี่ยนค่าเองโดยไม่ผ่าน API Server อาจทำให้ระบบ "ลืม" สถานะที่แท้จริงและเกิดความเสียหายได้
สรุป: การนำไปใช้จริงสำหรับโปรแกรมเมอร์
การเข้าใจ Kubernetes Architecture ช่วยให้เราเขียนแอปพลิเคชันได้ "ฉลาดขึ้น" ครับ แทนที่จะเขียนโค้ดแบบรอรับ Request ทั่วไป เราจะเริ่มคิดถึงการทำ Health Check (เช็คว่าแอปยังหายใจอยู่ไหม) เพื่อให้ Kubelet ตรวจสอบได้ หรือการออกแบบให้แอปเป็น Stateless (ไม่เก็บข้อมูลไว้ในเครื่องตัวเอง) เพื่อให้ Scheduler สามารถย้ายแอปไปรันที่โหนดอื่นได้โดยที่ข้อมูลไม่หาย
หัวใจสำคัญคือการมองระบบให้เป็นองค์รวม ไม่ว่าจะเป็นการเลือกใช้ทรัพยากรให้เหมาะสม หรือการเข้าใจว่าทำไมแอปของเราถึงเข้าถึงไม่ได้หาก Kube-proxy มีปัญหา การเป็นโปรแกรมเมอร์ที่เข้าใจสถาปัตยกรรมจะช่วยให้เราแก้บั๊กได้เร็วกว่าคนอื่น เพราะเราไม่ได้แค่ดูโค้ดที่เขียน แต่เรามองเห็นถึง "บ้าน" ที่โค้ดของเราอาศัยอยู่ด้วยครับ
ลองเริ่มฝึกจากการติดตั้ง Minikube (เครื่องมือจำลอง Kubernetes คลัสเตอร์ในเครื่องตัวเอง) แล้วลองสั่ง kubectl create deployment ดูครับ การได้เห็นว่า Pod ถูกสร้างขึ้นมาอย่างไรผ่านคำสั่ง kubectl get pods จะช่วยให้สิ่งที่อ่านมาทั้งหมดกลายเป็นประสบการณ์จริงที่ติดตัวน้องไปตลอดการทำงานสายนี้ครับ
ที่มา: Kubernetes Architecture — DEV Community
