Kubernetes 1.37 permite escalar a cero pods: qué implica para tu infraestructura

El fin de los recursos ociosos en Kubernetes

La reciente actualización de Kubernetes a la versión 1.37 trae una funcionalidad que muchas empresas esperaban: el escalado automático de cargas de trabajo hasta cero réplicas. Esta característica, ahora en fase Beta y habilitada por defecto, permite que un HorizontalPodAutoscaler (HPA) reduzca a cero los pods de un despliegue cuando no hay demanda, y los reactive automáticamente cuando la métrica configurada indica que se necesita capacidad.

Hasta ahora, para lograr este comportamiento era necesario recurrir a componentes externos o activar una feature gate alfa. Con esta novedad, el escalado a cero pasa a ser parte del núcleo de Kubernetes, lo que simplifica su adopción y lo hace más accesible para todo tipo de organizaciones.

¿Por qué es relevante para una pyme?

Para una pyme que ejecuta sus aplicaciones en Kubernetes, los costos de infraestructura suelen ser uno de los mayores desafíos. Los clústeres, aunque sean administrados (como EKS de AWS o GKE de Google), tienen un costo base que se suma al de los nodos y los recursos reservados por cada pod.

El escalado a cero permite eliminar el gasto asociado a pods que permanecen inactivos durante largos períodos, especialmente en cargas de trabajo como consumidores de colas, procesadores por lotes o servicios que atienden picos esporádicos. El ahorro es mayor cuando cada pod reserva recursos costosos, como CPUs dedicadas o GPUs.

Sin embargo, no todo es beneficio: existe un costo de arranque en frío. Cuando el HPA decide escalar desde cero, debe observar la métrica, programar un pod y esperar a que la aplicación se inicie. Esto funciona bien si el trabajo puede esperar en una cola duradera, pero no es adecuado para servicios que reciben tráfico HTTP directo sin una capa de buffer.

Métricas que permiten escalar desde cero

El HPA tradicionalmente se basa en métricas como uso de CPU o memoria, que provienen de pods en ejecución. Si el número de réplicas es cero, no hay pods que midan y, por tanto, ninguna señal para que el HPA vuelva a escalar. Por eso, el escalado a cero requiere métricas de objeto o externas, como la longitud de una cola, que existen independientemente de los workers que la consumen.

Esto abre la puerta a patrones muy útiles: un worker que procesa mensajes de una cola puede estar apagado cuando la cola está vacía y encenderse automáticamente cuando llegan mensajes. La métrica externa (por ejemplo, queue_consumer_lag) sigue siendo visible para el HPA incluso sin pods activos, lo que permite tomar decisiones de escalado.

Para implementarlo, necesitas un adaptador de métricas que exponga esos valores a través de la API de métricas externas de Kubernetes. Prometheus Adapter es una opción común, pero existen otras. La configuración del adaptador es un paso crítico: si la métrica no está disponible, el HPA no podrá escalar desde cero.

Consideraciones clave antes de adoptar el escalado a cero

• Diferencia entre pausa manual y escalado automático: Kubernetes distingue entre un despliegue que el HPA redujo a cero y uno que fue pausado manualmente por un operador. La condición ScaledToZero en el estado del HPA permite al controlador saber que él es el dueño del estado cero y que debe seguir evaluando métricas para decidir si vuelve a escalar.
• Estabilización del escalado: El comportamiento estándar de reducción incluye una ventana de estabilización de cinco minutos por defecto. Esto evita que una caída breve en la métrica (por ejemplo, en la longitud de la cola) elimine todos los workers de inmediato. Puedes ajustar este período si tu carga de trabajo lo requiere.
• Actualizaciones y rollbacks: Si estás actualizando el plano de control, asegúrate de que tanto el API server como el controller manager soporten la feature y la tengan habilitada antes de crear HPA con minReplicas: 0. De lo contrario, el controller manager podría interpretar el cero como una pausa manual y dejar la carga de trabajo detenida para siempre.

¿Cómo empezar a usar el escalado a cero?

Para probar esta funcionalidad, necesitas un clúster con Kubernetes 1.37 o superior y un adaptador de métricas externas configurado. El primer paso es definir una métrica que tenga sentido para tu aplicación, como el tamaño de una cola o el número de tareas pendientes. Luego, creas un HPA con minReplicas: 0 y la métrica correspondiente.

Es importante que el despliegue comience con al menos una réplica. Si estableces manualmente el despliegue a cero, el HPA lo interpretará como una pausa y no lo reactivará. La documentación oficial de Kubernetes incluye ejemplos detallados de configuración, y la comunidad está activa en el SIG Autoscaling para resolver dudas.

En Altya Studio, ayudamos a pymes a implementar Kubernetes y a optimizar sus infraestructuras con automatización y buenas prácticas. Si estás considerando adoptar el escalado a cero o necesitas asesoría para reducir costos en tu clúster, podemos acompañarte en el proceso.

Fuente: kubernetes.io