Por qué el autoscaling de Kubernetes falla en cargas de trabajo de IA y cómo lo soluciona DRA

Kubernetes ha confiado durante mucho tiempo en una separación clara entre su planificador (scheduler), que coloca pods en nodos existentes, y su escalador automático (autoscaler), que añade nuevos nodos cuando se agota la capacidad. Esta división del trabajo funcionaba bien para el cómputo estándar, pero ahora se está desmoronando bajo el peso de las cargas de trabajo de IA que requieren topologías específicas de aceleradores. A partir de octubre de 2026, la comunidad está rediseñando activamente estos componentes para garantizar que hablen el mismo idioma respecto a las restricciones de hardware.

Qué ocurrió

Durante una década, la premisa de que los recursos de cómputo eran mayormente intercambiables permitió que el planificador y el escalador automático operaran de forma independiente. Sin embargo, los aceleradores de IA como las GPUs no son genéricos; su rendimiento depende en gran medida de cómo están conectados a las CPUs, la memoria y otras GPUs. Un modo de fallo común actual observa pods que permanecen pendientes incluso cuando el clúster parece tener capacidad. El escalador automático añade un nodo, pero el planificador lo rechaza porque la topología del hardware no coincide con los estrictos requisitos de localidad de la carga de trabajo.

El problema central es que el escalador automático responde si añadir o no un nodo, mientras que la verdadera pregunta es si el nodo añadido tiene la forma adecuada para el trabajo. Si el escalador automático aprovisiona un nodo sin comprender el intrincado cableado de los aceleradores, el planificador no puede colocar el pod. Esta discrepancia deja capacidad de acelerador costosa sin usar y retrasa trabajos críticos de inferencia o entrenamiento. La Cloud Native Computing Foundation (CNCF) destaca que esto no es solo un problema específico de un proveedor, sino un desafío arquitectónico fundamental en Kubernetes upstream.

Para abordar esto, la comunidad se dirige hacia un vocabulario compartido para la descripción del hardware. Históricamente, Kubernetes trataba los aceleradores como simples recuentos enteros. Ahora, con la introducción de la Asignación Dinámica de Recursos (DRA), las cargas de trabajo pueden presentar reclamaciones estructuradas que describen no solo cuántos dispositivos necesitan, sino cómo deben estar relacionados esos dispositivos entre sí y con las interfaces de red. Esto permite tanto al planificador como a los escaladores automáticos conscientes de DRA evaluar la capacidad utilizando los mismos criterios detallados.

Cómo funciona

La Asignación Dinámica de Recursos cambia el modelo de recursos de un simple recuento a una reclamación estructurada. En lugar de solicitar cuatro GPUs, una carga de trabajo especifica que necesita cuatro GPUs ubicadas dentro del mismo dominio NUMA y conectadas mediante enlaces de alto ancho de banda. El planificador lee estas reclamaciones directamente para tomar decisiones de colocación. Crucialmente, los escaladores automáticos conscientes de DRA están comenzando a utilizar esta misma información al simular posibles adiciones de capacidad. Esto asegura que, cuando el escalador automático decide escalar hacia arriba, seleccione tipos de nodos que realmente satisfagan las restricciones de topología definidas por la carga de trabajo.

Más allá de la topología, DRA también habilita una compartición más granular de los aceleradores. Los dispositivos modernos son tan potentes que asignar una GPU completa a un trabajo pequeño es desperdiciado. DRA admite dispositivos particionables, permitiendo dividir un único acelerador físico en instancias aisladas o cuotas consumibles. Múltiples cargas de trabajo pueden extraer porciones medidas de un dispositivo simultáneamente. El planificador rastrea estas asignaciones fraccionarias, y los escaladores automáticos pueden ponderar los nodos prospectivos basándose en las rebanadas disponibles en lugar de solo en dispositivos completos. Esto reduce el desperdicio de todo-o-nada que previamente plagaba la utilización de GPU.

A pesar de estos avances, persiste una brecha para la programación en grupo (gang scheduling), donde un conjunto de pods debe programarse junto o no programarse en absoluto. Las APIs actuales de programación consciente de la carga de trabajo permiten al planificador mantener los pods en espera hasta que se pueda colocar un grupo completo, pero el escalador automático todavía razona pod por pod. Puede aprovisionar capacidad parcial para unos pocos miembros de un grupo, desperdiciando recursos mientras el trabajo espera por el resto. Un mecanismo provisional llamado solicitud de aprovisionamiento intenta cerrar esta brecha permitiendo a las cargas de trabajo solicitar capacidad de grupo de forma atómica, pero sigue siendo una solución añadida (bolt-on) en lugar de una característica profundamente integrada.

Detalles clave

• La topología importa: El rendimiento del acelerador depende de la localidad, incluyendo dominios NUMA de CPU, rutas PCIe y enlaces inter-GPU, no solo del recuento de dispositivos.
• Asignación Dinámica de Recursos (DRA): Reemplaza las solicitudes de recursos basadas en enteros con reclamaciones estructuradas que describen relaciones entre dispositivos e interfaces de red.
• Vocabulario compartido: DRA permite tanto al planificador como al escalador automático entender las restricciones de hardware de manera idéntica, reduciendo las discrepancias de aprovisionamiento.
• Compartición fraccionaria: DRA admite dispositivos particionables y capacidad consumible, permitiendo que múltiples cargas de trabajo compartan un único acelerador eficientemente.
• Brecha en la programación en grupo: Mientras que el planificador admite la colocación atómica de grupos, el escalador automático aún escala pod-por-pod, lo que lleva a un posible desperdicio para grandes trabajos distribuidos.
• Integración futura: SIG-Autoscaling y SIG-Scheduling están diseñando APIs para permitir que el planificador vea la capacidad aprovisionable y la solicite explícitamente.

Por qué importa

Para los equipos de ingeniería que gestionan infraestructura de IA, esta discrepancia se traduce directamente en presupuesto desperdiciado y ciclos de iteración más lentos. Las horas de GPU son caras, y tenerlas inactivas debido a un desacuerdo entre programación y aprovisionamiento es un costo operativo significativo. Comprender que un pod pendiente podría no indicar una falta de capacidad regional, sino más bien una discrepancia de topología, cambia cómo los equipos depuran y optimizan sus clústeres. Desplaza el enfoque de simplemente añadir más nodos a asegurar que los nodos añadidos sean compatibles con las necesidades estructurales de la carga de trabajo.

Además, el movimiento hacia un diseño integrado significa que las futuras características de Kubernetes considerarán las implicaciones de autoscaling desde el principio. En lugar de adaptar el soporte de autoscaling después de que se lance una nueva primitiva de programación, la comunidad está construyendo interfaces que permiten a los dos bucles de control coordinarse proactivamente. Esta evolución es crítica para soportar inferencias explosivas (bursty) y cargas de trabajo agénticas que no pueden tolerar la latencia de los arranques en frío o los nodos mal aprovisionados. Los equipos que ejecutan aceleradores ahora tienen un interés en estas discusiones upstream, ya que los estándares resultantes definirán la eficiencia de su infraestructura durante años venideros.

Qué puedes hacer

• Auditar pods pendientes: Verifica si los pods de GPU pendientes se deben a discrepancias de topología en lugar de un verdadero agotamiento de capacidad.
• Adoptar DRA: Migra las cargas de trabajo para usar reclamaciones de Asignación Dinámica de Recursos para expresar explícitamente los requisitos de topología y compartición.
• Habilitar la programación consciente de la carga de trabajo: Prueba las APIs beta Workload y PodGroup para mejorar el comportamiento de la programación en grupo, teniendo en cuenta que están deshabilitadas por defecto.
• Evaluar la compatibilidad del escalador automático: Verifica si tu implementación actual del escalador automático es consciente de DRA y puede simular restricciones de topología durante el escalado hacia arriba.
• Monitorear la fragmentación: Rastrea las métricas de utilización de GPU para identificar desperdicios por asignaciones de todo-o-nada y considera habilitar la compartición fraccionaria.
• Participar con los SIGs: Participa en las discusiones de SIG-Autoscaling y SIG-Scheduling para influir en el diseño de las próximas APIs de integración.