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

> Kubernetes คือแพลตฟอร์ม open source สำหรับจัดการแอปพลิเคชันในคอนเทนเนอร์จำนวนมากให้ทำงานต่อเนื่อง บทความนี้อธิบายแนวคิดหลัก ความต่างจาก Docker และ VM ทางเลือกแบบ managed และองค์กรที่ควรใช้

- ประเภท: อธิบาย · หมวด: Software & DevOps
- เผยแพร่: 2026-10-01T18:10:00.000Z · อัปเดต: 2026-10-02T10:40:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/software/what-is-kubernetes/

## สรุปประเด็นสำคัญ

- **Kubernetes** (K8s) คือแพลตฟอร์ม open source สำหรับจัดการ workload และบริการที่อยู่ในคอนเทนเนอร์ Google เปิดซอร์สโครงการนี้ในปี 2014 และปัจจุบันอยู่ภายใต้การดูแลของ Cloud Native Computing Foundation (CNCF)
- หน่วยที่เล็กที่สุดคือ **Pod** ซึ่งรันอยู่บน **Node** ภายใน **Cluster** โดยมี Deployment, Service และ Ingress ดูแลจำนวนสำเนา การเข้าถึงภายใน และการรับทราฟฟิกจากภายนอก
- Docker ใช้สร้างและรันคอนเทนเนอร์ ส่วน Kubernetes จัดการคอนเทนเนอร์ข้ามหลายเครื่อง ตั้งแต่ **v1.24** Kubernetes ถอด dockershim ออกแล้ว แต่ image ที่สร้างด้วย Docker ยังใช้ได้ตามปกติ
- โครงการ Kubernetes ดูแล release branch เฉพาะ **3 รุ่นย่อยล่าสุด** และแต่ละรุ่นได้แพตช์ประมาณ 1 ปี ผู้ใช้จึงต้องอัปเกรดคลัสเตอร์อย่างสม่ำเสมอ
- แบบสำรวจของ CNCF ที่เผยแพร่เมื่อ 20 มกราคม 2026 ระบุว่า **82%** ของผู้ใช้คอนเทนเนอร์รัน Kubernetes บน production แต่ระบบที่มีไม่กี่แอปและโหลดคงที่อาจไม่คุ้มกับความซับซ้อน

**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: control plane ทางซ้ายสั่งงาน node ซึ่งรัน kubelet และ kube-proxy](https://thaidata.co.th/images/articles/what-is-kubernetes/kubernetes-components.webp) _(ภาพ: The Kubernetes Authors (CC BY 4.0))_

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

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

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

| แนวคิด | คืออะไร | เทียบให้เข้าใจง่าย |
| --- | --- | --- |
| Cluster | กลุ่มของ node ที่รันแอปพลิเคชันในคอนเทนเนอร์ภายใต้การจัดการของ Kubernetes ประกอบด้วย control plane และ worker node อย่างน้อยหนึ่งเครื่อง | ทั้งระบบหนึ่งชุด |
| Node | เครื่องที่ใช้รันงาน อาจเป็น VM หรือเครื่องจริง แต่ละ node ถูกจัดการโดย control plane | เซิร์ฟเวอร์หนึ่งเครื่องในกลุ่ม |
| Pod | หน่วยที่เล็กที่สุดที่สร้างและจัดการได้ เป็นกลุ่มของคอนเทนเนอร์หนึ่งตัวหรือมากกว่าที่ใช้ storage และเครือข่ายร่วมกัน | แอปหนึ่งสำเนาที่กำลังทำงาน |
| Deployment | ตัวจัดการชุดของ Pod สำหรับแอปที่ไม่เก็บสถานะ ดูแลจำนวนสำเนา การอัปเดตทีละส่วน และการย้อนกลับ | คำสั่งว่า "ให้มีแอปนี้ 3 สำเนาเสมอ" |
| Service | วิธีเปิดแอปที่รันอยู่ใน Pod หลายตัวให้เข้าถึงได้ผ่านปลายทางเดียวที่คงที่ แม้ Pod จะถูกสร้างและลบตลอดเวลา | เบอร์กลางของแผนก |
| Ingress | ออบเจ็กต์ที่กำหนดเส้นทาง HTTP และ HTTPS จากภายนอกคลัสเตอร์ไปยัง Service ภายใน ตามชื่อโฮสต์หรือพาธ | ประตูหน้าและป้ายบอกทาง |

![Pod หนึ่งตัวมี IP ของตัวเอง และอาจมีคอนเทนเนอร์กับ volume มากกว่าหนึ่งรายการ](https://thaidata.co.th/images/articles/what-is-kubernetes/kubernetes-pods-overview.webp) _(ภาพ: The Kubernetes Authors (CC BY 4.0))_

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

![Service เลือก Pod ปลายทางด้วย label ไม่ใช่ด้วย IP ของ Pod ตัวใดตัวหนึ่ง ส่วน Deployment ดูแลจำนวน Pod ผ่าน ReplicaSet](https://thaidata.co.th/images/articles/what-is-kubernetes/kubernetes-service-labels.webp) _(ภาพ: The Kubernetes Authors (CC BY 4.0))_

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

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

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

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

ประเด็นที่สับสนกันมากคือข่าวว่า "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 หน่วยความจำ และพื้นที่โพรเซสของตัวเอง จึงเบาและย้ายข้ามคลาวด์หรือข้ามระบบปฏิบัติการได้ง่าย

![การ deploy สามยุคตามเอกสารของ Kubernetes: บนเครื่องจริง บน Virtual Machine และบนคอนเทนเนอร์ที่ใช้ระบบปฏิบัติการร่วมกัน](https://thaidata.co.th/images/articles/what-is-kubernetes/kubernetes-deployment-evolution.webp) _(ภาพ: The Kubernetes Authors (CC BY 4.0))_

| ประเด็น | Virtual Machine | คอนเทนเนอร์บน Kubernetes |
| --- | --- | --- |
| สิ่งที่จำลอง | ฮาร์ดแวร์ทั้งเครื่อง | สภาพแวดล้อมของแอปพลิเคชัน |
| ระบบปฏิบัติการ | แต่ละ VM มีของตัวเอง | ใช้ร่วมกับเครื่องที่รัน |
| หน่วยที่จัดการ | เครื่อง | แอปพลิเคชัน |
| การแยกส่วน | เข้มกว่า | ผ่อนกว่า เพราะใช้ kernel ร่วมกัน |
| การอัปเดตแอป | แก้ไขภายในเครื่องหรือสร้าง image เครื่องใหม่ | สร้าง image ใหม่แล้วสลับ ย้อนกลับได้เร็ว |

ทั้งสองอย่างไม่ได้แทนกัน 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 ให้ด้วย

| ประเด็น | Managed Kubernetes | ดูแลเอง (self-managed) |
| --- | --- | --- |
| control plane | ผู้ให้บริการดูแลความพร้อมใช้งานและการอัปเกรด | องค์กรติดตั้งเองด้วยเครื่องมืออย่าง kubeadm, kops หรือ Kubespray |
| ฐานข้อมูล etcd | ผู้ให้บริการดูแล | ต้องวางแผนสำรองและกู้คืนเอง |
| การอัปเกรดเวอร์ชัน | สั่งผ่านบริการ แต่ยังต้องทดสอบแอปเอง | วางแผนและลงมือเองทุกขั้น |
| การควบคุม | จำกัดตามที่บริการเปิดให้ | ปรับได้ทุกส่วน |
| ทักษะที่ต้องมี | ทีมที่เข้าใจการใช้งาน Kubernetes | ทีมที่ดูแลระบบกระจายตัวได้ตลอดเวลา |
| เหมาะกับ | องค์กรส่วนใหญ่ที่เริ่มต้น | องค์กรที่มีข้อกำหนดเฉพาะ เช่น ต้องรันในดาต้าเซ็นเตอร์ของตัวเอง หรือระบบที่ไม่เชื่อมต่อภายนอก |

ไม่ว่าเลือกแบบใด ภาระหนึ่งที่เลี่ยงไม่ได้คือรอบอัปเกรด โครงการ 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 ไม่ได้เปลี่ยนหน้าที่ตามกฎหมายและข้อกำหนดที่มีอยู่ ทีมงานยังต้องตอบให้ได้ว่าข้อมูลอยู่ที่ใด ใครเข้าถึงได้ และมีบันทึกการเข้าถึงหรือไม่ จึงควรนำทีมความปลอดภัยและทีมกำกับดูแลเข้ามาตั้งแต่ขั้นออกแบบ ไม่ใช่หลังจากระบบขึ้นใช้งานแล้ว

## คำถามที่พบบ่อย

### Kubernetes คืออะไร แบบสั้นที่สุด?

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

### Kubernetes กับ Docker ต่างกันอย่างไร?

Docker เป็นเครื่องมือสำหรับสร้าง image และรันคอนเทนเนอร์ โดยทั่วไปใช้บนเครื่องเดียว ส่วน Kubernetes เป็นระบบที่จัดการคอนเทนเนอร์จำนวนมากบนหลายเครื่องพร้อมกัน ทั้งสองอย่างจึงใช้ร่วมกันได้ นักพัฒนาสร้าง image ด้วย Docker แล้วนำไปรันบน Kubernetes ซึ่งใช้ container runtime อย่าง containerd หรือ CRI-O

### Managed Kubernetes คืออะไร ต่างจากติดตั้งเองอย่างไร?

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

### องค์กรขนาดเล็กจำเป็นต้องใช้ Kubernetes ไหม?

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

### K8s ย่อมาจากอะไร?

K8s เป็นตัวย่อของ Kubernetes ได้มาจากการนับตัวอักษร 8 ตัวที่อยู่ระหว่างตัว K กับตัว s ส่วนคำว่า Kubernetes มาจากภาษากรีก แปลว่านายท้ายเรือหรือผู้นำร่อง ตามที่เอกสารของโครงการอธิบายไว้


## แหล่งอ้างอิง

- [Overview](https://kubernetes.io/docs/concepts/overview/) — Kubernetes
- [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) — Kubernetes
- [Container Runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) — Kubernetes
- [Production environment](https://kubernetes.io/docs/setup/production-environment/) — Kubernetes
- [Releases](https://kubernetes.io/releases/) — Kubernetes
- [The CNCF Annual Cloud Native Survey: The Infrastructure of AI's Future](https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/) — Cloud Native Computing Foundation (CNCF)