Kommentar: Unterirdische Kubernetes-Qualität – Containerland ist abgebrannt
Sämtliche Linux-Anbieter wollen ihre Kunden mit Kubernetes beglücken. Dumm nur, dass es aus Sicht des Administrators oft das Problem und nicht die Lösung ist.
(Bild: iX)
- Martin Gerhard Loschwitz
Waren Sie in den letzten Jahren mal auf einer IT-Messe oder hatten Sie Vertreter von Red Hat, Suse & Co. im Haus, die Sie über die neuesten Trends der Branche informiert haben? Falls ja, werden Sie ein Wort penetrant gehört haben: Kubernetes. Kaum ein Tag vergeht derzeit, an dem nicht irgendein Start-up irgendein neues Produkt auf den Markt wirft, das Kubernetes noch besser, noch stabiler und noch vielseitiger machen soll.
Gleich vorab: Natürlich hat das maßgeblich von Docker etablierte Prinzip der Container unter Linux seine Vorzüge. Und wer Cloud-native Anwendungen im Flottenverbund steuern möchte, braucht dafür nolens volens einen Flottenorchestrierer. Doch rechtfertigt die Qualität von Kubernetes, dessen Entwicklungsgeschichte einst bei Google begann und das mittlerweile mit viel finanziellem Bumms und sogar einer eigenen Stiftung ausgestattet ist, nicht den Hype. Denn Administratoren, die mit Kubernetes produktiv arbeiten wollen oder müssen, merken sehr schnell: Technisch steht Kubernetes viel zu oft mit heruntergelassener Hose da.
Kein Spaß mit Versionen
Das geht mit vermeintlichen Kleinigkeiten los. Das Semantic Versioning, kurz SemVer, gilt in der Open-Source-Szene heute als De-facto-Standard für Versionsschemata. SemVer macht klare Vorgaben hinsichtlich der Versionsnummern, die für neue Versionen von Software zu nutzen sind. Grundsätzlich bestehen Versionsnummern nach SemVer aus drei Teilen: Major-Releases ändern demnach die erste Zahl der Version, sie sind durch API-Änderungen gekennzeichnet, die mit der bisherigen Implementierung des Programms inkompatibel sind. Minor-Releases führen neue Funktionen ein, behalten aber die Kompatibilität zur API des Vorgängers bei. Bugfix- oder Patch-Releases ändern den dritten Teil der Versionsnummer.
Wer mit dieser Erwartungshaltung allerdings an die Kubernetes-Verwaltung herangeht, erlebt früher oder später unweigerlich sein blaues Wunder – denn Kubernetes kocht lieber sein eigenes Süppchen und pfeift auf den SemVer-Standard. Bei Reddit hat man das auf die harte Tour gelernt: Hier nahm das vermeintliche Minor-Update von Kubernetes 1.23 auf Kubernetes 1.24 die Plattform für mehrere Stunden offline. Ursache: Aus der Bezeichnung master in einer URL war in der API von Kubernetes zwischenzeitlich control-plane geworden, die Version 1.24 hatte die Unterstützung für die alte Variante ersatzlos gestrichen.
"Schade, Schokolade", könnte man denken, sowas kommt eben vor. Doch lässt der Vorfall nicht nur den Rückschluss zu, dass Kubernetes ein Problem mit seinem Versionsschema hat. Stattdessen tritt hier ein tiefgreifendes Qualitätsproblem hinsichtlich der Architektur der Software offen zutage, das Kubernetes in Sachen Benutzung ebenso behindert wie in Sachen Entwicklung. Und das, was Reddit erlebt hat, ist beileibe kein Einzelfall.
Das merkt man schnell, wenn man sich mit der Software auch nur innerhalb der Demo-Szenarien befasst, die deren eigene Dokumentation vorgibt. Auf dem Papier ist die Einrichtung von Kubernetes trivial. Das liegt unter anderem daran, dass Kubernetes den größten Teil der von ihm benötigten Software selbst ausrollt und steuert. Wer so vorgeht und der Anleitung Schritt für Schritt folgt, sollte am Ende also einen funktionierenden Cluster haben. Doof nur: Selbst in einer Laborumgebung aus frischen VMs mit funktionalem Netz und funktionalem Storage lässt sich eben dieses Setup nicht mit absoluter Zuverlässigkeit reproduzieren. Regelmäßig verweigert etwa CoreDNS den Dienst. Der kümmert sich in Kubernetes um die interne Auflösung von DNS-Namen, von denen der Container-Orchestrierer ebenso wie Drittanbieterlösungen zum Teil exzessiven Gebrauch macht. Warum die CoreDNS-Pods – so heißt im Kubernetes-Sprech der Verbund aus einem oder mehreren zusammenhängenden Containern – nicht funktionieren, ist dabei kaum sinnvoll herauszufinden. Ihr Neustart sorgt aber dafür, dass der Dienst auf gar wundersame Art und Weise von den Toten wiederaufersteht. Vertrauenerweckend ist das nicht.
Und die Liste der Kubernetes-Probleme ließe sich an dieser Stelle beliebig fortsetzen. So setzt Kubernetes ähnlich wie der Linux-Kernel auf Namespaces, um Ressourcen logisch voneinander zu trennen. Namespaces lassen sich löschen – und laut Lehrbuch führt das eigentlich dazu, dass auch die zum Namespace gehörenden Ressourcen ihren Weg in die ewigen Jagdgründe antreten. Genau das funktioniert aber nicht konsistent. Im schlimmsten Fall führt das Löschen eines Namespaces dazu, dass ein paar von dessen Ressourcen als Zombies übrig bleiben, aber über die Namespace-API nicht mehr erreichbar sind. Dann pult der Administrator irgendwelche obskuren kubectl-Befehle aus Google oder muss gleich mit curl und einem per REST-API injiziertem JSON-Snippet anrücken, um Kubernetes in einen funktionalen Zustand zurückzuversetzen. Schlimmer noch: Zum Teil ist gar nicht definiert, wie Kubernetes mit widersprüchlichen Anweisungen umgehen soll. Was etwa mit PVCs – Persistent Volume Claims, also alloziertem Blockspeicher von Instanzen – geschehen soll, deren Reclaim-Policy zwar auf Retain – also Behalten – steht, deren Namespace jedoch gelöscht wird, hat mehr mit Roulette gemein als mit zuverlässiger Systemadministration.
Widewidewitt, denkt sich Kubernetes, und macht sich die Welt, wie sie ihm gefällt. Dasselbe gilt für nicht wenige Kubernetes-Entwickler: Im Bug-Tracker des Tools finden sich mittlerweile zahllose Einträge, in denen Anwender von inkonsistentem und fehlerhaftem Verhalten berichten, ohne die Ursache dafür ausfindig gemacht zu haben. Fast schon eine Standardantwort ist dann, dass man das Deployment der Anwendung oder am besten gleich das ganze Kubernetes wegwerfen und neu ausrollen soll, weil das Problem dann vermutlich verschwinde. Administratoren nützt dieser Ansatz allerdings nichts, denn sie haben so schlicht keine Möglichkeit, Software zuverlässig auszurollen und zu betreiben.
Man hätte es wissen können
Wenn die Vertreter der Hersteller weg sind, ist der Alltag eines Kubernetes-Administrators am Ende regelmäßig ein Kampf gegen zum Teil absurde Qualitätsmängel der Software. Die zahllosen Werkzeuge, Aufbauten, Erweiterungen und Integrationen in andere Dienste, mit denen seriöse Firmen ebenso wie Glücksritter aktuell ein Stück des Kubernetes-Kuchens zu ergattern versuchen, helfen da auch nicht weiter – zumal deren Qualität oft vergleichbar unterirdisch ist. Ein erquicklicher Anteil der Probleme, die Kubernetes heute beuteln, sind architektonischen Ursprungs. Das Argument, man habe es eben nicht besser gewusst, zieht dabei nicht: Verteilte Systeme sind zwar komplex – Kubernetes war aber nicht die erste Software, die diese Probleme lösen musste.
Ein paar Jahre zuvor erst lief man bei OpenStack in viele derselben Probleme, mit denen auch Kubernetes sich herumschlägt. Einige Entwickler aus dem Kubernetes-Universum indes, zum Teil selbst einst in OpenStack aktiv, hielten die OpenStack-Macher für eine Bande ausgemachter Idioten. Deren Warnungen stießen deshalb meist auf taube Ohren – sogar dann, wenn man bei OpenStack Ansätze in Kubernetes kritisierte, weil man sie selbst vor Jahren ausprobiert hatte und damit auf die Nase geflogen war. Fakt ist: Dienste wie OpenStack Heat für Orchestrierung innerhalb der Cloud oder Nova, das virtuelle Instanzen verwaltet, hatten gerade anfangs mit ähnlichen Konsistenzproblemen zu kämpfen wie Kubernetes heute. Sic transit gloria mundi: Auch wenn es kaum noch jemanden interessiert – mittlerweile hat OpenStack diese Probleme praktisch komplett im Griff.
Kubernetes nicht. Es wäre aktuell insofern ein guter Zeitpunkt für die Kubernetes-Community, innezuhalten und sich den drängendsten Architektur- und Konsistenzproblemen zu widmen, statt weiter an der Feature-Schraube zu drehen. Zweifelsohne ist Kubernetes bis hierhin eine – vor allem kommerzielle – Erfolgsgeschichte. Soll das Werkzeug sich aber dauerhaft am Markt etablieren und erfolgreich bleiben, muss es zuverlässiger, stabiler und ganz allgemein besser werden. Dass Container gekommen sind, um zu bleiben, ist mittlerweile unstrittig. Dass Kubernetes bleibt, nicht so sehr.
(fo)