Echte Geschichten von Kubernetes-Admins, die die Produktion stabil halten
Ein perfekt laufender Kubernetes-Cluster hat etwas seltsam Schönes an sich. Die Art, wie Ihre Apps im Einklang summen, Ihre CI/CD-Pipelines wie ein Fluss dahinfließen und jeder Pod seinen Platz in der Welt kennt. Aber auf jeden Moment des Zen folgt ein Sturm, der nur darauf wartet loszubrechen. Fragen Sie irgendeinen Kubernetes-Admin, und er wird Ihnen die Wahrheit sagen: k8s zu betreiben ist kein Job – es ist eine Überlebenssportart.
Von außen mag Kubernetes wie eine Utopie aus Automatisierung und Skalierbarkeit wirken. Aber steigen Sie ins Cockpit, und Sie finden ein Labyrinth aus YAML, kryptischen Fehlerprotokollen und genug mit Panzertape geflickten Lösungen, um einen Klempner erröten zu lassen. Und dahinter halten die Leute, die den Laden am Laufen halten – Admins, Ingenieure und SREs – alles mit Koffein, Panzertape und einer ordentlichen Portion innerem Schreien zusammen.
Dieser Artikel ist für sie.
„Einfach" – bis man es tatsächlich betreiben muss
Machen wir das gleich klar: Kubernetes ist nicht schwer, weil es schlecht ist. Es ist schwer, weil es Ihnen erlaubt, praktisch alles zu tun. Das ist Segen und Fluch zugleich. Wollen Sie einen Single-Node-Cluster auf einem Raspberry Pi im Abstellraum betreiben? Kein Problem. Wollen Sie skalieren und Hunderte Microservices über mehrere Clouds hinweg orchestrieren? Nur zu. Wollen Sie die Produktion mit aktiviertem SELinux betreiben, weil Ihr CEO sich für ein Buzzword auf LinkedIn begeistert hat? Nun... da fängt der Ärger an.
Ein Admin schilderte seinen kafkaesken Abstieg ins Chaos: Es begann mit einem MicroK8s-Cluster auf Ubuntu und endete mit Upstream-Kubernetes auf Rocky Linux – alles dank eines CEOs, der entschieden hatte, dass „Enterprise" „ohne Grund komplizierter" bedeutet. Derselbe CEO bestand auf verpflichtendem SELinux, obwohl er es nicht verstand, und erwartete, dass Snap-Pakete auf Rocky wie von Zauberhand funktionieren. Was folgte? Sitzungen um 2 Uhr nachts, um Denial-Logs für Funktionen zu debuggen, die ohnehin niemand nutzte. Ein Zirkus, nur mit mehr Abkürzungen.
Und doch blieb der Cluster trotz all der Schmerzen am Laufen. GitLab, Telefonanlagen, SSO – der gesamte Stack lief über ein Jahr lang ohne einen einzigen Ausrutscher. Aber Uptime bringt einem nicht immer Anerkennung ein. Manchmal reicht es, dass ein einziger Entwickler beschließt, Git zu umgehen und Code stattdessen über eine SMB-Freigabe zu pushen. Ja. Eine Netzwerkfreigabe. Für die Versionskontrolle.
An diesem Punkt betätigte unser Protagonist den Schleudersitz. Der Cluster blieb am Laufen. Er nicht.
Homelabs und Hybris
Man könnte meinen, das Chaos beschränke sich auf große Unternehmen, aber nein. Kubernetes kann selbst im heimischen Keller Verwüstung anrichten. Ein Nutzer brachte es am besten auf den Punkt: „K8s ist ein Geschenk des Himmels, selbst für ein kleines Homelab." Da ist etwas Wahres dran. Ob Sie private Projekte deployen oder produktionsreife Setups bauen – Kubernetes lässt Sie reale Umgebungen nachbilden wie nie zuvor.
Das heißt aber nicht, dass alles glatt läuft. Selbst selbsternannte Profis verheddern sich in Crash-Loop-Backoffs, Meltdowns bei selbstgebauten Controllern oder stellen plötzlich fest, dass die neueste Version ihres Ingress-Controllers sich nicht mit ihrem Lieblings-Operator verträgt.
Und manchmal liegt das Problem gar nicht bei Kubernetes selbst – sondern beim Sammelsurium an Drittanbieter-Apps, die obendrauf mit Panzertape befestigt wurden. Es gibt immer einen neuen glänzenden Operator, ein magisches Observability-Tool oder eine GitOps-Lösung, die Nirvana verspricht. Aber öfter als nicht überschneiden sich diese Tools, kollidieren miteinander oder gehen einfach kaputt. Und dann ist es Ihr Problem.
„Das liegt nicht an K8s, das liegt an Ihrem Anbieter"
Ein weiterer roter Faden durch diese Geschichten: die Komplexität von Vendor-Lock-in. Die Kubernetes-API mag stabil sein, aber die Anbieter sind es ganz sicher nicht. Ob EKS, AKS oder irgendeine „Value-Added"-Distro mit fünf Abstraktionsebenen – diese Frankenstein-Cluster zu unterstützen bedeutet, mit Entscheidungen zu leben, die Sie nicht getroffen haben und nicht beheben können.
Ein Admin merkte an, dass K8s einfach ist... bis der Anbieter anfängt, „Mehrwert hinzuzufügen." Plötzlich wird Ihr sauberer Cluster zu einem verworrenen Knäuel aus proprietären Sidecars, mysteriösen CRDs und Upgrade-Pfaden, die sich anfühlen, als würde man mit verbundenen Augen durch ein Minenfeld navigieren. Und wenn etwas kaputtgeht? Viel Glück beim Finden von Dokumentation. Sie sind auf sich allein gestellt – oder zahlen für das Privileg, den Support fragen zu dürfen, warum ihr Custom-DNS-Controller Arbeitsspeicher frisst, als stünde er auf einer RAM-Diät.
„Wenn es dumm ist und funktioniert…"
Manchmal führt der einzige Ausweg mittendurch. Ein Admin, der versuchte, den External Secrets Operator clusterübergreifend mit Vault zu verbinden, brachte es am besten auf den Punkt: „Es gibt keine Anleitung, keine Dokumentation. Vaults Docs sind Marketing-Geschwafel. ESOs Docs sind kryptisch. AWS bleibt dem Leser als Übung überlassen."
Es brauchte CoreDNS-Rewrites, OIDC-Magie und eine gesunde Portion Trial-and-Error. Aber es hat funktioniert. Und im Kubernetes-Land gilt: Wenn es funktioniert, ist es nicht dumm. Das ist die Regel.
Die tiefere Wahrheit? Die meisten schwierigen Teile bei Kubernetes haben gar nichts mit Kubernetes zu tun. Es ist der menschliche Faktor – die Annahmen, das Ego, die endlosen „das sollte doch einfach sein"-Momente, die sich zu einer wochenlangen Debugging-Session auswachsen.
Sie werden es lieben. Sie werden es hassen. Und morgen nutzen Sie es immer noch.
Kubernetes wird nicht verschwinden. Im Guten wie im Schlechten ist es das Rückgrat moderner Infrastruktur. Und die Leute, die es betreiben? Sie sind diejenigen, die dafür sorgen, dass Ihre Apps, Ihre Dienste und Ihre glänzenden Cloud-native-Träume nicht in sich zusammenstürzen.
Aber übertreiben wir es nicht mit der Romantisierung. Ein Kommentar brachte es perfekt auf den Punkt: „K8s ist ein Geschenk und ein Albtraum." Sie werden darauf schwören und darüber fluchen. Sie werden fließend kubectl sprechen und trotzdem einfache Befehle googeln. Sie werden Helm meistern und sich trotzdem dabei ertappen, wie Sie eine values-Datei anschreien, die sich partout nicht richtig mergen lässt.
Und vielleicht, nur vielleicht, finden Sie nach all den Crash-Loops, den fehlenden Zertifikaten, den unerklärlichen Netzwerkproblemen und den CEOs, die glauben, AWS-Dashboards würden sie zu DevOps-Göttern machen, einen seltsamen Stolz darin, alles am Laufen zu halten.
Denn wenn Kubernetes Sie eines lehrt, dann Resilienz.
Selbst wenn sich um Sie herum alles wie clusterf*cked anfühlt.