Kubernetes v1.36: Server-seitige Sharded Liste und Watch

TL;DR

Kubernetes v1.36 führt die Funktion “Server-seitige Sharded Liste und Watch” als Alpha-Feature ein, um die Effizienz von Controllern in großen Clustern zu verbessern. Diese Funktion ermöglicht es dem API-Server, Ereignisse bereits an der Quelle zu filtern, sodass jede Controller-Instanz nur die relevanten Ressourcen empfängt, was die CPU- und Netzwerkbelastung erheblich reduziert.

Hauptinhalt

Mit dem Wachstum von Kubernetes-Clustern auf Zehntausende von Knoten stehen Controller, die hochgradige Ressourcen wie Pods überwachen, vor erheblichen Skalierungsproblemen. Bisher empfing jede Instanz eines horizontal skalierten Controllers den vollständigen Ereignisstrom vom API-Server, was zu unnötigen CPU-, Speicher- und Netzwerkressourcen führte, da viele der empfangenen Objekte nicht relevant waren. Die Einführung der serverseitigen Sharded Liste und Watch in Kubernetes v1.36 zielt darauf ab, dieses Problem zu lösen, indem das Filtern von Ereignissen auf den API-Server verlagert wird.

Die neue Funktion ermöglicht es jedem Controller, dem API-Server mitzuteilen, welchen Hash-Bereich er überwachen möchte. Der API-Server sendet dann nur die Ereignisse, die in diesen Bereich fallen. Dies reduziert die Datenmenge, die über das Netzwerk fließt, und minimiert die CPU-Auslastung für die Deserialisierung unnötiger Daten. Die Implementierung erfolgt durch die Hinzufügung eines shardSelector-Feldes zu den ListOptions, wobei Clients den Hash-Bereich über die Funktion shardRange() angeben.

Funktionsweise

Der API-Server berechnet einen deterministischen 64-Bit-FNV-1a-Hash des angegebenen Feldes und gibt nur Objekte zurück, deren Hash innerhalb des definierten Bereichs liegt. Derzeit werden die Felder object.metadata.uid und object.metadata.namespace unterstützt. Controller, die typischerweise Informer verwenden, um Ressourcen zu listen und zu überwachen, können den shardSelector in ihre Anfragen integrieren. Dies geschieht über die Methode WithTweakListOptions, die es ermöglicht, den shardSelector in die ListOptions einzufügen.

Für eine Implementierung mit zwei Replikaten wird der Hash-Bereich in zwei Hälften aufgeteilt. Jede Replikat-Instanz erhält somit nur einen Teil des Gesamtbereichs, was die Effizienz weiter steigert. Auch nicht zusammenhängende Bereiche können abgedeckt werden, indem mehrere shardRange()-Aufrufe kombiniert werden.

Technische Details/Implikationen

Die Einführung dieser Funktion hat signifikante technische Implikationen für die Skalierbarkeit von Kubernetes-Clustern. Durch die Reduzierung der Datenmenge, die jede Controller-Instanz verarbeiten muss, wird nicht nur die Effizienz erhöht, sondern auch die Reaktionszeit der Controller verbessert. Da die Hash-Funktion über alle API-Server-Instanzen hinweg konsistent ist, kann die Funktion sicher in Umgebungen mit mehreren API-Servern eingesetzt werden. Die Unterstützung des shardSelector wird in den Antwortmetadaten durch ein shardInfo-Feld angezeigt, das den verwendeten Selektor zurückgibt. Fehlt dieses Feld, bedeutet dies, dass der Server den Selektor nicht anerkannt hat, und der Client muss in der Lage sein, die vollständige Ergebnismenge zu verarbeiten.

Fazit/Ausblick

Die serverseitige Sharded Liste und Watch-Funktion in Kubernetes v1.36 bietet eine vielversprechende Lösung für die Herausforderungen der Skalierung in großen Clustern. Die Funktion befindet sich derzeit im Alpha-Stadium und erfordert das Aktivieren des ShardedListAndWatch-Feature-Gates auf dem API-Server. Feedback von Entwicklern und Betreibern großer Cluster wird aktiv gesucht, um die Funktion weiter zu verbessern.