Linux-Swap-Parameter für stabile Kubernetes-Nodes optimieren

In einem Beitrag im Kubernetes-Blog vom August 2025 erläuterte Ajay Sundar Karuppasamy von Google, wie man Linux-Swap für Kubernetes-Cluster optimiert. Der Artikel befasst sich mit der bevorstehenden Stabilisierung des NodeSwap-Features in Kubernetes v1.34, das es Nodes ermöglicht, Festplattenspeicher als virtuellen Speicher zu nutzen. Diese Umstellung erfordert eine sorgfältige Konfiguration der Kernel-Parameter, um die Ressourcennutzung und die Systemstabilität in Einklang zu bringen.

Was passiert ist

Jahrelang lautete die Standardempfehlung für Kubernetes-Operatoren, Swap vollständig zu deaktivieren, um vorhersagbare Performance zu gewährleisten. Die Einführung des NodeSwap-Features ändert dieses Paradigma jedoch, indem es Linux-Nodes erlaubt, seltener genutzte Speicherseiten auf Sekundärspeicher auszulagern. Diese Funktion zielt darauf ab, Out-of-Memory-Kills (OOM) zu reduzieren und die allgemeine Ressourceneffizienz zu verbessern. Trotz dieser Vorteile ist die Aktivierung von Swap kein einfaches Umschalten. Ohne präzise Tuning kann dies zu schwerwiegenden Performance-Einbußen führen und die Fähigkeit des Kubelets beeinträchtigen, Pod-Evictions ordnungsgemäß zu verwalten.

Der Artikel hebt hervor, dass falsch konfigurierte Swap-Einstellungen dazu führen können, dass sich der Kernel unter Speicherdruck unvorhersehbar verhält. In Tests mit Standardeinstellungen erlebten Nodes unerwartete Neustarts und vorzeitige OOM-Kills bei hohen Speicherzuweisungsraten. Das Kernproblem liegt in der Interaktion zwischen den Seiten-Austauschalgorithmen des Linux-Kernels und der Eviction-Logik von Kubernetes. Wenn der Kernel nicht schnell genug Speicher freigibt oder den falschen Speichertyp freisetzt, kann der Node instabil werden, bevor das Kubelet eingreifen kann.

Um diese Herausforderungen anzugehen, führte der Autor eine Reihe von Stresstests auf Google Kubernetes Engine (GKE)-Nodes durch, auf denen Kubernetes v1.33.2 lief. Die Tests umfassten benutzerdefinierte Go-Anwendungen, die verschiedene Speicherzugriffsmuster und -belastungen simulierten. Durch die Anpassung spezifischer Kernel-Parameter demonstrierte der Autor, wie ein sichereres Betriebsfenster für das Speichermanagement geschaffen wird, um kritische Ausfälle während plötzlicher Lastspitzen zu verhindern.

Wie es funktioniert

Linux verwaltet den Speicher in Seiten, typischerweise jeweils 4 KiB groß. Wenn der physische RAM voll ist, muss der Kernel entscheiden, welche Seiten in den Swap-Bereich verschoben werden. Er unterscheidet dabei zwischen anonymem Speicher, wie Heap- und Stack-Daten, und dateibasiertem Speicher, wie ausführbarem Code und Caches. Anonyme Seiten müssen auf ein Swap-Gerät geschrieben werden, um freigegeben zu werden, während saubere dateibasierte Seiten einfach verworfen werden können. Der Kernel verwendet mehrere Parameter, um diese Entscheidungen zu steuern, primär vm.swappiness, der die Präferenz für das Swappen anonymer Seiten gegenüber dem Verwerfen des Datei-Caches regelt.

Zwei weitere kritische Parameter sind vm.min_free_kbytes und vm.watermark_scale_factor. Die Einstellung min_free_kbytes definiert einen Sicherheitspuffer für freien Speicher. Wenn der verfügbare Speicher unter diesen Schwellenwert fällt, gibt der Kernel aggressiv Seiten frei. Der watermark_scale_factor bestimmt die Lücke zwischen den niedrigen, minimalen und hohen Speicher-Watermarks. Eine größere Lücke gibt dem Hintergrund-Freigabeprozess, bekannt als kswapd, mehr Zeit, um Seiten schrittweise in den Swap-Bereich zu verschieben. Dies verhindert, dass das System zu schnell die kritische min-Watermark erreicht, was sonst Prozess-Zuweisungen blockieren und OOM-Kills auslösen würde.

Wichtige Details

• Das NodeSwap-Feature soll in Kubernetes v1.34 den stabilen Status erreichen.
• Die Tests wurden auf GKE-Nodes mit 8 GiB RAM und 50 GB Swap auf pd-balanced Disks durchgeführt.
• Standardeinstellungen (swappiness=60, min_free_kbytes=68MB) führten unter hoher Last zu OOM-Kills.
• Eine Erhöhung von min_free_kbytes auf 512 MiB erzwingt eine frühere Speicherfreigabe und bietet einen größeren Sicherheitspuffer.
• Das Setzen von watermark_scale_factor auf 2000 erweitert das Swap-Fenster und ermöglicht es kswapd, effektiver zu arbeiten.
• Kritischen Systemkomponenten wie kubelet und Container-Runtime sollte Swap über cgroups deaktiviert werden.

Warum es wichtig ist

Für Software-Ingenieure und Plattform-Teams führt die Aktivierung von Swap zu einem komplexen Kompromiss zwischen Kapazität und Latenz. Swapping ist deutlich langsamer als der Zugriff auf RAM; wenn der aktive Working Set einer Anwendung auf die Festplatte ausgelagert wird, leidet die Performance aufgrund erhöhter I/O-Wartezeiten. Richtig getunter Swap kann jedoch abrupte Anwendungsabstürze durch OOM-Kills verhindern, die oft disruptiver sind als temporäre Latenzspitzen. Das Verständnis dieser Kernel-Mechanismen ist entscheidend für den Aufbau widerstandsfähiger Systeme, die Memory Overcommitment sicher handhaben können.

Darüber hinaus kann ein unsachgemäßes Tuning zugrunde liegende Probleme wie Memory Leaks verdecken. Anstatt schnell mit einem OOM-Kill zu scheitern, könnte eine leaky Application die Node-Performance langsam degradieren, indem sie Swap-Space verbraucht, was die Diagnose erschwert. Es besteht auch das Risiko, dass die graceful Eviction-Mechanismen von Kubernetes umgangen werden. Wenn der Kernel einen OOM-Kill auslöst, bevor das Kubelet Pods basierend auf Richtlinien evictieren kann, können höher priorisierte Workloads unerwartet beendet werden. Daher ist es entscheidend, das Verhalten des Kernels mit den Erwartungen von Kubernetes in Einklang zu bringen, um die Cluster-Gesundheit aufrechtzuerhalten.

Was Sie tun können

• Beginnen Sie mit vm.swappiness=60 für Allzweck-Workloads, passen Sie dies aber an, je nachdem, ob Ihre Apps I/O-sensitiv oder cache-lastig sind.
• Setzen Sie vm.min_free_kbytes auf ungefähr 2–3 % des gesamten Node-Speichers (z. B. 500 MB für einen 8-GiB-Node), um einen ausreichenden Sicherheitspuffer zu schaffen.
• Erhöhen Sie vm.watermark_scale_factor auf 2000, um das Fenster für die Hintergrund-Speicherfreigabe zu erweitern und plötzliche OOM-Ereignisse zu verhindern.
• Schützen Sie kritische System-Daemons, indem Sie memory.swap.max=0 in ihren cgroups setzen, damit sie unter Druck reaktionsfähig bleiben.
• Benchmarken Sie diese Einstellungen in einer Testumgebung mit Ihren spezifischen Workloads, da die Performance je nach Disk-Typ und CPU-Last variiert.
• Überwachen Sie I/O-Wartezeiten und Swap-Nutzung genau, um Thrashing oder versteckte Memory Leaks frühzeitig zu erkennen.