Kubernetes v1.34: El intercambio de memoria en nodos aumenta hasta 3 veces la densidad de pods en cargas de trabajo con agentes de IA

Con el soporte para el intercambio de memoria en nodos (node swap) alcanzando la disponibilidad general en Kubernetes v1.34, los equipos de infraestructura pueden respaldar el intercambio del host con unidades de estado sólido locales NVMe de alta velocidad para incrementar la densidad de contenedores. Las pruebas de rendimiento en entornos de ejecución aislados demuestran que transferir a disco la memoria anónima inactiva permite a los nodos albergar hasta tres veces más pods concurrentes sin activar la finalización por falta de memoria (Out-Of-Memory).

Superación de las limitaciones históricas de memoria mediante cgroup v2

Los despliegues tradicionales de Kubernetes evitaban sistemáticamente el uso de espacio de intercambio debido a limitaciones arquitectónicas y de hardware. Bajo cgroup v1, los controles del sistema rastreaban la memoria y el espacio de intercambio como un único límite combinado, lo que hacía que la huella de memoria de los contenedores fuera impredecible y difícil de aislar. Asimismo, los discos duros mecánicos antiguos introducían penalizaciones de latencia significativas cada vez que se producía la paginación.

El intercambio de memoria en nodos de Kubernetes resuelve estos problemas operativos al requerir cgroup v2, el cual introduce una contabilidad independiente para el espacio de intercambio. Al combinarse con almacenamiento SSD NVMe local, los nodos pueden absorber picos repentinos en el uso de RAM paginando la memoria inactiva a disco, lo que previene la expulsión prematura de pods manteniendo límites de rendimiento predecibles.

Pruebas de rendimiento de densidad en entornos de ejecución aislados

Las pruebas demuestran cómo el intercambio de memoria altera la utilización de recursos en tres patrones habituales de desarrollo y ejecución. En una compilación base del kernel de Linux 6.1.1, representativa de las canalizaciones empresariales de CI/CD, activar el intercambio en NVMe permitió a los operadores reducir a la mitad el límite de memoria de un contenedor, pasando de 600 MB a 300 MB sin pérdida de rendimiento, completándose en 374 segundos frente a los 433 segundos sin espacio de intercambio. Sin embargo, restringir en exceso el contenedor a 200 MB forzó el conjunto de trabajo activo a trasladarse al disco, causando una ralentización de E/S superior al 40 por ciento.

En el caso de los agentes de IA y los entornos de ejecución aislados, el intercambio de memoria absorbe la sobrecarga de memoria creada por los límites de seguridad. En un nodo de 32 vCPU, los contenedores runc sin aislamiento aumentaron su densidad máxima de 512 a 768 pods. Bajo el aislamiento de gVisor, la capacidad se duplicó de 80 a 160 pods, mientras que las microVM de Kata Containers pasaron de 40 a 50 pods antes de alcanzar las limitaciones de CPU. En entornos aislados de Python que analizaban conjuntos de datos con un requisito de aproximadamente 375 MiB de memoria residente cada uno, el intercambio de memoria en el nodo liberó los estados inactivos para triplicar la capacidad de sesiones, pasando de 80 a 240 entornos aislados concurrentes.

Configuración del intercambio de memoria en nodos dentro de Kubelet

Para implementar el intercambio de memoria en nodos en Kubernetes v1.34 y versiones posteriores, los operadores deben actualizar la configuración del kubelet ajustando failSwapOn a false y configurando el comportamiento de memorySwap como LimitedSwap. Esta configuración está diseñada para combinarse con los ajustes de calidad de servicio (QoS) de tipo Burstable, donde los límites de memoria de los contenedores se establecen por encima de sus solicitudes. Bajo este modelo, el nodo pagina automáticamente la memoria inactiva de las aplicaciones mientras prioriza la RAM física para los hilos de procesamiento activos.

Ilustración editorial generada con IA; no es una fotografía documental.

Fuente: Scaling Kubernetes Workloads with Node Swap