โหมดมืด
บทที่ 4 — Kubernetes สำหรับ DevOps (quick reference — ของจริงอยู่ Kubernetes Book)
← บทที่ 3 | สารบัญ | บทที่ 5 →
ℹ️ บทนี้เป็น quick reference สั้น ๆ — เนื้อหาเต็มอยู่ที่ Kubernetes Book ลำดับการอ่านหลักตาม README คือไป K8s Book ก่อนแล้วค่อยมาบท 05 (CI/CD)
👶 ถ้าคุณมาจากบท 03 และยังไม่เคยใช้ K8s เลย — บทนี้ไม่ใช่บทสอน K8s บทนี้เป็น "คู่มือตัดสินใจ" สำหรับคนที่ผ่าน Kubernetes Book มาแล้ว ถ้ายังไม่รู้จัก K8s เลย ข้ามไปอ่าน Kubernetes Book โดยตรง (11 บท ครบทั้ง Lab) แล้วค่อยกลับมาบทนี้
📚 บทนี้คือ "ภาพรวมสั้น + วิจารณญาณ" สำหรับ DevOps generalist — เนื้อหา Kubernetes ฉบับเต็มอยู่ที่ Kubernetes Book → (11 บท) บทนี้เน้นสิ่งที่ DevOps ต้องตัดสินใจ: เมื่อไรควร/ไม่ควรใช้ K8s แล้วชี้ทางไปเรียนลึก
👶 มือใหม่ที่ยังไม่เคยใช้ K8s → ข้ามไปอ่าน Kubernetes Book ให้ครบ 11 บทก่อน แล้วค่อยกลับมาตัดสินใจที่บทนี้ — บทนี้ไม่ได้สอน K8s แต่ช่วยคุณ "ตัดสินใจว่าจะใช้ไหม"
หลังจบบท คุณจะ:
- เข้าใจว่า K8s แก้ปัญหาอะไรที่ Docker เดี่ยวทำไม่ได้
- ตัดสินใจได้ว่าโปรเจกต์นี้ควรใช้ K8s ไหม (สำคัญที่สุด)
- รู้ศัพท์แกนพอคุยกับทีม และรู้ว่าจะไปเรียนลึกที่บทไหน
🗓️ Baseline 2026: Kubernetes 1.31 stable / 1.33 stable · Gateway API GA แล้ว (ทางเข้า cluster แบบใหม่ที่แทน Ingress สำหรับงานซับซ้อน) · Pod Security Admission เป็น default แทน PSP เก่า · Sidecar Containers GA (pattern ผูก container ช่วยเข้ากับ pod หลัก — ใช้ลด complexity ของ service mesh (เครือข่ายจัดการการสื่อสารระหว่าง service) และ log shipper (ตัวส่ง log ออกไปเก็บที่อื่น) รายละเอียดใน K8s Book)
1. ทำไม Kubernetes — ปัญหาของ Docker เดี่ยว
Docker รัน container ได้ แต่พอขึ้น production จริงจะเจอ:
| ปัญหาของ Docker เดี่ยว | K8s แก้ยังไง |
|---|---|
❌ Server ตาย → app ตาย (Docker มี --restart=always ช่วยได้บ้าง แต่ถ้าเครื่องดับทั้งเครื่องก็จบ) | ✅ Self-healing = ระบบตรวจเจอ pod ที่ crash แล้วรีสตาร์ตให้เอง รวมถึงย้ายไปเครื่องอื่นถ้าเครื่องเดิมตาย |
❌ Scale = พิมพ์ docker run เองทีละตัว | ✅ Auto-scale = เพิ่ม/ลดจำนวน pod อัตโนมัติตาม CPU/memory ที่ใช้จริง |
| ❌ Update = stop + rebuild + start เอง (ดาวน์ระหว่างทำ) | ✅ Rolling update = ค่อย ๆ เปลี่ยน pod ทีละตัวโดยไม่ดาวน์ + rollback กลับเวอร์ชันเก่าได้ทันทีถ้าพัง |
| ❌ Load balance = ตั้ง nginx แยกเอง | ✅ Service discovery = pod ใหม่ ๆ จะถูกหาเจอและกระจาย traffic ให้อัตโนมัติ (built-in load balance) |
| ❌ หลาย server = จัดการเองทั้งหมด | ✅ มองหลายเครื่องเป็น cluster เดียว (กลุ่มเครื่องที่ K8s จัดการรวมกัน) |
Kubernetes (อ่าน "คู-เบอ-เน-ทีส" — ย่อ "K8s" เพราะมีอักษร 8 ตัวคั่นระหว่าง K กับ s) = ระบบ orchestrate (จัดการ/สั่งการ container จำนวนมากให้ทำงานประสานกัน) container ข้ามหลายเครื่อง ที่ทำเรื่องพวกนี้ให้อัตโนมัติ
2. ⚠️ สิ่งที่ DevOps ต้องตัดสินใจ — K8s ไม่ใช่คำตอบทุกอย่าง
นี่คือส่วนสำคัญที่สุดของบทนี้ K8s ทรงพลังแต่ ซับซ้อนและมีต้นทุนดูแลสูง อย่าใช้เพราะมันเท่:
text
❌ อย่าใช้ K8s ถ้า: ✅ ใช้ K8s เมื่อ:
- มี 1-3 service - มี 10+ microservices
(microservices = แอปแยก - หลายทีมทำงานร่วมกัน
เป็นบริการย่อยหลายตัว) - ต้อง scale ขึ้น/ลงตาม load
- ทีม < 5 คน (load = ปริมาณ traffic ที่เข้ามา)
- traffic คาดเดาได้ - ต้องการ self-healing
(traffic = ปริมาณ request) + zero-downtime deploy
- budget/เวลาจำกัด (deploy ใหม่โดยไม่มี downtime)
- ทีมยังไม่เคยทำ Linux - มี requirement compliance
/networking มาก่อน ที่ต้อง audit/isolation ระดับสูง💡 กฎง่าย ๆ: ถ้ายังตอบไม่ได้ว่า "ทำไมต้องใช้ K8s" แปลว่ายังไม่ต้องใช้ — เริ่มจาก PaaS (Platform as a Service — บริการคลาวด์ที่เอา code ไปวางแล้วรันให้เลย ไม่ต้องดูแล server) ที่ง่ายกว่าก่อน แล้วค่อยย้ายเมื่อโตจริง
ทางเลือก PaaS ที่ง่ายกว่า K8s (สำหรับโปรเจกต์เล็ก-กลาง):
- Heroku / Render / Railway — push code แล้วได้ URL เลย ฟรี tier มี เหมาะกับโปรเจกต์ตัวอย่าง
- Google Cloud Run — รัน container แบบ serverless ของ GCP (จ่ายตาม request, scale ลง 0 ได้)
- AWS ECS Fargate — รัน container แบบ serverless ของ AWS (ไม่ต้องจัดการ server)
🔧 เคล็ดลับ 2026: ถ้า K8s ใหญ่เกินตัวจริง ๆ แต่ยังอยากได้ API ของ K8s ลองใช้ distribution เล็ก ก่อน:
- k3s (Rancher) — K8s ตัวเต็ม แต่เบา (~50MB binary) เหมาะ edge / IoT / dev
- kind / minikube — รัน K8s ใน Docker / VM บนเครื่อง dev สำหรับเรียนหรือทดสอบ
- microk8s / k0s — single-node K8s ติดตั้งง่ายสำหรับ home server
และอย่าลืมว่า managed K8s (EKS ของ AWS, GKE ของ GCP, AKS ของ Azure) เปลี่ยนสมการต้นทุน — ทีมเล็กก็ใช้ K8s ได้เพราะ cloud provider ดูแล control plane ให้
2.1 ภาพการตัดสินใจ — flow แบบเร็ว
3. คำศัพท์แกนที่ต้องรู้ (พอคุยกับทีม)
| คำ (วิธีอ่าน) | ความหมายสั้น ๆ | ตัวอย่างการใช้ |
|---|---|---|
| Pod ("พอด") | หน่วยเล็กสุดที่ K8s รัน — ห่อ container 1 ตัว (หรือมากกว่า) | kubectl get pods ดูว่ามี pod อะไรรันอยู่ |
| Deployment ("ดี-พลอย-เม้นท์") | คุมว่าจะรัน pod กี่ตัว + จัดการ update/rollback | kubectl rollout undo deployment/api ย้อนกลับเวอร์ชัน |
| Service ("เซอร์-วิส") | จุดเข้าถึงคงที่ไปยังกลุ่ม pod (load balance ให้) | service ชื่อ api → pod ไหนก็ได้ที่ label ตรง |
| Ingress ("อิน-เกรส") / Gateway API | ทางเข้าจากภายนอกเข้า cluster (routing ตาม path/host) — Gateway API คือมาตรฐานใหม่ปี 2026 | example.com/api → service api |
| ConfigMap / Secret ("คอน-ฟิก-แมป" / "ซี-เคร็ต") | เก็บ config / ความลับ แยกจาก image | DB URL, API key เก็บนอก image ได้ |
| Namespace ("เนม-สเปซ") | "ห้อง" แบ่งทรัพยากรใน cluster เดียวกัน เช่น dev / staging / prod | kubectl -n prod get pods |
| Node ("โหนด") | เครื่อง (จริง/เสมือน) ที่เป็นสมาชิกของ cluster | cluster มี 3 node = 3 เครื่อง |
| RBAC ("อาร์-แบ็ค") | Role-Based Access Control — ใครทำอะไรได้บ้างใน cluster | dev อ่านได้, ops แก้ได้ |
| PV / PVC ("พี-วี" / "พี-วี-ซี") | PersistentVolume / Claim — ที่เก็บข้อมูลถาวรนอก pod | DB ต้องใช้เพื่อไม่ให้ข้อมูลหาย |
| HPA ("เอช-พี-เอ") | Horizontal Pod Autoscaler — เพิ่ม/ลดจำนวน pod อัตโนมัติตาม metric (metric = ค่าที่ระบบวัดได้ เช่น CPU ที่แต่ละ pod ใช้ — ถ้า CPU เกิน 70% K8s จะสร้าง pod ใหม่เพิ่มอัตโนมัติ) | CPU > 70% → เพิ่ม pod |
| kubectl ("คูบ-คอน-โทรล" หรือ "คูบ-ซีทีแอล") | คำสั่ง CLI ที่ใช้สั่ง cluster | kubectl apply --server-side -f app.yaml (แนะนำให้ใช้ --server-side บน K8s 1.22+ เพื่อหลีกเลี่ยงปัญหา annotation bloat และ field conflict) |
💬 เกร็ดการอ่าน: ในวงการมีหลายสำเนียง บางคนอ่าน kubectl ว่า "คูบ-คัดเดิล" ก็ยังได้ — เลือกที่สบายปาก แล้วเข้าใจตรงกันก็พอ
4. ไปเรียนลึกต่อที่ไหน — แผนที่ Kubernetes Book
| อยากเข้าใจ... | อ่านบทนี้ |
|---|---|
| Architecture + kubectl เริ่มต้น | K8s 00 — Introduction |
| Pod (หน่วยเล็กสุด) | K8s 01 — Pods |
| Deployment, self-healing, rolling update | K8s 02 — Deployments |
| Service + networking ใน cluster | K8s 03 — Services + Networking |
| ConfigMap + Secret | K8s 04 — Config + Secrets |
| Storage — PV / PVC | K8s 05 — Storage |
| Ingress + Gateway API | K8s 06 — Ingress |
| Health check + autoscaling (HPA) | K8s 07 — Health + Scaling |
| Workload Types ที่ไม่ใช่ Deployment — StatefulSet (สำหรับ DB ที่ต้องจดจำ identity), DaemonSet (รันบนทุก node เช่น log agent), Job/CronJob (งาน batch ทำครั้งเดียว/ตามเวลา) | K8s 08 — Workload Types |
| Helm (package manager ของ K8s) + deployment strategy | K8s 09 — Helm + Deployment |
| Observability + production hardening | K8s 10 — Observability + Production |
✅ Checkpoint
- K8s แก้ปัญหาอะไรที่ Docker เดี่ยวทำไม่ได้ (ยก 3 ข้อ)?
- โปรเจกต์มี 2 service ทีม 3 คน traffic นิ่ง — ควรใช้ K8s ไหม เพราะอะไร? ทางเลือกที่เหมาะกว่าคืออะไร?
- Pod, Deployment, Service ต่างกันยังไง?
- ถ้าต้องทำ autoscaling ควรไปอ่านบทไหนของ K8s Book?
- ทีมเล็กอยากลองใช้ K8s แบบเบา ๆ ก่อน — ควรเริ่มที่ distribution ตัวไหน?
🛠️ Lab อยู่ในเล่มเต็ม — Kubernetes Book มี Lab ครบทุกบท เริ่มที่ K8s 00