Kubernetes Cloud-Kosten senken: FinOps und Right-Sizing

TL;DR

Die meisten Kubernetes-Cluster verschwenden 40-65 Prozent ihrer Cloud-Ressourcen durch ueberdimensionierte Pods, fehlende Autoscaler und 24/7-Dev-Umgebungen
Right-Sizing allein (Requests und Limits anpassen) spart 30-40 Prozent der Node-Kosten -- in einer Stunde umsetzbar
Spot Instances fuer nicht-kritische Workloads senken Compute-Kosten um 60-70 Prozent
Ein FinOps-Prozess mit Kubecost oder OpenCost macht Verschwendung sichtbar -- pro Namespace, Team und Label
Ein Managed Service Partner uebernimmt die kontinuierliche Optimierung, sodass kein internes Kubernetes-Team noetig ist

Warum Cloud-Kosten bei Kubernetes explodieren

Die Cloud-Rechnung steigt Monat fuer Monat, aber niemand weiss genau, wohin das Geld fliesst. Das ist kein Kubernetes-Problem -- es ist ein Sichtbarkeitsproblem. Ohne FinOps-Prozesse passiert Folgendes:

Typische Kostenverteilung eines unkontrollierten Clusters:

Compute (Nodes):              65%  <- Hier liegt das meiste Sparpotenzial
Storage (PVCs, Snapshots):    15%  <- Oft vergessene Altlasten
Networking (LB, NAT, Egress): 12%  <- Ueberraschend teuer
Monitoring/Logging:            5%  <- Datenvolumen kontrollieren
Sonstiges (DNS, Secrets):      3%

Die gute Nachricht: Compute ist der groesste Posten und gleichzeitig am einfachsten zu optimieren.

Strategie 1: Right-Sizing -- der schnellste Hebel

Das Problem

Entwickler setzen Resource Requests nach dem Motto "lieber zu viel als zu wenig". Das Ergebnis: Pods reservieren 5-10x mehr CPU und Memory als sie tatsaechlich nutzen. Die Nodes muessen aber fuer die reservierten Ressourcen bezahlt werden.

Vorher vs. Nachher

Metrik	Vorher (typisch)	Nachher (optimiert)	Ersparnis
CPU Requests gesamt	48 vCPU	12 vCPU	75%
Memory Requests gesamt	96 GB	32 GB	67%
Benoetigte Nodes (m5.xlarge)	12 Nodes	4 Nodes	67%
Monatliche Compute-Kosten	4.200 EUR	1.470 EUR	65%

So finden Sie die Verschwender

# Top-10 Pods mit der groessten CPU-Verschwendung
# (Requests vs. tatsaechlicher Verbrauch)
kubectl top pods -A --sort-by=cpu --no-headers | head -20

# Detailansicht fuer einen Namespace
kubectl top pods -n production --containers

# Fuer systematisches Right-Sizing: VPA im Recommendation-Mode
# installieren und 7 Tage Daten sammeln lassen

# Vertical Pod Autoscaler im Empfehlungsmodus
# Aendert nichts automatisch, gibt nur Empfehlungen
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-gateway-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  updatePolicy:
    updateMode: "Off"  # Nur Empfehlungen, kein Auto-Update
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 50m
        memory: 64Mi
      maxAllowed:
        cpu: 2
        memory: 4Gi

Nach 7 Tagen Datensammlung:

# Empfehlungen abrufen
kubectl describe vpa api-gateway-vpa -n production

# Typischer Output:
# Target:      Cpu: 100m, Memory: 256Mi
# Upper Bound: Cpu: 250m, Memory: 512Mi
#
# Statt der konfigurierten:
# Requests:    Cpu: 1000m, Memory: 2Gi  <- 10x zu viel!

Strategie 2: Autoscaling richtig konfigurieren

Horizontal Pod Autoscaler (HPA)

Ohne HPA laufen immer gleich viele Pods -- egal ob Mitternacht oder Mittagspeak.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webshop-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webshop-frontend
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 5 Min warten vor Scale-Down
      policies:
      - type: Percent
        value: 25
        periodSeconds: 60  # Max 25% der Pods pro Minute entfernen
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60  # Max 50% mehr Pods pro Minute

Cluster Autoscaler: Nodes dynamisch skalieren

Der Cluster Autoscaler entfernt Nodes, die nicht benoetigt werden, und fuegt neue hinzu, wenn Pods nicht gescheduled werden koennen.

Kosteneffekt bei typischem Tagesverlauf:

Ohne Cluster Autoscaler (8 Nodes, 24/7):
08:00-18:00:  8 Nodes, 70% Auslastung (OK)
18:00-08:00:  8 Nodes, 15% Auslastung (Verschwendung!)
Wochenende:   8 Nodes,  8% Auslastung (Massive Verschwendung!)

Kosten: 8 Nodes x 730h x 0.192 EUR = 1.121 EUR/Monat

Mit Cluster Autoscaler (2-8 Nodes):
08:00-18:00:  6-8 Nodes (Lastabhaengig)
18:00-08:00:  2-3 Nodes (Autoscaled)
Wochenende:   2 Nodes (Minimum)

Kosten: Durchschnitt 4.2 Nodes x 730h x 0.192 EUR = 589 EUR/Monat
Ersparnis: 47%

Strategie 3: Spot Instances fuer nicht-kritische Workloads

Spot Instances (AWS) bzw. Preemptible VMs (GCP) oder Spot VMs (Azure) kosten 60-70 Prozent weniger als On-Demand. Der Haken: Sie koennen jederzeit terminiert werden.

Welche Workloads eignen sich?

Workload	Spot geeignet	Begruendung
Dev/Test/Staging	Ja	Kein Produktionsrisiko
CI/CD Build-Agents	Ja	Jobs koennen wiederholt werden
Batch-Processing	Ja	Checkpointing moeglich
Stateless APIs (mit Replicas)	Ja	Andere Pods uebernehmen Traffic
Datenbanken	Nein	Datenverlust-Risiko
Single-Replica Production	Nein	Kein Failover moeglich

Implementierung mit Node Pools

# Karpenter Provisioner fuer Spot Instances (AWS)
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-workloads
spec:
  template:
    spec:
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot"]
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m5.large
        - m5.xlarge
        - m5a.large
        - m5a.xlarge
        - m6i.large
        - m6i.xlarge
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "40"
    memory: "160Gi"
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s

Strategie 4: Dev/Test-Umgebungen zeitgesteuert skalieren

Entwickler arbeiten 8 Stunden am Tag, 5 Tage die Woche. Dev/Test-Cluster laufen aber 24/7. Das sind 128 von 168 Wochenstunden Verschwendung.

# CronJob: Dev-Namespace nachts auf 0 skalieren
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-down-dev
  namespace: kube-system
spec:
  schedule: "0 20 * * 1-5"  # Mo-Fr um 20:00 Uhr
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: namespace-scaler
          containers:
          - name: scaler
            image: bitnami/kubectl:1.29
            command:
            - /bin/sh
            - -c
            - |
              echo "Scaling down development namespace..."
              kubectl scale deployment --all --replicas=0 -n development
              kubectl scale deployment --all --replicas=0 -n staging
              echo "Done. Nodes will be removed by Cluster Autoscaler."
          restartPolicy: OnFailure
---
# CronJob: Morgens wieder hochfahren
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-up-dev
  namespace: kube-system
spec:
  schedule: "0 7 * * 1-5"  # Mo-Fr um 07:00 Uhr
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: namespace-scaler
          containers:
          - name: scaler
            image: bitnami/kubectl:1.29
            command:
            - /bin/sh
            - -c
            - |
              echo "Scaling up development namespace..."
              kubectl scale deployment --all --replicas=1 -n development
              kubectl scale deployment --all --replicas=1 -n staging
          restartPolicy: OnFailure

Ersparnis: 60-70 Prozent der Dev/Test-Kosten.

Strategie 5: FinOps-Dashboard fuer Kostentransparenz

Ohne Sichtbarkeit keine Optimierung. Kubecost oder OpenCost zeigen Kosten pro Namespace, Team und Label.

# OpenCost installieren (CNCF-Projekt, kostenlos)
helm install opencost opencost/opencost \
  --namespace opencost \
  --create-namespace \
  --set opencost.prometheus.internal.enabled=true

# Nach Installation: Port-Forward zum Dashboard
kubectl port-forward -n opencost svc/opencost 9090:9090

# API-Abfrage: Kosten pro Namespace der letzten 7 Tage
curl "http://localhost:9090/allocation/compute?window=7d&aggregate=namespace" | \
  jq '.data[] | to_entries[] | {namespace: .key, totalCost: .value.totalCost}'

Kostenalerts einrichten

Definieren Sie Budgets pro Team und lassen Sie sich warnen, bevor die Kosten aus dem Ruder laufen.

Namespace	Monatliches Budget	Alert bei	Aktion
production	3.000 EUR	80% (2.400 EUR)	Slack-Notification
development	1.500 EUR	90% (1.350 EUR)	Slack + Scale-Down-Warnung
data-pipeline	2.000 EUR	70% (1.400 EUR)	Review anfordern

Gesamtbild: Was 45% Einsparung konkret bedeutet

Fuer ein mittelstaendisches Unternehmen mit monatlichen Cloud-Kosten von 8.000 EUR fuer Kubernetes-Workloads:

Massnahme	Einsparung	Monatlich	Aufwand
Right-Sizing (Requests anpassen)	30%	2.400 EUR	1-2 Tage
Cluster Autoscaler aktivieren	15% zusaetzlich	840 EUR	2 Stunden
Dev/Test nachts abschalten	5% gesamt (60% Dev)	400 EUR	2 Stunden
Spot Instances (Dev + Batch)	5% gesamt	400 EUR	1 Tag
Gesamt	~45%	~3.640 EUR	3-4 Tage

Hochgerechnet auf 12 Monate: rund 43.700 EUR Einsparung. Und das ist konservativ gerechnet.

Detaillierte Optimierungstipps finden Sie im Kubernetes Kosten-Optimierung Praxis-Guide.

Warum Sie dafuer kein internes K8s-Team brauchen

Die beschriebenen Optimierungen erfordern Kubernetes-Expertise. Aber sie erfordern kein Vollzeit-Team. Ein Managed Service Partner setzt die Massnahmen einmalig um und ueberwacht die Kosten kontinuierlich.

Was ein externer Partner uebernimmt:

Initiales Right-Sizing: VPA-Analyse, Empfehlungen umsetzen, Monitoring aufbauen
Autoscaling-Konfiguration: HPA, Cluster Autoscaler, Spot-Integration
Monatlicher FinOps-Report: Kostenentwicklung, Anomalien, Optimierungsvorschlaege
Kontinuierliche Anpassung: Neue Workloads bewerten, Konfiguration nachfuehren

Der Vergleich zwischen Managed Service und Inhouse-Betrieb zeigt, ab welcher Groesse ein internes Team wirtschaftlicher wird. Fuer die meisten Mittelstaendler ist es das nicht.

Haeufige Fehler bei der Kostenoptimierung

Nur auf Compute schauen: Storage- und Networking-Kosten werden oft vergessen. Alte PVCs und ueberdimensionierte Load Balancer kosten mehr als erwartet.
Zu aggressive Limits setzen: Wer CPU-Limits zu niedrig setzt, erzeugt Throttling. Die Anwendung wird langsam, Nutzer beschweren sich, und jemand dreht die Limits wieder hoch -- hoeher als vorher.
Spot Instances fuer alles nutzen: Spot in Production ohne PodDisruptionBudgets und mehrere Replicas ist ein Rezept fuer Ausfaelle.
Einmalige Optimierung statt Prozess: Cloud-Kosten optimiert man nicht einmal, sondern kontinuierlich. Ohne monatliches Review schleichen sich die alten Muster wieder ein.

Details zum laufenden Betrieb und warum 24/7-Monitoring dazugehoert, finden Sie im Artikel Kubernetes 24/7-Betrieb im Mittelstand.

Fazit

Cloud-Kosten fuer Kubernetes sind kein Naturgesetz. Mit Right-Sizing, Autoscaling, Spot Instances und einem FinOps-Prozess sparen Mittelstaendler realistisch 40-50 Prozent ihrer monatlichen Rechnung. Der Aufwand fuer die initiale Optimierung liegt bei 3-4 Tagen -- die Einsparungen wirken dauerhaft.

Wer kein internes Kubernetes-Team hat oder aufbauen will, laesst die Optimierung von einem Managed Service Partner umsetzen und profitiert vom monatlichen FinOps-Reporting. So bleiben die Kosten unter Kontrolle, ohne dass eine Vollzeitstelle dafuer noetig ist.

Weiterfuehrende Artikel:

Sie wollen wissen, wie viel Ihre Kubernetes-Umgebung konkret einsparen kann? Kontaktieren Sie uns fuer eine kostenlose Erstanalyse Ihrer Cloud-Rechnung.