Come funziona l'Horizontal Pod Autoscaler, e che relazione ha con il Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

L'**Horizontal Pod Autoscaler (HPA)** aggiunge o rimuove **replica di Pod** in base alle metriche osservate (CPU, memoria o custom). Il **Cluster Autoscaler (CA)** aggiunge o rimuove **node** quando i Pod non possono essere schedulati o i node sono sottoutilizzati. Operano a livelli diversi e lavorano insieme.

## Due autoscaler, due livelli

```text
HPA  → scales PODS  (more/fewer replicas of a Deployment)     — reacts to LOAD
CA   → scales NODES (grows/shrinks the cluster's machines)     — reacts to PENDING Pods
VPA  → (bonus) adjusts a Pod's requests/limits                 — reacts to right-sizing

Typical flow: load rises → HPA adds Pods → Pods can't fit → CA adds a node →
              Pods schedule. Load drops → HPA removes Pods → node idle → CA removes it.
```

## Come funziona il control loop dell'HPA

```text
Every ~15s the HPA controller:
  1. reads current metric (e.g. avg CPU across Pods) from metrics-server / custom API
  2. computes:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. scales the Deployment toward that (bounded by minReplicas/maxReplicas)
Example: 4 Pods at 80% CPU, target 50% → 4 * 80/50 = 6.4 → 7 replicas.
Stabilization windows dampen flapping (esp. on scale-down).
```

## Un manifest di 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      # keep avg CPU ~60% of the REQUEST
  behavior:                           # optional: tune scale up/down speed
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # current/target metric, replica count
kubectl top pods                      # requires metrics-server
```

## Dipendenze e avvertenze importanti

```text
• HPA on CPU/memory REQUIRES metrics-server installed; utilization is relative to REQUESTS
  → if requests are unset/wrong, HPA math is meaningless. Set requests correctly.
• Custom/external metrics (RPS, queue depth) need an adapter (Prometheus Adapter, KEDA).
• HPA and manual `replicas` conflict — let the HPA own the replica count.
• Cluster Autoscaler needs correct requests too: it looks at Pending Pods' REQUESTS to
  decide node scaling. Node scale-up takes minutes (provisioning), so keep headroom.
```

## Perché è importante

L'autoscaling è ciò che permette a Kubernetes di far corrispondere automaticamente la capacità alla domanda, e capire i due livelli è una conoscenza di livello senior che distingue i cluster efficienti nei costi e resilienti da quelli sovra- o sotto-provisionati. Il modello mentale chiave è che l'**HPA scala i Pod** in risposta al carico (regolando il conteggio delle replica in base a CPU, memoria o metriche custom osservate) mentre il **Cluster Autoscaler scala i node** in risposta alla pressione di scheduling (aggiungendo macchine quando i Pod sono in Pending, rimuovendole quando i node sono inattivi) — operano a livelli diversi e cooperano: l'HPA può aggiungere Pod solo se c'è spazio, e il CA fornisce quello spazio. Capire il control loop dell'HPA — la formula `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, la reconciliation periodica e le finestre di stabilizzazione che prevengono il flapping — ti permette di configurarlo e farne il debug anziché trattarlo come magia. Le avvertenze sono dove si vede il giudizio senior: l'HPA su CPU/memoria **richiede metrics-server** e calcola l'utilizzo **relativamente alle request**, quindi request errate o mancanti rendono i suoi calcoli privi di senso; le metriche custom (richieste al secondo, profondità di coda) richiedono un adapter come Prometheus Adapter o KEDA; e lo scale-up dei node richiede minuti, quindi il margine (headroom) conta. Poiché dimensionare correttamente la capacità incide direttamente sull'affidabilità durante i picchi di traffico e sulla spesa cloud nei periodi tranquilli, e poiché entrambi gli autoscaler dipendono da request delle risorse impostate correttamente, padroneggiare l'HPA e il Cluster Autoscaler è fondamentale per operare Kubernetes in produzione in modo efficiente e affidabile.

Due autoscaler, due livelli

Come funziona il control loop dell'HPA

Un manifest di HPA

Dipendenze e avvertenze importanti

Perché è importante

Domande correlate