Deployment และ ReplicaSet คืออะไร และ rolling update กับ rollback ทำงานอย่างไร?

Question

IT Interview Practice · Accepted Answer

**Deployment** เป็น controller มาตรฐานสำหรับการรันแอป stateless มันจัดการ **ReplicaSet** และ ReplicaSet จะรักษาจำนวน Pod ที่เหมือนกันทุกประการให้รันอยู่ตามที่ระบุ คุณแก้ไข Deployment แล้วมันจะประสานงาน **rolling update** และ **rollback** ให้คุณ

## ลำดับชั้น

```text
Deployment  → ประกาศสถานะที่ต้องการ + กลยุทธ์การอัปเดต (สิ่งที่คุณจัดการ)
   └── ReplicaSet  → รับประกันว่ามี Pod ที่เหมือนกัน N ตัว (หนึ่งชุดต่อหนึ่งเวอร์ชันแอป)
          └── Pod  → Pod → Pod ...  (ก็อปปี้ที่รันอยู่จริง)

ทุกเวอร์ชันใหม่ Deployment จะสร้าง ReplicaSet ใหม่และย้าย Pod ข้ามไป
```

## Manifest ของ Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # อย่างมาก 1 Pod ที่ดับได้ระหว่างการอัปเดต
      maxSurge: 1            # อย่างมาก 1 Pod ที่เกินจากจำนวนที่ต้องการ
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: เปลี่ยนเวอร์ชันโดยไม่มี downtime

```bash
kubectl set image deployment/web web=myapp:2.0   # เริ่ม rolling update
kubectl rollout status deployment/web            # เฝ้าดูความคืบหน้า
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (เริ่มต้น: 4 Pod เก่า)
      █████       สร้าง 1 Pod ใหม่ (v2) ขึ้น ตอนนี้รวม 5 (surge)
      ███ █       Pod เก่าลดเหลือ 3, Pod ใหม่ Ready แล้ว
      ...ค่อย ๆ ย้าย...
  v2: ████        (จบ: 4 Pod ใหม่, ReplicaSet เก่า scale เหลือ 0)
ทราฟฟิกไปที่ Pod ที่ผ่าน readiness probe เท่านั้น → ไม่มี downtime
```

## Rollback เมื่อการปล่อยเวอร์ชันมีปัญหา

```bash
kubectl rollout history deployment/web       # แสดงรายการ revision
kubectl rollout undo deployment/web          # ย้อนกลับไป revision ก่อนหน้า
kubectl rollout undo deployment/web --to-revision=3
```

เพราะ ReplicaSet เก่าถูกเก็บไว้ (scale เหลือ 0) การ rollback จึงเร็ว: Kubernetes เพียงแค่ scale ReplicaSet ก่อนหน้ากลับขึ้นและตัวใหม่ลง

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # เปลี่ยนจำนวนที่ต้องการ
```

## ทำไมจึงสำคัญ

Deployment เป็นตัวหลักในการรันแอปพลิเคชัน stateless บน Kubernetes ดังนั้นการเข้าใจมันและความสัมพันธ์กับ ReplicaSet จึงเป็นความรู้ที่จำเป็นและใช้ทุกวัน การแบ่งชั้นคือประเด็นสำคัญ: คุณจัดการ **Deployment** ซึ่งเป็นเจ้าของ **ReplicaSet** (หนึ่งชุดต่อหนึ่งเวอร์ชัน) และแต่ละ ReplicaSet รับประกันว่ามี Pod ที่เหมือนกันจำนวนหนึ่งรันอยู่ — เป็นห่วงโซ่ของ reconciliation loop ที่ร่วมกันมอบ self-healing และจำนวน replica ที่เสถียร พลังที่แท้จริงอยู่ที่วิธีที่ Deployment จัดการกับการเปลี่ยนแปลง: **rolling update** สร้าง ReplicaSet ใหม่และย้าย Pod จากเก่าไปใหม่อย่างค่อยเป็นค่อยไป ควบคุมโดย `maxSurge` และ `maxUnavailable` เพื่อรักษาความสามารถในการรองรับไว้ และ — เมื่อรวมกับ readiness probe ที่กำหนดว่า Pod ไหนได้รับทราฟฟิก — การปล่อยเวอร์ชันจึงเกิดขึ้น **โดยไม่มี downtime** เพราะ ReplicaSet ก่อนหน้าถูกเก็บไว้ (scale เหลือศูนย์แทนที่จะลบ) การ **rollback** จึงเร็วและปลอดภัย: `kubectl rollout undo` เพียงแค่ scale เวอร์ชันเก่ากลับขึ้นและตัวที่มีปัญหาลง ซึ่งคือสิ่งที่คุณคว้ามาใช้เมื่อการปล่อยเวอร์ชันทำงานผิดพลาด การเข้าใจกลไกเหล่านี้ — พร้อมกับวิธี scale (`kubectl scale`) และตรวจสอบความคืบหน้า (`kubectl rollout status/history`) — เป็นรากฐานของการส่งซอฟต์แวร์อย่างปลอดภัยบน Kubernetes และสะท้อนโมเดล declarative ที่ขับเคลื่อนด้วย controller ซึ่งกำหนดวิธีที่แพลตฟอร์มทำงานใน production

ลำดับชั้น

Manifest ของ Deployment

Rolling update: เปลี่ยนเวอร์ชันโดยไม่มี downtime

Rollback เมื่อการปล่อยเวอร์ชันมีปัญหา

Scaling

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง