Dem Kubernetes-Typen steht ein sehr schlechtes Jahr bevor

6. August 2026 SupportTrenches Geschichten & Fallstudien 8 Minuten

Wenn Ihre gesamte Karriere in einer YAML-Datei steckt, sollten Sie sich nicht wundern, wenn sie plötzlich automatisch generiert wird

Vor einiger Zeit habe ich irgendwo beiläufig angemerkt, dass Kubernetes für einen bestimmten Anwendungsfall überdimensioniert sei. Nichts Radikales. Nur der Hinweis, dass eine einzelne Anwendung mit ein paar tausend Nutzern vermutlich keine Container-Orchestrierungsplattform braucht, die einst gebaut wurde, um die gesamte Produktivumgebung von Google zu steuern.

Es dauerte keine fünf Minuten, da rückte der Klerus an.

"Ach komm schon, Alter. Pipe dein Jsonnet einfach durch den Kluster Konfig Kompiler, deploye den Sidecar-Injector über einen Mutating Webhook, häng den ChaosMonkeyMesh-Operator für die Resilienz-Tests dran, sync deinen GitOps-State über FluxKapacitor und tail die Logs aus dem Kloud-Native Kombined Kockpit. Das sind buchstäblich fünf Schritte. Warum hast du so Angst vor YAML?"

Ich habe keine Angst vor YAML. Ich habe Angst vor Menschen, die das Auswendiglernen einer Toolchain mit dem Verstehen von Infrastruktur verwechseln.

Denn eines muss man Kubernetes lassen: Es ist wirklich gute Technologie. Google hat es der Welt geschenkt, die CNCF hat es großgezogen, und es hat ein echtes Problem gelöst - die Orchestrierung von Containern in großem Maßstab über verteilte Systeme hinweg. Wenn Sie Hunderte Microservices in mehreren Regionen betreiben, mit komplexem Networking, Auto-Scaling-Anforderungen und Deployments ohne Downtime, dann ist Kubernetes vermutlich genau richtig.

Aber irgendwo auf diesem Weg wurde aus "das richtige Werkzeug für bestimmte Aufgaben" das "einzige Werkzeug für jede Aufgabe". Und um genau dieses Missverständnis herum entstand eine ganze berufliche Subkultur.

Sie kennen diesen Typus. In der LinkedIn-Überschrift steht "Kubernetes-Experte". Der Lebenslauf ist eine vertikale Stapelei von CNCF-Logos. Die Karriere beruht nicht auf dem Verständnis verteilter Systeme, sondern auf dem Wissen, welche Flags man kubectl mitgibt und welches Helm Chart man installiert, wenn es seltsam wird. Diese Leute entwerfen keine Lösungen. Sie montieren sie aus fertigen Bausteinen und Konfigurationsdateien - und beschreiben den Montagevorgang anschließend in einer Sprache, die so undurchdringlich ist, dass sie als sozialer Filter taugt.

Das ist keine technische Leistung. Das ist IKEA mit steilerer Lernkurve.

Das Kubernetes-Ökosystem folgt einem Muster, das jedem bekannt vorkommen sollte, der schon einmal zugesehen hat, wie eine Technologie zu ihrer eigenen Industrie wird. Es geht so:

1. Ein Werkzeug löst ein schwieriges Problem elegant.
2. Die Leute setzen es für Probleme ein, für die es nie gedacht war.
3. Aus dieser Fehlpassung entsteht Reibung.
4. Neue Werkzeuge entstehen, um diese Reibung zu verwalten.
5. Diese Werkzeuge erzeugen ihre eigene Reibung.
6. Weiter so, bis Sie 347 CNCF-Projekte und einen eigenen Konferenzzirkus haben.

Das ist Gall's Law, rückwärts gefahren. Funktionierende komplexe Systeme entstehen aus funktionierenden einfachen - doch das Kubernetes-Ökosystem schraubt Komplexität auf Komplexität und nennt das Reife. Am Ende steht kein funktionierendes komplexes System. Am Ende steht eine Rube-Goldberg-Maschine (ein Apparat, der in 47 Schritten erledigt, wofür einer gereicht hätte), die zufällig HTTP ausliefert.

Ich habe einmal erlebt, wie ein Team drei Wochen brauchte, um ein Kubernetes-Cluster aufzusetzen - komplett mit Istio Service Mesh, Prometheus-Monitoring, Grafana-Dashboards, ArgoCD für GitOps und einem selbstgeschriebenen Admission Controller -, nur um eine Django-Anwendung auszurollen, die vorher auf einer einzelnen VM mit einer systemd-Service-Datei problemlos lief. Das alte Setup kannte genau eine Abhängigkeit: Linux. Das neue hatte einen Abhängigkeitsgraphen, der aussah wie die Beweismittelpinnwand eines Verschwörungstheoretikers - komplett mit roten Wollfäden.

Als ich fragte, welches reale Problem Kubernetes bei ihnen denn nun konkret gelöst hatte, wurde es lange still. Dann kam: "Naja, wir müssen halt skalierfähig sein."

Die Anwendung hatte 200 Nutzer. Allesamt intern.

Und genau hier wird es existenziell für unseren Kubernetes-Typen.

Alles, was an Kubernetes wehtut - die YAML-Flut, die Konfigurationskomplexität, die Fehlersuche in Network Policies, die CRD-Definitionen, die Helm-Chart-Templates -, ist exakt die Art strukturierter, schematischer, vorzüglich dokumentierter Arbeit, die KI peinlich gut beherrscht.

Bitten Sie ein LLM, ein Kubernetes-Deployment-Manifest zu erzeugen - mit Health Checks, Resource Limits, einem Horizontal Pod Autoscaler und einer Ingress-Resource mit TLS-Terminierung. Sie bekommen sauberes, funktionierendes YAML in ungefähr vier Sekunden. Ein Helm Chart mit parametrisierten Werten für drei Umgebungen? Erledigt. Fehlersuche, warum Ihr Pod im CrashLoopBackOff festhängt? Das Modell führt Sie schneller durch die Diagnoseschritte, als die meisten Menschen "kubectl describe pod" tippen können.

Der Kubernetes-Typ hat Jahre damit verbracht, Wissen anzuhäufen, das sich heute nahezu kostenlos in Serie fertigen lässt.

Das ist die brutale Arithmetik dessen, was passiert, wenn die eigene Qualifikation aus Konfiguration statt aus Verständnis besteht. Zu wissen, wie man Dinge verdrahtet, ist nur so lange wertvoll, wie die Verdrahtung schwierig ist. In dem Moment, in dem eine Maschine diese Verdrahtung übernimmt - schneller, konsistenter und ohne erst die Syntax für ein PodDisruptionBudget zu googeln -, verdunstet Ihr Wertversprechen.

Wer ist sicher? Die Menschen, die das Warum verstehen. Warum diese Architektur und nicht jene. Warum diese Kompromisse tragbar sind und andere nicht. Warum Kubernetes hier die richtige Wahl ist und dort eine furchtbare. Warum das Netzwerkmodell so funktioniert, wie es funktioniert - und nicht nur, welche Annotation man anhängen muss, damit der Load Balancer glücklich ist.

Dieses Verständnis wohnt nicht in YAML-Dateien. Es wohnt in der Fähigkeit, Systeme aus ersten Prinzipien heraus zu durchdenken - ein Problem anzusehen und zu fragen: "Was braucht das hier eigentlich?", bevor man zu dem Werkzeug greift, das man zufällig am besten kennt.

Es gibt ein Konzept, zu dem ich immer wieder zurückkehre: den Idioten-Index. Man nimmt die Kosten des fertigen Ergebnisses und teilt sie durch die Kosten der Inputs, die wirklich zählen. Ist das Verhältnis gigantisch, haben Sie kein Problem mit teuren Rohstoffen - Sie haben einen kaputten Prozess.

Übertragen wir das auf die Kubernetes-Beratung. Der Rohinput - das eigentliche technische Nachdenken über Architektur, Fehlerfälle, Kapazitätsplanung und Sicherheitsgrenzen - kostet eine erfahrene Kraft vielleicht ein paar Stunden. Das fertige Ergebnis - das ausgerollte, konfigurierte, überwachte Cluster mit dem ganzen zugehörigen Werkzeugkasten - verschlingt Wochen voller YAML-Gerangel, Plugin-Installationen, Fehlersuche und Konfigurationsmanagement.

Diese Lücke? Genau da wohnt die Kubernetes-Industrie. Und KI ist dabei, sie zum Einsturz zu bringen.

Nicht das architektonische Denken. Nicht das Gespräch "sollten wir Kubernetes überhaupt einsetzen?". Nicht das Verständnis der Grundlagen verteilter Systeme. All das bleibt zutiefst menschlich, zutiefst kontextabhängig und zutiefst wertvoll.

Aber das YAML? Die Helm Charts? Die CRDs von der Stange? Der Workflow "installieren Sie einfach diesen Operator und konfigurieren Sie diese siebzehn Umgebungsvariablen"?

Diese Arbeit ist bereits tot. Sie weiß es nur noch nicht.

Das Aufschlussreichste an der Kubernetes-Verteidigungsarmee sind nicht ihre technischen Argumente. Es ist ihre emotionale Investition. Kritisieren Sie Kubernetes, und Sie bekommen nicht zu hören: "Hier ist ein Anwendungsfall, in dem es die Alternative an dieser Kennzahl schlägt." Stattdessen gibt es Komplexitätstheater - man ertränkt Sie in Tool-Namen und Abkürzungen, um zu signalisieren, dass es Ihnen schlicht an der nötigen Reife fehlt, das Ökosystem zu würdigen.

Das ist ein Abwehrmechanismus, keine technische Position. Denn tief im Inneren ahnt der Kubernetes-Typ, dass sein Burggraben nicht aus tiefem Verständnis besteht - sondern aus angehäufter Komplexität. Und angehäufte Komplexität ist genau die Sorte Burggraben, die KI über Nacht zuschüttet.

Die Menschen, die ich durch jeden Technologiewechsel erfolgreich habe kommen sehen, haben eines gemeinsam: Sie identifizieren sich mit dem Problem, das sie lösen - nicht mit dem Werkzeug, das sie benutzen. Sie waren der "mach es zuverlässig"-Mensch oder der "mach es skalierbar"-Mensch, nicht der "Kubernetes-Mensch" oder der "Terraform-Mensch". Als sich die Werkzeuge änderten, änderten sie sich mit - denn das Problem interessierte sich nicht für die Toolchain.

Der Kubernetes-Typ hat sich mit der Toolchain identifiziert. Und genau diese Toolchain wurde gerade zur Commodity.

Nichts davon heißt, dass Kubernetes verschwinden wird. Wird es nicht. Es ist tief in der modernen Infrastruktur verankert und erledigt seine Kernaufgabe gut. Aber das Ökosystem aus vermeidbarer Komplexität drumherum - die menschliche Middleware aus Konfigurations-Dompteuren und YAML-Flüsterern - wird schon bald sehr viel dünner werden.

Wenn Sie das hier lesen und Ihre Karriere konkret auf Kubernetes-Expertise gebaut ist: Das ist keine Todesanzeige. Es ist eine Wettervorhersage. Sie haben noch Zeit. Aber der richtige Zug ist nicht, jetzt erst recht das nächste CNCF-Tool zu lernen. Der richtige Zug ist, tiefer zu gehen - in Netzwerk-Grundlagen, die Theorie verteilter Systeme, Sicherheitsarchitektur, Kapazitätsplanung, Kostenoptimierung. All das, was Urteilsvermögen verlangt und nicht nur Syntax.

Denn wenn Sie das nächste Mal jemand fragt: "Warum haben Sie so Angst vor YAML?" - könnte die ehrliche Antwort lauten: "Habe ich nicht. Die Maschine, die gerade Ihren Job übernommen hat, übrigens auch nicht."

👉 Wenn Ihre berufliche Identität ein Tool-Name ist, hat Ihre Karriere einen Single Point of Failure. Kubernetes braucht keine Verteidiger. Es braucht Menschen, die verstehen, wann man es nicht einsetzen sollte.

👉 KI beseitigt keine Infrastrukturarbeit - sie beseitigt Infrastruktur-Beschäftigungstherapie. Und genau in der Lücke zwischen beiden verstecken sich derzeit sehr viele Karrieren.

👉 Komplexität ist keine Tiefe. Zwanzig Werkzeuge einen Zentimeter tief zu kennen, ist nicht dasselbe wie eine Domäne zwanzig Zentimeter tief zu kennen. Das Erste lässt sich automatisieren. Das Zweite nicht.

Die sicherste Karriere in der Tech-Branche hieß nie "die Person, die Tool X kennt". Sie hieß immer "die Person, die weiß, wann Tool X die falsche Antwort ist".

👇 Was ist Ihr Lieblingsbeispiel für eine Technologie, um die herum eine ganze Industrie unnötiger Komplexität gewachsen ist? Und durften Sie sie jemals eigenhändig wieder ausreißen?

Dieser Artikel ist auch auf English verfügbar.

AIJobsKarriereKILernenTechnologieZukunft