Kubernetes v1.33 führt Streaming-Listenantworten ein, um die Speichernutzung des API-Servers zu reduzieren

In einem Beitrag im Kubernetes Blog im Mai 2025 beschrieben die Maintainer Marek Siarkowicz und Wei Fu eine wesentliche architektonische Änderung in Kubernetes v1.33. Das Update führt eine Streaming-Kodierung für List-Antworten ein, eine Funktion, die darauf abzielt, den Speicherverbrauch im API-Server bei der Verarbeitung großer Datensätze drastisch zu senken. Diese Verbesserung adressiert langjährige Stabilitätsprobleme in großskaligen Clustern, wo das Abrufen umfangreicher Ressourcenlisten zuvor das Risiko von Out-of-Memory-Fehlern barg.

Was passiert ist

Der Betrieb großer Kubernetes-Cluster war schon immer mit dem Abwägen zwischen Datenzugänglichkeit und Ressourcenverbrauch verbunden. Eine der hartnäckigsten Herausforderungen war die Handhabung von List-Anfragen, die erhebliche Datenmengen aus dem Cluster-Zustand abrufen. In früheren Versionen serialisierte der API-Server die gesamte Antwort in einen einzigen zusammenhängenden Speicherblock, bevor er sie an den Client sendete. Obwohl HTTP/2 Antworten in kleinere Frames für die Übertragung aufteilen kann, hielt der zugrunde liegende Server den vollständigen Datenpuffer so lange im Speicher, bis die gesamte Übertragung abgeschlossen war. Dies bedeutete, dass wenn Netzwerküberlastung die Übertragung verlangsamt, Hunderte von Megabytes Speicher für Sekunden oder Minuten blockiert blieben.

Diese Ineffizienz wurde im großen Maßstab kritisch. Wenn mehrere große List-Anfragen gleichzeitig auftraten, konnte der kumulative Speicherverbrauch schnell ansteigen, was zu Out-of-Memory-(OOM)-Situationen führte, die die Cluster-Stabilität beeinträchtigten. Das Problem wurde dadurch verschärft, wie das Go-Paket encoding/json den Speicher verwaltet. Es nutzt sync.Pool, um Puffer wiederzuverwenden, was für gleichmäßige Workloads effizient ist, aber bei sporadischen großen Antworten problematisch wird. Sobald eine große Antwort den Speicherpool erweiterte, blieben diese überdimensionierten Puffer für nachfolgende kleine Anfragen reserviert, was die Garbage Collection verhinderte und die Speichernutzung künstlich hoch hielt, lange nachdem die hohe Last vorüber war.

Wie es funktioniert

Der neue Streaming-Encoder ändert die Art und Weise, wie der API-Server List-Antworten verarbeitet, indem er sich auf das Feld Items konzentriert, das den Großteil der Daten in Sammlungsstrukturen enthält. Anstatt das gesamte Array als einen monolithischen Block zu kodieren, verarbeitet und überträgt der Server nun jedes Element einzeln. Sobald jeder Chunk an den Client gesendet wird, wird der damit verbundene Speicher sofort freigegeben. Dieser inkrementelle Ansatz stellt sicher, dass der Speicherbedarf des API-Servers vorhersehbar und handhabbar bleibt, unabhängig von der Gesamtanzahl der Objekte in der Liste.

Da Kubernetes-Objekte in etcd typischerweise auf 1,5 MiB begrenzt sind, hält das Streaming die einzelnen Speicherzuweisungen klein. Das System wahrt strenge Abwärtskompatibilität, indem es Go-Struct-Tags vor der Aktivierung validiert, um sicherzustellen, dass die Ausgabe byte-genau mit dem ursprünglichen Encoder identisch ist. Die Standardkodierung behandelt weiterhin alle Felder außer Items, sodass Clients ihren Code nicht ändern müssen und sich nicht einmal dessen bewusst sein müssen, dass sich der zugrunde liegende Mechanismus geändert hat. Diese nahtlose Integration unterstützt alle Kubernetes-Listentypen, einschließlich eingebauter Listen und Custom Resource UnstructuredLists.

Wichtige Details

• Version: Die Funktion wurde in Kubernetes v1.33 eingeführt und im Mai 2025 angekündigt.
• Speicherreduzierung: Benchmarks zeigten eine 20-fache Verbesserung der Speichernutzung bei großen List-Operationen, wobei der Verbrauch von 70–80 GB auf nur 3 GB sank.
• Mechanismus: Der Encoder streamt einzelne Elemente innerhalb des Feldes Items, anstatt das gesamte Array auf einmal zu serialisieren.
• Kompatibilität: Es sind keine clientseitigen Änderungen erforderlich; die Ausgabe bleibt byte-genau konsistent mit früheren Versionen.
• Auslöser: Der Streaming-Encoder aktiviert sich erst nach einer rigorosen Validierung der Struct-Tags, um Sicherheit zu gewährleisten.
• Umfang: Er gilt für alle Kubernetes-Listentypen, einschließlich Standardressourcen und benutzerdefinierter Ressourcen.

Warum es wichtig ist

Für Ingenieure, die große Kubernetes-Infrastrukturen bauen und warten, wirkt sich dieses Update direkt auf Zuverlässigkeit und Kosteneffizienz aus. Hoher Speicherverbrauch im kube-apiserver zwingt Teams oft dazu, Hardware zu überdimensionieren, um Spitzenlasten zu bewältigen, was die Betriebskosten erhöht. Indem der Speicherbedarf großer List-Anfragen um eine solche signifikante Marge reduziert wird, können Organisationen schlankere Control Planes betreiben, ohne Leistungseinbußen hinnehmen zu müssen. Es reduziert auch das Risiko unerwarteter OOM-Kills, die Dienstunterbrechungen verursachen und Debugging-Bemühungen während der Incident Response komplizieren können.

Darüber hinaus verbessert diese Änderung die Vorhersagbarkeit des Cluster-Verhaltens unter Last. In Umgebungen, in denen Monitoring-Tools, Controller oder CI/CD-Pipelines häufig große Mengen an Ressourcen auflisten, konnten die früheren Speicher-Spitzen kaskadierende Fehler auslösen. Mit der Streaming-Kodierung halten diese Operationen während Übertragungsverzögerungen keinen übermäßigen Speicher mehr fest. Dies ermöglicht es dem API-Server, mehr gleichzeitige Anfragen und größere Datensätze reibungslos zu verarbeiten, was die Skalierung von Clustern zur Unterstützung von Tausenden von Nodes und Zehntausenden von Pods erleichtert.

Was Sie tun können

• Aktualisieren Sie Ihren Control Plane auf Kubernetes v1.33 oder später, um vom Streaming-Encoder zu profitieren.
• Überwachen Sie die Speichernutzung des kube-apiserver während großer List-Operationen, um die Reduzierung des Spitzenverbrauchs zu beobachten.
• Prüfen Sie alle benutzerdefinierten Controller oder Operatoren, die große List-Aufrufe durchführen, um sicherzustellen, dass sie Streaming-Antworten ordnungsgemäß handhaben, obwohl keine Codeänderungen streng genommen erforderlich sind.
• Überprüfen Sie die Einstellungen Ihres horizontal pod autoscalers im Cluster, da eine reduzierte API-Server-Last engere Schwellenwerte für die Skalierung ermöglichen kann.
• Stellen Sie sicher, dass Ihr Monitoring-Stack nicht auf festen Puffergrößen für die Analyse von API-Antworten beruht, although die byte-genaue Kompatibilität Probleme verhindern sollte.
• Erwägen Sie die Anpassung der Ressourcenanforderungen und -limits für den kube-apiserver, wenn Sie zuvor Speicher überdimensioniert haben, um OOM-Risiken zu mildern.