TL;DR

Kubernetes bietet vier Autoscaling-Mechanismen: HPA skaliert Pods horizontal nach CPU/Memory oder Custom Metrics, VPA passt Ressourcen-Requests vertikal an, der Cluster Autoscaler fügt Nodes hinzu und KEDA skaliert event-basiert. Die Kombination dieser Tools ergibt ein robustes Capacity Planning.

Capacity Planning mit Kubernetes-Autoscaling

Manuelles Skalieren funktioniert bis zu einem gewissen Punkt. Ab 20+ Services wird es zum Vollzeitjob. Kubernetes bringt vier Autoscaling-Mechanismen mit, die zusammen ein durchdachtes Capacity Planning ermöglichen.

Voraussetzung: Der Metrics Server muss im Cluster laufen.

# Metrics Server prüfen
kubectl get deployment metrics-server -n kube-system

# Falls nicht vorhanden:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Test: Pod-Metriken abrufen
kubectl top pods -A

Horizontal Pod Autoscaler (HPA)

Der HPA ist der meistgenutzte Autoscaler. Er erhöht oder reduziert die Anzahl der Pod-Replicas basierend auf Metriken.

HPA mit CPU und Custom Metrics

Ein Standard-HPA auf CPU-Basis reicht oft nicht. Besser: Kombiniere CPU mit applikationsspezifischen Metriken wie Requests pro Sekunde.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 15
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 20
          periodSeconds: 120

Der behavior-Block ist entscheidend: Ohne ihn skaliert der HPA bei kurzen Lastspitzen aggressiv hoch und danach sofort wieder runter. Das stabilizationWindowSeconds verhindert dieses Flapping.

# HPA-Status prüfen
kubectl get hpa -n production

# Detaillierte Ansicht mit aktuellen Metriken
kubectl describe hpa web-app-hpa -n production

Vertical Pod Autoscaler (VPA)

Der VPA analysiert den tatsächlichen Ressourcenverbrauch und passt requests und limits automatisch an. Besonders nützlich für Workloads, deren Ressourcenbedarf schwer einzuschätzen ist.

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

Wichtig: HPA und VPA auf derselben Metrik (z.B. CPU) gleichzeitig zu nutzen führt zu Konflikten. Nutze HPA für CPU-basierte Skalierung und VPA nur für Memory — oder setze den VPA auf updateMode: "Off" und übernimm die Empfehlungen manuell.

Cluster Autoscaler

Wenn der HPA mehr Pods will, aber kein Node genug Kapazität hat, springt der Cluster Autoscaler ein. Er fügt Nodes hinzu oder entfernt ungenutzte.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  template:
    spec:
      containers:
        - name: cluster-autoscaler
          image: registry.k8s.io/autoscaling/cluster-autoscaler:v1.31.0
          command:
            - ./cluster-autoscaler
            ---v=4
            ---cloud-provider=aws
            ---skip-nodes-with-local-storage=false
            ---expander=least-waste
            ---node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster
            ---balance-similar-node-groups
            ---scale-down-delay-after-add=10m
            ---scale-down-unneeded-time=10m
            ---max-node-provision-time=15m

Der --expander=least-waste sorgt dafür, dass der Autoscaler die Node-Gruppe wählt, die am wenigsten Ressourcen verschwendet. Alternative Expander:

KEDA: Event-Driven Autoscaling

KEDA erweitert den HPA um externe Event-Quellen. Damit skalierst du basierend auf Kafka-Queue-Länge, RabbitMQ-Messages, Prometheus-Queries oder Cron-Schedules.

# KEDA installieren
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace

Ein ScaledObject für Kafka-Consumer:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaler
  namespace: production
spec:
  scaleTargetRef:
    name: kafka-consumer
  pollingInterval: 15
  cooldownPeriod: 120
  minReplicaCount: 1
  maxReplicaCount: 30
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka.kafka.svc:9092
        consumerGroup: my-consumer-group
        topic: orders
        lagThreshold: "50"

KEDA kann Pods sogar auf null skalieren — ideal für Workloads, die nur bei eingehenden Events laufen sollen.

Entscheidungshilfe: Welchen Autoscaler wann?

Nicht jeder Workload braucht jeden Autoscaler. Diese Entscheidungslogik hilft:

1. Stateless Web-Service mit variablem Traffic → HPA (CPU + Requests/s)
2. Batch-Jobs mit unbekanntem Ressourcenbedarf → VPA im Off-Mode für Empfehlungen
3. Queue-basierte Worker → KEDA mit Queue-Length-Trigger
4. Cluster läuft regelmäßig an Kapazitätsgrenze → Cluster Autoscaler
5. Vorhersehbare Last (z.B. Business Hours) → KEDA mit Cron-Trigger + HPA

Die stärkste Kombination für Production: HPA für Pod-Skalierung, Cluster Autoscaler für Node-Skalierung und VPA im Off-Mode für Ressourcen-Empfehlungen.

# Gesamtübersicht aller Autoscaler im Cluster
kubectl get hpa -A
kubectl get vpa -A
kubectl get scaledobjects.keda.sh -A

# Node-Auslastung prüfen
kubectl top nodes

FAQ

Können HPA und VPA gleichzeitig laufen?

Ja, aber nicht auf derselben Metrik. Nutze HPA für CPU-basiertes Skalieren und VPA nur für Memory-Anpassungen. Ab Kubernetes 1.27 gibt es experimentellen In-Place-VPA-Support, der Restarts vermeidet.

Wie schnell skaliert der Cluster Autoscaler neue Nodes?

Typischerweise 2-5 Minuten je nach Cloud-Provider. AWS mit Warm Pools oder GKE mit Node Auto-Provisioning sind schneller. Für latenzkrische Workloads: Überprovisioning mit niedrig-prioren Placeholder-Pods.

Was passiert bei KEDA, wenn die Event-Quelle ausfällt?

KEDA behält den letzten bekannten Zustand bei. Die Pods werden weder hoch- noch runterskaliert. Über fallback in der ScaledObject-Spec kannst du einen Fallback-Wert definieren.

Wie verhindere ich zu aggressives Scale-Down?

Nutze stabilizationWindowSeconds im HPA-Behavior-Block (empfohlen: 300s für Scale-Down). Beim Cluster Autoscaler hilft --scale-down-delay-after-add=10m. Für kritische Pods: cluster-autoscaler.kubernetes.io/safe-to-evict: "false" als Annotation.

Nächster Schritt: Kombiniere Autoscaling mit Monitoring. Setze Alerts auf HPA-Events, damit du weißt, wann dein Cluster an Limits stößt — beispielsweise mit dem kube-prometheus-stack.