การทำความเข้าใจเรื่อง Deployment และ ReplicaSet (มักจะพิมพ์ผิดหรือเรียกย่อกันว่า replica/republica) ใน Kubernetes (K8s) เป็นหัวใจสำคัญของการจัดการแอปพลิเคชันให้ทำงานได้แบบไม่มีล่ม (High Availability) และขยายระบบได้ง่ายครับ
เพื่อให้เห็นภาพชัดเจน เรามาดูหน้าที่และความสัมพันธ์ของทั้งสองตัวนี้กันครับ
Kubernetes Deployment คืออะไร?
Deployment เป็น Object ระดับสูงใน Kubernetes ที่ทำหน้าที่ควบคุมและจัดการแอปพลิเคชันของเรา โดยเราจะบอก Deployment ว่า “ฉันต้องการให้แอปพลิเคชันเวอร์ชันนี้ หน้าตาแบบนี้ รันอยู่บนระบบนะ” แล้ว Deployment จะไปจัดการส่วนที่เหลือให้เอง
หน้าที่หลักของ Deployment
- การอัปเดตแอปพลิเคชัน (Rollout/Upgrade): เช่น เปลี่ยนจากเวอร์ชัน 1 ไปเวอร์ชัน 2 โดยที่ระบบไม่ล่ม (Zero Downtime)
- การย้อนกลับ (Rollback): ถ้าอัปเดตเวอร์ชันใหม่แล้วพัง สามารถสั่งถอยกลับไปเวอร์ชันก่อนหน้าได้ทันที
- การควบคุมสถานะ (Declarative State): คอยตรวจดูว่าแอปพลิเคชันรันได้ตามที่ตั้งค่าไว้ไหม
ReplicaSet (หรือที่ระบบชอบเรียกว่า Replica) คืออะไร?
คำว่า “replica” แปลตรงตัวคือ “สําเนา” ส่วน ReplicaSet คือ Object ที่ทำหน้าที่ “ปั๊มและควบคุมจำนวนสำเนา (Pod)” ให้ตรงตามจำนวนที่เราสั่งไว้ตลอดเวลา
หน้าที่หลักของ ReplicaSet
- รักษาจำนวน Pod (Self-Healing): สมมติตั้งไว้ว่าต้องการ 3 สำเนา (Replicas: 3) เกิดมี Pod หนึ่งตายไปเพราะเครื่องเซิร์ฟเวอร์พัง ReplicaSet จะรู้ตัวทันที แล้วสั่งเปิด Pod ใหม่ขึ้นมาทดแทนให้ครบ 3 ตัวเสมอ
ความสัมพันธ์ของ Deployment และ ReplicaSet / Replica
ถ้าจะให้อธิบายให้เห็นภาพง่ายที่สุด
Deployment คือ “ผู้จัดการใหญ่” ส่วน ReplicaSet คือ “หัวหน้างานหน้างาน” และ Pod คือ “พนักงาน (ตัวแอปพลิเคชัน)”
ความสัมพันธ์ของมันจะทำงานร่วมกันเป็นชั้น ๆ (Hierarchy) ดังนี้ครับ
[ Deployment ] <-- ควบคุมนโยบาย, การอัปเดตเวอร์ชัน (V1 -> V2)
|
v
[ ReplicaSet ] <-- ควบคุมจำนวนสำเนา (เช่น ต้องมี 3 ตัวเสมอ)
|
+---+---+
| | |
[Pod][Pod][Pod] <-- ตัวแอปพลิเคชันที่ทำงานจริง
กระบวนการทำงานร่วมกันตอนอัปเดตระบบ (Rollout)
ความสัมพันธ์นี้จะชัดเจนที่สุดเวลาเราสั่ง อัปเดตเวอร์ชันแอปพลิเคชัน
- Deployment จะสร้าง ReplicaSet ตัวใหม่ขึ้นมา: สมมติแอปเดิมเป็น V1 (ควบคุมโดย ReplicaSet-V1) พอเราสั่งอัปเดตเป็น V2 ตัว Deployment จะสร้าง ReplicaSet-V2 ขึ้นมาใหม่
- ทยอยเปลี่ยนไม้ (Rolling Update): Deployment จะสั่งให้ ReplicaSet-V2 ค่อยๆ เปิด Pod V2 ขึ้นมาทีละตัว และสั่งให้ ReplicaSet-V1 ค่อยๆ ลดจำนวน Pod V1 ลงทีละตัว
- เก็บประวัติไว้ย้อนกลับ: เมื่ออัปเดตเสร็จแล้ว Pod V1 จะเหลือ 0 ตัว แต่ ReplicaSet-V1 จะยังไม่ถูกลบไป เพื่อให้ Deployment สามารถสั่ง Rollback ย้อนกลับมาใช้สำเนาเดิมได้ทันทีหากเวอร์ชัน V2 มีปัญหา
สรุปความต่างสั้น ๆ
- เราเขียนไฟล์ Config (YAML) สั่งงานที่ Deployment เสมอ
- Deployment จะไปสั่งงาน ReplicaSet อีกทีเพื่อกำหนดจำนวนสำเนา (Replica)
- เราแทบจะไม่ต้องสร้างหรือสั่งงาน ReplicaSet ตรง ๆ เลย เพราะ Deployment จัดการเบื้องหลังให้เราอย่างอัตโนมัติครับ
อ่านเพิ่มเติม