Kubernetes คืออะไร? แนวคิดหลัก ความต่างจาก Docker และ VM และองค์กรแบบไหนควรใช้

Kubernetes คือแพลตฟอร์ม open source สำหรับจัดการ workload และบริการที่บรรจุอยู่ในคอนเทนเนอร์ (container) ให้ทำงานบนกลุ่มเครื่องเซิร์ฟเวอร์ได้อย่างอัตโนมัติ ผู้ดูแลระบบเพียงประกาศ "สถานะที่ต้องการ" เช่น ให้แอปนี้ทำงาน 3 สำเนา แล้ว Kubernetes จะจัดวาง เฝ้าดู และแก้ไขให้ระบบกลับมาตรงตามที่ประกาศไว้เสมอ

ชื่อ Kubernetes มาจากภาษากรีก แปลว่านายท้ายเรือ และมักย่อว่า K8s จากการนับตัวอักษร 8 ตัวระหว่าง K กับ s Google เปิดซอร์สโครงการนี้ในปี 2014 โดยอาศัยประสบการณ์การรันระบบ production ขนาดใหญ่ของตัวเองมากว่า 15 ปี ต่อมา CNCF รับเข้าเป็นโครงการระดับ Incubating เมื่อ 10 มีนาคม 2016 และเลื่อนขึ้นเป็นระดับ Graduated เมื่อ 6 มีนาคม 2018

Kubernetes แก้ปัญหาอะไร

คอนเทนเนอร์ทำให้การบรรจุและรันแอปพลิเคชันง่ายขึ้น แต่เมื่อนำขึ้นใช้งานจริงจะเกิดคำถามตามมาทันที ถ้าคอนเทนเนอร์ตัวหนึ่งล้ม ใครจะเริ่มตัวใหม่ ถ้าผู้ใช้เพิ่มขึ้นสิบเท่า จะเพิ่มสำเนาอย่างไร และเมื่อออกเวอร์ชันใหม่ จะสลับอย่างไรไม่ให้บริการหยุด งานเหล่านี้ทำด้วยมือได้เมื่อมีคอนเทนเนอร์ไม่กี่ตัว แต่จะควบคุมไม่ไหวเมื่อมีหลายร้อยตัวบนหลายสิบเครื่อง

เอกสารของโครงการสรุปสิ่งที่ Kubernetes ทำให้ไว้ดังนี้

• Service discovery และ load balancing เปิดให้เข้าถึงคอนเทนเนอร์ผ่านชื่อ DNS หรือ IP และกระจายทราฟฟิกเมื่อโหลดสูง
• Automated rollouts และ rollbacks เปลี่ยนจากสถานะปัจจุบันไปสู่สถานะที่ต้องการในอัตราที่ควบคุมได้ และย้อนกลับได้เมื่อมีปัญหา
• Self-healing เริ่มคอนเทนเนอร์ที่ล้มใหม่ แทนที่ตัวที่ไม่ตอบสนอง และไม่ส่งทราฟฟิกให้จนกว่าจะพร้อม
• Automatic bin packing ผู้ดูแลบอกว่าแต่ละคอนเทนเนอร์ต้องการ CPU และหน่วยความจำเท่าใด ระบบจะจัดวางลงบนเครื่องให้ใช้ทรัพยากรคุ้มที่สุด
• Horizontal scaling เพิ่มหรือลดจำนวนสำเนาด้วยคำสั่งเดียว หรือปรับอัตโนมัติตามการใช้ CPU
• Storage orchestration และการจัดการ Secret เชื่อมต่อที่เก็บข้อมูลที่เลือกได้เอง และเก็บรหัสผ่านหรือโทเคนแยกจาก image

Kubernetes ทำงานอย่างไร

คลัสเตอร์ Kubernetes ประกอบด้วยสองส่วน ส่วนแรกคือ control plane ซึ่งเป็นสมองของระบบ และส่วนที่สองคือ worker node ซึ่งเป็นเครื่องที่รันแอปพลิเคชันจริง

control plane มีองค์ประกอบหลักสี่อย่าง kube-apiserver เป็นประตูที่เปิด API ของ Kubernetes ให้ทุกส่วนเรียกใช้ etcd เป็นฐานข้อมูลแบบ key-value ที่เก็บสถานะทั้งหมดของคลัสเตอร์ kube-scheduler คอยเลือกว่า Pod ที่ยังไม่มีที่ลงควรไปอยู่บน node ใด และ kube-controller-manager รันตัวควบคุมที่คอยปรับสถานะจริงให้ตรงกับสถานะที่ประกาศไว้ คลัสเตอร์บนคลาวด์อาจมี cloud-controller-manager เพิ่มเข้ามาเพื่อเชื่อมกับบริการของผู้ให้บริการ ส่วนบนแต่ละ node จะมี kubelet คอยดูแลให้ Pod และคอนเทนเนอร์ทำงาน มี container runtime ซึ่งเป็นซอฟต์แวร์ที่รันคอนเทนเนอร์จริง และมักมี kube-proxy ดูแลกฎเครือข่ายที่ทำให้ Service ใช้งานได้

หัวใจของ Kubernetes คือการทำงานแบบประกาศ (declarative) ผู้ใช้ไม่ได้สั่งทีละขั้นว่าให้ทำอะไรก่อนหลัง แต่เขียนไฟล์บรรยายสถานะที่ต้องการแล้วส่งให้ API ตัวควบคุมต่าง ๆ จะทำงานวนไปเรื่อย ๆ เพื่อขยับสถานะจริงให้เข้าใกล้สถานะนั้น เอกสารของโครงการจึงอธิบายว่า Kubernetes ไม่ใช่ระบบ orchestration แบบสั่งงานเป็นลำดับขั้น แต่เป็นชุดกระบวนการควบคุมอิสระที่ทำงานประกอบกัน

แนวคิดหลักของ Kubernetes ที่ต้องรู้

คำศัพท์หกคำต่อไปนี้ครอบคลุมสิ่งที่ต้องเข้าใจก่อนคุยกับทีมพัฒนาหรือผู้ให้บริการ

มีรายละเอียดสามเรื่องที่ควรรู้เพิ่ม เรื่องแรก Pod เป็นทรัพยากรชั่วคราว Kubernetes สร้างและลบ Pod เพื่อให้ตรงกับสถานะที่ต้องการอยู่ตลอด จึงไม่ควรออกแบบระบบให้พึ่ง Pod ตัวใดตัวหนึ่ง เรื่องที่สอง Service มีหลายประเภท ค่าเริ่มต้นคือ ClusterIP ที่เข้าถึงได้เฉพาะภายในคลัสเตอร์ ส่วน NodePort และ LoadBalancer ใช้เปิดออกสู่ภายนอก เรื่องที่สาม การสร้าง Ingress อย่างเดียวไม่มีผลใด ๆ ต้องมี Ingress controller ทำงานอยู่ในคลัสเตอร์ด้วย และปัจจุบันเอกสารของ Kubernetes ระบุว่า Ingress API ถูกตรึงไว้ ไม่พัฒนาต่อ โครงการแนะนำให้ใช้ Gateway API แทน แม้จะไม่มีแผนถอด Ingress ออกก็ตาม

สำหรับแอปที่ต้องเก็บสถานะ เช่น ฐานข้อมูล Kubernetes มีทรัพยากรอีกชนิดชื่อ StatefulSet ซึ่งจับคู่ Pod แต่ละตัวกับที่เก็บข้อมูลถาวรของตัวเอง

Kubernetes ต่างจาก Docker อย่างไร

สองชื่อนี้มักถูกพูดถึงคู่กันจนเข้าใจว่าเป็นคู่แข่ง ความจริงคือทำงานคนละชั้น Docker เป็นแพลตฟอร์มสำหรับพัฒนา ส่งมอบ และรันแอปพลิเคชันในคอนเทนเนอร์ ใช้สร้าง image จาก Dockerfile และรันคอนเทนเนอร์บนเครื่องที่ติดตั้ง ส่วน Kubernetes ไม่ได้สร้าง image และไม่ได้ build แอปพลิเคชัน แต่รับ image ที่สร้างเสร็จแล้วไปจัดการให้ทำงานบนเครื่องจำนวนมาก

ประเด็นที่สับสนกันมากคือข่าวว่า "Kubernetes เลิกใช้ Docker" ข้อเท็จจริงคือ Kubernetes รุ่นแรก ๆ ทำงานกับ Docker Engine ได้อย่างเดียว ผ่านโค้ดเชื่อมต่อชื่อ dockershim ต่อมาโครงการกำหนดมาตรฐาน Container Runtime Interface (CRI) เพื่อรองรับ runtime หลายตัว และถอด dockershim ออกตั้งแต่ Kubernetes v1.24 ปัจจุบัน runtime ที่เอกสารแนะนำวิธีใช้ได้แก่ containerd, CRI-O, Docker Engine ซึ่งต้องใช้ตัวแปลง cri-dockerd และ Mirantis Container Runtime ทั้งนี้เอกสารคำถามที่พบบ่อยของโครงการยืนยันว่า image ที่สร้างด้วยคำสั่ง docker build ใช้ได้กับ runtime ทุกตัวที่รองรับ CRI ทีมพัฒนาจึงไม่ต้องเปลี่ยนวิธีทำงาน

Kubernetes ต่างจาก Virtual Machine อย่างไร

Virtual Machine (VM) จำลองเครื่องทั้งเครื่อง แต่ละ VM มีระบบปฏิบัติการของตัวเองรันอยู่บนฮาร์ดแวร์เสมือน จึงแยกจากกันชัดเจน แต่ใช้ทรัพยากรมากและเริ่มทำงานช้ากว่า ส่วนคอนเทนเนอร์ใช้ระบบปฏิบัติการของเครื่องร่วมกัน มีเพียงระบบไฟล์ CPU หน่วยความจำ และพื้นที่โพรเซสของตัวเอง จึงเบาและย้ายข้ามคลาวด์หรือข้ามระบบปฏิบัติการได้ง่าย

ทั้งสองอย่างไม่ได้แทนกัน node ของ Kubernetes เองเป็นได้ทั้ง VM และเครื่องจริง องค์กรที่รันคลัสเตอร์บน VM จึงยังต้องมีแพลตฟอร์ม virtualization หรือคลาวด์รองรับอยู่ข้างล่าง คำถามที่ถูกจึงไม่ใช่ "VM หรือ Kubernetes" แต่คือ "แอปตัวใดควรอยู่ใน VM ตรง ๆ และตัวใดควรอยู่ในคอนเทนเนอร์"

สิ่งที่ Kubernetes ไม่ได้ทำให้

ความคาดหวังที่ผิดเป็นสาเหตุสำคัญของโครงการที่ล้มเหลว เอกสารของโครงการระบุชัดว่า Kubernetes ไม่ใช่ PaaS แบบครบวงจร และไม่ได้ทำสิ่งต่อไปนี้ให้

• ไม่ build แอปพลิเคชันและไม่ deploy ซอร์สโค้ด องค์กรต้องมีระบบ CI/CD ของตัวเอง
• ไม่มีบริการระดับแอปพลิเคชันในตัว เช่น ฐานข้อมูล message bus หรือ cache สิ่งเหล่านี้รันบน Kubernetes ได้ แต่ต้องติดตั้งและดูแลเอง
• ไม่กำหนดระบบ logging, monitoring และ alerting ให้ ต้องเลือกและติดตั้งเพิ่ม
• ไม่จัดการตัวเครื่อง ทั้งการตั้งค่า การบำรุงรักษา และการซ่อมแซมเครื่องอยู่นอกขอบเขต

กล่าวอีกแบบ Kubernetes ให้ชิ้นส่วนสำหรับสร้างแพลตฟอร์ม แต่ไม่ใช่แพลตฟอร์มสำเร็จรูป งานประกอบชิ้นส่วนเหล่านี้คือต้นทุนที่มักถูกประเมินต่ำไป

Managed Kubernetes กับการดูแลเอง เลือกแบบไหน

เอกสารของ Kubernetes แนะนำให้พิจารณามอบงานบางส่วนหรือทั้งหมดให้ผู้ให้บริการก่อนจะสร้างคลัสเตอร์ production เอง โดยมีทางเลือกตั้งแต่แบบ serverless ที่ไม่ต้องดูแลคลัสเตอร์เลย แบบที่ผู้ให้บริการดูแล control plane ทั้งการขยายขนาด ความพร้อมใช้งาน แพตช์ และการอัปเกรด ไปจนถึงแบบที่ดูแล worker node ให้ด้วย

ไม่ว่าเลือกแบบใด ภาระหนึ่งที่เลี่ยงไม่ได้คือรอบอัปเกรด โครงการ Kubernetes ดูแล release branch เฉพาะสามรุ่นย่อยล่าสุด และแต่ละรุ่นได้แพตช์ประมาณหนึ่งปี ณ ต้นเดือนตุลาคม 2026 สามรุ่นดังกล่าวคือ 1.37, 1.36 และ 1.35 ขณะที่รุ่น 1.34 มีกำหนดสิ้นสุดการดูแลในวันที่ 27 ตุลาคม 2026 คลัสเตอร์ที่ไม่ได้อัปเกรดเกินหนึ่งปีจึงมีแนวโน้มจะอยู่บนรุ่นที่ไม่ได้รับแพตช์ความปลอดภัยแล้ว

องค์กรแบบไหนควรใช้ Kubernetes และแบบไหนยังไม่ควร

Kubernetes เป็นทางเลือกกระแสหลักแล้ว แบบสำรวจประจำปีของ CNCF ที่เผยแพร่เมื่อ 20 มกราคม 2026 ระบุว่า 82% ของผู้ใช้คอนเทนเนอร์รัน Kubernetes บน production อย่างไรก็ตาม ตัวเลขนี้มาจากองค์กรที่ใช้คอนเทนเนอร์อยู่แล้ว ไม่ได้แปลว่าทุกองค์กรควรใช้

ควรพิจารณาใช้ เมื่อ

• มีบริการหรือ microservices จำนวนมากที่ต้อง deploy บ่อย และต้องการวิธี deploy แบบเดียวกันทั้งองค์กร
• โหลดขึ้นลงมาก เช่น ระบบที่มีช่วงแคมเปญหรือสิ้นเดือน และต้องการขยายขนาดอัตโนมัติ
• ต้องการรันงานแบบเดียวกันได้ทั้งบนคลาวด์หลายเจ้าและในดาต้าเซ็นเตอร์ของตัวเอง
• ซอฟต์แวร์ที่ซื้อมาเริ่มส่งมอบในรูปคอนเทนเนอร์และกำหนดให้รันบน Kubernetes
• มีทีมแพลตฟอร์มหรือพร้อมลงทุนสร้างทีมที่ดูแลได้ต่อเนื่อง

ยังไม่ควรใช้ เมื่อ

• มีแอปพลิเคชันไม่กี่ตัว โหลดคงที่ และ deploy ไม่บ่อย การรันบน VM หรือบริการสำเร็จรูปง่ายและถูกกว่า
• แอปพลิเคชันยังไม่ได้ออกแบบให้รันในคอนเทนเนอร์ เช่น ผูกกับเครื่อง เก็บไฟล์ไว้ในดิสก์ของตัวเอง หรือผู้ผลิตรับรองเฉพาะการติดตั้งบน VM
• ไม่มีคนรับผิดชอบแพลตฟอร์มชัดเจน คลัสเตอร์ที่ไม่มีเจ้าของจะค้างรุ่นและกลายเป็นความเสี่ยง
• เป้าหมายคือลดต้นทุนอย่างเดียว เพราะ Kubernetes เพิ่มงานด้านเครือข่าย ความปลอดภัย และการเฝ้าระวังที่ต้องใช้คนและเครื่องมือ

ขั้นตอนเริ่มต้นสำหรับองค์กรไทย

ขั้นตอนที่ 1: เริ่มจากคอนเทนเนอร์ก่อน Kubernetes

เลือกแอปพลิเคชันที่ไม่ซับซ้อนหนึ่งตัวมาบรรจุเป็น image และรันให้ได้บนเครื่องเดียว ขั้นนี้จะเผยปัญหาจริง เช่น การตั้งค่าที่ฝังอยู่ในโค้ด หรือไฟล์ที่เขียนลงดิสก์ ซึ่งต้องแก้ก่อนอยู่ดี

ขั้นตอนที่ 2: ทดลองกับบริการแบบ managed ในสภาพแวดล้อมที่ไม่ใช่ production

การเริ่มด้วยบริการที่มีผู้ดูแล control plane ให้ช่วยให้ทีมได้เรียนรู้แนวคิดหลักโดยไม่ต้องรับภาระทั้งหมดตั้งแต่วันแรก ไม่ว่าจะเลือกผู้ให้บริการรายใด ควรถามคำถามชุดเดียวกัน คือรองรับเวอร์ชันใดบ้าง อัปเกรดอย่างไร ข้อมูลอยู่ที่ใด และค่าใช้จ่ายคิดจากอะไร

ขั้นตอนที่ 3: กำหนดเจ้าของแพลตฟอร์ม

ระบุทีมที่รับผิดชอบคลัสเตอร์ รอบอัปเกรด สิทธิ์การเข้าถึงด้วย role-based access control (RBAC) และมาตรฐานการ deploy ก่อนจะย้ายระบบสำคัญขึ้นไป

ขั้นตอนที่ 4: วางระบบเฝ้าระวังและสำรองข้อมูลตั้งแต่ต้น

เลือกเครื่องมือ logging และ monitoring เพราะ Kubernetes ไม่ได้ให้มาในตัว และทดสอบการกู้คืนทั้งข้อมูลของแอปพลิเคชันและการตั้งค่าของคลัสเตอร์

ขั้นตอนที่ 5: ย้ายทีละระบบและวัดผล

เริ่มจากบริการที่ไม่เก็บสถานะ วัดเวลาที่ใช้ deploy จำนวนเหตุขัดข้อง และค่าใช้จ่ายจริง เทียบกับก่อนย้าย แล้วจึงตัดสินใจขยาย

สำหรับองค์กรที่ประมวลผลข้อมูลส่วนบุคคลหรืออยู่ในอุตสาหกรรมที่มีหน่วยงานกำกับดูแล การย้ายไป Kubernetes ไม่ได้เปลี่ยนหน้าที่ตามกฎหมายและข้อกำหนดที่มีอยู่ ทีมงานยังต้องตอบให้ได้ว่าข้อมูลอยู่ที่ใด ใครเข้าถึงได้ และมีบันทึกการเข้าถึงหรือไม่ จึงควรนำทีมความปลอดภัยและทีมกำกับดูแลเข้ามาตั้งแต่ขั้นออกแบบ ไม่ใช่หลังจากระบบขึ้นใช้งานแล้ว