Hvordan fungerer Horizontal Pod Autoscaler, og hvordan forholder den seg til Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** legger til eller fjerner **Pod-replicas** basert på observerte metrikker (CPU, minne eller egendefinerte). **Cluster Autoscaler (CA)** legger til eller fjerner **noder** når Pods ikke kan schedules eller noder er underbrukt. De opererer på forskjellige lag og jobber sammen.

## To autoscalere, to lag

```text
HPA  → skalerer PODS  (flere/færre replicas av en Deployment)  — reagerer på LAST
CA   → skalerer NODER (utvider/krymper klyngens maskiner)       — reagerer på PENDING Pods
VPA  → (bonus) justerer en Pods requests/limits                — reagerer på riktig-dimensjonering

Typisk flyt: last stiger → HPA legger til Pods → Pods får ikke plass → CA legger til en node →
              Pods schedules. Last synker → HPA fjerner Pods → node inaktiv → CA fjerner den.
```

## Hvordan HPA-control-loopen fungerer

```text
Hver ~15s gjør HPA-controlleren:
  1. leser gjeldende metrikk (f.eks. gj.snitt CPU over Pods) fra metrics-server / custom API
  2. beregner:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. skalerer Deploymenten mot det (begrenset av minReplicas/maxReplicas)
Eksempel: 4 Pods på 80% CPU, mål 50% → 4 * 80/50 = 6,4 → 7 replicas.
Stabiliseringsvinduer demper flapping (spesielt ved nedskalering).
```

## Et 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      # hold gj.snitt CPU ~60% av REQUEST-en
  behavior:                           # valgfritt: juster opp-/nedskaleringsfart
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # gjeldende/mål-metrikk, antall replicas
kubectl top pods                      # krever metrics-server
```

## Viktige avhengigheter og forbehold

```text
• HPA på CPU/minne KREVER metrics-server installert; utilization er relativt til REQUESTS
  → hvis requests er usatt/feil, er HPA-matematikken meningsløs. Sett requests riktig.
• Custom/eksterne metrikker (RPS, kødybde) trenger en adapter (Prometheus Adapter, KEDA).
• HPA og manuell `replicas` er i konflikt — la HPA eie antall replicas.
• Cluster Autoscaler trenger riktige requests også: den ser på Pending Pods' REQUESTS for
  å avgjøre node-skalering. Node-oppskalering tar minutter (provisjonering), så hold margin.
```

## Hvorfor det er viktig

Autoscaling er det som lar Kubernetes matche kapasitet til etterspørsel automatisk, og å forstå de to lagene er kunnskap på senior-nivå som skiller kostnadseffektive, robuste klynger fra over- eller underprovisjonerte. Nøkkel-modellen er at **HPA skalerer Pods** som respons på last (justerer antall replicas ut fra observert CPU, minne eller egendefinerte metrikker) mens **Cluster Autoscaler skalerer noder** som respons på scheduling-press (legger til maskiner når Pods er Pending, fjerner dem når noder er inaktive) — de opererer på forskjellige lag og samarbeider: HPA kan bare legge til Pods hvis det er plass, og CA skaffer den plassen. Å forstå HPA-ens control loop — formelen `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, den periodiske reconciliation-en, og stabiliseringsvinduene som forhindrer flapping — lar deg konfigurere og feilsøke den i stedet for å behandle den som magi. Forbeholdene er der senior-dømmekraft vises: HPA på CPU/minne **krever metrics-server** og beregner utilization **relativt til requests**, så feil eller manglende requests gjør matematikken meningsløs; egendefinerte metrikker (forespørsler-per-sekund, kødybde) trenger en adapter som Prometheus Adapter eller KEDA; og node-oppskalering tar minutter, så margin betyr noe. Fordi riktig kapasitetsdimensjonering direkte påvirker pålitelighet under trafikktopper og cloud-forbruk i rolige perioder, og fordi begge autoscalere avhenger av korrekt satte resource requests, er det å mestre HPA og Cluster Autoscaler grunnleggende for å drifte produksjons-Kubernetes effektivt og pålitelig.

To autoscalere, to lag

Hvordan HPA-control-loopen fungerer

Et HPA-manifest

Viktige avhengigheter og forbehold

Hvorfor det er viktig

Relaterte spørsmål