Kubernetes 1.32 führt API-Streaming ein, um Speicher-Spitzen bei List-Anfragen zu beheben

In einem Beitrag im Kubernetes Blog im Dezember 2024 haben Ingenieure von Upbound, Google und Red Hat eine entscheidende Verbesserung der Speichereffizienz für den Kubernetes API-Server detailliert beschrieben. Das Update adressiert, wie große Cluster Massen-Datenabfragen verarbeiten, und führt einen Streaming-Mechanismus ein, der plötzliche Speicherengpässe unter hoher Last verhindert.

Was passiert ist

Die Verwaltung großer Kubernetes-Cluster führt oft zu erheblichem Speicherverbrauch, wenn Komponenten List-Anfragen stellen. In der traditionellen Implementierung muss der kube-apiserver die gesamte Antwort im Speicher zusammenstellen, bevor Daten an den Client gesendet werden. Wenn der Antwortkörper mehrere Hundert Megabyte groß ist oder wenn nach einem Netzwerkausfall mehrere Anfragen gleichzeitig eintreffen, kann dieser Prozess schnell den gesamten verfügbaren RAM verbrauchen. Während bestehende Mechanismen zur API-Priorisierung und Fairness (API Priority and Fairness) vor CPU-Überlastung schützen, bieten sie nur begrenzten Schutz gegen diese unbegrenzten Speicher-Spitzen.

Die Untersuchung ergab, dass diese Speicherzuweisung stattfindet, weil der Server Daten aus der Datenbank abruft, sie deserialisiert und dann das endgültige Antwortformat alles auf einmal konstruiert. Diese Sequenz erzeugt einen massiven temporären Speicher-Footprint, den weder die Garbage Collection von Go noch konfigurierte Speicherlimits während plötzlicher Spitzen effektiv verwalten können. In Hochverfügbarkeits-Setups kann dies zu einer kaskadierenden Ausfallkette führen, bei der ein API-Server aufgrund eines Out-of-Memory-Zustands (OOM) abstürzt, dieselben schweren Anfragen an andere Nodes weiterleitet und auch diese zum Scheitern bringt.

Um dieses Problem zu lösen, hat das Kubernetes-Team die Watch List-Funktion in Version 1.32 auf Beta gehoben. Dies ermöglicht es Clients, sich für das Streaming von Listen zu entscheiden, indem sie von standardmäßigen List-Anfragen zu einer speziellen Form von Watch-Anfragen wechseln. Indem diese Anfragen aus dem Watch Cache bedient werden, streamt der Server jedes Element einzeln, anstatt die gesamte Kollektion zu puffern. Diese Änderung stellt sicher, dass der Speicherverbrauch konstant bleibt, begrenzt nur durch die maximale Größe eines einzelnen Objekts plus geringe Zuweisungen, was die Stabilität von Clustern mit vielen großen Objekten drastisch verbessert.

Wie es funktioniert

Der Kernmechanismus basiert auf dem Wechsel von Batch-Verarbeitung zu Streaming. Traditionelle List-Anfragen erfordern, dass der Server den gesamten Datensatz während der Serialisierung im RAM hält. Im Gegensatz dazu nutzt der neue Watch List-Ansatz den bestehenden Watch Cache, einen In-Memory-Cache, der für die Skalierung von Lesevorgängen entwickelt wurde. Wenn ein Client diese Methode verwendet, sendet der API-Server Objekte nacheinander, sobald sie aus dem Cache abgerufen werden, und vermeidet so die Notwendigkeit, Speicher für den vollständigen Antwortkörper auf einmal zuzuweisen.

Dieser architektonische Wandel entkoppelt die Speichernutzung von der Gesamtanzahl der Objekte in einer Kollektion. Anstatt dass der Speicherverbrauch linear mit der Größe der Liste wächst, bleibt er flach, unabhängig davon, wie viele Elemente zurückgegeben werden. Dies macht den API-Server robust, selbst wenn Tausende großer Ressourcen verarbeitet werden, wie Secrets mit umfangreichen Payloads, ohne das Risiko von OOM-Kills.

Wichtige Details

• Die Watch List-Funktion erreichte in Kubernetes 1.32 den Beta-Status.
• Clients müssen das Feature-Gate WatchListClient in client-go explizit aktivieren, um Streaming-Listen zu nutzen.
• Synthetische Tests zeigten, dass der Speicherverbrauch bei aktiviertem Streaming bei 2 GB stabilisierte, im Vergleich zu 20 GB bei deaktiviertem Streaming.
• Die Funktion erfordert etcd-Versionen 3.4.31+ oder 3.5.13+.
• In Kubernetes 1.33 wurden neue Feature-Gates StreamingCollectionEncodingToJSON und StreamingCollectionEncodingToProtobuf eingeführt, um serverseitiges Streaming ohne Änderungen am Client zu ermöglichen.
• Das Feature-Gate WatchList ist in Kubernetes 1.33 standardmäßig deaktiviert, obwohl es in 1.32 für den kube-controller-manager standardmäßig aktiviert war.

Warum es wichtig ist

Für Plattform-Ingenieure und SREs, die große Cluster verwalten, adressiert dieses Update einen fragilen Punkt in der Stabilität der Control Plane. Speicherengpässe im API-Server sind schwer zu diagnostizieren und wiederherzustellen, was oft zu vollständigen Ausfällen der Control Plane führt. Durch die Einführung von Streaming-Listen können Teams größere Cluster mit komplexeren Ressourcen betreiben, ohne befürchten zu müssen, dass ein routinemäßiger Reconciliation-Loop oder eine Synchronisation nach einem Ausfall ihre Management-Ebene zum Absturz bringt.

Diese Änderung hat auch Auswirkungen darauf, wie API-Kosten in zukünftigen Versionen berechnet werden. Derzeit weist API Priority and Fairness List-Anfragen niedrige Kosten zu, um die Parallelität für typische Anwendungsfälle aufrechtzuerhalten. Da das Ökosystem sich hin zu Watch Lists verschiebt, kann das System die Kostenschätzung für traditionelle List-Anfragen sicher erhöhen. Dies bietet besseren Schutz gegen Legacy-Clients oder falsch konfigurierte Tools, die weiterhin teure Bulk-Anfragen stellen, und gewährleistet eine fairere Ressourcenzuteilung im gesamten Cluster.

Was Sie tun können

• Aktualisieren Sie Ihren Cluster auf Kubernetes 1.32 oder höher, um auf die Beta-Watch List-Funktion zuzugreifen.
• Stellen Sie sicher, dass Ihre etcd-Version mindestens 3.4.31 oder 3.5.13 beträgt, um Kompatibilität zu gewährleisten.
• Aktualisieren Sie Golang-basierte Clients, um das Feature-Gate WatchListClient in client-go zu aktivieren.
• Überwachen Sie die Speichernutzung Ihrer API-Server während Lastspitzen, um festzustellen, ob große List-Anfragen immer noch zu Spitzen führen.
• Ermutigen Sie Drittanbieter-Controller und Operatoren in Ihrer Umgebung, die Streaming-API während der Beta-Phase zu übernehmen.
• Planen Sie zukünftige Upgrades auf Kubernetes 1.33, um serverseitige Streaming-Encoding-Funktionen zu nutzen, die keine Änderungen am Client-Code erfordern.