Kubernetes-Swap auf NVMe verdreifacht in Tests die Sandbox-Dichte – aber nur für ruhenden Speicher

Victoria Shinder06 October 2026, 09:221 Min. Lesezeit

Der Kubernetes-Blog hat am 5. Oktober Messungen zum Betrieb von Knoten mit aktiviertem Swap veröffentlicht – eine Funktion, die mit Kubernetes 1.34 allgemein verfügbar wurde. Das Argument zielt auf agentische KI-Workloads: Sandboxen, die zum Start und für fremden Code viel Speicher brauchen und dann untätig auf den nächsten Prompt warten, während sie RAM belegen, der die Zahl der Pods pro Knoten begrenzt.

Warum Swap verpönt war und was sich geändert hat. Unter cgroup v1 teilten sich Speicher und Swap ein gemeinsames Limit, sodass der tatsächliche Speicherverbrauch eines Containers schwer vorherzusagen und zu isolieren war. Die Swap-Unterstützung von Kubernetes setzt auf cgroup v2, das Swap getrennt erfasst. Der zweite Einwand, die Latenz beim Auslagern auf rotierende Platten, entfällt mit schnellen lokalen NVMe-SSDs weitgehend.

Was gemessen wurde. Drei Workload-Typen, mit Swap auf Local SSD:

• Linux-Kernel-Build (wie in CI). Das Mindestlimit gegen einen Out-of-Memory-Abbruch sank von 600 MB auf 300 MB, der Build lief in 374 s statt 433 s ohne Swap. Bei 200 MB rutschte der aktive Arbeitsbereich in den Swap, und der Build wurde um mehr als 40 % langsamer.
• Headless-Chrome-Sandboxen. Unter gVisor stieg ein Knoten von 80 auf 160 gleichzeitige Pods, unter Kata Containers von 40 auf 50. Einfache runc-Container auf einem Knoten mit 32 vCPU und 120 GB scheiterten ohne Swap ab 512 Pods und schafften mit Swap 768.
• Python-Sandboxen unter gVisor. Von 80 auf 240 gleichzeitige Pods – der größte Zuwachs, das Dreifache.

Die Einschränkung, die die Autoren selbst machen. Swap ist eine Versicherung für Lastspitzen und für belegten, aber ruhenden Speicher, kein Ersatz für RAM, den die Arbeit aktiv nutzt. Der Kernel-Build zeigt die Grenze: Das Limit zu halbieren kostete nichts, es um zwei Drittel zu senken dagegen schon.

Die Tests liefen in Google Cloud mit Swap auf Local SSD; der runc-Durchlauf nutzte einen Knoten c4-standard-32.