Bagaimana Horizontal Pod Autoscaler berfungsi, dan bagaimana ia berkait dengan Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** menambah atau membuang **replika Pod** berdasarkan metrik yang diperhati (CPU, memory, atau tersuai). **Cluster Autoscaler (CA)** menambah atau membuang **node** apabila Pod tidak boleh dijadualkan atau node kurang digunakan. Mereka beroperasi pada lapisan berbeza dan bekerjasama.

## Dua autoscaler, dua lapisan

```text
HPA  → menskala POD  (lebih/kurang replika sebuah Deployment)   — bertindak balas kepada BEBAN
CA   → menskala NODE (membesar/mengecilkan mesin cluster)       — bertindak balas kepada Pod PENDING
VPA  → (bonus) melaraskan requests/limits sebuah Pod            — bertindak balas untuk saiz-tepat

Aliran tipikal: beban naik → HPA tambah Pod → Pod tak muat → CA tambah node →
                Pod dijadualkan. Beban turun → HPA buang Pod → node melahu → CA buangkannya.
```

## Bagaimana gelung kawalan HPA berfungsi

```text
Setiap ~15s controller HPA:
  1. baca metrik semasa (cth. purata CPU merentas Pod) dari metrics-server / API tersuai
  2. mengira:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. menskala Deployment ke arahnya (dibatasi oleh minReplicas/maxReplicas)
Contoh: 4 Pod pada 80% CPU, sasaran 50% → 4 * 80/50 = 6.4 → 7 replika.
Tetingkap penstabilan (stabilization window) meredam kegoyahan (terutama pada scale-down).
```

## Sebuah 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      # kekalkan purata CPU ~60% daripada REQUEST
  behavior:                           # pilihan: tala kelajuan scale naik/turun
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # metrik semasa/sasaran, bilangan replika
kubectl top pods                      # memerlukan metrics-server
```

## Kebergantungan & amaran penting

```text
• HPA pada CPU/memory MEMERLUKAN metrics-server dipasang; utilization adalah relatif kepada REQUESTS
  → jika requests tidak ditetapkan/salah, matematik HPA tidak bermakna. Set requests dengan betul.
• Metrik tersuai/luaran (RPS, kedalaman baris gilir) perlukan adapter (Prometheus Adapter, KEDA).
• HPA dan `replicas` manual bercanggah — biarkan HPA memiliki bilangan replika.
• Cluster Autoscaler juga perlukan requests yang betul: ia melihat REQUESTS Pod Pending untuk
  memutuskan penskalaan node. Scale-up node ambil masa berminit (peruntukan), jadi kekalkan headroom.
```

## Mengapa ia penting

Autoscaling ialah apa yang membolehkan Kubernetes memadankan kapasiti dengan permintaan secara automatik, dan memahami kedua-dua lapisan ialah pengetahuan peringkat senior yang membezakan cluster yang cekap kos dan berdaya tahan daripada yang terlebih atau terkurang peruntukan. Model pemikiran utama ialah **HPA menskala Pod** sebagai tindak balas kepada beban (melaraskan bilangan replika daripada CPU, memory, atau metrik tersuai yang diperhati) manakala **Cluster Autoscaler menskala node** sebagai tindak balas kepada tekanan penjadualan (menambah mesin apabila Pod Pending, membuangnya apabila node melahu) — mereka beroperasi pada lapisan berbeza dan bekerjasama: HPA hanya boleh menambah Pod jika ada ruang, dan CA menyediakan ruang itu. Memahami gelung kawalan HPA — formula `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, penyelarasan berkala, dan tetingkap penstabilan yang menghalang kegoyahan — membolehkan anda mengkonfigurasi dan menyahpepijatnya dan bukan menganggapnya sihir. Amaran ialah tempat pertimbangan senior menonjol: HPA pada CPU/memory **memerlukan metrics-server** dan mengira utilization **relatif kepada requests**, jadi requests yang salah atau tiada menjadikan matematiknya tidak bermakna; metrik tersuai (request per saat, kedalaman baris gilir) perlukan adapter seperti Prometheus Adapter atau KEDA; dan scale-up node ambil masa berminit, jadi headroom penting. Kerana saiz-tepat kapasiti secara langsung mempengaruhi kebolehpercayaan semasa lonjakan trafik dan perbelanjaan cloud semasa tempoh sunyi, dan kerana kedua-dua autoscaler bergantung pada resource requests yang ditetapkan dengan betul, menguasai HPA dan Cluster Autoscaler adalah asas untuk mengendalikan Kubernetes production dengan cekap dan boleh dipercayai.

Dua autoscaler, dua lapisan

Bagaimana gelung kawalan HPA berfungsi

Sebuah manifest HPA

Kebergantungan & amaran penting

Mengapa ia penting

Soalan berkaitan