Kubernetes Autoscaling: HPA, VPA und Cluster Autoscaler richtig kombinieren

TL;DR

• Kubernetes bietet drei Autoscaling-Mechanismen: HPA (mehr/weniger Pods), VPA (groessere/kleinere Pods), Cluster Autoscaler (mehr/weniger Nodes).
• HPA und VPA duerfen nicht gleichzeitig auf die gleiche Metrik (CPU/Memory) skalieren -- das fuehrt zu Konflikten.
• Starten Sie immer mit korrekten Resource Requests. Ohne sinnvolle Requests kann kein Autoscaler vernuenftig arbeiten.
• Karpenter ist eine performantere Alternative zum klassischen Cluster Autoscaler, besonders auf AWS.
• Typische Einsparungen durch Autoscaling: 25-40% gegenueber statisch provisionierten Clustern.

Die drei Autoscaler im Ueberblick

Kubernetes hat kein einzelnes "Autoscaling" -- es gibt drei unabhaengige Mechanismen, die auf unterschiedlichen Ebenen arbeiten. Das Zusammenspiel ist entscheidend.

Horizontal Pod Autoscaler (HPA): Mehr Pods bei mehr Last

Der HPA ist der meistgenutzte Autoscaler. Er beobachtet Metriken (standardmaessig CPU-Auslastung) und passt die Anzahl der Replicas an.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60

Wichtige Details zur Konfiguration:

• minReplicas: 2 -- nie auf 1 setzen in Production. Wenn der eine Pod waehrend eines Rollouts weg ist, haben Sie null Kapazitaet.
• behavior.scaleDown -- das Stabilization Window verhindert, dass der HPA bei kurzen Last-Spitzen sofort wieder herunterskaliert. 5 Minuten sind ein guter Startwert.
• behavior.scaleUp -- hier sollte das Window kurz sein (30s), damit der Cluster schnell auf Lastspitzen reagiert.

Pruefen Sie den aktuellen Status:

# HPA-Status anzeigen
kubectl get hpa web-api-hpa -n production

# Detaillierte Informationen
kubectl describe hpa web-api-hpa -n production

# Metriken pruefen (Metrics Server muss installiert sein)
kubectl top pods -n production -l app=web-api

HPA mit Custom Metrics

CPU und Memory reichen nicht immer. Fuer eine Queue-basierte Architektur wollen Sie vielleicht nach Queue-Laenge skalieren:

metrics:
  - type: Object
    object:
      metric:
        name: rabbitmq_queue_messages
      describedObject:
        apiVersion: v1
        kind: Service
        name: rabbitmq
      target:
        type: Value
        value: "100"

Dafuer brauchen Sie einen Custom Metrics Adapter (z.B. Prometheus Adapter oder KEDA).

Vertical Pod Autoscaler (VPA): Richtige Groesse fuer Pods

Der VPA analysiert den tatsaechlichen Ressourcenverbrauch und passt die Requests und Limits an. Das ist besonders nuetzlich in zwei Szenarien:

1. Sie wissen bei einem neuen Service nicht, wie viele Ressourcen er braucht.
2. Der Ressourcenbedarf aendert sich ueber die Zeit (z.B. durch wachsende Datenmengen).

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: backend-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
      - containerName: backend
        minAllowed:
          cpu: "100m"
          memory: "128Mi"
        maxAllowed:
          cpu: "2"
          memory: "4Gi"
        controlledResources: ["cpu", "memory"]

Drei VPA-Modi:

Empfehlung: Starten Sie im Off-Modus, pruefen Sie die Empfehlungen, und wechseln Sie dann auf Auto:

# VPA-Empfehlungen anzeigen
kubectl describe vpa backend-vpa -n production

Die HPA/VPA-Falle

HPA und VPA duerfen nicht gleichzeitig auf CPU oder Memory skalieren. Der HPA sagt "mehr Pods!", der VPA sagt "groessere Pods!" -- das fuehrt zu einem Skalierungskonflikt.

Die saubere Loesung:

• HPA skaliert auf Basis von CPU/Memory oder Custom Metrics (Replica Count)
• VPA setzt nur die initialen Resource Requests (updateMode: Initial oder Off)
• Oder: HPA skaliert nach Custom Metrics, VPA nach CPU/Memory

Cluster Autoscaler: Nodes hinzufuegen und entfernen

Der Cluster Autoscaler beobachtet, ob Pods wegen fehlender Node-Kapazitaet im Pending-State haengen. Wenn ja, fuegt er Nodes hinzu. Wenn Nodes unterlastet sind, entfernt er sie.

Fuer einen Managed-Kubernetes-Service (EKS, AKS, GKE) ist die Konfiguration relativ einfach. Beispiel fuer ein Terraform-Setup mit AWS EKS:

# Cluster Autoscaler Node Group (Terraform / AWS EKS)
resource "aws_eks_node_group" "workers" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "general-workers"
  node_role_arn   = aws_iam_role.node.arn
  subnet_ids      = var.private_subnet_ids

  instance_types = ["m6i.xlarge", "m6a.xlarge", "m5.xlarge"]

  scaling_config {
    desired_size = 3
    min_size     = 2
    max_size     = 15
  }

  labels = {
    workload-type = "general"
  }
}

Der Cluster Autoscaler braucht passende IAM-Rechte und wird typischerweise als Deployment im Cluster installiert:

# Cluster Autoscaler Status pruefen
kubectl get pods -n kube-system -l app=cluster-autoscaler
kubectl logs -n kube-system -l app=cluster-autoscaler --tail=50

Karpenter: Die modernere Alternative

Karpenter (urspruenglich von AWS, jetzt ein CNCF-Projekt) ist in vielen Szenarien dem klassischen Cluster Autoscaler ueberlegen:

Wenn Sie auf AWS arbeiten, ist Karpenter in den meisten Faellen die bessere Wahl.

Alle drei Autoscaler kombinieren

Die optimale Autoscaling-Konfiguration fuer einen typischen Kubernetes-Cluster:

1. HPA fuer alle stateless Workloads (APIs, Web-Frontends, Worker)
2. VPA im Off/Initial-Modus fuer alle Workloads, um Empfehlungen zu sammeln und initiale Requests zu setzen
3. Cluster Autoscaler oder Karpenter fuer die Node-Ebene

# Gesamtuebersicht aller Autoscaler
kubectl get hpa -A
kubectl get vpa -A
kubectl get nodes -o custom-columns=NAME:.metadata.name,STATUS:.status.conditions[-1].type,CAPACITY_CPU:.status.capacity.cpu,CAPACITY_MEM:.status.capacity.memory

Typische Fehler bei Autoscaling

1. Keine Resource Requests definiert: Ohne Requests hat der HPA keine Basis fuer die Berechnung der Auslastung. Setzen Sie immer Requests.

2. HPA minReplicas auf 1: Bei einem Rollout gibt es kurzzeitig null verfuegbare Pods. Minimum 2 in Production.

3. Cluster Autoscaler zu konservativ: Der Default scale-down-delay-after-add von 10 Minuten ist oft zu lang. 5 Minuten reichen in den meisten Faellen.

4. Limits deutlich hoeher als Requests: Wenn Requests 200m CPU und Limits 2 CPU sind, kann ein einzelner Pod einen ganzen Node blockieren und andere Pods verdraengen.

5. Autoscaling ohne Monitoring: Ohne Metriken und Alerts wissen Sie nicht, ob der Autoscaler funktioniert oder kaempft. Integrieren Sie HPA-Metriken in Ihr Prometheus/Grafana-Setup.

Kostenersparnis messen

Autoscaling macht sich nur bezahlt, wenn Sie den Effekt messen:

# Aktuelle Node-Auslastung pruefen
kubectl top nodes

# Pods ohne Resource Requests finden (sollten keine sein)
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[].resources.requests == null) | .metadata.namespace + "/" + .metadata.name'

Vergleichen Sie Ihre monatlichen Cluster-Kosten vor und nach dem Autoscaling-Rollout. Typische Ergebnisse:

• Statisch provisionierte Cluster: 40-60% durchschnittliche CPU-Auslastung
• Mit Autoscaling: 65-80% durchschnittliche CPU-Auslastung
• Einsparung: 25-40% der Infrastrukturkosten

Weiterführende Artikel

• Kubernetes Resource Management im Detail
• Kubernetes Monitoring: Kosten senken mit Open Source
• Kubernetes ROI berechnen
• Kubernetes Performance verdoppeln

Wenn Sie Ihre Autoscaling-Konfiguration optimieren oder eine Kostenanalyse Ihres Clusters durchfuehren moechten, stehen wir Ihnen gerne zur Verfuegung -- Kontakt aufnehmen.