El problema del autoescalado de las cargas de GPU puede no ser que Kubernetes no tome la decisión, sino que la decisión llegue demasiado tarde. Ramkumar Nagaraj y Bingi Narasimha Karthik, de Adobe, describen un incidente en el que un servicio de producción crítico sufrió una oleada de demanda que elevó las tasas de error de los usuarios al 15–20 %, aunque el Horizontal Pod Autoscaler había iniciado el escalado. La razón fue que cientos de contenedores permanecieron en espera, mientras que los nuevos nodos de GPU necesitaron mucho tiempo para estar listos.
En la secuencia documentada por los autores, la oleada de demanda llegó a las 06:00, los indicadores del HPA superaron el umbral a las 06:05 y la programación de los contenedores comenzó a las 06:15. Sin embargo, los primeros nodos de GPU no terminaron de aprovisionarse hasta las 06:45, es decir, después de que terminara el pico. El aprovisionamiento de nodos de GPU suele tardar entre tres y cinco veces más que el de los servicios basados en CPU, debido a la carga del firmware, la configuración de los controladores y la preparación de CUDA.
De reaccionar a la demanda a estar preparados para ella
El equipo propuso ejecutar un controlador dentro de Kubernetes cada 60 segundos, leer una hora de métricas anteriores y predecir la demanda diez minutos después. El objetivo no es lograr una predicción perfecta, sino comenzar a preparar la capacidad con suficiente antelación para que los nodos y los contenedores estén listos cuando se necesiten.
El diseño aprovechó los datos recopilados por Prometheus, incluido el uso de CPU y memoria, la latencia, la tasa de solicitudes y el uso de GPU. El equipo probó modelos ARIMA, suavizado exponencial, la biblioteca Prophet y LSTM, antes de elegir un modelo Bi-LSTM compuesto por dos capas de 64 y 32 unidades, respectivamente. Según el artículo, la elección respondió a patrones de datos que incluían picos breves, periodos de recuperación y valores constantes anómalos, y no a que fuera la mejor opción teórica en todos los casos.
El modelo se vuelve a entrenar semanalmente, mientras que el modelo desplegado funciona únicamente en modo de inferencia dentro de un binario del controlador escrito en Go, mediante TensorFlow Lite. De este modo, el diseño no necesita una plataforma externa de aprendizaje automático ni una capa para servir modelos.
Tres capas para controlar el escalado
El diseño se basa en tres funciones interrelacionadas: predicción, preparación y absorción. El modelo predice la demanda; después, el controlador comienza a aumentar gradualmente el número de réplicas, mientras que la capacidad preparada de antemano proporciona espacio para absorber la oleada real.
Como la predicción no puede afrontar todas las sorpresas, el equipo añadió un detector de picos repentinos que funciona en paralelo. Este componente compara la demanda real con las predicciones mediante un umbral adaptativo basado en la desviación estándar móvil. Si la demanda supera la predicción por una diferencia que alcanza el nivel de confianza definido, el detector aumenta la velocidad de escalado. Los autores describen este componente como una red de seguridad heurística, no como un segundo modelo predictivo.
El escalador gradual limita el aumento a 20 contenedores por minuto. El objetivo es evitar una oleada masiva de programación que ejerza presión sobre el programador y etcd, y que provoque congestión en las operaciones de extracción de imágenes, inicio de contenedores, inicialización de contenedores y la inyección de sidecars. El uso objetivo también se fijó en el 70 % en lugar del 100 %, para dejar un margen que permita absorber los picos y que el modelo siga siendo ocasionalmente impreciso sin que el error se convierta en una cadena de fallos.
¿Qué demostraron las pruebas?
El equipo ejecutó primero el sistema en modo sombra, de modo que las predicciones se registraban sin realizar un escalado real, y recopiló más de 500 horas de datos. Los resultados mostraron una precisión del 85 % cuando la predicción de la demanda diez minutos después se encontraba dentro de un margen de ±10 % respecto de la demanda real. El detector de picos también capturó nueve de diez oleadas, con dos falsas alarmas, mientras que las pruebas del escalador gradual no mostraron fallos en cadena ni oscilaciones del escalado.
El sistema también funcionó junto con HPA v2 sin conflictos. Durante una semana de validación en un entorno de desarrollo controlado, superó 23 de 23 pruebas. En una simulación de los patrones de pico que provocaron el incidente original, el sistema logró detectar la oleada aproximadamente 11 minutos antes.
¿Cuándo es adecuado este enfoque?
El valor del escalado predictivo aparece cuando el aprovisionamiento de los nodos tarda más de dos o tres minutos y cuando la demanda es parcialmente predecible, como ocurre con los patrones diarios o semanales o con eventos conocidos. También requiere buenos datos de monitorización, con al menos una semana de métricas de Prometheus. En cambio, la idea resulta menos útil si los nodos se preparan en 30 segundos, si la demanda es completamente aleatoria o si la prioridad del equipo es reducir costes por encima de todo; mantener nodos calientes implica pagar por capacidad de reserva.
Lectura editorial: El cambio práctico no consiste en sustituir HPA, sino en añadir un horizonte de predicción a un sistema que normalmente responde a la demanda después de que esta aparece. Su importancia reside específicamente en las cargas de GPU, donde la rapidez de la decisión de escalado no basta si la infraestructura necesita decenas de minutos antes de iniciar los contenedores. Sin embargo, la evidencia presentada sigue procediendo de una validación controlada, no de una medición independiente y a gran escala en múltiples entornos de producción.
La propia experiencia del equipo también señala limitaciones importantes: un modelo ARIMA bien ajustado podría obtener un resultado cercano con una arquitectura más sencilla, y el modelo puede quedar obsoleto en cuestión de días cuando cambian los patrones de demanda. Además, siguió siendo difícil explicar por qué se predice un número concreto de réplicas, y aún no se han resuelto las preguntas sobre el tamaño óptimo de los datos, la periodicidad del reentrenamiento y la capacidad del detector heurístico de picos para capturar eventos sin precedentes.
Por ello, el artículo propone comenzar recopilando una semana de métricas, entrenar un modelo sencillo, ejecutarlo en modo sombra y medir la precisión antes de activar el escalado. Al pasar a producción, conviene imponer un límite máximo de réplicas, proporcionar un procedimiento claro de desactivación y, preferiblemente, atravesar una etapa de escalado restringido antes de abrir completamente el sistema. La conclusión que repiten los autores es práctica: la complejidad del modelo no es una ventaja por sí misma; si la solución más sencilla funciona, es preferible utilizarla.