Cuando un sitio web recibe un pico masivo de tráfico, como en un Black Friday, escalar pods en Kubernetes deja de ser opcional. Aquí entran dos objetos clave: el Horizontal Pod Autoscaler (HPA) y el Vertical Pod Autoscaler (VPA), pensados para que tus aplicaciones respondan sin degradar la experiencia del usuario.

Esta guía te sirve si administras clústeres, despliegas microservicios o quieres entender cómo Kubernetes ajusta recursos de forma dinámica frente a la demanda real.

Qué es el Horizontal Pod Autoscaler y cuándo usarlo

El HPA es el escalador nativo de Kubernetes y fue la primera opción para manejar elasticidad dentro del clúster [01:00]. Su trabajo es aumentar o disminuir dinámicamente la cantidad de pods asociados a un deployment o statefulset, según el consumo de una métrica, casi siempre la CPU.

La diferencia con un replica set tradicional es importante: un deployment solo puede mantener un número fijo de réplicas, mientras que el HPA ajusta esa cantidad en tiempo real cuando la carga sube o baja.

¿Qué hace el Horizontal Pod Autoscaler? Aumenta o reduce automáticamente el número de pods en un deployment basándose en métricas como el uso de CPU. Si el consumo supera un umbral, crea más réplicas; si baja, las elimina.

Qué limitaciones tiene el HPA en producción

El HPA es potente, pero conviene tener claros sus puntos débiles antes de implementarlo:

• Depende de un metric server configurado para leer el consumo de CPU o memoria.
• Es reactivo, no proactivo: actúa cuando el pico ya está ocurriendo, no se anticipa.
• No escala más allá de los límites del clúster, así que tus worker nodes también deben crecer.
• Funciona bien con CPU, pero no siempre es eficiente cuando la métrica es memoria.

Cómo funciona el Vertical Pod Autoscaler frente al HPA

Mientras el HPA agrega más pods, el VPA hace algo distinto: toma los pods existentes y les asigna más CPU o más memoria RAM [05:30]. Imagina un pod que arranca con 100m de CPU y 100 MB de memoria; tras escalar verticalmente, puede pasar a 500m de CPU y 500 MB de memoria.

El detalle incómodo es que el VPA mata el pod actual para recrearlo con los nuevos recursos. Por eso se basa en recomendaciones y permite configurarse en distintos modos: solo sugerir, o recrear automáticamente.

¿Cuándo conviene usar VPA en lugar de HPA? Cuando tu aplicación necesita más recursos por instancia en vez de más instancias, por ejemplo bases de datos o procesos pesados que no se paralelizan bien.

Qué precauciones debes tomar al usar VPA

El escalamiento vertical también tiene su letra pequeña:

• Reinicia los pods para aplicar nuevos recursos, lo que puede afectar la disponibilidad.
• No es compatible con HPA cuando ambos miden CPU o memoria, porque entran en bloqueo mutuo.
• Depende de datos históricos, así que necesitas monitoreo y observabilidad sólidos.
• En pods con varios contenedores, el reinicio afecta a todos y puede degradar el servicio.

Cómo configurar HPA y VPA paso a paso

El ejercicio práctico parte de un deployment sencillo de nginx en su versión 1.14.2, con dos réplicas y recursos muy ajustados para forzar el escalado [10:30]. Junto a él se expone un service para poder generar tráfico.

El objeto HPA usa la API autoscaling/v2 y apunta al deployment my-app-deployment con un mínimo de 1 réplica, un máximo de 4 y un target de utilización promedio de CPU del 20 %. Ese 20 % es solo para demostración; en entornos reales conviene fijar el umbral entre 70 % y 80 %, según el tipo de aplicación y cuánto tarda un nuevo pod en levantarse.

Para aplicar la configuración:

bash kubectl apply -f app.yaml kubectl apply -f hpa.yaml kubectl get hpa

Cómo generar carga y validar el escalado

Para probar el HPA en vivo se lanza un busybox que dispara peticiones contra el servicio cada 0.01 segundos:

bash kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://my-app-service; done"

A los pocos minutos, el HPA detecta consumos altos y los pods pasan de 2 a 4. En el ejemplo el consumo llega al 550 %, un número exagerado que solo ocurre porque las métricas objetivo están deliberadamente bajas. El minikube dashboard permite visualizar el aumento de réplicas en tiempo real.

Cómo instalar y aplicar el VPA

El VPA no viene incluido por defecto en Kubernetes. Hay que clonar el repositorio oficial, ubicarse en la rama master y ejecutar el script hack/vpa-up.sh para instalar los Custom Resource Definitions necesarios.

El manifiesto del VPA define el mismo target (my-app-deployment) y agrega una containerPolicy con un mínimo y un máximo de recursos, en este caso 8m de CPU y 32 MB de memoria como tope.

bash kubectl apply -f vpa.yaml kubectl get vpa kubectl describe vpa

Al describir el VPA aparece una recomendación con un lower bound y un target de recursos para el contenedor de nginx. Cuando el modo de actualización está en Auto o Recreate, el VPA mata los pods actuales y crea nuevos con los recursos ajustados. Comparando los pods antes y después, los requests pasan de valores mínimos a 8000m de CPU y memoria más generosa.

Qué componentes hacen posible el escalado vertical

Detrás del VPA trabajan tres piezas dentro de la capa de orquestación: el VPA Admission Controller, el VPA Recommender y el VPA Updater [18:00]. El Recommender analiza el consumo histórico, el Admission Controller inyecta los nuevos recursos al crear pods y el Updater es el encargado de reiniciar los que ya están corriendo.

El resultado en un escenario tipo Black Friday es claro: los usuarios no perciben demoras ni degradación, y la plataforma atiende miles o millones de peticiones sin comprometer la experiencia. Cuéntame en los comentarios qué métricas estás usando hoy para escalar tus aplicaciones y qué umbrales te han funcionado mejor.