„Wir dachten, Kubernetes würde uns retten" — Die Produktionsausfälle, die niemand in die Konferenzfolien packt

Jemand stellte eine einfache Frage:

Was geht in der Kubernetes-Produktion tatsächlich schief?

Nicht Best Practices. Nicht Theorie. Nicht Whiteboard-Architektur.

Echte Ausfälle.

Die Antworten waren nicht poliert. Es waren Narben.

Und wenn man zwischen den Zeilen liest, erkennt man ein Muster:

Kubernetes versagt normalerweise nicht auf dramatische, filmreife Art.

Es versagt auf zutiefst menschliche Art.

Reden wir darüber, was tatsächlich kaputtgeht.

1️⃣ Die Control Plane stirbt nicht leise – sie implodiert

Ein Ingenieur fügte versehentlich rund 60 Maschinen dem API-Server-Pool statt dem Node-Pool hinzu. etcd „wurde WIRKLICH wütend und brach unter seinem eigenen Gewicht zusammen".

Das ist kein Bug.

Das ist operativer Explosionsradius.

Aber hier kommt der unheimliche Teil: Die Workloads liefen weiter.

Sie wurden nicht neu geplant.

Sie heilten sich nicht selbst.

Sie skalierten nicht.

Aber sie bedienten weiter Traffic in ihrem letzten bekannten Zustand.

Das ist etwas, das die meisten Leute nicht verstehen, bis sie es live erleben:

Kubernetes ist auf eigenartige Weise Split-Brain-tolerant.

Die Data Plane tuckert weiter, selbst wenn die Control Plane in Flammen steht.

Bis sie es nicht mehr tut.

Die Wiederherstellung erforderte das manuelle Wiederherstellen von etcd aus seinem eigenen Datenverzeichnis und das erneute Beitreten der Mitglieder.

Das ist kein lustiger Dienstag.

2️⃣ IP-Adressen-Erschöpfung – Der stille Killer

„Subnetzgröße für k8s zu klein angelegt."

Dieser eine Satz verbirgt Wochen voller Schmerz.

Cluster laufen aus IPs.

Pods können nicht geplant werden.

Nodes skalieren, können aber keine ENIs anhängen.

Firewall-Regeln müssen neu geschrieben werden.

Networking-Teams werden in Meetings gezogen.

Ein anderer Kommentar sagte unverblümt:

Kein IPv6 zu nutzen, ist der erste Fehler.

War das Sarkasmus? Vielleicht. Aber der Schmerz ist real.

Jemand anders erwähnte, dass das Deaktivieren der Warm-ENI-Zuweisung in EKS Tausende von IPs freigab.

Das ist die Art von Sache, die man nur lernt, nachdem man Nodes während eines Incidents beim Skalieren scheitern sieht.

IP-Mathematik ist nicht sexy.

Bis die Produktion Read-only wird.

3️⃣ DockerHub-Rate-Limits: Das selbst verursachte DDoS

„DockerHub-Rate-Limits sind ein großes Henne-Ei-Problem."

Hier ist, was passiert:

• Sie skalieren Nodes.
• Nodes ziehen Images.
• DockerHub drosselt Sie.
• Pods schlagen fehl.
• Der Autoscaler fügt mehr Nodes hinzu.
• Die scheitern auch.

Sie DDoSen versehentlich Ihre eigene Supply Chain.

Ein Ingenieur erwähnte, während eines Node-Pool-Rollouts die eigene interne Container-Registry per DDoS lahmgelegt zu haben.

Das ist die Sache mit Kubernetes:

Es verstärkt Fehler.

Rollouts sind multiplikative Ereignisse.

Wenn Sie noch nicht implementiert haben:

• Private Registry
• Pull-Through Cache
• ECR/ACR/GCR-Mirror
• Harbor
• Image Swapper

Werden Sie es irgendwann auf die harte Tour lernen.

4️⃣ etcd ist klein … bis es das nicht mehr ist

etcd taucht selten als der Bösewicht in Architekturdiagrammen auf.

Aber es ist das Herz.

Wenn es langsam ist:

• Fühlt sich die Control Plane langsam an.
• Kommt es zu Scheduling-Verzögerungen.
• Hängen API-Aufrufe.

Wenn es überlastet ist:

• Stellen Sie aus Snapshots wieder her.
• Beten Sie.

Die meisten Teams überwachen etcd nicht tief, bis nach ihrem ersten Ausfall.

Das ist das Thema hier.

5️⃣ Kapazitätsplanung ist keine Option

Jemand gab beiläufig zu:

Schlechte Kapazitätsplanung auf unserer Seite.

Das ist nicht selten.

Cluster werden für die heutige Skala gebaut.

Sechs Monate später:

• Mehr Namespaces
• Mehr Services
• Mehr Pods
• Mehr IP-Nutzung
• Mehr Control-Plane-Last

Kubernetes versagt nicht laut, wenn es an seine Grenzen kommt.

Es degradiert.

Und Degradation ist schwerer zu diagnostizieren als Explosionen.

6️⃣ Die Registry-Lektion: Alles cachen

Eine Antwort erwähnte, dass Image-Caching zu ECR hinzugefügt wurde, nachdem man sich verbrannt hatte.

Eine andere sagte, die Installation von Harbor habe massiv geholfen.

Das Muster ist klar:

Externe Abhängigkeiten werden im großen Maßstab zu internen Single Points of Failure.

Ihr Cluster mag gesund sein.

Ihre Registry vielleicht nicht.

Und Kubernetes ist es egal, wer schuld ist.

Es meldet einfach „ImagePullBackOff".

7️⃣ IPv4-Annahmen

Es gibt einen Grund, warum jemand sagte:

Wenn Sie einen Cluster deployen und denken „ein /16 wird nicht reichen", dann ja, IPv6.

Die meisten Teams nehmen an:

• /24 reicht
• /22 ist großzügig
• /16 ist gewaltig

Bis:

• Die Pod-pro-Node-Dichte steigt
• Sekundäre ENIs zugewiesen werden
• Warm Pools IPs reservieren
• Sidecars die Pod-Anzahl verdoppeln

Networking ist der Ort, an dem „Cloud-native"-Optimismus auf physische Grenzen trifft.

8️⃣ Der echte Horror: Es ist meist nicht Kubernetes

Hier ist, was auffällt, wenn man das alles liest:

Die Horrorgeschichten handeln nicht von Kubernetes-Bugs.

Sie handeln von:

• Fehlkonfiguration
• Überskalierten Control Planes
• Zu klein dimensionierten Subnetzen
• Registry-Abhängigkeiten
• Blinden Flecken bei der Kapazität

Kubernetes hat größtenteils getan, was ihm gesagt wurde.

Die Menschen haben ihm das Falsche gesagt.

9️⃣ Beobachtbarkeitslücken

Die ursprüngliche Frage fragte nach Beobachtbarkeitslücken.

Fällt Ihnen etwas auf?

Die meisten beschriebenen Ausfälle waren keine Anwendungsprobleme.

Es waren:

• Netzwerkbeschränkungen
• Control-Plane-Kollaps
• Infrastruktur-Engpässe
• Registry-Drosselung

Diese tauchen nicht in Ihrem APM-Dashboard auf.

Sie tauchen auf in:

• etcd-Metriken
• Cloud-Subnetz-Auslastung
• ENI-Zuweisungen
• Image-Pull-Latenz
• API-Server-Sättigung

Wenn Sie nur Pod-CPU und -Speicher beobachten, sind Sie blind.

🔟 Die große Lektion, die niemand mag

Kubernetes ist nicht zerbrechlich.

Es ist mächtig.

Aber Macht multipliziert den Explosionsradius.

Ein kleiner Fehler wird im großen Maßstab zu:

• 60 fehlkonfigurierten API-Servern
• Tausenden erschöpften IPs
• Registry-Kollaps

Das System ist deterministisch.

Die Ergebnisse sind es nicht.

Was geht tatsächlich schief?

Destilliert man den Thread herunter:

1. Control-Plane-Überlastung
2. IP-/Subnetz-Erschöpfung
3. Registry-Engpässe
4. Kapazitäts-Fehleinschätzungen
5. Networking-Annahmen
6. Übermütige Rollouts

Keine YAML-Einrückung.

Keine Container-Abstürze.

Infrastruktur-Mathematik.

Die stille Wahrheit

Kubernetes in der Produktion versagt normalerweise nicht wegen eines exotischen Zero-Day-Exploits oder eines Scheduler-Bugs.

Es versagt, weil:

• Jemand annahm, der Cluster würde nicht so schnell wachsen.
• Jemand die IP-Mathematik unterschätzte.
• Jemand Node-Pools skalierte, ohne Images zu cachen.
• Jemand Maschinen zum falschen Pool hinzufügte.
• Jemand den Worst-Case-Rollout nicht modellierte.

Der Cluster hat sie nicht verraten.

Er hat sie verstärkt.

Und vielleicht ist das der Grund, warum sie ein Kommentator „Horror-Kurzgeschichten für K8s-Leute" nannte.

Denn sobald man einen dieser Vorfälle live erlebt hat …

Sieht man ein einfaches kubectl apply nie wieder auf dieselbe Weise.