Hogyan működik a Horizontal Pod Autoscaler, és hogyan viszonyul a Cluster Autoscalerhez?

Question

IT Interview Practice · Accepted Answer

A **Horizontal Pod Autoscaler (HPA)** **Pod-replikákat** ad hozzá vagy vesz el megfigyelt metrikák (CPU, memória vagy egyedi) alapján. A **Cluster Autoscaler (CA)** **node-okat** ad hozzá vagy vesz el, amikor a Podok nem ütemezhetők, vagy a node-ok kihasználatlanok. Különböző rétegekben működnek, és együtt dolgoznak.

## Két autoscaler, két réteg

```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.
```

## Hogyan működik a HPA control loopja

```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).
```

## Egy HPA manifest

```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      # az átlag CPU-t a REQUEST ~60%-án tartani
  behavior:                           # opcionális: a fel-/leskálázás sebességének hangolása
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # aktuális/cél metrika, replikaszám
kubectl top pods                      # metrics-server szükséges hozzá
```

## Fontos függőségek és figyelmeztetések

```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.
```

## Miért fontos

Az autoscaling az, ami lehetővé teszi, hogy a Kubernetes automatikusan a kereslethez igazítsa a kapacitást, és a két réteg megértése senior szintű tudás, amely megkülönbözteti a költséghatékony, ellenálló clustereket a túl- vagy alulméretezettektől. A kulcs gondolati modell, hogy a **HPA Podokat skáláz** a terhelésre reagálva (a replikaszámot igazítja megfigyelt CPU, memória vagy egyedi metrikák alapján), míg a **Cluster Autoscaler node-okat skáláz** az ütemezési nyomásra reagálva (gépeket ad hozzá, amikor Podok Pending állapotban vannak, és eltávolítja őket, amikor a node-ok üresek) — különböző rétegekben működnek és együttműködnek: a HPA csak akkor tud Podokat hozzáadni, ha van hely, a CA pedig ezt a helyet biztosítja. A HPA control loopjának megértése — a `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` képlet, a periodikus reconciliation és a flapping-et megelőző stabilizációs ablakok — lehetővé teszi a konfigurálását és hibakeresését ahelyett, hogy varázslatként kezelnéd. A figyelmeztetéseknél mutatkozik meg a senior ítélőképesség: a HPA CPU/memórián **metrics-servert igényel**, és a kihasználtságot a **requestekhez viszonyítva** számolja, így a hibás vagy hiányzó requestek értelmetlenné teszik a matematikáját; az egyedi metrikák (kérés/másodperc, sorhossz) egy adaptert igényelnek, mint a Prometheus Adapter vagy a KEDA; a node felskálázása pedig percekbe telik, így a tartalék (headroom) számít. Mivel a kapacitás helyes méretezése közvetlenül befolyásolja a megbízhatóságot forgalomcsúcsok idején és a cloud-költséget csendes időszakokban, és mivel mindkét autoscaler a helyesen beállított erőforrás-requestektől függ, a HPA és a Cluster Autoscaler elsajátítása alapvető a production Kubernetes hatékony és megbízható üzemeltetéséhez.

Két autoscaler, két réteg

Hogyan működik a HPA control loopja

Egy HPA manifest

Fontos függőségek és figyelmeztetések

Miért fontos

Kapcsolódó kérdések