kubectl และแนวคิด Declarative
สั่งงานคลัสเตอร์ด้วย kubectl และไฟล์ YAML manifest
kubectl (อ่านว่า คิวบ์-คอน-โทรล): คือ เครื่องมือ Command Line ที่เราใช้สำหรับคุยและสั่งงาน Kubernetes Cluster
kubectl คือรีโมตคอนโทรลของคลัสเตอร์ · การสั่งมี 2 สไตล์: imperative = กดปุ่มสั่งทีละอย่าง ("เปิดแอร์เดี๋ยวนี้") กับ declarative = เขียนโพยไว้ว่าอยากให้ห้องเป็นยังไงแล้วให้ระบบจัดการ ("ห้องนี้ให้ 25°C เสมอ") — K8s แนะนำแบบหลัง
คำสั่ง kubectl ที่ใช้บ่อยที่สุด
kubectl get nodes # ดูรายชื่อเครื่องในคลัสเตอร์
kubectl get pods # ดู Pod ใน namespace ปัจจุบัน
kubectl get pods -A # ดู Pod ทุก namespace
kubectl describe pod <ชื่อ> # ดูรายละเอียด + เหตุการณ์ (ดีมากตอน debug)
kubectl logs <ชื่อ pod> # ดู log ของ container
kubectl apply -f app.yaml # ปรับคลัสเตอร์ให้ตรงกับไฟล์ (declarative)
kubectl delete -f app.yaml # ลบสิ่งที่นิยามในไฟล์Imperative vs Declarative
- Imperative —
kubectl run,kubectl createสั่งตรง ๆ เห็นผลไว เหมาะทดลอง/เรียนรู้ แต่ไม่มีบันทึกว่าระบบควรเป็นยังไง - Declarative — เขียนไฟล์ YAML บอก "อยากได้อะไร" แล้ว
kubectl apply -f· ไฟล์เก็บใน Git ได้ ทำซ้ำได้ ตรวจสอบย้อนหลังได้ = มาตรฐานงานจริง
สรุป Key Takeaways
- kubectl = รีโมตสั่งงานคลัสเตอร์ · get / describe / logs / apply คือชุดที่ใช้บ่อยสุด
- Declarative (apply -f ไฟล์ YAML) เป็นมาตรฐานงานจริง — เก็บใน Git ทำซ้ำได้ idempotent
- ทุก manifest มี 4 ฟิลด์: apiVersion, kind, metadata, spec · YAML เยื้องด้วย space ห้าม Tab
คำถามที่พบบ่อย
Imperative กับ declarative ต่างกันยังไง ควรใช้แบบไหน
Imperative = สั่งเป็นคำสั่ง (kubectl run/create/scale) เหมาะกับทดลองเร็วๆ ส่วน declarative = เขียน YAML บอกสภาพที่อยากได้แล้ว kubectl apply — งานจริงใช้ declarative เพราะไฟล์อยู่ใน git, review ได้, ทำซ้ำได้, และ apply ซ้ำกี่รอบผลเหมือนเดิม (idempotent)
คำสั่ง kubectl ที่ควรคล่องที่สุดตอน debug คืออะไร
สามตัวหลัก: kubectl describe pod <name> (ดู events ว่าทำไม pod ไม่ขึ้น — คำตอบ 80% อยู่ตรงนี้), kubectl logs <pod> (ดู log แอป, เพิ่ม --previous ดูตัวที่เพิ่ง crash) และ kubectl get pods -o wide (สถานะ+อยู่ node ไหน) — สามคำสั่งนี้แก้ปัญหาได้เกินครึ่งของชีวิตจริง