Kubernetes 成立 Workload Conformance 工作组，为应用运行时行为制定一致性标准

close notice

This article is also available in English.

It was translated with technical assistance and editorially reviewed before publication.

.

Die Kubernetes-Community hat die „Workload Conformance Working Group“ gegründet. Sie soll einen gemeinsamen Standard dafür erarbeiten, wie sich Anwendungen zur Laufzeit auf einem Cluster verhalten, und passende Werkzeuge für automatisierte Tests bereitstellen.

Weiterlesen nach der Anzeige

Bislang konzentrieren sich Konformitätstests im Kubernetes-Ökosystem ausschließlich auf die Infrastruktur. Programme wie „Certified Kubernetes“ oder „Kubernetes AI Conformance“ prüfen lediglich, ob ein Cluster selbst den Vorgaben entspricht oder sich für KI- und ML-Aufgaben eignet. Für die darauf laufenden Anwendungen existiert hingegen kein vergleichbarer Maßstab. Wie Initiator Nabarun Pal in der Ankündigung der neuen Arbeitsgruppe erläutert, müssen Administratoren daher vor regulären Wartungsarbeiten oder Cluster-Upgrades oft noch manuell prüfen, ob die einzelnen Workloads damit klarkommen.

Die Folgen im Betriebsalltag sind bekannt: Oft zeigt sich erst beim routinemäßigen Node-Drain, dass eine Anwendung Unterbrechungen nicht sauber toleriert. Das kann zum Beispiel passieren, weil Pod Disruption Budgets fehlen oder Prozesse nicht korrekt auf Terminierungssignale reagieren. Ebenso scheitern Cluster-Upgrades häufig daran, dass eingesetzte Software noch auf abgekündigten und schließlich entfernten API-Versionen aufbaut. Im laufenden Betrieb fallen zudem immer wieder Workloads auf, die unnötig weitreichende Berechtigungen anfordern oder dauerhaft Hardwareressourcen reservieren, ohne sie tatsächlich abzurufen. Zwar dokumentiert das Kubernetes-Projekt Best Practices für solche Fälle bereits ausführlich, doch in der Praxis wiederholen Plattformteams dieselben Prüfungen für jede Umgebung, während Anwendungsentwickler immer wieder identische Rückfragen beantworten müssen.

Objektive Tests gegen laufende Anwendungen

Abhilfe schaffen soll nun eine verbindliche Basis, die für jede Minor-Version von Kubernetes festlegt, welches Laufzeitverhalten von einer konformen Anwendung erwartet wird. Neben dieser Spezifikation will die Arbeitsgruppe eine Testmethodik gegen laufende Workloads sowie ein dazugehöriges Upstream-Testwerkzeug entwickeln. Inhaltlich steckt das Gremium ein breites Feld ab: Es reicht von Sicherheitsaspekten, Ressourcenverbrauch und Ausfallsicherheit bei Störungen über Netzwerk- und Storage-Verhalten bis hin zu API-Nutzung und Observability. Welche konkreten Anforderungen in den Katalog aufgenommen werden, ist derzeit noch offen.

Fest steht allerdings die Grundregel, dass sich jede Anforderung objektiv durch eine Test-Binary überprüfen lassen muss. Subjektive Kriterien schließt die Charta der Gruppe explizit aus. Ferner wird ausschließlich geprüft, wie eine Anwendung auf dem Cluster ausgeführt wird. Die interne Geschäftslogik der Software bleibt also außen vor. Zudem soll das geplante Werkzeug keine Tests wiederholen, die bereits durch die bestehende Cluster-Zertifizierung abgedeckt sind. Es schreibt auch weder bestimmte Paketformate wie Helm-Charts noch Drittanbieter-Werkzeuge wie externe Policy-Engines oder Security-Scanner vor.

Erste stabile Version in zwei bis drei Release-Zyklen

Weiterlesen nach der Anzeige

Organisatorisch wird die Initiative von zwei Special Interest Groups (SIGs) getragen. Die SIG Apps bringt die Perspektive der Anwendungsentwickler ein, während die SIG Architecture die Spezifikation und die Werkzeuge langfristig in einem eigenen Unterprojekt verwalten wird, sobald erste Entwürfe vorliegen. Berühren geplante Vorgaben andere Fachbereiche wie das Netzwerk oder das Knotenverhalten, bindet die Gruppe die jeweiligen SIGs direkt ein.

Bis eine erste stabile Spezifikation samt funktionierender Tests steht, veranschlagen die Beteiligten zwei bis drei Kubernetes-Release-Zyklen. Aktuell sucht die Arbeitsgruppe noch Administratoren und Entwickler, die reale Problemfälle aus vergangenen Wartungsfenstern beisteuern, Anforderungen begutachten oder frühe Versionen der Test-Binary gegen eigene Workloads laufen lassen. Die Abstimmung erfolgt über den Kanal #wg-workload-conformance im Kubernetes-Slack, eine Mailingliste und Videokonferenzen.

(fo)