Ajuste de los parámetros de swap en Linux para nodos estables de Kubernetes

En una publicación en el blog de Kubernetes en agosto de 2025, Ajay Sundar Karuppasamy, de Google, detalló cómo ajustar el swap de Linux para clústeres de Kubernetes. El artículo aborda la próxima estabilización de la función NodeSwap en Kubernetes v1.34, que permite a los nodos utilizar espacio en disco como memoria virtual. Este cambio requiere una configuración cuidadosa de los parámetros del kernel para equilibrar la utilización de recursos con la estabilidad del sistema.

Qué ocurrió

Durante años, el consejo estándar para los operadores de Kubernetes fue desactivar completamente el swap para garantizar un rendimiento predecible. Sin embargo, la introducción de la función NodeSwap cambia este paradigma al permitir que los nodos Linux descarguen las páginas de memoria menos utilizadas en el almacenamiento secundario. Esta capacidad busca reducir las terminaciones por falta de memoria (OOM kills) y mejorar la eficiencia general de los recursos. A pesar de estos beneficios, habilitar el swap no es simplemente un interruptor. Sin un ajuste preciso, puede provocar una degradación severa del rendimiento e interferir con la capacidad del Kubelet para gestionar las expulsiones de pods de manera elegante.

El artículo destaca que una configuración incorrecta de los ajustes de swap puede hacer que el kernel se comporte de manera impredecible bajo presión de memoria. En pruebas realizadas con la configuración predeterminada, los nodos experimentaron reinicios inesperados y terminaciones prematuras por OOM cuando fueron sometidos a altas tasas de asignación de memoria. El problema central radica en la interacción entre los algoritmos de reemplazo de páginas del kernel de Linux y la lógica de expulsión de Kubernetes. Si el kernel no recupera la memoria lo suficientemente rápido, o si recupera el tipo incorrecto de memoria, el nodo puede volverse inestable antes de que el Kubelet tenga la oportunidad de actuar.

Para abordar estos desafíos, el autor realizó una serie de pruebas de estrés en nodos de Google Kubernetes Engine (GKE) que ejecutaban Kubernetes v1.33.2. Las pruebas involucraron aplicaciones personalizadas en Go diseñadas para simular varios patrones y presiones de acceso a la memoria. Al ajustar parámetros específicos del kernel, el autor demostró cómo crear una ventana operativa más segura para la gestión de memoria, previniendo fallos críticos durante picos súbitos de demanda.

Cómo funciona

Linux gestiona la memoria en páginas, típicamente de 4KiB cada una. Cuando la RAM física está llena, el kernel debe decidir qué páginas mover al espacio de swap. Distingue entre memoria anónima, como datos de heap y stack, y memoria respaldada por archivos, como código ejecutable y cachés. Las páginas anónimas deben escribirse en un dispositivo de swap para ser recuperadas, mientras que las páginas limpias respaldadas por archivos pueden simplemente descartarse. El kernel utiliza varios parámetros para guiar estas decisiones, principalmente vm.swappiness, que controla la preferencia por intercambiar páginas anónimas frente a eliminar la caché de archivos.

Otros dos parámetros críticos son vm.min_free_kbytes y vm.watermark_scale_factor. La configuración min_free_kbytes define un búfer de seguridad de memoria libre. Cuando la memoria disponible cae por debajo de este umbral, el kernel recupera páginas agresivamente. El watermark_scale_factor determina la brecha entre los niveles bajos, mínimos y altos de memoria (watermarks). Una brecha mayor otorga al proceso de recuperación en segundo plano, conocido como kswapd, más tiempo para mover páginas al swap gradualmente. Esto evita que el sistema alcance demasiado rápido el nivel mínimo crítico, lo cual bloquearía las asignaciones de procesos y provocaría terminaciones por OOM.

Detalles clave

• Se espera que la función NodeSwap alcance el estado estable en Kubernetes v1.34.
• Las pruebas se realizaron en nodos GKE con 8GiB de RAM y 50GB de swap en discos pd-balanced.
• La configuración predeterminada (swappiness=60, min_free_kbytes=68MB) condujo a terminaciones por OOM bajo alta carga.
• Aumentar min_free_kbytes a 512MiB fuerza una recuperación de memoria más temprana, proporcionando un búfer de seguridad más grande.
• Establecer watermark_scale_factor en 2000 amplía la ventana de intercambio, permitiendo que kswapd trabaje de manera más efectiva.
• Componentes críticos del sistema como kubelet y el runtime de contenedores deberían tener el swap deshabilitado mediante cgroups.

Por qué importa

Para ingenieros de software y equipos de plataforma, habilitar el swap introduce una compleja compensación entre capacidad y latencia. El intercambio es significativamente más lento que el acceso a la RAM, por lo que si el conjunto activo de trabajo de una aplicación se mueve al disco, el rendimiento sufrirá debido a mayores tiempos de espera de E/S. Sin embargo, un swap correctamente ajustado puede prevenir fallos abruptos de aplicaciones causados por terminaciones por OOM, que suelen ser más disruptivos que los picos temporales de latencia. Comprender estos mecanismos del kernel es esencial para construir sistemas resilientes que puedan manejar la sobreasignación de memoria de forma segura.

Además, un ajuste inadecuado puede ocultar problemas subyacentes como fugas de memoria. En lugar de fallar rápidamente con una terminación por OOM, una aplicación con fugas podría degradar lentamente el rendimiento del nodo consumiendo espacio de swap, dificultando el diagnóstico. También existe el riesgo de saltarse los mecanismos de expulsión elegante de Kubernetes. Si el kernel provoca una terminación por OOM antes de que el Kubelet pueda expulsar pods basándose en la política, cargas de trabajo de mayor prioridad podrían terminar inesperadamente. Por lo tanto, alinear el comportamiento del kernel con las expectativas de Kubernetes es crucial para mantener la salud del clúster.

Qué puedes hacer

• Comienza con vm.swappiness=60 para cargas de trabajo de propósito general, pero ajusta según si tus aplicaciones son sensibles a la E/S o intensivas en caché.
• Establece vm.min_free_kbytes en aproximadamente el 2-3% de la memoria total del nodo (por ejemplo, 500MB para un nodo de 8GiB) para crear un búfer de seguridad suficiente.
• Aumenta vm.watermark_scale_factor a 2000 para expandir la ventana de recuperación de memoria en segundo plano y prevenir terminaciones por OOM.