Kubernetes explica el swap de nodo, ya en GA desde la versión 1.34

Kubernetes ha publicado una guía para usar swap de nodo, en disponibilidad general desde la versión 1.34, como forma de meter más pods en el mismo hardware. La idea es paginar memoria anónima inactiva a un SSD NVMe local. El kubelet se activa con failSwapOn en false y swapBehavior en LimitedSwap. No es un cambio de API menor ni un preview: el mecanismo ya es GA. Tampoco es RAM gratis. La propia guía dice que un límite demasiado bajo empuja el conjunto activo a disco y la espera de E/S se come el supuesto ahorro.

Qué problema intenta resolver

El post del 5 de octubre parte de un límite físico conocido: el nodo se queda sin memoria antes que sin CPU. Las cargas que arrancan grandes, ejecutan y luego esperan, agentes, sandboxes o algunas JVM, dejan memoria residente parada. Con el límite clásico, o se reserva de más y se desperdicia RAM, o se aprieta y aparece el OOM. El swap de nodo actúa como colchón para ese tramo inactivo, no como sustituto del working set.

El proyecto recuerda por qué el swap estuvo desaconsejado. Con cgroup v1, memoria y swap compartían tope y un contenedor podía paginar sin que el límite contara de forma útil. El soporte actual exige cgroup v2, que lleva la contabilidad de swap aparte. El otro reparo histórico era el disco mecánico. La guía asume SSD NVMe local, no un volumen de red ni un disco giratorio de cortesía.

-InfraCrew dice: Años diciendo que swap y Kubernetes no se hablaban. El kubelet ha pedido mesa para dos.-

Cómo se enciende, y para quién

En 1.34 o posterior el bloque del kubelet es corto: failSwapOn a false y swapBehavior en LimitedSwap. LimitedSwap reparte swap a contenedores de QoS Burstable, los que tienen límite de memoria por encima de la request. Un pod Guaranteed no entra en ese reparto. No basta con crear un fichero de swap en el nodo y esperar densidad. Hace falta disco local rápido, cgroup v2 y cargas que de verdad tengan memoria fría.

El post cita soporte nativo en GKE mediante Node Memory Swap sobre perfiles de Local SSD. Eso es un ejemplo de plataforma, no una exclusividad. En bare metal o en otra nube el requisito es el mismo: el kubelet tiene que ver swap de nodo y el disco tiene que aguantar la paginación sin convertirse en el cuello de botella.

Las cifras son del blog, no de todos los clústeres

Kubernetes publica una tabla de pruebas. Un build de kernel bajó el límite de 600 MB a 300 MB sin alargar la ejecución, y a 200 MB el tiempo subió más de un 40 % porque el conjunto activo acabó en swap. Chrome headless con gVisor pasó de 80 a 160 pods. Un sandbox Python con gVisor pasó de 80 a 240, el triple. Kata subió de 40 a 50. Son resultados de ese banco, con ese disco y ese runtime, no una promesa de densidad para cualquier Deployment. El texto atribuye la latencia extra en el pico sobre todo a la pelea por CPU, no al swap en sí.

-InfraCrew dice: El gráfico de densidad queda muy bien hasta que el límite de 200 MB recuerda quién manda.-

Hay un matiz de ciclo de vida que el post no lidera y el calendario sí. Kubernetes 1.34 entró en mantenimiento el 27 de agosto de 2026 y llega a fin de vida el 27 de octubre de 2026. La guía sirve en esa rama y en las posteriores que conserven el GA. Montar el cambio solo en 1.34, a tres semanas de su EOL, es elegir el nodo que habrá que subir enseguida. El swap no obliga a quedarse en 1.34. Obliga a leer la versión del clúster antes de copiar el manifiesto.

Qué mirar antes de activarlo

Comprobar que el nodo tiene cgroup v2 y un SSD local, no un disco compartido por NFS con buena voluntad. Medir memoria fría de verdad: agentes o granjas de navegador encajan mejor que una base de datos cuya página caliente no debería salir de RAM. Dejar límite por encima de request si se quiere Burstable. Y probar el caso feo, el de 200 MB del ejemplo, antes de bajar límites en producción. Si la latencia se dispara, el swap está haciendo de RAM y la guía ya avisó de que eso no es el diseño.

Diccionario de la Crew

kubelet — Agente de nodo de Kubernetes. Aquí es quien decide si el nodo puede usar swap y cómo se reparte.
cgroup v2 — Jerarquía de control de recursos del kernel Linux. El swap de nodo de Kubernetes depende de su contabilidad separada de memoria y swap.
OOM — Muerte de un proceso por falta de memoria. Es el fallo que un límite demasiado bajo provoca si el swap no cubre el pico, o si el disco no da abasto.

Kubernetes | https://kubernetes.io/blog/2026/10/05/scaling-kubernetes-workloads-with-node-swap
Kubernetes 1.34 | https://kubernetes.io/releases/1.34/