Kubernetes FinOps: Cloud-Kosten systematisch senken

TL;DR

FinOps für Kubernetes beginnt mit Kostentransparenz: OpenCost zeigt, welcher Namespace wie viel verbraucht. Danach folgt Ressourcen-Optimierung durch korrekte Requests und Limits -- die meisten Cluster sind 30–50% überprovisioniert. Cluster-Autoscaler-Tuning und Namespace-Budgets schließen den Kreislauf. Dieser Guide zeigt die konkreten Schritte von der Installation bis zur monatlichen Kostenreduktion.

Kosten sichtbar machen mit OpenCost

Du kannst nicht optimieren, was du nicht misst. OpenCost ist ein CNCF-Projekt, das Kubernetes-Kosten in Echtzeit aufschlüsselt.

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update

helm install opencost opencost/opencost \
  --namespace opencost \
  --create-namespace \
  --set opencost.prometheus.internal.serviceName=prometheus-kube-prometheus-prometheus \
  --set opencost.prometheus.internal.namespaceName=monitoring \
  --set opencost.ui.enabled=true

Nach der Installation zeigt die API sofort Kosten pro Namespace:

kubectl port-forward -n opencost svc/opencost 9090:9090 &

# Kosten der letzten 7 Tage pro Namespace
curl -s "http://localhost:9090/allocation/compute?window=7d&aggregate=namespace" | \
  python3 -m json.tool

OpenCost berechnet Kosten anhand von Cloud-Preisen (AWS, Azure, GCP werden automatisch abgerufen) und den Resource Requests der Pods. Für On-Prem-Cluster lassen sich Custom-Preise hinterlegen.

Requests und Limits: Der größte Hebel

Über-provisionierte Requests sind der häufigste Kostentreiber. Ein Pod mit requests.cpu: 2 und tatsächlichem Verbrauch von 200m blockiert 1.8 CPU, für die ihr zahlt.

So findet ihr die Kandidaten:

# Pods mit CPU-Nutzung deutlich unter dem Request
kubectl top pods -A --sort-by=cpu | head -20

# Detaillierte Analyse: VPA Recommender installieren
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install goldilocks fairwinds-stable/goldilocks \
  --namespace goldilocks \
  --create-namespace

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

Goldilocks nutzt den VPA-Recommender und zeigt pro Deployment eine Web-UI mit empfohlenen Requests und Limits. Erfahrungsgemäß lassen sich Requests in bestehenden Clustern um 30–50% reduzieren.

Konkrete Optimierung

# Vorher: Über-provisioniert
resources:
  requests:
    cpu: "2"
    memory: 4Gi
  limits:
    cpu: "4"
    memory: 8Gi

# Nachher: An tatsächlichen Verbrauch angepasst
resources:
  requests:
    cpu: 400m
    memory: 768Mi
  limits:
    cpu: "1"
    memory: 1536Mi

Wichtig: Limits nicht zu eng setzen. Ein Limit von cpu: 400m führt zu CPU-Throttling unter Last. Setzt das CPU-Limit mindestens auf das 2–3-fache des Requests oder lasst es ganz weg (nur Request setzen).

Cluster Autoscaler tunen

Der Cluster Autoscaler skaliert Nodes basierend auf Pending Pods. Default-Einstellungen sind konservativ und halten oft zu viel Kapazität vor.

# cluster-autoscaler-values.yaml
autoscaling:
  enabled: true
extraArgs:
  scale-down-delay-after-add: "5m"      # Default: 10m
  scale-down-unneeded-time: "5m"         # Default: 10m
  scale-down-utilization-threshold: "0.65" # Default: 0.5
  skip-nodes-with-local-storage: "false"
  balance-similar-node-groups: "true"
  expander: "least-waste"

Für Workloads, die Unterbrechungen vertragen (Batch-Jobs, Dev/Staging): Spot- bzw. Preemptible-Nodes nutzen. Die Ersparnis liegt bei 60–80%.

Namespace-Level Kostenallokation

Ohne Zuordnung optimiert niemand. Jeder Namespace braucht einen Verantwortlichen.

# ResourceQuota pro Namespace
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-commerce-quota
  namespace: commerce-production
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    persistentvolumeclaims: "10"

ResourceQuotas begrenzen den maximalen Verbrauch. Damit Teams nicht einfach hohe Requests setzen, kombiniert ihr Quotas mit den VPA-Empfehlungen aus Goldilocks.

Kosten pro Team abfragen:

# OpenCost: Monatskosten pro Label "team"
curl -s "http://localhost:9090/allocation/compute?window=30d&aggregate=label:team" | \
  python3 -c "
import json, sys
data = json.load(sys.stdin)
for entry in data.get('data', []):
    for team, costs in entry.items():
        total = costs.get('totalCost', 0)
        print(f'{team:20s}  {total:8.2f} EUR')
"

Kosten-Reduktion Checkliste

Die folgende Checkliste priorisiert nach Aufwand und Wirkung:

Quick Wins (Woche 1)

• OpenCost installieren und Kosten pro Namespace sichtbar machen
• Top-10 Pods mit höchster Über-Provisionierung identifizieren
• Ungenutzte PersistentVolumeClaims löschen: kubectl get pvc -A --no-headers | wc -l
• Idle Load Balancer und Services vom Typ LoadBalancer prüfen

Mittelfristig (Monat 1–2)

• Goldilocks pro Namespace aktivieren und Requests anpassen
• Cluster Autoscaler Scale-Down-Parameter verschärfen
• Spot-Nodes für Dev/Staging und Batch-Workloads einführen
• ResourceQuotas für alle Produktions-Namespaces setzen

Langfristig (Quartal)

• Monatliche FinOps-Reviews mit Team-Leads etablieren
• Showback-Reports automatisieren und per Slack verteilen
• Budget-Alerts in Prometheus konfigurieren
• Reserved Instances / Committed Use Discounts für Baseline-Kapazität kaufen

FAQ

Wie viel Ersparnis ist realistisch?

Teams, die zum ersten Mal Requests optimieren, sparen typischerweise 25–40% der Compute-Kosten. Spot-Nodes bringen weitere 30–50% für geeignete Workloads. Insgesamt sind 40–60% Reduktion keine Seltenheit.

OpenCost oder Kubecost?

OpenCost ist Apache-2.0-lizenziert und deckt Kostenallokation ab. Kubecost Enterprise bietet zusätzlich automatische Optimierungsempfehlungen, Multi-Cluster-Support und SSO. Für den Einstieg reicht OpenCost.

Soll ich CPU-Limits setzen oder weglassen?

Kontrovers diskutiert. Ohne CPU-Limits kann ein Pod die gesamte Node-CPU nutzen, was Noisy-Neighbor-Probleme verursacht. Mit zu engen Limits wird der Pod gedrosselt. Empfehlung: CPU-Limits auf das 2–3-fache des Requests setzen oder in dedizierten Node-Pools komplett weglassen.

Wie messe ich den Erfolg der FinOps-Initiative?

Trackt drei Metriken monatlich: Gesamtkosten pro Cluster, Kosten pro Namespace/Team und CPU/Memory-Effizienz (tatsächliche Nutzung geteilt durch Requests). Ein Effizienz-Ziel von 60–70% ist realistisch.

Was sind die häufigsten versteckten Kosten?

Persistent Volumes, die nach dem Löschen eines Pods bestehen bleiben. Load Balancer für Services, die niemand mehr nutzt. Und Logging/Monitoring-Daten: Ein Cluster mit verbose Logging erzeugt leicht 500 Gi pro Monat an Log-Daten.