Kubernetes v1.34 Node-Swap liefert bis zu 3-fache Pod-Dichte für KI-Agenten-Workloads

Mit dem Erreichen der allgemeinen Verfügbarkeit (General Availability) der Node-Swap-Unterstützung in Kubernetes v1.34 können Infrastrukturteams den Host-Swap durch schnelle, lokale NVMe-SSDs absichern, um die Containerdichte zu erhöhen. Benchmarks in isolierten Ausführungsumgebungen zeigen, dass das Auslagern von inaktivem anonymem Speicher es Nodes ermöglicht, bis zu dreimal so viele gleichzeitige Pods zu hosten, ohne eine Out-Of-Memory-Beendigung auszulösen.

Überwindung historischer Speicherbeschränkungen mit cgroup v2

Traditionelle Kubernetes-Bereitstellungen vermieden Swap aufgrund von Architektur- und Hardwaregrenzen gewöhnlich. Unter cgroup v1 erfassten die Systemkontrollen Arbeitsspeicher und Swap als eine einzige kombinierte Grenze, was den Speicherbedarf von Containern unvorhersehbar und schwer zu isolieren machte. Ältere Magnetfestplatten verursachten zudem erhebliche Latenznachteile, sobald Auslagerungsvorgänge stattfanden.

Kubernetes Node-Swap löst diese betrieblichen Probleme durch das Erfordernis von cgroup v2, das eine unabhängige Swap-Abrechnung einführt. In Kombination mit lokalem NVMe-SSD-Speicher können Nodes plötzliche Spitzen in der RAM-Nutzung abfedern, indem inaktiver Speicher auf die Festplatte ausgelagert wird. Dies verhindert eine vorzeitige Pod-Räumung bei gleichzeitiger Wahrung vorhersagbarer Leistungsgrenzen.

Dichte-Benchmarks über gesandboxte Laufzeiten hinweg

Tests zeigen, wie Swap die Ressourcennutzung über drei typische Entwicklungs- und Ausführungsmuster hinweg verändert. Bei einem Baseline-Build des Linux-6.1.1-Kernels, der Unternehmens-CI/CD-Pipelines repräsentiert, ermöglichte die Aktivierung von NVMe-Swap den Betreibern, das Speicherlimit eines Containers ohne Leistungsverlust von 600 MB auf 300 MB zu halbieren – der Vorgang wurde in 374 Sekunden abgeschlossen, verglichen mit 433 Sekunden ohne Swap. Eine zu starke Einschränkung des Containers auf 200 MB zwang jedoch aktiven Arbeitsspeicher auf die Festplatte, was zu einer I/O-Verlangsamung von über 40 Prozent führte.

Für KI-Agenten und gesandboxte Ausführungsumgebungen fängt Swap den Speicher-Overhead ab, der durch Sicherheitsgrenzen entsteht. Auf einem Node mit 32 vCPUs steigerten ungesandboxte runc-Container die maximale Dichte von 512 auf 768 Pods. Unter gVisor-Isolierung verdoppelte sich die Kapazität von 80 auf 160 Pods, während MicroVMs von Kata Containers von 40 auf 50 Pods anwuchsen, bevor sie an CPU-Grenzen stießen. In isolierten Python-Sandboxes, die Datensätze analysierten und jeweils etwa 375 MiB Hauptspeicher benötigten, lagerte Node-Swap inaktive Zustände aus, um die Sitzungskapazität von 80 auf 240 gleichzeitige Sandboxes zu verdreifachen.

Konfiguration von Node-Swap im Kubelet

Um Node-Swap in Kubernetes v1.34 und neuer zu implementieren, aktualisieren Betreiber die Kubelet-Konfiguration, indem sie failSwapOn auf false setzen und das memorySwap-Verhalten auf LimitedSwap konfigurieren. Diese Konfiguration soll mit Burstable-Quality-of-Service-Einstellungen (QoS) kombiniert werden, bei denen die Speicherlimits von Containern höher als ihre Anfragen eingestellt sind. Unter diesem Modell lagert der Node inaktiven Anwendungsspeicher automatisch aus, während physischer RAM für aktive Verarbeitungsthreads priorisiert wird.

KI-generierte redaktionelle Illustration; kein Dokumentarfoto.

Quelle: Scaling Kubernetes Workloads with Node Swap