TL;DR

Kubernetes Rightsizing bedeutet, CPU- und Memory-Requests so zu setzen, dass Pods weder zu viel noch zu wenig Ressourcen bekommen. Mit kubectl top findest du aktuelle Verbrauchswerte, der Vertical Pod Autoscaler (VPA) gibt automatische Empfehlungen, und Goldilocks visualisiert das Ganze pro Namespace.

Kubernetes Rightsizing: Ressourcen richtig dimensionieren

Die meisten Kubernetes-Cluster sind über-provisioniert. Entwickler setzen Requests auf "sicherheitshalber 2 CPU und 4 Gi Memory" — und der Cluster braucht doppelt so viele Nodes wie nötig. Rightsizing löst genau dieses Problem.

Prüfe zuerst, wie viel deine Pods tatsächlich nutzen:

# Ressourcenverbrauch aller Pods im Namespace
kubectl top pods -n production

# Node-Auslastung anzeigen
kubectl top nodes

Requests vs. Limits: Die Grundlagen

Requests und Limits steuern, wie der Scheduler Pods platziert und wie viel ein Container maximal nutzen darf.

resources:
  requests:
    cpu: 100m      # Garantierte CPU
    memory: 128Mi  # Garantierter Speicher
  limits:
    cpu: 500m      # Maximum CPU
    memory: 512Mi  # Maximum Speicher (OOMKill bei Überschreitung)

Best Practice: Requests immer setzen, CPU-Limits weglassen (CPU-Throttling schadet mehr als es hilft), Memory-Limits setzen (OOM ist besser als Node-Crash).

Über-Provisionierung erkennen

Der schnellste Weg: Requests mit dem tatsächlichen Verbrauch vergleichen.

# Requests und tatsächliche Nutzung pro Pod vergleichen
kubectl top pods -n production --containers | sort -k3 -rn

# Alle Pods mit ihren Requests auflisten
kubectl get pods -n production -o custom-columns=\
NAME:.metadata.name,\
CPU_REQ:.spec.containers[0].resources.requests.cpu,\
MEM_REQ:.spec.containers[0].resources.requests.memory,\
CPU_LIM:.spec.containers[0].resources.limits.cpu,\
MEM_LIM:.spec.containers[0].resources.limits.memory

Ein typisches Bild: Der Pod requested 2 CPU, nutzt aber nur 50m. Das sind 97,5% verschwendete Kapazität, die kein anderer Pod nutzen kann.

VPA: Automatische Empfehlungen

Der Vertical Pod Autoscaler analysiert den historischen Ressourcenverbrauch und gibt Empfehlungen. Im Recommendation-Mode ändert er nichts — er schlägt nur vor.

# VPA installieren
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-up.sh

VPA-Objekt für ein Deployment erstellen:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  updatePolicy:
    updateMode: "Off"  # Nur Empfehlungen, keine automatischen Änderungen
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 50m
        memory: 64Mi
      maxAllowed:
        cpu: 2
        memory: 4Gi

Nach ein paar Stunden Datensammlung:

# VPA-Empfehlungen abrufen
kubectl get vpa app-vpa -n production -o jsonpath='{.status.recommendation}' | jq .

Die Ausgabe zeigt drei Werte: lowerBound (Minimum), target (Empfehlung) und upperBound (Spitzenlast). Nutze target als neuen Request-Wert.

Goldilocks: Dashboard für alle Namespaces

Goldilocks von Fairwinds erstellt automatisch VPA-Objekte für jeden Namespace und zeigt die Empfehlungen in einem Web-Dashboard.

# Goldilocks per Helm installieren
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm repo update

helm install goldilocks fairwinds-stable/goldilocks \
  --namespace goldilocks \
  --create-namespace \
  --set dashboard.enabled=true

# Namespace für Goldilocks aktivieren
kubectl label namespace production goldilocks.fairwinds.com/enabled=true

Dashboard aufrufen:

kubectl port-forward svc/goldilocks-dashboard -n goldilocks 8080:80
# Browser: http://localhost:8080

Das Dashboard zeigt pro Deployment die aktuellen Requests/Limits neben den VPA-Empfehlungen — mit konkreten YAML-Snippets zum Kopieren.

Vorher/Nachher: Was Rightsizing bringt

Ein reales Beispiel mit 12 Microservices in einem Production-Namespace:

Der Schlüssel: Die meisten Services hatten 2 CPU requested, nutzten aber durchschnittlich 80-150m.

Rightsizing-Workflow

So gehst du systematisch vor:

1. Metrics-Server prüfen: kubectl top muss funktionieren
2. VPA im Off-Mode für alle kritischen Deployments aktivieren
3. Mindestens 7 Tage Daten sammeln (Werktag- und Wochenend-Muster)
4. Target-Werte als neue Requests setzen, mit 20% Puffer nach oben
5. Memory-Limits auf 1,5x des Requests setzen
6. Monitoring nach Änderung: OOMKills und CPU-Throttling beobachten

# OOMKills der letzten Stunde finden
kubectl get events -A --field-selector reason=OOMKilling --sort-by='.lastTimestamp'

# Pods mit Restart-Count > 0 (mögliche OOMKills)
kubectl get pods -A | awk '$5 > 0'

FAQ

Soll ich VPA im Auto-Mode nutzen?

Für Stateless-Workloads ja — VPA startet Pods mit neuen Werten neu. Für Stateful-Workloads oder bei wenigen Replicas nutze den Off-Mode und ändere Requests manuell.

Wie oft sollte ich Rightsizing durchführen?

Mindestens quartalsweise. Nach größeren Releases oder Traffic-Änderungen sofort. Goldilocks als Dauer-Monitoring laufen zu lassen kostet wenig und zeigt Abweichungen früh.

Was ist besser: VPA oder HPA?

Beide lösen unterschiedliche Probleme. VPA passt Ressourcen pro Pod an, HPA skaliert die Anzahl der Pods. Kombiniere beides: VPA für korrekte Requests, HPA für Last-Skalierung. Achtung: VPA und HPA auf derselben Metrik (CPU) kollidieren.

Kann Rightsizing die Stabilität gefährden?

Ja, bei zu aggressiver Reduktion. Deshalb immer 20% Puffer auf den VPA-Target-Wert und Memory-Limits über dem Request setzen. Starte mit nicht-kritischen Namespaces.