Kubernetes im Produktivbetrieb: Wo Plattformentscheidungen still scheitern

Jeder Platform Lead erbt dieselbe Falle: einen funktionierenden Kubernetes-Cluster, den irgendwer, irgendwann, als „fertig" bezeichnet hat. Dann trifft ein Sev-1 um 3 Uhr nachts ein, Telemetrie korreliert nicht, und ein SOC-Analyst fragt, warum der Alert vier Hops gebraucht hat, um anzukommen. Genau diese Lücke zwischen einem grünen Cluster und einer produktionsreifen Plattform ist der Ort, an dem Engineering-Budgets still verschwinden.

Ein neuer Beitrag von Alex Vakulov zeigt auf, wo diese Plattformentscheidungen versagen, sobald echte Workloads darauf landen. Die Diagnose deckt sich mit Mustern, die ich seit fast einem Jahrzehnt in iGaming- und Fintech-Unternehmen beobachte.

Wichtige Details

Kubernetes wird als „kostenlos" beschrieben – und wie Cloud Native Now darlegt, bricht diese Annahme in dem Moment zusammen, in dem man versucht, etwas Produktionsreifes darauf zu betreiben. Eine Standardinstallation liefert grundlegende Orchestrierungs-Primitives. Sie liefert keine Plattform.

Die Liste dessen, was Teams nachrüsten müssen, ist nicht exotisch. Es ist dieselbe Checkliste, mit der jeder Operator am Ende dasteht:

• Netzwerk-Plugins für Service-Konnektivität
• Ingress-Kontrolle für Traffic-Routing
• CI/CD-Integration für Delivery-Pipelines
• Monitoring-, Logging- und Tracing-Systeme
• Authentifizierungs- und Autorisierungsmechanismen

Nichts davon wird kohärent ausgeliefert – auch nicht in Managed-Angeboten. Teams integrieren es, standardisieren es und besitzen es für immer.

Der Artikel rahmt die Wahl als Build versus Buy. Interne Plattformen werden an die Umgebung angepasst. Vendor-Distributionen versprechen schnellere Standardisierung und geringere Day-one-Last. Beide Wege stoßen an dieselben Wände – nur an unterschiedlichen Meilensteinen.

Die Personalrechnung ist der Teil, den die meisten Präsentationen überspringen. Ein kleines Kubernetes-Deployment kann mit einer Handvoll Engineers betrieben werden. Große Umgebungen binden routinemäßig Dutzende von Engineers in Plattformentwicklung und -support. Zwei Engineers können Dutzende von Clustern betreuen, wenn die Automatisierung stark ist – aber Anpassungen kommen zum Stillstand. Ein Team von sechs Engineers kann den Betrieb aufrechterhalten und auf Incidents reagieren, hat aber selten Kapazität, Developer-Workflows zu verbessern.

Auf der Zeitachse gilt: Intern aufgebaute Plattformen brauchen typischerweise ein bis zwei Jahre, um funktionale Reife zu erreichen. Frühe Versionen decken grundlegende Orchestrierung ab. Vendor-Plattformen verschieben diese Kurve nach vorn – viele Funktionen sind von Tag eins an verfügbar, allerdings auf Kosten von Vendor-Abhängigkeit bei Upgrades, Konfigurationsänderungen und Incident-Diagnose.

Und unabhängig vom Ansatz tauchen dieselben Komponenten in jedem Produktions-Cluster auf: Deployment-Controller, Monitoring, Logging- und Tracing-Pipelines, Policy Enforcement und Custom Resource Extensions. Es gibt keine Möglichkeit, sich von dieser versteckten Schicht abzumelden.

Warum das für Engineering-Teams relevant ist

Die Zahl „zwei Engineers für Dutzende von Clustern" ist diejenige, die ich rot einkreisen würde. In einem 10-köpfigen Platform-Team entspricht das rund 20 % des Gehaltsbudgets, das allein dafür aufgewendet wird, das Fundament am Leben zu erhalten – bevor jemand die Developer Experience anfasst. In einer schlankeren Engineering-Organisation mit 30 Personen ist das sechsköpfige Team, das „stabil, aber stagnierend" ist, ein Fünftel des Unternehmens, das auf der Stelle tritt. Das ist kein Tooling-Kostenpunkt. Das sind Opportunitätskosten, gemessen in nicht ausgelieferten Features.

Der Incident-Response-Aspekt wird besonders kritisch in regulierten Branchen. Innerhalb des Clusters erzeugte Alerts durchlaufen mehrere Systeme, bevor sie einen SOC erreichen. Im iGaming, wo Regulierungsbehörden Zeitlinien sekundengenau rekonstruiert haben wollen, ist jede Übersetzungsschicht zwischen Cluster-Events und dem SOC eine Stelle, an der Kontext verloren geht. Bei Post-Mortems von Produktions-Incidents, die ich verfolgt habe, führt die Ursache immer auf dasselbe zurück: Anreicherung variierte über Hops hinweg, und niemand bemerkte es, bis die Zeitlinie schriftlich benötigt wurde.

Der Vendor-Dependency-Trade ist die zweite Mine. Wenn Upgrades und Konfigurationsänderungen von Vendor-Zeitplänen abhängen, gehört der eigene CAB-Kalender einem nicht mehr. Wenn Root-Cause-Analysen Vendor-Beteiligung erfordern, hat die eigene MTTR eine Untergrenze, die man technisch nicht überwinden kann. Für Fintech- und iGaming-Plattformen, die rund um die Uhr mit harten SLAs laufen, ist diese Untergrenze wichtiger als die Marketing-Folie über „schnelleres Day-one-Deployment."

Meine Einschätzung: Das Build-versus-Buy-Framing ist die falsche Achse. Die eigentliche Achse ist, ob das Team die Disziplin hat, konsistente Labels, Service-Identitäten und Environment-Tagging über alle Signale hinweg von Tag eins an durchzusetzen. Teams, die Telemetrie-Hygiene richtig umsetzen, können beide Wege überleben. Teams, die das nicht tun, rekonstruieren Incidents um 4 Uhr morgens von Hand – egal, wer ihnen die Control Plane verkauft hat.

Auswirkungen auf die Branche

Für iGaming-Betreiber trifft die Personalrealität bei Scaling-Events am härtesten. Ein Platform-Team von sechs Personen, das stabil, aber nicht weiterentwickelt ist, kann im selben Quartal keinen neuen Jurisdiktions-Launch, keine neue Payment-Provider-Integration und kein neues Game-Studio-Onboarding verkraften. Irgendetwas bricht – meist die Developer Experience –, und Produktteams beginnen, die Plattform zu umgehen. Der Artikel spricht das direkt an: Wenn Teams regelmäßig außerhalb der Plattform deployen, ist sie als Standard bereits gescheitert. Dieser Satz sollte an der Wand jedes Platform-Teams hängen.

Fintech hat eine schärfere Version desselben Problems. Compliance-Teams erwarten deterministische Audit-Trails. Wenn Telemetrie inkonsistent ist und Logs, Metriken und Traces aufhören, sich zu decken, bricht die Korrelation zusammen und Incidents erfordern manuelle Rekonstruktion. Manuelle Rekonstruktion ist akzeptabel für einen Blog-Post-Mortem. Sie ist nicht akzeptabel für eine Aufsichtsbehörde, die fragt, warum eine Zahlung um 02:14:33 UTC fehlgeschlagen ist. Von Anfang an in OpenTelemetry-konforme Konventionen zu investieren – gemäß der OTel-Spezifikation – ist günstiger als die Nachrüstung nach dem ersten Audit-Befund.

Crypto- und DeFi-Infrastrukturteams sind vom Vendor-Dependency-Problem in besonders schmerzhafter Form betroffen. Chains forken, RPC-Provider ändern ihr Verhalten, und der Cluster muss sich diese Woche anpassen – nicht im nächsten Quartal auf der Vendor-Roadmap. Interne Plattformen gewinnen hier, aber nur, wenn das Team die Kapazität hat, sie tatsächlich weiterzuentwickeln. Andernfalls hat man einen maßgeschneiderten Wartungsaufwand aufgebaut, ohne die Agilität, die ihn gerechtfertigt hätte.

Die unbequeme Erkenntnis: Die meisten mittelgroßen Engineering-Organisationen wählen das Schlechteste aus beiden Welten. Sie kaufen eine Vendor-Distribution, um Personal zu „sparen", besetzen dann ein internes Sechser-Team, um sie mit SOC, ITSM und CI/CD zu integrieren, und zahlen am Ende sowohl für die Lizenz als auch für die Arbeit.

Worauf man achten sollte

Drei Signale zeigen, ob die eigene Kubernetes-Plattform gesund ist oder still verrottet. Man sollte sie quartalsweise beobachten.

Erstens die Bypass-Rate. Zählen Sie die Services, die in den letzten 90 Tagen außerhalb des Golden Path der Plattform deployed wurden. Wenn Produktteams das Onboarding umgehen, weil es tiefes Kubernetes-Security-Wissen oder lange manuelle Konfiguration erfordert, hat die Plattform als Standard bereits versagt. Die Zahl muss nicht null sein, aber sie muss sinken.

Zweitens den Kalender des Platform-Teams. Wenn Platform-Engineers den Großteil ihrer Woche mit Tickets und Incident-Bridges verbringen, wird die Plattform gewartet, nicht weiterentwickelt. Das ist die Vorbedingung dafür, dass sich die ein-bis-zwei-Jahre Reifekurve auf drei oder vier Jahre ausdehnt.

Drittens Vendor-abhängige Incidents. Verfolgen Sie, wie viele Sev-1- und Sev-2-Incidents zur Diagnose Vendor-Beteiligung erfordert haben. Wenn diese Zahl nicht trivial ist, ist die eigene MTTR teilweise ausgelagert, und die On-call-Rotation ist eine Fiktion.

Referenzarchitekturen von Google Cloud sind nützliche Orientierungspunkte, setzen aber ein Maß an Plattformreife voraus, das die meisten Teams noch nicht erreicht haben. Kalibrieren Sie zuerst anhand der eigenen Bypass-Rate.

Wichtigste Erkenntnisse

• „Kostenloses" Kubernetes sind Orchestrierungs-Primitives. Die Plattform drumherum – Networking, Ingress, CI/CD, Observability, Authn/Authz – ist das eigentliche Kostenzentrum.
• Personalrealität: Zwei Engineers können Dutzende von Clustern betreiben, aber nicht anpassen; sechs können den Betrieb stabil halten, können aber die Developer Experience nicht weiterentwickeln. Headcount entsprechend planen.
• Interne Plattformen brauchen ein bis zwei Jahre zur Reife. Vendor-Plattformen verlagern Funktionalität nach vorne und Abhängigkeit bei Upgrade- und Incident-Zeitplänen nach hinten.
• Konsistente Labels, Service-Identitäten und Environment-Tagging über Logs, Metriken und Traces hinweg von Tag eins sind nicht verhandelbar. Telemetrie-Hygiene nachzurüsten ist schmerzhaft und für Auditoren sichtbar.
• Wenn Produktteams routinemäßig außerhalb der Plattform deployen, hat die Plattform ihr Mandat bereits verloren. Bypass-Rate messen, bevor man irgendetwas anderes misst.