Hvordan fungerer Horizontal Pod Autoscaler, og hvordan hænger den sammen med Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** tilføjer eller fjerner **Pod-replicas** baseret på observerede metrikker (CPU, memory eller custom). **Cluster Autoscaler (CA)** tilføjer eller fjerner **nodes**, når Pods ikke kan schedules, eller nodes er underudnyttede. De opererer på forskellige lag og arbejder sammen.

## To autoscalere, to lag

```text
HPA  → skalerer PODS  (flere/færre replicas af en Deployment)  — reagerer på BELASTNING
CA   → skalerer NODES (vokser/skrumper klyngens maskiner)       — reagerer på PENDING Pods
VPA  → (bonus) justerer en Pods requests/limits                 — reagerer på dimensionering

Typisk flow: belastning stiger → HPA tilføjer Pods → Pods kan ikke være der → CA tilføjer en node →
              Pods schedules. Belastning falder → HPA fjerner Pods → node idle → CA fjerner den.
```

## Hvordan HPA-control-loopet fungerer

```text
Ca. hver 15s gør HPA-controlleren:
  1. læser nuværende metrik (fx gns. CPU over Pods) fra metrics-server / custom API
  2. beregner:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. skalerer Deployment'en hen mod det (afgrænset af minReplicas/maxReplicas)
Eksempel: 4 Pods ved 80% CPU, target 50% → 4 * 80/50 = 6,4 → 7 replicas.
Stabiliseringsvinduer dæmper flapping (især ved scale-down).
```

## 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 gns. CPU ~60% af REQUEST'en
  behavior:                           # valgfri: tune scale up/down-hastighed
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # nuværende/target-metrik, replica-antal
kubectl top pods                      # kræver metrics-server
```

## Vigtige afhængigheder & forbehold

```text
• HPA på CPU/memory KRÆVER metrics-server installeret; utilization er relativ til REQUESTS
  → hvis requests er usat/forkert, er HPA-matematikken meningsløs. Sæt requests korrekt.
• Custom/eksterne metrikker (RPS, queue depth) kræver en adapter (Prometheus Adapter, KEDA).
• HPA og manuelt `replicas` er i konflikt — lad HPA'en eje replica-antallet.
• Cluster Autoscaler kræver også korrekte requests: den ser på Pending Pods' REQUESTS for at
  afgøre node-skalering. Node-scale-up tager minutter (provisionering), så hold hovedrum.
```

## Hvorfor det betyder noget

Autoscaling er det, der lader Kubernetes matche kapacitet til efterspørgsel automatisk, og at forstå de to lag er viden på seniorniveau, der adskiller omkostningseffektive, robuste klynger fra over- eller underprovisionerede. Den centrale mentale model er, at **HPA skalerer Pods** som reaktion på belastning (justerer replica-antal ud fra observeret CPU, memory eller custom-metrikker), mens **Cluster Autoscaler skalerer nodes** som reaktion på scheduling-pres (tilføjer maskiner, når Pods er Pending, fjerner dem, når nodes er idle) — de opererer på forskellige lag og samarbejder: HPA kan kun tilføje Pods, hvis der er plads, og CA leverer den plads. At forstå HPA'ens control loop — formlen `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, den periodiske reconciliation og stabiliseringsvinduer, der forhindrer flapping — lader dig konfigurere og fejlfinde den frem for at behandle den som magi. Forbeholdene er, hvor senior-dømmekraft viser sig: HPA på CPU/memory **kræver metrics-server** og beregner utilization **relativt til requests**, så forkerte eller manglende requests gør dens matematik meningsløs; custom-metrikker (requests-per-sekund, queue depth) kræver en adapter som Prometheus Adapter eller KEDA; og node-scale-up tager minutter, så hovedrum betyder noget. Fordi korrekt dimensionering af kapacitet direkte påvirker pålidelighed under trafikspidser og cloud-forbrug i stille perioder, og fordi begge autoscalere afhænger af korrekt satte resource requests, er det at mestre HPA og Cluster Autoscaler fundamentalt for at drive production-Kubernetes effektivt og pålideligt.

To autoscalere, to lag

Hvordan HPA-control-loopet fungerer

Et HPA-manifest

Vigtige afhængigheder & forbehold

Hvorfor det betyder noget

Relaterede spørgsmål