Kubernetes v1.34: Snapshottable API-Server-Cache

TL;DR

Die Kubernetes-Version 1.34 führt den snapshottable API-Server-Cache in den Beta-Status ein, was die Performance und Stabilität des API-Servers erheblich verbessert. Diese Funktion ermöglicht es, fast alle Leseanfragen direkt aus dem Cache zu bedienen, wodurch die Belastung des etcd-Datenspeichers verringert wird.

Hauptinhalt

Kubernetes hat sich kontinuierlich darum bemüht, die Stabilität und Vorhersagbarkeit der Performance des API-Servers zu verbessern. Ein zentrales Anliegen war die Optimierung von LIST-Anfragen, die historisch gesehen zu hohem Speicherverbrauch und einer starken Belastung des etcd-Datenspeichers führten. Mit der Einführung des snapshottable API-Server-Caches in Kubernetes v1.34 wird ein bedeutender Fortschritt in dieser Hinsicht erzielt.

Die Entwicklung des Caches umfasste mehrere wesentliche Verbesserungen in den vorherigen Versionen. In v1.31 wurde die Konsistenz der Lesevorgänge aus dem Cache gewährleistet, was es ermöglichte, gefilterte Sammlungen sicher aus dem Cache zu bedienen. Dies reduzierte die Last auf etcd erheblich, insbesondere bei häufigen Anfragen.

In v1.33 wurde ein Streaming-Encoder eingeführt, der es dem API-Server ermöglichte, große Antworten effizienter zu übertragen, indem er die Daten einzeln und nicht als gesamtes, voluminöses Paket übertrug. Dies führte zu einer vorhersehbaren und minimalen Speichernutzung, unabhängig von der Größe der Antwort.

Trotz dieser Fortschritte blieb eine kritische Lücke: Anfragen für historische LIST-Daten mussten nach wie vor direkt an etcd gerichtet werden, was zu unvorhersehbaren Kosten und zusätzlichem Speicherverbrauch führte. Mit der neuen snapshottable API-Server-Cache-Funktion wird dieses Problem gelöst. Der Cache erstellt für jede Aktualisierung leichtgewichtige Snapshots seines Zustands. Diese Snapshots sind “lazy copies”, die keine Objekte duplizieren, sondern lediglich Zeiger speichern, was sie äußerst speichereffizient macht.

Wenn eine LIST-Anfrage für eine historische resourceVersion eingeht, findet der API-Server den entsprechenden Snapshot und bedient die Anfrage direkt aus dem Speicher. Dies ermöglicht es, paginierte Anfragen vollständig aus dem Cache zu bedienen und schließt die letzte bedeutende Lücke in der API-Server-Architektur.

Technische Details/Implikationen

Die Kombination der neuen Funktionen führt zu einer signifikanten Verbesserung der Vorhersagbarkeit und Performance des API-Servers. Konsistente Lesevorgänge und der snapshottable Cache arbeiten zusammen, um nahezu alle Leseanfragen effizient aus dem Speicher zu bedienen. Zudem sorgt das Streaming von LIST-Antworten für einen konstanten und minimalen Speicherverbrauch beim Versand dieser Daten an den Client. Dies führt zu einer stabileren und skalierbareren Kontrollinstanz für Kubernetes-Cluster.

Mit der Einführung von Kubernetes v1.34 ist der SnapshottableCache-Feature-Gate standardmäßig aktiviert, sodass keine zusätzlichen Maßnahmen erforderlich sind, um von diesen Verbesserungen zu profitieren.

Fazit/Ausblick

Die Einführung des snapshottable API-Server-Caches markiert einen bedeutenden Fortschritt in der Leistungsfähigkeit von Kubernetes und bietet eine robuste Grundlage für zukünftige Entwicklungen in der API-Server-Architektur.