Horizontal Pod Autoscaler ทำงานอย่างไร และมันสัมพันธ์กับ Cluster Autoscaler อย่างไร?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** เพิ่มหรือลด **replica ของ Pod** ตาม metric ที่สังเกตได้ (CPU, memory หรือแบบกำหนดเอง) **Cluster Autoscaler (CA)** เพิ่มหรือลด **node** เมื่อ Pod ไม่สามารถถูกจัดตารางได้หรือ node ถูกใช้ไม่เต็ม ทั้งสองทำงานที่ชั้นต่างกันและทำงานร่วมกัน

## สอง autoscaler สองชั้น

```text
HPA  → scale POD   (เพิ่ม/ลด replica ของ Deployment)          — ตอบสนองต่อ LOAD
CA   → scale NODE  (ขยาย/หด จำนวนเครื่องของ cluster)          — ตอบสนองต่อ Pod ที่ PENDING
VPA  → (เพิ่มเติม) ปรับ requests/limits ของ Pod               — ตอบสนองเพื่อกำหนดขนาดให้พอดี

ลำดับทั่วไป: load เพิ่ม → HPA เพิ่ม Pod → Pod ไม่พอดี → CA เพิ่ม node →
              Pod จัดตารางได้ load ลด → HPA ลด Pod → node ว่าง → CA ถอดมันออก
```

## control loop ของ HPA ทำงานอย่างไร

```text
ทุก ~15s controller ของ HPA:
  1. อ่าน metric ปัจจุบัน (เช่น CPU เฉลี่ยข้าม Pod) จาก metrics-server / custom API
  2. คำนวณ:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. scale Deployment ไปสู่ค่านั้น (จำกัดด้วย minReplicas/maxReplicas)
ตัวอย่าง: 4 Pod ที่ 80% CPU, เป้าหมาย 50% → 4 * 80/50 = 6.4 → 7 replica
stabilization window ช่วยลดการกระพริบ (โดยเฉพาะตอน scale-down)
```

## Manifest ของ HPA

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60      # รักษา CPU เฉลี่ย ~60% ของ REQUEST
  behavior:                           # ระบุหรือไม่ก็ได้: ปรับความเร็ว scale ขึ้น/ลง
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # metric ปัจจุบัน/เป้าหมาย, จำนวน replica
kubectl top pods                      # ต้องมี metrics-server
```

## dependency & ข้อควรระวังสำคัญ

```text
• HPA ตาม CPU/memory ต้องติดตั้ง metrics-server; utilization คิดเทียบกับ REQUESTS
  → ถ้า requests ไม่ตั้ง/ผิด การคำนวณของ HPA ไร้ความหมาย ตั้ง requests ให้ถูก
• metric แบบกำหนดเอง/ภายนอก (RPS, ความลึกของ queue) ต้องมี adapter (Prometheus Adapter, KEDA)
• HPA และ `replicas` ด้วยมือขัดกัน — ให้ HPA เป็นเจ้าของจำนวน replica
• Cluster Autoscaler ก็ต้องการ requests ที่ถูก: มันดู REQUESTS ของ Pod ที่ Pending เพื่อ
  ตัดสินการ scale node การ scale-up node ใช้เวลาหลายนาที (จัดหา) ดังนั้นเก็บ headroom ไว้
```

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

Autoscaling คือสิ่งที่ทำให้ Kubernetes จับคู่กำลังการรองรับกับความต้องการโดยอัตโนมัติ และการเข้าใจสองชั้นเป็นความรู้ระดับ senior ที่แยกแยะ cluster ที่คุ้มค่าและยืดหยุ่นออกจากที่จัดหาเกินหรือขาด โมเดลทางความคิดหลักคือ **HPA scale Pod** เพื่อตอบสนองต่อ load (ปรับจำนวน replica จาก CPU, memory หรือ metric แบบกำหนดเองที่สังเกตได้) ขณะที่ **Cluster Autoscaler scale node** เพื่อตอบสนองต่อแรงกดดันการจัดตาราง (เพิ่มเครื่องเมื่อ Pod Pending, ถอดออกเมื่อ node ว่าง) — ทั้งสองทำงานที่ชั้นต่างกันและร่วมมือกัน: HPA เพิ่ม Pod ได้ก็ต่อเมื่อมีที่ว่าง และ CA คือผู้จัดหาที่ว่างนั้น การเข้าใจ control loop ของ HPA — สูตร `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, การ reconcile เป็นระยะ และ stabilization window ที่ป้องกันการกระพริบ — ทำให้คุณตั้งค่าและ debug มันได้แทนที่จะมองว่าเป็นเวทมนตร์ ข้อควรระวังคือที่ที่ดุลยพินิจระดับ senior แสดงตัว: HPA ตาม CPU/memory **ต้องมี metrics-server** และคำนวณ utilization **เทียบกับ requests** ดังนั้น requests ที่ผิดหรือขาดทำให้การคำนวณของมันไร้ความหมาย; metric แบบกำหนดเอง (request ต่อวินาที, ความลึกของ queue) ต้องมี adapter อย่าง Prometheus Adapter หรือ KEDA; และการ scale-up node ใช้เวลาหลายนาที ดังนั้น headroom จึงสำคัญ เพราะการกำหนดขนาดกำลังการรองรับให้พอดีส่งผลโดยตรงต่อความน่าเชื่อถือเมื่อทราฟฟิกพุ่งและค่าใช้จ่าย cloud ในช่วงเงียบ และเพราะ autoscaler ทั้งสองพึ่งพา resource requests ที่ตั้งถูกต้อง การเชี่ยวชาญ HPA และ Cluster Autoscaler จึงเป็นรากฐานของการดำเนินการ Kubernetes production อย่างมีประสิทธิภาพและน่าเชื่อถือ

สอง autoscaler สองชั้น

control loop ของ HPA ทำงานอย่างไร

Manifest ของ HPA

dependency & ข้อควรระวังสำคัญ

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

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