Kubernetes ฉบับเริ่มต้น: เข้าใจ Pod, Deployment และ Service ใน 10 นาที

Kubernetes กลายเป็นมาตรฐานของการรันคอนเทนเนอร์ในโปรดักชัน แต่ศัพท์เฉพาะจำนวนมากทำให้ผู้เริ่มต้นถอดใจ บทความนี้สรุปแนวคิดหลักจากบทเรียนทางการของ kubernetes.io อธิบาย Pod, Deployment, Service และ Self-Healing ด้วยภาษาที่เข้าใจง่าย พร้อมคำแนะนำว่าทีมแบบไหนควรใช้หรือยังไม่ควรใช้

Kubernetes เกิดมาแก้ปัญหาอะไร

เมื่อทีมเริ่มใช้คอนเทนเนอร์ (เช่น Docker) คำถามถัดมาคือ ใครจะคอยรีสตาร์ตคอนเทนเนอร์ที่ตาย ใครจะกระจายโหลดไปหลายเครื่อง และจะเพิ่มจำนวนอย่างไรเมื่อทราฟฟิกพุ่ง Kubernetes (ย่อว่า K8s) คือระบบ Orchestration โอเพนซอร์สที่ Google เปิดตัวและปัจจุบันดูแลโดย CNCF ทำหน้าที่จัดการงานเหล่านี้อัตโนมัติทั้งหมด

หลักคิดสำคัญที่สุดคือ Declarative Model เราประกาศ "สถานะที่ต้องการ" เช่น ต้องการแอปนี้รัน 3 สำเนาเสมอ แล้ว Kubernetes จะเฝ้าเทียบสถานะจริงกับที่ประกาศไว้ตลอดเวลา ถ้าคอนเทนเนอร์ตายไปหนึ่งตัว ระบบจะสร้างใหม่เองทันทีโดยไม่ต้องมีใครตื่นมากดอะไรตอนตีสาม

โครงสร้างคลัสเตอร์: Control Plane และ Node

คลัสเตอร์ Kubernetes ประกอบด้วยสองส่วน คือ Control Plane ทำหน้าที่เป็นสมองที่ตัดสินใจว่าจะวางงานไว้ที่ไหนและดูแลสถานะรวม กับ Worker Node คือเครื่อง (จริงหรือเสมือน) ที่รันคอนเทนเนอร์ของเราจริง ๆ โดยแต่ละ Node มีตัวแทนชื่อ kubelet คอยรับคำสั่งและรายงานสุขภาพกลับไป

ในทางปฏิบัติ ทีมส่วนใหญ่ไม่ควรติดตั้งคลัสเตอร์เองตั้งแต่ศูนย์ บริการ Managed Kubernetes อย่าง GKE, EKS หรือ AKS ดูแล Control Plane ให้ทั้งหมด เหลือเพียงจัดการ Node และแอปของเรา ซึ่งลดภาระงานดูแลระบบลงมหาศาล ส่วนการทดลองบนเครื่องตัวเองใช้ Minikube หรือ Kind ได้ฟรี

Pod: หน่วยเล็กที่สุดของการรันงาน

Pod คือหน่วยเล็กที่สุดที่ Kubernetes สร้างและจัดการ หนึ่ง Pod ห่อคอนเทนเนอร์หนึ่งตัว (หรือกลุ่มเล็ก ๆ ที่ต้องอยู่ด้วยกัน) พร้อมทรัพยากรที่แชร์กัน เช่น เครือข่ายและพื้นที่เก็บข้อมูลชั่วคราว โดยทุก Pod ได้ IP ของตัวเอง

สิ่งที่ผู้เริ่มต้นต้องปรับความเข้าใจคือ Pod เป็นของใช้แล้วทิ้ง (Ephemeral) มันตายได้ ถูกแทนที่ได้ และ IP เปลี่ยนได้ตลอด เราจึงไม่สร้าง Pod ตรง ๆ ในงานจริง และห้ามเก็บสถานะสำคัญไว้ใน Pod แต่ให้ออกแบบแอปแบบ Stateless แล้วฝากข้อมูลไว้กับฐานข้อมูลหรือ Storage ภายนอก

Deployment และ Service: คู่หูที่ใช้งานจริงทุกวัน

Deployment คือออบเจกต์ที่เราใช้ประกาศว่าต้องการรันอิมเมจอะไร กี่สำเนา (Replicas) และอัปเดตอย่างไร เมื่อเราแก้เวอร์ชันอิมเมจในไฟล์ YAML แล้ว Apply, Kubernetes จะทำ Rolling Update ทยอยเปลี่ยน Pod ทีละส่วนโดยไม่มี Downtime และถ้าเวอร์ชันใหม่มีปัญหา สั่ง Rollback กลับได้ในคำสั่งเดียว

ส่วน Service แก้ปัญหาว่า Pod เกิดดับและเปลี่ยน IP ตลอดเวลา โดยให้ชื่อและ IP เสถียรหนึ่งจุดพร้อมกระจายโหลดไปยัง Pod ที่แข็งแรงเบื้องหลัง ประเภทที่ใช้บ่อยคือ ClusterIP สำหรับคุยกันภายใน และ LoadBalancer สำหรับเปิดรับทราฟฟิกภายนอก ขณะที่ Ingress ช่วยจัดเส้นทาง HTTP หลายโดเมน/หลายเส้นทางเข้าคลัสเตอร์ผ่านจุดเดียว

Self-Healing และ Scaling: เหตุผลที่คนยอมเรียนรู้ K8s

พลังที่แท้จริงของ Kubernetes อยู่ที่ความสามารถดูแลตัวเอง ถ้าเรากำหนด Liveness Probe และ Readiness Probe ไว้ ระบบจะรีสตาร์ตคอนเทนเนอร์ที่ค้าง และหยุดส่งทราฟฟิกไปยัง Pod ที่ยังไม่พร้อมโดยอัตโนมัติ เมื่อ Node ทั้งเครื่องล่ม งานทั้งหมดบนเครื่องนั้นจะถูกย้ายไปเครื่องอื่นเอง

ด้าน Scaling ใช้ Horizontal Pod Autoscaler (HPA) กำหนดกติกา เช่น ถ้า CPU เฉลี่ยเกิน 70% ให้เพิ่ม Replicas จาก 3 สูงสุดถึง 10 เหมาะกับธุรกิจที่ทราฟฟิกพุ่งเป็นช่วง เช่น แคมเปญโปรโมชัน ระบบจะขยายรับโหลดเองแล้วหดกลับเมื่อเหตุการณ์จบ ช่วยประหยัดค่าใช้จ่ายไปพร้อมกัน

ทีมของคุณควรใช้ Kubernetes หรือยัง

Kubernetes มีต้นทุนการเรียนรู้และดูแลไม่น้อย ทีมเล็กที่มีบริการเดียวหรือสองบริการ อาจเหมาะกับทางเลือกที่ง่ายกว่า เช่น Cloud Run, App Service หรือ ECS Fargate ซึ่งได้ Auto Scaling โดยแทบไม่ต้องดูแลอะไร สัญญาณที่บอกว่าถึงเวลา K8s คือมีหลายบริการที่ต้อง Deploy บ่อย ต้องการควบคุมโครงสร้างพื้นฐานละเอียด หรือต้องการหลีกเลี่ยงการผูกติดผู้ให้บริการรายเดียว

เส้นทางเรียนรู้ที่แนะนำคือเริ่มจากบทเรียนโต้ตอบ "Kubernetes Basics" บนเว็บ kubernetes.io ทดลองกับ Minikube บนเครื่องตัวเอง แล้วขึ้นคลัสเตอร์ Managed ขนาดเล็กสำหรับ Workload ที่ไม่วิกฤติก่อน จากนั้นค่อยเพิ่มมาตรฐานอย่าง Resource Limits, Namespace แยกทีม และ GitOps เมื่อทีมพร้อม