Hoe werkt de Horizontal Pod Autoscaler, en hoe verhoudt die zich tot de Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

De **Horizontal Pod Autoscaler (HPA)** voegt **Pod-replicas** toe of verwijdert ze op basis van waargenomen metrics (CPU, memory of custom). De **Cluster Autoscaler (CA)** voegt **nodes** toe of verwijdert ze wanneer Pods niet ingepland kunnen worden of nodes onderbenut zijn. Ze werken op verschillende lagen en werken samen.

## Twee autoscalers, twee lagen

```text
HPA  → schaalt PODS  (meer/minder replicas van een Deployment)  — reageert op BELASTING
CA   → schaalt NODES (vergroot/verkleint de machines van het cluster) — reageert op PENDING Pods
VPA  → (bonus) past requests/limits van een Pod aan             — reageert op right-sizing

Typische flow: belasting stijgt → HPA voegt Pods toe → Pods passen niet → CA voegt een node toe →
               Pods worden ingepland. Belasting daalt → HPA verwijdert Pods → node idle → CA verwijdert hem.
```

## Hoe de HPA-control-loop werkt

```text
Elke ~15s doet de HPA-controller:
  1. leest de huidige metric (bijv. gem. CPU over Pods) van metrics-server / custom API
  2. berekent:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. schaalt de Deployment daarnaartoe (begrensd door minReplicas/maxReplicas)
Voorbeeld: 4 Pods op 80% CPU, target 50% → 4 * 80/50 = 6.4 → 7 replicas.
Stabilization windows dempen flapping (vooral bij scale-down).
```

## Een 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      # houd gem. CPU ~60% van de REQUEST
  behavior:                           # optioneel: stem scale up/down-snelheid af
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # huidige/target-metric, aantal replicas
kubectl top pods                      # vereist metrics-server
```

## Belangrijke dependencies & kanttekeningen

```text
• HPA op CPU/memory VEREIST dat metrics-server geïnstalleerd is; utilization is relatief aan REQUESTS
  → als requests ongezet/verkeerd zijn, is de HPA-rekenkunde zinloos. Zet requests correct.
• Custom/externe metrics (RPS, queue depth) hebben een adapter nodig (Prometheus Adapter, KEDA).
• HPA en handmatige `replicas` conflicteren — laat de HPA het replica-aantal bezitten.
• Cluster Autoscaler heeft ook correcte requests nodig: hij kijkt naar de REQUESTS van Pending Pods om
  node-scaling te bepalen. Node scale-up duurt minuten (provisioning), dus houd headroom aan.
```

## Waarom het belangrijk is

Autoscaling is wat Kubernetes in staat stelt capaciteit automatisch af te stemmen op de vraag, en de twee lagen begrijpen is kennis op senior-niveau die kostenefficiënte, veerkrachtige clusters onderscheidt van over- of ondergeprovisioneerde. Het kernmodel is dat **HPA Pods schaalt** als reactie op belasting (het replica-aantal aanpassen op basis van waargenomen CPU, memory of custom metrics) terwijl de **Cluster Autoscaler nodes schaalt** als reactie op scheduling-druk (machines toevoegen wanneer Pods Pending zijn, ze verwijderen wanneer nodes idle zijn) — ze werken op verschillende lagen en werken samen: HPA kan alleen Pods toevoegen als er ruimte is, en de CA levert die ruimte. De control-loop van de HPA begrijpen — de formule `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, de periodieke reconciliation, en de stabilization windows die flapping voorkomen — laat je hem configureren en debuggen in plaats van als magie te behandelen. De kanttekeningen zijn waar senior-oordeel zich toont: HPA op CPU/memory **vereist metrics-server** en berekent utilization **relatief aan requests**, dus verkeerde of ontbrekende requests maken de rekenkunde zinloos; custom metrics (requests-per-seconde, queue depth) hebben een adapter als Prometheus Adapter of KEDA nodig; en node scale-up duurt minuten, dus headroom is belangrijk. Omdat het juist dimensioneren van capaciteit direct de betrouwbaarheid bij verkeerspieken en de cloudkosten in rustige periodes beïnvloedt, en omdat beide autoscalers afhangen van correct ingestelde resource requests, is het beheersen van HPA en de Cluster Autoscaler fundamenteel om productie-Kubernetes efficiënt en betrouwbaar te bedienen.

Twee autoscalers, twee lagen

Hoe de HPA-control-loop werkt

Een HPA-manifest

Belangrijke dependencies & kanttekeningen

Waarom het belangrijk is

Gerelateerde vragen