← Alle Beiträge

Kubernetes in Produktion — Was Dir keiner sagt

Matthias Bruns · · 7 Min. Lesezeit
kubernetes cloud-native engineering

Das Tutorial lügt durch Auslassung

Jedes Kubernetes-Tutorial folgt dem gleichen Drehbuch: Cluster hochfahren, kubectl apply auf ein Deployment, Pods kommen hoch, feiern. Vielleicht noch ein Ingress und ein HPA für Bonuspunkte. Fertig — Du betreibst Kubernetes!

Nein. Du betreibst eine Demo.

Ich betreibe seit Jahren Kubernetes-Cluster in Produktion. Für Unternehmen von Startups bis Konzerne. Und die Kluft zwischen “Ich habe meinen ersten Pod deployed” und “Ich betreibe einen zuverlässigen Produktions-Workload” ist gewaltig. Hier ist, was Dir keiner sagt.

Upgrade-Schmerz ist real

Kubernetes veröffentlicht alle vier Monate eine neue Minor-Version. Jede Version wird ungefähr 14 Monate unterstützt. Das heißt: Du bist auf einem Laufband — wenn Du aufhörst zu upgraden, fällst Du aus dem Support.

Klingt machbar? Hier die Realität:

  • API-Deprecations brechen Dinge. Die PodSecurityPolicy, auf die Du Dich verlässt? Weg in 1.25. Deine Ingress-Annotations? Die Hälfte hat sich zwischen Beta und GA geändert. Jedes Upgrade ist ein Audit Deiner gesamten Manifest-Basis.
  • Managed Services hinken hinterher. EKS, GKE, AKS — alle haben ihren eigenen Upgrade-Zeitplan. Dein Cluster läuft vielleicht auf 1.28, während die aktuelle Version 1.31 ist. Versuch mal, Docs für Deine spezifische Version zu finden, wenn alle über die neuesten Features bloggen.
  • Add-ons haben eigene Kompatibilitätsmatrizen. Dein CNI-Plugin, Dein Ingress-Controller, Dein cert-manager, Dein Monitoring-Stack — alles muss zu Deiner K8s-Version passen. Upgrade eins, und plötzlich müssen drei andere auch aktualisiert werden.

Ein echtes Upgrade sieht so aus:

# Was Du denkst, wie es aussieht
kubectl upgrade cluster --version 1.30

# Was es wirklich ist
# 1. Changelog lesen (komplett)
# 2. Deprecated APIs mit pluto/kubent prüfen
# 3. In Staging testen (Du hast Staging, oder?)
# 4. Alle Helm Charts auf Kompatibilität updaten
# 5. Mit jedem Team koordinieren, das auf den Cluster deployed
# 6. Wartungsfenster finden
# 7. Beten
# 8. Rollback, wenn was kaputtgeht
# 9. 3 Stunden debuggen
# 10. Nochmal versuchen

Plane mindestens einen vollen Tag pro Upgrade für einen Cluster mittlerer Komplexität. Pro Quartal.

Operator-Müdigkeit

Das Kubernetes-Ökosystem liebt Operators. Brauchst Du eine Datenbank? Es gibt einen Operator. Message Queue? Operator. Zertifikatsverwaltung? Operator. Monitoring? Rate mal.

Das Versprechen ist wunderschön: Deklariere Deinen gewünschten Zustand, und der Operator gleicht die Realität ab. Das Problem ist, dass jeder Operator seine eigene kleine Control Plane ist — mit eigenen Bugs, eigenem Upgrade-Zyklus und eigenen Vorstellungen davon, wie Dinge laufen sollten.

Ich habe Cluster mit 15+ Operators gesehen. Jeder einzelne:

  • Beobachtet den API-Server (zusätzliche Last)
  • Hat eigene CRDs (verstopft Deine API-Oberfläche)
  • Braucht eigene RBAC-Regeln (Sicherheitsoberfläche)
  • Hat eigene Logging- und Fehlermuster
  • Kann mit anderen Operators kollidieren

Wenn was schiefgeht — und das wird es — debuggst Du Interaktionen zwischen mehreren Reconciliation-Loops. Kämpft der Datenbank-Operator mit dem Backup-Operator? Stört der Istio-Sidecar-Injector Dein StatefulSet-Rollout? Viel Spaß beim Log-Durchsuchen.

Meine Faustregel: Jeder Operator, den Du hinzufügst, sollte mehr operativen Aufwand sparen, als er verursacht. Die meisten bestehen diesen Test nicht. Ein gut geschriebenes Helm Chart mit einem CronJob schlägt oft einen schlecht gewarteten Operator.

Die Monitoring-Lücke

Hier ein offenes Geheimnis: Die meisten Kubernetes-Monitoring-Setups zeigen Dir nur, was innerhalb von Kubernetes passiert. Sie zeigen Dir nicht, was Deine Nutzer erleben.

Ein typisches Prometheus + Grafana Setup gibt Dir:

  • Pod-CPU- und Speicherverbrauch
  • Container-Restart-Counts
  • Node-Ressourcenauslastung
  • Kubernetes API-Server-Latenz

Was es Dir nicht out-of-the-box gibt:

  • End-to-End-Request-Latenz aus Nutzersicht
  • Ob Deine DNS-Auflösung sporadisch versagt
  • Dass ein Node still und leise Daten korruptiert
  • Dass Dein PersistentVolume 30ms langsamer ist als gestern
  • Dass der Load Balancer Deines Cloud-Providers alle 47 Minuten Verbindungen droppt

Die Metriken, die Du wirklich brauchst, um ein Produktionssystem zu betreiben, sind Application-Level-Metriken und Infrastructure-Level-Metriken, die über das hinausgehen, was die Kubernetes-API exponiert. Du brauchst Distributed Tracing. Du brauchst Synthetic Monitoring. Du musst Dich um die Dinge zwischen Deinen Pods und Deinen Nutzern kümmern.

# Was die meisten monitoren
- pod_cpu_usage
- pod_memory_usage
- container_restarts

# Was wirklich zählt
- p99_request_latency
- error_rate_by_endpoint
- dns_resolution_time
- certificate_expiry_days
- persistent_volume_iops
- cross_az_network_latency

Die Kostenüberraschung

“Kubernetes wird uns durch bessere Ressourcenauslastung Geld sparen!” — jedes Pitch Deck.

Hier ist, was wirklich passiert:

Control-Plane-Kosten. Bei EKS zahlst Du 0,10$/Stunde allein für den API-Server. Das sind 73$/Monat, bevor ein einziger Pod läuft. Multi-Cluster? Multipliziere das.

Node-Overhead. Auf jedem Node läuft kubelet, kube-proxy, ein CNI-Agent, potenziell ein Logging-Agent, ein Monitoring-Agent und was auch immer das Platform-Team an DaemonSets für nötig hielt. Auf einer t3.medium sind das locker 30–40% der Node-Ressourcen, die von der Plattform selbst gefressen werden.

Der “Wir brauchen drei Umgebungen”-Multiplikator. Dev, Staging, Prod — jede bekommt ihren eigenen Cluster. Jeder Cluster braucht eigene Nodes, eigenes Monitoring, eigenen Ingress. Deine Cloud-Rechnung hat sich gerade verdreifacht.

Load-Balancer-Wildwuchs. Jeder Service vom Typ LoadBalancer erstellt einen Cloud-LB. Jeder kostet 15–25$/Monat auf AWS. Ich habe Cluster mit 40+ Load Balancern gesehen, weil niemand einen gemeinsamen Ingress-Controller eingerichtet hat.

PersistentVolume-Verschwendung. Volumes, die für gelöschte Pods provisioniert wurden und Kosten verursachen. PVCs mit 100GB, weil jemand ein Manifest kopiert und vergessen hat, die Größe anzupassen.

Die echten Kosten von Kubernetes sind nicht der Listenpreis — es ist der operationelle Overhead. Du brauchst mindestens eine Person, die die Plattform wirklich versteht. Das Gehalt dieser Person übersteigt Deine Cloud-Rechnung bei weitem.

Networking — Wo Träume sterben

Kubernetes-Networking ist ein Schichtkuchen aus Abstraktionen, und jede Schicht kann unabhängig kaputtgehen:

  1. Pod-to-Pod: Das CNI-Plugin kümmert sich drum. Funktioniert super, bis es das nicht tut. CNI-Probleme zu debuggen erfordert Verständnis von iptables, eBPF oder was auch immer Dein Plugin unter der Haube benutzt.
  2. Service Discovery: kube-dns/CoreDNS. Meistens okay. Bis Du auf den ndots:5-Default triffst und jede externe DNS-Anfrage 5x länger dauert, weil zuerst Cluster-lokale Suffixe durchprobiert werden.
  3. Ingress: Eine ganze Kategorie von “funktioniert in der Doku, bricht in der Praxis.” TLS-Terminierung, Pfad-Routing, Header-Manipulation — jeder Ingress-Controller implementiert die Spec etwas anders.
  4. Network Policies: Die Firewall, die Du nutzen solltest, aber wahrscheinlich nicht tust. Und wenn doch, wirst Du feststellen, dass die NetworkPolicy-Implementierung Deines CNI-Plugins “bekannte Einschränkungen” hat.
# Diese harmlos aussehende Config hat mich mehrfach gebissen
apiVersion: v1
kind: Pod
spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"  # Override den Default 5
  # Ohne das erzeugt die Auflösung von "api.stripe.com"
  # 5 fehlgeschlagene Lookups, bevor der echte gelingt

Solltest Du also Kubernetes nutzen?

Ja — wenn Du das Team, den Workload und die operationelle Reife dafür hast.

Kubernetes ergibt Sinn, wenn:

  • Du 10+ Services betreibst, die unabhängig skaliert und deployed werden müssen
  • Du ein dediziertes Platform-Team hast (oder bereit bist, eins aufzubauen)
  • Du Multi-Cloud- oder Hybrid-Fähigkeiten brauchst
  • Deine Deployment-Frequenz die Komplexität rechtfertigt

Kubernetes ist Overkill, wenn:

  • Du weniger als 5 Services hast
  • Dein Team kleiner als 10 Entwickler ist
  • Ein Managed PaaS (Cloud Run, App Runner, Fly.io) Deine Anforderungen abdeckt
  • Du es wählst, weil es gut auf dem Lebenslauf aussieht

Die ehrliche Wahrheit: Kubernetes ist Infrastruktur zum Bauen von Plattformen. Wenn Du keine Plattform brauchst, brauchst Du kein Kubernetes. Ein gut konfigurierter VPS mit Docker Compose und einer CI/CD-Pipeline schlägt ein schlecht betriebenes Kubernetes-Cluster jedes Mal.

Das Fazit

Kubernetes ist ein mächtiges Werkzeug. Es ist auch ein komplexes, das Respekt einfordert. Wenn Du es in Produktion betreiben willst, geh mit offenen Augen rein:

  • Plane Upgrades als laufende Arbeit ein, nicht als einmaliges Setup
  • Sei wählerisch bei Operators — weniger ist mehr
  • Investiere in Monitoring, das über Pod-Metriken hinausgeht
  • Tracke Deine echten Kosten, nicht Deine prognostizierten Einsparungen
  • Akzeptiere, dass Networking Dich überraschen wird

Und wenn Du ein mittelständisches Unternehmen bist und Dich fragst, ob Kubernetes das Richtige für Dich ist — sprich mit jemandem, der es betrieben hat, nicht mit jemandem, der es verkauft. Der Unterschied ist entscheidend.

Lesebarkeit

Schriftgröße