Kako radi Horizontal Pod Autoscaler i kako se odnosi prema Cluster Autoscaleru?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** dodaje ili uklanja **Pod replike** na temelju promatranih metrika (CPU, memorija ili prilagođene). **Cluster Autoscaler (CA)** dodaje ili uklanja **nodeove** kad se Podovi ne mogu rasporediti ili su nodeovi nedovoljno iskorišteni. Rade na različitim slojevima i surađuju.

## Dva autoscalera, dva sloja

```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 radi HPA kontrolna petlja

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

```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      # drži prosječni CPU ~60% REQUESTA
  behavior:                           # opcionalno: podesi brzinu skaliranja gore/dolje
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # trenutna/ciljna metrika, broj replika
kubectl top pods                      # zahtijeva metrics-server
```

## Važne ovisnosti i napomene

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

## Zašto je to važno

Autoscaling je ono što omogućuje Kubernetesu da automatski uskladi kapacitet s potražnjom, a razumijevanje dvaju slojeva znanje je senior razine koje razlikuje troškovno učinkovite, otporne klastere od onih pre- ili poddimenzioniranih. Ključni mentalni model je da **HPA skalira Podove** kao odgovor na opterećenje (podešavajući broj replika iz promatranog CPU-a, memorije ili prilagođenih metrika), dok **Cluster Autoscaler skalira nodeove** kao odgovor na pritisak schedulinga (dodajući strojeve kad su Podovi u Pending stanju, uklanjajući ih kad su nodeovi neaktivni) — rade na različitim slojevima i surađuju: HPA može dodati Podove samo ako ima mjesta, a CA to mjesto osigurava. Razumijevanje HPA-ove kontrolne petlje — formule `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, periodičnog usklađivanja i stabilizacijskih prozora koji sprječavaju treperenje (flapping) — omogućuje vam da ga konfigurirate i otklanjate greške umjesto da ga tretirate kao magiju. Napomene su mjesto gdje se pokazuje senior prosudba: HPA na CPU-u/memoriji **zahtijeva metrics-server** i računa iskorištenost **relativno prema requestovima**, pa neispravni ili nedostajući requestovi čine njegovu matematiku besmislenom; prilagođene metrike (zahtjevi po sekundi, dubina reda) trebaju adapter poput Prometheus Adaptera ili KEDA-e; a skaliranje nodeova gore traje minutama, pa je zaliha kapaciteta važna. Budući da ispravno dimenzioniranje kapaciteta izravno utječe na pouzdanost pri naglim skokovima prometa i cloud troškove u mirnim razdobljima, te budući da oba autoscalera ovise o ispravno postavljenim resource requestovima, ovladavanje HPA-om i Cluster Autoscalerom temeljno je za učinkovit i pouzdan pogon produkcijskog Kubernetesa.

Dva autoscalera, dva sloja

Kako radi HPA kontrolna petlja

Manifest HPA-a

Važne ovisnosti i napomene

Zašto je to važno

Povezana pitanja