Kubernetes Node Swap en Linux: guía de operación y riesgos

Swap amortigua picos; no equivale a instalar más RAM

Swap permite que el kernel mueva páginas de memoria menos activas desde RAM hacia almacenamiento. Puede reducir terminaciones durante ciertos picos y ayudar a algunas cargas intermitentes, pero recuperar páginas desde disco agrega latencia e I/O. Si la carga mantiene un conjunto de trabajo activo mayor que la RAM disponible, el nodo puede caer en swapping constante y volverse más lento.

En Kubernetes, la opción de usar swap para cargas llegó a disponibilidad general en la versión 1.34. Esa madurez solo describe la función upstream: la distribución, el proveedor administrado, el kernel, el runtime y el almacenamiento del nodo todavía determinan qué configuración es válida. Al 17 de octubre de 2026, el proyecto publica las ramas 1.35, 1.36 y 1.37; consulta también el ciclo y soporte de tu proveedor.

La mejora de densidad publicada por Kubernetes se midió en perfiles específicos, entre ellos sandboxes y discos locales rápidos. No predice el resultado de una aplicación empresarial distinta. Úsala como motivo para diseñar una prueba, no como una promesa de ahorro o rendimiento.

Qué hacen los valores predeterminados

Por defecto, failSwapOn hace que kubelet falle si detecta swap habilitado en el nodo. El comportamiento NoSwap impide que los Pods utilicen swap, aunque procesos fuera de los contenedores administrados por Kubernetes, incluido kubelet, todavía podrían usar el swap del sistema. Por eso hay que distinguir entre permitir que el nodo arranque con swap y permitir que las cargas de Kubernetes lo consuman.

Para permitirlo, la configuración de kubelet debe tolerar swap y establecer LimitedSwap. El ejemplo solo ilustra campos upstream: aplícalo mediante el mecanismo soportado por tu distribución o proveedor, en un grupo de nodos de prueba y con su procedimiento de reversión disponible. La ubicación del archivo y la forma de reiniciar o reemplazar nodos no son universales.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failSwapOn: false
memorySwap:
  swapBehavior: LimitedSwap

LimitedSwap limita automáticamente el uso de swap por Pod. Según la documentación vigente de Kubernetes, solo Pods con calidad de servicio Burstable pueden utilizarlo; BestEffort, Guaranteed y Pods de alta prioridad no. En un Pod Burstable, igualar solicitud y límite de memoria del contenedor puede excluirlo del uso de swap. Verifica el comportamiento exacto de tu versión antes de diseñar capacidad alrededor de ese límite.

Comprueba primero cgroup, versión y almacenamiento

La contabilidad separada de memoria y swap de cgroup v2 es una pieza central del soporte de Kubernetes. Confirma la jerarquía de control y el swap presente en cada nodo Linux; repetir estas lecturas durante una ventana operativa permite comparar hosts y detectar diferencias entre grupos.

# Tipo de jerarquía de control montada en el nodo
findmnt -n -o FSTYPE /sys/fs/cgroup

# Dispositivos y uso de swap configurados por Linux
swapon --show --bytes

# Presión reciente de memoria y de I/O del host
cat /proc/pressure/memory
cat /proc/pressure/io

En cgroup v2, el kernel expone también límites y contadores propios del grupo. Para diagnosticar un servicio Linux fuera de Kubernetes, consulta nuestra guía de presión de memoria con PSI, cgroups y systemd. No infieras que un nodo es compatible solo porque swaponmuestra un dispositivo activo: confirma soporte del proveedor, versión de kernel y runtime, configuración de kubelet y capacidad real del disco.

El almacenamiento importa. Un disco limitado por IOPS puede perjudicar tanto a las cargas como a servicios críticos del nodo cuando aumenta el intercambio. Kubernetes recomienda swap cifrado; recomienda además que los nodos del plano de control funcionen sin swap configurado. No mezcles swap experimental con el disco raíz saturado ni asumas que una VM ofrece el rendimiento de un NVMe local.

Protege datos y cargas críticas

Una página que sale de RAM puede terminar en almacenamiento persistente. Si el swap no está cifrado, un secreto que haya pasado por memoria puede quedar expuesto fuera del ciclo normal del contenedor. Evalúa cifrado y recuperación de claves en el sistema operativo antes de activar la función. Kubernetes no configura ni gestiona el cifrado del swap por ti.

Los volúmenes de memoria, como emptyDir con medium: Memory y los montajes tmpfs de Secrets, necesitan una revisión aparte. La opción de montaje noswap está soportada por el kernel upstream desde la versión 6.3; algunas distribuciones la retroportan a kernels anteriores. Comprueba el soporte efectivo del host y los avisos de kubelet; no des por hecho que todo tmpfs queda protegido en cualquier kernel.

Prioriza las unidades de systemd y demonios necesarios para mantener el nodo. Si aparece degradación por I/O, la documentación describe limitar swap para la porción del sistema y dar prioridad de latencia a servicios críticos. Para el plano de control, el criterio upstream es más sencillo: mantenerlo sin swap configurado.

El scheduler no planifica según el swap disponible

Aunque LimitedSwap impone límites por Pod, la documentación de Kubernetes 1.37 indica que el scheduler no incluye el uso de swap en sus decisiones de colocación. Una carga que puede intercambiar páginas no reserva una cuota de swap en la API del mismo modo que solicita memoria. Si mezclas nodos con y sin swap, podrías colocar una carga en un nodo que no cumpla sus expectativas operativas.

Para una prueba especializada, considera un grupo de workers separado y protegido mediante etiquetas, afinidad y taints tolerados solo por las cargas aprobadas. Esas reglas deben seguir el diseño de tu plataforma: una etiqueta aislada no garantiza seguridad si los workloads pueden tolerar cualquier taint o seleccionar cualquier nodo.

Cargas por lotes o sesiones que pasan largos periodos inactivas pueden ser candidatas a evaluar. Bases de datos con límites estrictos de latencia, servicios sensibles a pausas y nodos del plano de control requieren un análisis más conservador. No clasifiques una carga por tecnología; mide su patrón de memoria, latencia y recuperación.

Prueba gradual y mide efectos adversos

1. Inventaría la versión de Kubernetes, sistema operativo, kernel, runtime, jerarquía cgroup, almacenamiento de swap, cifrado y configuración actual de kubelet.
2. Selecciona una carga Burstable y no crítica. Define latencia máxima, errores, tiempo de recuperación, presión de I/O, OOM y umbral para detener la prueba antes de cambiar nada.
3. Configura un grupo pequeño de workers según el procedimiento del proveedor. Mantén fuera los nodos de control y conserva capacidad para mover o recuperar la carga.
4. Revisa métricas de nodo y contenedor como node_swap_usage_bytes, container_swap_usage_bytes y container_swap_limit_bytes cuando la versión y la ruta de observabilidad las expongan.
5. Correlaciona esas métricas con PSI de memoria e I/O, latencia de disco, evicciones, reinicios, OOM y latencia de aplicación. El aumento de Pods por nodo no es éxito si crecen las pausas o se degrada el sistema.
6. Decide con los resultados de tu carga. Si empeora la cola de I/O o la latencia, retira primero la carga de ese grupo y aplica la reversión documentada por el proveedor; no desactives swap abruptamente bajo presión sin conocer el uso actual.

Para el panorama de versión, compatibilidad y recuperación, complementa esta prueba con el checklist de cambios operativos de Kubernetes 1.37. El monitoreo de servidores debe cubrir tanto disponibilidad como presión de recursos; consulta también la guía de métricas, registros y alertas para Linux.

Decide a partir de una carga medida

Node Swap añade una herramienta de gestión de memoria, no una reserva gratuita de capacidad. La decisión depende de versiones compatibles, cifrado, almacenamiento, calidad de servicio, aislamiento de nodos y tolerancia a latencia de la carga. Una prueba acotada puede demostrar si ese intercambio sirve en tu entorno; cifras publicadas para otro hardware no reemplazan esa evidencia.

Elaine System ofrece revisión de infraestructura Linux y Kubernetes. El alcance se define con versiones, topología, restricciones y objetivos de servicio; no se realizan cambios en producción sin evaluación y aprobación del responsable del entorno.