„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? Gefragt waren keine Best Practices, keine Theorie und keine Whiteboard-Architektur, sondern echte Ausfälle.

Die Antworten waren nicht poliert, es waren Narben. Zwischen den Zeilen erkennt man ein Muster: Kubernetes versagt selten auf dramatische, filmreife Art, sondern auf zutiefst menschliche. Reden wir also darüber, was wirklich 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.

Unheimlich wird es beim nächsten Detail: Die Workloads liefen weiter. Sie wurden nicht neu geplant, heilten sich nicht selbst und skalierten nicht, bedienten aber weiter Traffic in ihrem letzten bekannten Zustand.

Die meisten Leute verstehen das erst, wenn 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 irgendwann nicht mehr tut.

Für die Wiederherstellung musste etcd von Hand aus seinem eigenen Datenverzeichnis zurückgeholt werden, danach mussten die Mitglieder erneut beitreten. Ein lustiger Dienstag war das nicht.

2. Erschöpfte IP-Adressen, der stille Killer

„Subnetzgröße für k8s zu klein angelegt." In diesem einen Satz stecken Wochen voller Schmerz.

Der Cluster läuft aus IPs, Pods lassen sich nicht mehr planen, Nodes skalieren, können aber keine ENIs anhängen, Firewall-Regeln müssen neu geschrieben werden, und das Networking-Team wird in Meetings gezogen.

Ein anderer Kommentar sagte unverblümt:

Kein IPv6 zu nutzen, ist der erste Fehler.

Ob das Sarkasmus war, weiß man nicht, aber der Schmerz dahinter ist echt. Jemand anders erwähnte, dass das Deaktivieren der Warm-ENI-Zuweisung in EKS Tausende von IPs freigab. So etwas lernt man erst, wenn man mitten im Incident zusieht, wie Nodes beim Skalieren scheitern.

IP-Mathematik ist nicht sexy, bis die Produktion read-only wird.

3. DockerHub-Rate-Limits als selbst verursachtes DDoS

„DockerHub-Rate-Limits sind ein großes Henne-Ei-Problem." Der Ablauf ist immer derselbe:

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

Sie DDoSen also versehentlich Ihre eigene Supply Chain. Ein Ingenieur erzählte, er habe bei einem Node-Pool-Rollout die interne Container-Registry selbst lahmgelegt.

Das ist die Sache mit Kubernetes: Es verstärkt Fehler, weil Rollouts multiplikative Ereignisse sind. Wer noch keine private Registry, keinen Pull-Through Cache, keinen Mirror in ECR, ACR oder GCR, kein Harbor und keinen Image Swapper hat, lernt das irgendwann auf die harte Tour.

4. etcd ist klein, bis es das nicht mehr ist

In Architekturdiagrammen taucht etcd selten als Bösewicht auf, obwohl es das Herz des Clusters ist.

Ist es langsam, fühlt sich die Control Plane langsam an, Scheduling verzögert sich, und API-Aufrufe hängen. Ist es überlastet, stellen Sie aus Snapshots wieder her und beten.

Die meisten Teams überwachen etcd erst nach ihrem ersten Ausfall wirklich genau, und darum geht es hier.

5. Kapazitätsplanung ist keine Option

Jemand gab beiläufig zu:

Schlechte Kapazitätsplanung auf unserer Seite.

Selten ist das nicht. Cluster werden für die Skala von heute gebaut, und sechs Monate später gibt es mehr Namespaces, mehr Services, mehr Pods, mehr IP-Nutzung und mehr Last auf der Control Plane.

An seinen Grenzen versagt Kubernetes nicht laut, es degradiert. Und Degradation ist schwerer zu diagnostizieren als eine Explosion.

6. Die Registry-Lektion: alles cachen

Eine Antwort erwähnte, dass Image-Caching in ECR erst dazukam, nachdem man sich verbrannt hatte. Eine andere berichtete, 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 schrieb:

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

Die meisten Teams nehmen an, ein /24 reiche, ein /22 sei großzügig und ein /16 gewaltig. Dann steigt die Pod-Dichte pro Node, sekundäre ENIs werden zugewiesen, Warm Pools reservieren IPs, und Sidecars verdoppeln die Pod-Anzahl.

Im Networking trifft der Optimismus des Cloud-native-Ansatzes auf physische Grenzen.

8. Der echte Horror: Es ist meist nicht Kubernetes

Beim Lesen all dieser Geschichten fällt eines auf: Sie handeln nicht von Kubernetes-Bugs, sondern von Fehlkonfiguration, überskalierten Control Planes, zu klein dimensionierten Subnetzen, Registry-Abhängigkeiten und blinden Flecken bei der Kapazität.

Kubernetes hat größtenteils getan, was ihm gesagt wurde. Nur haben die Menschen ihm das Falsche gesagt.

9. Lücken in der Beobachtbarkeit

Die ursprüngliche Frage zielte auch auf Lücken in der Beobachtbarkeit, und die beschriebenen Ausfälle waren fast nie Anwendungsprobleme. Es waren Netzwerkbeschränkungen, ein Kollaps der Control Plane, Infrastruktur-Engpässe und Drosselung durch die Registry.

Im APM-Dashboard sieht man davon nichts. Sichtbar wird es in etcd-Metriken, in der Auslastung der Cloud-Subnetze, bei ENI-Zuweisungen, in der Latenz von Image-Pulls und in der Sättigung des API-Servers. Wer nur CPU und Speicher der Pods beobachtet, ist blind.

10. Die große Lektion, die niemand mag

Nach all diesen Geschichten könnte man Kubernetes für zerbrechlich halten. Es ist vor allem mächtig, und Macht multipliziert den Explosionsradius. Aus einem kleinen Fehler werden im großen Maßstab 60 fehlkonfigurierte API-Server, Tausende erschöpfte IPs oder ein Registry-Kollaps. Das System ist deterministisch, die Ergebnisse sind es nicht.

Was geht tatsächlich schief?

Destilliert man den Thread herunter, bleiben sechs Punkte:

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

Das alles ist Infrastruktur-Mathematik und hat mit YAML-Einrückung oder abgestürzten Containern nichts zu tun.

Die stille Wahrheit

In der Produktion versagt Kubernetes normalerweise nicht wegen eines exotischen Zero-Day-Exploits oder eines Scheduler-Bugs. Es versagt, weil jemand annahm, der Cluster werde nicht so schnell wachsen, weil jemand die IP-Mathematik unterschätzte, weil jemand Node-Pools skalierte, ohne Images zu cachen, weil jemand Maschinen zum falschen Pool hinzufügte oder weil niemand den schlimmsten Fall eines Rollouts modelliert hat.

Verraten hat der Cluster diese Teams nicht, er hat sie verstärkt. Vielleicht nannte ein Kommentator die Sammlung deshalb „Horror-Kurzgeschichten für K8s-Leute". Wer einen dieser Vorfälle einmal live erlebt hat, sieht ein einfaches kubectl apply nie wieder mit denselben Augen.