Hur fungerar Horizontal Pod Autoscaler, och hur förhåller den sig till Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** lägger till eller tar bort **Pod-replicas** baserat på observerade metrics (CPU, minne eller custom). **Cluster Autoscaler (CA)** lägger till eller tar bort **noder** när Pods inte kan schemaläggas eller noder underutnyttjas. De opererar på olika skikt och samarbetar.

## Två autoscalers, två skikt

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

## Hur HPA:s control loop fungerar

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

## Ett 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      # håll snitt-CPU ~60% av REQUEST
  behavior:                           # valfritt: justera hastighet för upp/nedskalning
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # aktuell/mål-metric, antal replicas
kubectl top pods                      # kräver metrics-server
```

## Viktiga beroenden & förbehåll

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

## Varför det är viktigt

Autoscaling är det som låter Kubernetes automatiskt matcha kapacitet mot efterfrågan, och att förstå de två skikten är kunskap på senior-nivå som skiljer kostnadseffektiva, motståndskraftiga kluster från över- eller underdimensionerade. Den centrala mentala modellen är att **HPA skalar Pods** som svar på belastning (justerar antalet replicas utifrån observerad CPU, minne eller custom metrics) medan **Cluster Autoscaler skalar noder** som svar på schemaläggningstryck (lägger till maskiner när Pods är Pending, tar bort dem när noder är lediga) — de opererar på olika skikt och samverkar: HPA kan bara lägga till Pods om det finns plats, och CA tillhandahåller den platsen. Att förstå HPA:s control loop — formeln `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, den periodiska reconciliation:en, och stabiliseringsfönstren som förhindrar fladder — låter dig konfigurera och felsöka den snarare än att behandla den som magi. Förbehållen är där seniort omdöme visar sig: HPA på CPU/minne **kräver metrics-server** och beräknar utnyttjande **relativt requests**, så felaktiga eller saknade requests gör dess matematik meningslös; custom metrics (requests-per-sekund, ködjup) behöver en adapter som Prometheus Adapter eller KEDA; och nod-uppskalning tar minuter, så marginal spelar roll. Eftersom rätt dimensionerad kapacitet direkt påverkar tillförlitlighet under trafiktoppar och molnkostnad under lugna perioder, och eftersom båda autoscalers är beroende av korrekt satta resurs-requests, är det grundläggande att behärska HPA och Cluster Autoscaler för att driva produktions-Kubernetes effektivt och tillförlitligt.

Två autoscalers, två skikt

Hur HPA:s control loop fungerar

Ett HPA-manifest

Viktiga beroenden & förbehåll

Varför det är viktigt

Relaterade frågor