Kubernetes: Deployment และ ReplicaSet

phunsanit

11 ปี ago

การทำความเข้าใจเรื่อง 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 ]  &lt;-- ควบคุมนโยบาย, การอัปเดตเวอร์ชัน (V1 -> V2)
      |
      v
[ ReplicaSet ]  &lt;-- ควบคุมจำนวนสำเนา (เช่น ต้องมี 3 ตัวเสมอ)
      |
  +---+---+
  |   |   |
[Pod][Pod][Pod] &lt;-- ตัวแอปพลิเคชันที่ทำงานจริง

กระบวนการทำงานร่วมกันตอนอัปเดตระบบ (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 จัดการเบื้องหลังให้เราอย่างอัตโนมัติครับ

อ่านเพิ่มเติม