Kubernetes hat sich als Plattform für den Betrieb containerisierter Anwendungen etabliert. Die Open-Source-Technologie übernimmt die Orchestrierung von Containern, verteilt Anwendungen auf verfügbare Server und unterstützt deren Skalierung und Verwaltung.
Die zugrunde liegende Infrastruktur wird als Kubernetes-Cluster bezeichnet. Er besteht aus mehreren miteinander verbundenen Systemen, auf denen Anwendungen in sogenannten Pods ausgeführt werden. Kubernetes koordiniert diese Ressourcen und stellt Funktionen bereit, um Anwendungen auch bei Änderungen an der Infrastruktur weiterzubetreiben.
Gerade in größeren IT-Umgebungen müssen solche Cluster regelmäßig gewartet und aktualisiert werden. Dabei sollen Anwendungen möglichst ohne Unterbrechungen weiterlaufen.
Doch genau hier gibt es eine Lücke: Ein Kubernetes-Cluster kann sämtliche Konformitätstests bestehen, während die darauf betriebenen Anwendungen bei einem regulären Upgrade Probleme verursachen.
Die Kubernetes-Community will diese Lücke nun schließen.
Kubernetes prüft bisher die Infrastruktur, nicht die Anwendungen
Mit Programmen wie „Certified Kubernetes“ existieren bereits etablierte Verfahren, um die Konformität eines Kubernetes-Clusters zu überprüfen. Auch „Kubernetes AI Conformance“ bewertet bestimmte Voraussetzungen für den Betrieb von KI- und Machine-Learning-Anwendungen.
Diese Prüfungen konzentrieren sich jedoch auf den Cluster selbst. Sie untersuchen nicht, ob die darauf ausgeführten Anwendungen mit typischen Betriebsabläufen zuverlässig umgehen können.
Für diese sogenannten Workloads existiert bislang kein vergleichbarer Konformitätsstandard.
Das bedeutet, dass Administratoren vor Wartungsarbeiten oder Cluster-Upgrades häufig selbst überprüfen müssen, ob ihre Anwendungen mit den geplanten Änderungen zurechtkommen.
Die dafür notwendigen Best Practices sind innerhalb des Kubernetes-Projekts bereits dokumentiert. Ihre Einhaltung muss in der Praxis jedoch immer wieder individuell geprüft werden.
Warum Anwendungen bei regulären Wartungsarbeiten Probleme verursachen
Ein typisches Beispiel ist der sogenannte Node-Drain.
Dabei wird ein Kubernetes-Knoten für Wartungsarbeiten vorbereitet. Die darauf ausgeführten Pods werden kontrolliert beendet beziehungsweise auf anderen Knoten neu gestartet.
Anwendungen müssen mit solchen Unterbrechungen umgehen können. Das funktioniert allerdings nicht immer.
Fehlen beispielsweise geeignete Pod Disruption Budgets, können bei Wartungsarbeiten mehr Anwendungsinstanzen gleichzeitig ausfallen als vorgesehen. Diese Budgets legen fest, wie viele Pods einer Anwendung bei freiwilligen Unterbrechungen gleichzeitig nicht verfügbar sein dürfen.
Ein weiteres Problem entsteht, wenn Prozesse nicht korrekt auf Terminierungssignale reagieren. Kubernetes kann einen Pod zwar beenden, die Anwendung muss aber selbst angemessen auf diesen Vorgang reagieren.
Auch bei Cluster-Upgrades treten regelmäßig Schwierigkeiten auf.
Kubernetes entwickelt seine Programmierschnittstellen kontinuierlich weiter. Dabei werden ältere API-Versionen zunächst abgekündigt und später gegebenenfalls entfernt. Anwendungen, die weiterhin auf solche Versionen angewiesen sind, können nach einem Upgrade nicht mehr wie vorgesehen funktionieren.
Hinzu kommen Probleme, die nicht unmittelbar zu Ausfällen führen, aber den Betrieb beeinträchtigen.
Manche Workloads fordern unnötig weitreichende Berechtigungen an. Andere reservieren dauerhaft Hardwareressourcen, obwohl sie diese tatsächlich nicht benötigen.
Alle diese Fälle haben eine Gemeinsamkeit: Sie betreffen das Verhalten der Anwendungen und lassen sich nicht allein durch die Konformität des Clusters ausschließen.
Eine neue Arbeitsgruppe soll einheitliche Standards schaffen
Um diese Lücke zu schließen, hat die Kubernetes-Community die „Workload Conformance Working Group“ gegründet.
Ihr Ziel ist es, einen gemeinsamen Standard für das Laufzeitverhalten von Anwendungen auf Kubernetes zu entwickeln.
Künftig soll für jede Kubernetes-Minor-Version festgelegt werden, welche Anforderungen eine konforme Anwendung erfüllen muss.
Eine Minor-Version bezeichnet dabei eine reguläre Kubernetes-Version innerhalb einer Hauptversionsreihe. Die Anforderungen sollen also auf den jeweiligen Entwicklungsstand von Kubernetes abgestimmt werden.
Neben der Spezifikation plant die Arbeitsgruppe eine standardisierte Testmethodik sowie ein Upstream-Testwerkzeug, mit dem sich laufende Workloads automatisiert überprüfen lassen.
Der vorgesehene Prüfbereich ist umfangreich. Er umfasst Sicherheit, Ressourcenverbrauch, Ausfallsicherheit bei Störungen, Netzwerk- und Storage-Verhalten sowie API-Nutzung und Observability.
Observability beschreibt dabei die Möglichkeiten, den Zustand und das Verhalten einer Anwendung anhand ihrer Betriebsdaten nachzuvollziehen.
Welche konkreten Anforderungen letztlich Bestandteil des Standards werden, ist noch nicht entschieden.
Objektive Tests statt individueller Bewertungen
Eine wesentliche Vorgabe hat die Arbeitsgruppe bereits festgelegt: Jede Anforderung muss sich objektiv durch eine Test-Binary überprüfen lassen.
Damit wird die technische Überprüfbarkeit zur Voraussetzung für die Aufnahme in den Standard.
Subjektive Kriterien sind ausdrücklich ausgeschlossen.
Die Tests sollen ausschließlich bewerten, wie eine Anwendung auf einem Kubernetes-Cluster ausgeführt wird. Die interne Geschäftslogik bleibt außerhalb des Prüfbereichs.
Es geht also nicht darum, ob eine Anwendung ihre fachlichen Aufgaben korrekt erfüllt, sondern darum, wie sie sich innerhalb der Kubernetes-Umgebung verhält.
Auch bei der Wahl der eingesetzten Technologien setzt die Arbeitsgruppe Grenzen.
Der Standard soll keine bestimmten Paketformate wie Helm-Charts voraussetzen. Ebenso wenig werden externe Policy-Engines oder Security-Scanner vorgeschrieben.
Außerdem sollen keine Tests wiederholt werden, die bereits durch die bestehende Cluster-Zertifizierung abgedeckt sind.
Die neue Workload-Konformität soll die vorhandenen Infrastrukturprüfungen ergänzen, nicht ersetzen.
Was sich für Plattformteams und Entwickler ändern könnte
Bislang müssen Plattformteams vor Wartungsarbeiten und Upgrades häufig dieselben Prüfungen in unterschiedlichen Umgebungen wiederholen.
Gleichzeitig beantworten Anwendungsentwickler immer wieder ähnliche Fragen zu den technischen Eigenschaften ihrer Workloads.
Eine standardisierte Testmethodik könnte diese wiederkehrenden Prüfungen vereinheitlichen.
Statt Anforderungen individuell zu interpretieren, könnten sich Entwickler und Administratoren auf eine gemeinsame Spezifikation beziehen und das Laufzeitverhalten anhand definierter Tests überprüfen.
Gerade bei Cluster-Upgrades wäre das relevant. Die Kompatibilität von Anwendungen ließe sich anhand einheitlicher Kriterien untersuchen, bevor Änderungen an der Infrastruktur vorgenommen werden.
Allerdings hängt der praktische Nutzen davon ab, welche Anforderungen tatsächlich in die Spezifikation aufgenommen werden und wie zuverlässig sich diese automatisiert überprüfen lassen.
Dazu liegen bislang noch keine abschließenden Festlegungen vor.
Erste stabile Version frühestens nach mehreren Release-Zyklen
Organisatorisch wird die Initiative von zwei Kubernetes Special Interest Groups getragen.
Die SIG Apps bringt die Perspektive der Anwendungsentwickler ein. Die SIG Architecture soll die Spezifikation und die Werkzeuge langfristig in einem eigenen Unterprojekt verwalten, sobald erste Entwürfe vorliegen.
Wenn Anforderungen andere technische Bereiche betreffen, beispielsweise Netzwerkfunktionen oder das Verhalten einzelner Knoten, sollen die zuständigen SIGs direkt eingebunden werden.
Für eine erste stabile Spezifikation einschließlich funktionierender Tests rechnen die Beteiligten mit zwei bis drei Kubernetes-Release-Zyklen.
Die Arbeitsgruppe befindet sich damit noch in einer frühen Entwicklungsphase.
Aktuell werden Administratoren und Entwickler gesucht, die konkrete Problemfälle aus vergangenen Wartungsfenstern beisteuern, geplante Anforderungen begutachten oder frühe Versionen der Test-Binary gegen eigene Workloads ausführen.
Die Zusammenarbeit erfolgt über den Kubernetes-Slack-Kanal #wg-workload-conformance, eine Mailingliste und Videokonferenzen.
Fazit: Konformität muss über den Cluster hinausgehen
Die neue Initiative adressiert eine konkrete Schwachstelle im bisherigen Kubernetes-Konformitätsmodell.
Während sich die Infrastruktur bereits anhand definierter Standards überprüfen lässt, fehlt ein vergleichbares Verfahren für das Laufzeitverhalten der Anwendungen.
Die Folgen zeigen sich bei Wartungsarbeiten, Cluster-Upgrades und im laufenden Betrieb. Anwendungen reagieren nicht wie erwartet auf Unterbrechungen, verwenden entfernte APIs oder beanspruchen unnötige Berechtigungen und Ressourcen.
Die Workload Conformance Working Group will dafür objektive, automatisierbare Prüfungen entwickeln.
Ob daraus ein praxistauglicher Standard entsteht, wird sich erst mit der konkreten Spezifikation und den dazugehörigen Werkzeugen zeigen.
Der Ansatz ist dennoch nachvollziehbar: Ein konformer Kubernetes-Cluster sagt bislang wenig darüber aus, ob die darauf betriebenen Anwendungen die Anforderungen eines zuverlässigen Betriebs erfüllen. Genau diese Unterscheidung soll künftig überprüfbar werden.