Kako deluje Horizontal Pod Autoscaler in kako je povezan s Cluster Autoscalerjem?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** dodaja ali odstranjuje **replike Podov** glede na opazovane metrike (CPU, pomnilnik ali po meri). **Cluster Autoscaler (CA)** dodaja ali odstranjuje **node**, kadar Podov ni mogoče razporediti ali so nodi premalo izkoriščeni. Delujeta na različnih plasteh in sodelujeta.

## Dva autoscalerja, dve plasti

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

## Kako deluje krmilna zanka 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).
```

## 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      # ohranjaj povprečni CPU ~60 % REQUESTA
  behavior:                           # neobvezno: uravnaj hitrost scale up/down
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # trenutna/ciljna metrika, število replik
kubectl top pods                      # zahteva metrics-server
```

## Pomembne odvisnosti in opozorila

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

## Zakaj je to pomembno

Samodejno skaliranje je tisto, kar Kubernetesu omogoča samodejno uskladiti zmogljivost s povpraševanjem, razumevanje obeh plasti pa je znanje senior ravni, ki loči stroškovno učinkovite in odporne gruče od prekomerno ali premalo opremljenih. Ključni miselni model je, da **HPA skalira Pode** kot odziv na obremenitev (prilagaja število replik na podlagi opazovanega CPU, pomnilnika ali metrik po meri), medtem ko **Cluster Autoscaler skalira node** kot odziv na razporejevalni pritisk (doda stroje, ko so Podi v Pending, in jih odstrani, ko so nodi nedejavni) — delujeta na različnih plasteh in sodelujeta: HPA lahko doda Pode le, če je prostor, CA pa ta prostor zagotovi. Razumevanje krmilne zanke HPA — formule `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, periodičnega usklajevanja in stabilizacijskih oken, ki preprečujejo nihanje — vam omogoča, da jo nastavite in odpravljate napake, namesto da bi jo obravnavali kot čarovnijo. Opozorila so tam, kjer se pokaže senior presoja: HPA na CPU/pomnilniku **zahteva metrics-server** in izkoriščenost izračuna **relativno na requests**, zato so ob napačnih ali manjkajočih requests njegovi izračuni brez pomena; metrike po meri (zahtevki na sekundo, globina čakalne vrste) potrebujejo adapter, kot je Prometheus Adapter ali KEDA; povečanje števila nodov pa traja minute, zato je rezerva (headroom) pomembna. Ker pravilno določanje velikosti zmogljivosti neposredno vpliva na zanesljivost ob konicah prometa in porabo v oblaku v mirnih obdobjih in ker sta oba autoscalerja odvisna od pravilno nastavljenih resource requests, je obvladovanje HPA in Cluster Autoscalerja temeljno za učinkovito in zanesljivo upravljanje produkcijskega Kubernetesa.

Dva autoscalerja, dve plasti

Kako deluje krmilna zanka HPA

Manifest HPA

Pomembne odvisnosti in opozorila

Zakaj je to pomembno

Povezana vprašanja