Was mir Bewerbungsgespräche über Kubernetes beigebracht haben

• Kubernetes wird selbst in kleinen Unternehmen weniger wegen technischer Skalierbarkeit eingesetzt, sondern als Standard, um einheitliche Deployments und organisatorische Betriebsprobleme zu lösen
• In meinem jüngsten Bewerbungsprozess nutzten alle Unternehmen, mit denen ich gesprochen habe, Kubernetes; das unterscheidet sich von der früheren Koexistenz von VMs, serverless und K8s vor fünf Jahren
• Die Hauptgründe, die CTOs nannten, waren, Services auf dieselbe Weise zu deployen, Betriebswissen in YAML und Helm-Charts zu hinterlegen und Änderungen per GitOps nachverfolgbar zu machen
• Kleine Unternehmen nehmen die Komplexität von Kubernetes eher wegen der organisatorischen Vorteile in Kauf als wegen fortgeschrittener Funktionen wie HPA, Pod Disruption Budget oder Node Affinity
• Für junge Unternehmen ist es oft besser, zunächst ohne Kubernetes zu starten und sich auf das Produkt zu konzentrieren; der Bedarf steigt, sobald der CTO nicht mehr allein für das Engineering zuständig ist

---

Veränderungen, die sich bei meiner jüngsten Jobsuche gezeigt haben

• Bei meiner jüngsten Jobsuche habe ich Stellenanzeigen gelesen, Interviews geführt und mit rund einem Dutzend Engineering-Teams gesprochen; alle Unternehmen, mit denen ich sprach, nutzten Kubernetes
• Bei meiner Jobsuche vor fünf Jahren gab es noch nebeneinander Gruppen, die Kubernetes eher selten nutzten, Gruppen mit systemd auf VM/VPS/EC2 und serverless-Gruppen mit Lambda und Cloud Run
• Mein derzeitiger Arbeitsplatz hat Probleme in Big-Tech-Größe, bei denen Kubernetes eindeutig passt, aber es hat mich überrascht, dass selbst Startups mit 10 Mitarbeitenden und nur zwei Services Kubernetes einsetzen
• Die Unternehmen, mit denen ich sprach, betrieben weder Microservices noch Umgebungen nahe sehr hoher Skalierung und hatten kein großes Interesse an den technischen Aspekten von Kubernetes

Gründe für die Einführung von Kubernetes und Entscheidungskriterien

• Warum Kubernetes eingesetzt wird

  • Der erste Grund war Uniformität: Wenn alle Services auf dieselbe Weise deployt werden, verschwindet die Situation, dass nur ein bestimmter Service an alte bash-Skripte auf Bare-VMs oder an Docker Compose gebunden ist
  • Der zweite Grund war teilbares und einstellbares Wissen: Weil Kubernetes wie eine gemeinsame Sprache verwendet wird, kann man schon durch Helm-Charts und Kube-Konfigurationen die Architektur schnell erfassen
  • Wenn Wissen nicht in den Köpfen einzelner Menschen, sondern in YAML verbleibt, sinkt die Wahrscheinlichkeit, dass Nachfolger nach dem Weggang einer Person wochenlang herausfinden müssen, wie etwas ausgeführt wird
  • Die On-Call-SREs in meinem aktuellen Unternehmen können selbst ihnen unbekannte Services betreiben, weil die Kubernetes-Muster teamübergreifend gleich sind
  • Dieser Vorteil gilt allerdings nur, wenn die Konfigurationen nicht übermäßig speziell sind
  • Der dritte Grund war Nachverfolgbarkeit: Statt direkt kubectl apply -f auf dem Cluster auszuführen, werden Helm-Charts in git abgelegt und nach MR-Freigabe über FluxCD oder ArgoCD ausgerollt, wodurch eine Änderungshistorie entsteht
  • Dieser Ablauf hilft der Compliance fast ohne Zusatzkosten, weil GitOps und Kubernetes natürlich gut zusammenpassen
  • Mein derzeitiges Unternehmen besteht ISO-Zertifizierungen mit diesem Vorgehen problemlos

• Mein Fazit

  • Die Entscheidungen der CTOs waren keine törichten Entscheidungen, sondern eine Art, reale Probleme zu lösen
  • Kubernetes wirkte wie eine technische Antwort auf technische Probleme, doch viele CTOs interessierten sich stärker als erwartet für die nichttechnischen Vorteile
  • Die technischen Probleme kleiner Unternehmen sind meist nicht so groß, dass Kubernetes zwingend nötig wäre, und ihre Manifeste enthalten wahrscheinlich weder topologySpreadConstraints, HPA, Pod Disruption Budget noch Regeln für Node Affinity
  • Sie behalten damit ähnlich viele Nodes wie zuvor mit VMs, akzeptieren aber die Betriebskosten komplexer Software wegen der organisatorischen Vorteile

• Warum der Wandel erst kürzlich stattgefunden hat

  • Vor fünf Jahren waren VM plus systemd, serverless und Kubernetes alles noch echte Optionen; heute ist die Kombination aus VM und systemd in Stellenanzeigen fast verschwunden, serverless bleibt eine Nische und Kubernetes hat gewonnen
  • Warum der Wandel genau zu diesem Zeitpunkt passiert ist, ist nicht völlig klar
  • Mögliche Gründe sind, dass gemanagtes Kubernetes wie EKS, GKE und AKS ausgereift ist und inzwischen genügend Menschen Kubernetes gelernt haben, sodass es schwieriger geworden ist, für andere Ansätze Personal zu finden
  • Helm hat außerdem die Möglichkeit realistisch gemacht, die von anderen erstellten Charts unverändert zu nutzen

• Wann ich Kubernetes einsetzen würde

  • Mein persönliches Kriterium ist der Moment, in dem der CTO nicht mehr der einzige Engineer ist
  • Sobald der zweite Engineer dazukommt, muss jemand deployen können, der den Server nicht selbst aufgesetzt hat, und es braucht angemessene Zugriffskontrolle statt SSH-Schlüssel für alles
  • Irgendwann verlässt immer jemand das Unternehmen, und mit dieser Person kann auch ihr Betriebswissen verschwinden
  • Ab diesem Punkt muss Wissen eher im System als in einzelnen Menschen verbleiben
  • Davor ist Cluster-Debugging tatsächlich schwierig, und man kann Energie, die ins Produkt fließen sollte, in Infrastruktur verlieren
  • Statt zwei Stunden lang kurz vor einem wichtigen Kundengespräch die Ursache eines Pods in CrashLoopBackOff zu suchen, kann es eine schnellere und verständlichere Notfallmaßnahme sein, einen Fehler auf einem VPS hastig mit git pull zu beheben

[GN⁺]

Lobste.rs-Meinungen

• In Europa ist der Grund ziemlich klar. CTOs glauben, dass man, wenn man auf K8s setzt, den Anbieter für Managed K8s innerhalb weniger Wochen wechseln kann
  Das heißt nicht, dass es stimmt, aber sie glauben tatsächlich daran. Sie denken auch, dass PR-Umgebungen dadurch einfacher werden
  Aber der Kernpunkt ist der Anbieterwechsel. Es wird erwartet, dass es in den kommenden Jahren Verbote gegen die Nutzung von Anbietern mit US-Bezug geben wird, besonders im Zusammenhang mit DSGVO, Finanzsystemen usw. Deshalb hat man sich gegen dieses Risiko abgesichert

• Es wirkt wie ein Beleg dafür, dass die Tech-Branche unabhängig von der Unternehmensgröße völlig die Richtung verloren hat. Der Stack ist immer einheitlicher und komplexer geworden, und dadurch ist es letztlich schwerer geworden, Produkte und Services zu finden, die man nutzen kann, ohne ständig die Zähne zusammenzubeißen

  • Die unteren Schichten sind so fehleranfällig und komplex, dass man zum Überleben am Ende gezwungen ist, so etwas wie Kubernetes zu bauen. Wenn man verhindern will, dass der Stack immer höher wird, muss man die unteren Ebenen verbessern
    Wir brauchen deutlich bessere Grundbausteine des Betriebssystems. Container waren zum Beispiel lange ein löchriger Mix verschiedener Isolationsfunktionen des Kernels ohne konsistentes Design
    Die Container-Isolation ist inzwischen viel besser, aber das Ergebnis stammt eher aus einem Whac-A-Mole-artigen Flickwerk als aus einem von Anfang an auf Sicherheit und Korrektheit ausgelegten Design. Solange der Kernel seine gewaltige technische Schuld nicht abbaut oder jemand einen Kernel baut, auf den es sich umzusteigen lohnt, wird man weiter Dinge daraufstapeln

• Jedes hinreichend komplexe Deployment-Tool enthält am Ende eine provisorisch zusammengebaute, informell definierte, fehleranfällige und langsame halbe Kubernetes-Implementierung

  • „Halb“ trifft es. Es ist nur so, dass diese Hälfte ausgerechnet die nötige Hälfte ist
    Ich könnte lange darüber reden, wie man 2009 ein SaaS-E-Commerce-Unternehmen mit einem Wert von 1 Milliarde Dollar aufgebaut hat oder wie die Online-Backends riesiger AAA-Multiplayer-Spiele funktionierten; diese Systeme waren einem Kubernetes-Ansatz eindeutig näher als einem Single-Machine-Deployment
    Sie waren aber schneller und auf genau die Weise meinungsstark, die die Organisation brauchte, statt auf eine Weise, die mit den Produktanforderungen kollidierte
    Die „Fehleranfälligkeit“ von Kubernetes entsteht oft nicht im Kernsystem selbst, sondern in den vielen Schnittstellenschichten, die wir daraufsetzen, damit es sich so verhält, wie wir es wollen
  • Das trifft auf Erlang zu, nicht auf Kubernetes. Für Kubernetes ergibt das überhaupt keinen Sinn

• Das Problem ist, dass die meisten Organisationen K8s halbherzig einführen, sogar ein DevOps-Team dafür aufbauen und am Ende doch den Softwareentwicklern alles rund um K8s aufbürden: Schreiben, Deployen, Debuggen und Betrieb
  Ein gutes DevOps-Team sollte intern eine Heroku-ähnliche Experience bereitstellen. Man sollte die benötigten Ressourcen definieren, in main mergen und dann wird deployed, statt sich in einem miserablen GitOps-/DevOps-Dashboard zu verirren und herauszufinden zu versuchen, was schiefgelaufen ist
  Heroku war der Höhepunkt der Developer Experience, und ich finde, wir haben das nach K8s verloren

  • Abgesehen davon, dass man sieht, wie Pods auf Nodes laufen, weiß ich nicht, worin der große Unterschied zwischen der Nutzungserfahrung von Heroku und Kubernetes besteht
    Klar, Heroku bietet eine stärker integrierte Erfahrung, etwa bei der Datenbankanbindung oder beim Deployment per git push, aber eine maßgeschneiderte Hülle um Kubernetes herum ist nicht besonders gut. Am Ende reicht man doch nur alle Parameter unverändert durch

• Die Einführung neuer Technologien in der Branche folgt schon immer dem Prinzip „wie Konfektionsware einkaufen und entlassen, wenn man sie nicht mehr braucht“. Das ist nur das neueste Beispiel dafür

• Der Satz „Wissen sollte im System stecken, nicht in Menschen“ formuliert etwas, das ich nur vage im Kopf hatte, sehr treffend
  Diese Art von Formalisierung ist nur möglich, wenn die Varianz eines Prozesses sinkt. Menschen machen es erst selbst, dann dokumentieren sie den Prozess, gießen ihn in Skripte und automatisieren ihn erst danach
  In beliebten Tools oder Ökosystemen mit verbreiteten Workflows bekommt man den Großteil dieser Schritte fast gratis

• Ich mache nicht viel DevOps, und bei mir läuft im Moment alles gut nur mit systemd und gelegentlich eingesetzten podman-Containern. Ich arbeite im IoT-/AgTech-Bereich
  In diesem Artikel stecken die typischen „Behauptungen“, die man oft von nichttechnischen Führungskräften hört. Ungefähr so: „Die dort drüben machen doch auch LoRa, oder? Dann passt das doch? Dann können wir morgen launchen, oder?“
  Dahinter steht der Glaube, dass Uneinheitlichkeit das einzige Hindernis für Erfolg sei. Wenn zwei Systeme Fiber oder Modbus verwenden oder „eine API haben“, dann könne man sie sofort verbinden und eine tolle Erfahrung schaffen, bei der „1 + 1 größer ist als die Summe“
  Aber nur weil sich zwei Softwaresysteme auf einen Interoperabilitätsstandard auf niedriger Ebene geeinigt haben, verschwindet nicht die eigentliche Arbeit, zu entscheiden, wie man die leicht parsbaren Daten interpretiert und sinnvoll nutzt
  Nur weil zwei Menschen dieselbe Sprache sprechen, heißt das nicht, dass es nichts mehr zu tun gibt. Eine gemeinsame Sprache lässt auch nicht die Entscheidungen verschwinden, die Teile des Teams damals unter den ihnen bekannten Bedingungen getroffen haben, während sie diese Tools nutzten
  In der frühen Wissenschafts- und Ingenieurwelt war Fortran einmal eine gemeinsame Sprache, aber das hat weder verhindert, dass man über die Arbeit von Kollegen komplett verwirrt war, noch dass man sie neu schreiben musste
  Ich habe nichts gegen den Wert von K8s oder dagegen, dass es heute als „Standard“ gilt. Aber ich kann schwer der Behauptung zustimmen, dass damit irgendeine Art von Programmierproblem verschwindet. Das Gesetz der Erhaltung der Hässlichkeit gilt weiterhin

• Kubernetes ist eine brauchbare Deployment-Plattform

• Auch die Art des Deployments ist ein weiterer Grund. Ich arbeite an Canton-Nodes, und die Upstream-Canton-Software sowie die zugehörigen Apps werden als Helm-Charts bereitgestellt
  Unabhängig davon, ob Kubernetes für unsere Arbeit geeignet ist — ich denke eher nicht — wird die Software eben so ausgeliefert und unterstützt. Wenn man diesen Pfad verlässt, hat man am Ende mehr Arbeit, als wenn man sich einfach mit Kubernetes beschäftigt

• Bin ich der Einzige, dem dieser Artikel viel zu sehr so vorkommt, als wäre er von einer KI geschrieben?
  Ich stimme der Stoßrichtung trotzdem zu. Ich migriere gerade Homelab-/Self-Hosting-Setups weg von maßgeschneiderten systemd-Konfigurationen, Shell-Befehlen, an die ich mich nicht mehr erinnere, und dem Zustand „Verdammt, in welcher Markdown-Datei hatte ich dieses Setup-Verfahren nochmal aufgeschrieben?“ — und das ist wirklich erfrischend
  Ich nutze noch kein echtes Continuous-Deployment-System, aber es fühlt sich gut an zu wissen, dass ich mit einem kleinen apply-Shell-Skript und einem Bündel YAML-Dateien selbst nach einer Katastrophe wohl 90 % wiederherstellen könnte
  systemd ist konzeptionell einfach, aber bei der Reproduzierbarkeit komplex, Kubernetes ist das Gegenteil. Man zahlt mehr an konzeptionellen Kosten, bekommt dafür aber eine viel stärkere Reproduzierbarkeit und das daraus folgende Verständnis. Zumindest sehe ich das im Moment so
  Ich bin noch in einer Zwischenphase des Lernens, aber in letzter Zeit habe ich ziemlich viel Spaß damit

  • Vor 10 Jahren hätte ich zugestimmt, aber heute fühlt sich auch systemd wegen der vielen Namespace-Optionen und der Integration dynamischer Benutzer wie „noch ein weiteres Monster“ an
    Diese vertikale Integration mit solchen Definitionen erster Klasse wirkt wie die falsche Richtung
  • Ob es von einer KI geschrieben wurde, ist nicht besonders wichtig. Wichtig ist, ob es gut oder schlecht geschrieben ist