Deployment — หน่วยหลักในการรันแอป
ห่อ ReplicaSet ให้ได้ทั้ง self-healing, scaling และจัดการเวอร์ชัน
Deployment: คือ Object หลักที่เราใช้ในการรันและจัดการแอปพลิเคชันแบบที่ไม่มีสถานะ (Stateless) โดยมันจะทำหน้าที่ไปจัดการ ReplicaSet เพื่อให้ได้ทั้งจำนวน Pod คงที่ และยังสามารถทำการเปลี่ยนเวอร์ชันได้อย่างปลอดภัย
Deployment เหมือนผู้จัดการสาขา ที่ไม่ได้คุมพนักงานเอง แต่คุม "หัวหน้ากะ" (ReplicaSet) อีกที · เวลาจะเปลี่ยนเมนู (เวอร์ชันใหม่) ผู้จัดการจะตั้งกะใหม่แล้วค่อย ๆ ย้ายคนจากกะเก่าไปกะใหม่ โดยร้านไม่ต้องปิด
Deployment คือ object ที่เราใช้จริงเกือบตลอดเวลาในการรันแอปแบบ stateless (เว็บ, API) มันให้เราครบทั้ง: จำนวน Pod คงที่ (ผ่าน ReplicaSet), สเกลขึ้นลง, และอัปเดต/ย้อนเวอร์ชันแบบปลอดภัย
เราแก้ที่ Deployment ชั้นบน · ชั้นล่างจัดการให้เอง
ตัวอย่าง Deployment
apiVersion: apps/v1 # Deployment อยู่ใน API group "apps"
kind: Deployment
metadata:
name: web
spec:
replicas: 3 # อยากได้ 3 Pod เสมอ
selector:
matchLabels:
app: web # คุม Pod ที่มี label app=web
template: # "พิมพ์เขียว" ของ Pod ที่จะสร้าง
metadata:
labels:
app: web # ต้องตรงกับ selector ด้านบน
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80kubectl apply -f deployment.yaml # สร้าง/อัปเดต Deployment
kubectl get deployments # ดูสถานะ (READY 3/3 = พร้อม)
kubectl scale deployment/web --replicas=5 # สเกลเป็น 5
kubectl set image deployment/web nginx=nginx:1.28 # อัปเดตเวอร์ชันสรุป Key Takeaways
- Deployment = หน่วยหลักในการรันแอป stateless — ให้ self-healing + scaling + version management
- โครงสร้าง: Deployment → ReplicaSet → Pods · เราแก้ที่ Deployment เท่านั้น
- selector.matchLabels ต้องตรงกับ template.metadata.labels
- งาน stateful (มี identity/storage ต่อ Pod) ใช้ StatefulSet แทน
คำถามที่พบบ่อย
Deployment เพิ่มอะไรจาก ReplicaSet
การจัดการ "เวอร์ชัน" — เปลี่ยน image แล้ว Deployment สร้าง RS ใหม่แล้วทยอยย้าย pod (rolling update), เก็บประวัติให้ rollback ได้ทันที — ReplicaSet ทำได้แค่รักษาจำนวน ไม่รู้จักการเปลี่ยนเวอร์ชัน — งานจริงจึงใช้ Deployment เป็น default ของ stateless app เสมอ
แก้ image ใน YAML กับใช้ kubectl set image ต่างกันไหม
ผลเหมือนกันแต่วินัยต่างกัน — set image เร็วแต่ทำให้ไฟล์ใน git ไม่ตรงกับของจริง (drift) แนวที่ถูกคือแก้ YAML/values แล้ว apply ผ่าน pipeline ให้ git เป็น source of truth เสมอ โดยเฉพาะเมื่อทีมโตขึ้น

