Wie funktioniert der Horizontal Pod Autoscaler, und wie verhält er sich zum Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

Der **Horizontal Pod Autoscaler (HPA)** fügt **Pod-Replicas** hinzu oder entfernt sie, basierend auf beobachteten Metriken (CPU, Memory oder custom). Der **Cluster Autoscaler (CA)** fügt **Nodes** hinzu oder entfernt sie, wenn Pods nicht eingeplant werden können oder Nodes ungenutzt sind. Sie arbeiten auf verschiedenen Ebenen und wirken zusammen.

## Zwei Autoscaler, zwei Ebenen

```text
HPA  → skaliert PODS  (mehr/weniger Replicas eines Deployments)   — reagiert auf LAST
CA   → skaliert NODES (vergrößert/verkleinert die Maschinen des Clusters) — reagiert auf PENDING Pods
VPA  → (bonus) passt requests/limits eines Pods an                — reagiert auf right-sizing

Typischer Ablauf: Last steigt → HPA fügt Pods hinzu → Pods passen nicht → CA fügt einen Node hinzu →
              Pods werden eingeplant. Last sinkt → HPA entfernt Pods → Node idle → CA entfernt ihn.
```

## Wie der HPA-control-loop funktioniert

```text
Alle ~15s macht der HPA-Controller:
  1. liest die aktuelle Metrik (z. B. avg CPU über die Pods) vom metrics-server / custom API
  2. berechnet:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. skaliert das Deployment darauf zu (begrenzt durch minReplicas/maxReplicas)
Beispiel: 4 Pods bei 80% CPU, target 50% → 4 * 80/50 = 6,4 → 7 Replicas.
Stabilization windows dämpfen Flattern (besonders beim scale-down).
```

## Ein 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      # avg CPU bei ~60% des REQUEST halten
  behavior:                           # optional: scale up/down-Geschwindigkeit tunen
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # aktuelle/target Metrik, Replica-Anzahl
kubectl top pods                      # benötigt metrics-server
```

## Wichtige Abhängigkeiten & Vorbehalte

```text
• HPA auf CPU/memory BENÖTIGT einen installierten metrics-server; utilization ist relativ zu REQUESTS
  → wenn requests fehlen/falsch sind, ist die HPA-Rechnung bedeutungslos. Setze requests korrekt.
• Custom/external metrics (RPS, queue depth) brauchen einen Adapter (Prometheus Adapter, KEDA).
• HPA und manuelles `replicas` kollidieren — lass den HPA die Replica-Anzahl besitzen.
• Der Cluster Autoscaler braucht ebenfalls korrekte requests: er schaut auf die REQUESTS von Pending-Pods,
  um die Node-Skalierung zu entscheiden. Node-scale-up dauert Minuten (Provisioning), also Headroom lassen.
```

## Warum es wichtig ist

Autoscaling ist das, was Kubernetes erlaubt, die Kapazität automatisch an die Nachfrage anzupassen, und das Verständnis der beiden Ebenen ist Senior-Level-Wissen, das kosteneffiziente, resiliente Cluster von über- oder unterprovisionierten unterscheidet. Das zentrale mentale Modell ist, dass der **HPA Pods skaliert** als Reaktion auf Last (er passt die Replica-Anzahl anhand beobachteter CPU, Memory oder custom metrics an), während der **Cluster Autoscaler Nodes skaliert** als Reaktion auf Scheduling-Druck (er fügt Maschinen hinzu, wenn Pods Pending sind, und entfernt sie, wenn Nodes idle sind) — sie arbeiten auf verschiedenen Ebenen und kooperieren: Der HPA kann nur Pods hinzufügen, wenn Platz ist, und der CA schafft diesen Platz. Den control loop des HPA zu verstehen — die Formel `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, die periodische reconciliation und stabilization windows, die Flattern verhindern — lässt dich ihn konfigurieren und debuggen, statt ihn als Magie zu behandeln. Bei den Vorbehalten zeigt sich Senior-Urteilsvermögen: HPA auf CPU/memory **benötigt metrics-server** und berechnet utilization **relativ zu requests**, sodass falsche oder fehlende requests seine Rechnung bedeutungslos machen; custom metrics (Requests-per-Second, queue depth) brauchen einen Adapter wie Prometheus Adapter oder KEDA; und Node-scale-up dauert Minuten, weshalb Headroom wichtig ist. Weil das richtige Dimensionieren der Kapazität die Zuverlässigkeit unter Traffic-Spikes und die Cloud-Kosten in ruhigen Zeiten direkt beeinflusst und weil beide Autoscaler von korrekt gesetzten resource requests abhängen, ist die Beherrschung von HPA und Cluster Autoscaler grundlegend für den effizienten und zuverlässigen Betrieb von Produktions-Kubernetes.

Zwei Autoscaler, zwei Ebenen

Wie der HPA-control-loop funktioniert

Ein HPA-Manifest

Wichtige Abhängigkeiten & Vorbehalte

Warum es wichtig ist

Ähnliche Fragen