- Diferencias fundamentales entre el escalado horizontal (HPA) para réplicas y el vertical (VPA) para recursos de CPU y RAM.
- Implementación de estrategias avanzadas como KEDA para el escalado basado en eventos externos y el Cluster Autoscaler para la gestión de nodos.
- Metodologías para combinar múltiples sistemas de escalado sin generar conflictos de métricas ni inestabilidad en el clúster.
Si alguna vez has sentido que tu clúster de Kubernetes es un agujero negro de dinero o que tus aplicaciones se quedan cortas justo cuando más tráfico tienes, no estás solo. Gestionar la infraestructura para que sea elástica no es moco de pavo, ya que requiere un equilibrio milimétrico entre ahorrar costes operativos y mantener un rendimiento que no haga sufrir al usuario final.
Para solucionar esto, Kubernetes nos ofrece un arsenal de herramientas que permiten que las cargas de trabajo respiren. Desde añadir más pods cuando la CPU se dispara hasta ajustar la memoria de un contenedor para evitar que el sistema lo mate, el ajuste dinámico de recursos es la clave para que cualquier SaaS o aplicación moderna sea viable a escala.
El Escalador Automático de Pods Horizontales (HPA)
El HPA es, básicamente, el encargado de jugar con el número de réplicas. Imagina que tienes un servicio web y, de repente, tienes un pico de visitas; el HPA detecta que la carga de trabajo aumenta y lanza más pods para repartir el esfuerzo. Este proceso se basa en un bucle de control que vigila métricas constantemente, generalmente a través del Metrics Server, para decidir si hay que sumar o quitar instancias.
Para que esto funcione como la seda, es vital definir correctamente las solicitudes de recursos (requests) en el manifiesto del pod. Si no le dices a Kubernetes cuánta CPU necesita tu contenedor como base, el HPA no tendrá un punto de referencia para calcular el porcentaje de uso y, sencillamente, no sabrá cuándo escalar. Además, es recomendable configurar ventanas de estabilización para evitar el efecto «yo-yo», donde el sistema crea y borra pods cada pocos segundos por fluctuaciones irrelevantes.
Existen diversas formas de configurar este sistema. Puedes usar la API autoscaling/v1 para casos sencillos de CPU, pero si buscas algo más pro, la versión autoscaling/v2 permite mezclar varias métricas, incluyendo datos personalizados o externos. Esto es oro puro para aplicaciones que no consumen mucha CPU pero que se saturan por el número de conexiones activas o la latencia de red.
El Escalador Automático de Pods Verticales (VPA)
A diferencia del anterior, el VPA no añade pods, sino que los «engorda» o los «adelgaza». Es la herramienta ideal para aquellas aplicaciones con estado, como las bases de datos, donde no puedes simplemente lanzar diez copias del mismo pod sin romper la consistencia de los datos. El VPA analiza el historial de consumo y sugiere (o aplica) cambios en los límites de memoria y CPU.
Este sistema opera principalmente en tres modalidades. El modo Off es perfecto para quienes quieren ir con pies de plomo, ya que solo ofrece recomendaciones sin tocar nada. El modo Initial ajusta los recursos solo al nacer el pod, y el modo Auto es el más agresivo, ya que modifica los recursos en vivo, aunque esto último suele implicar que el pod sea reiniciado para que los cambios surtan efecto.
Uno de los mayores dolores de cabeza con el VPA son los eventos OOM (Out Of Memory). Si el VPA ajusta la memoria demasiado al límite para ahorrar, cualquier pico inesperado puede provocar que el kernel de Linux mate el proceso. Para evitar estos sustos, es fundamental establecer límites mínimos y máximos en la política de recursos, asegurando que el pod siempre tenga un colchón de seguridad.
KEDA y el Escalado Basado en Eventos
A veces, la CPU y la RAM no nos dicen la verdad completa. Hay aplicaciones que están tranquilas en recursos pero tienen una cola de mensajes de RabbitMQ o Kafka que no deja de crecer. Aquí es donde entra KEDA, que no reemplaza al HPA sino que lo potencia, permitiendo escalar basándose en disparadores externos en lugar de métricas internas del nodo.
La joya de la corona de KEDA es la capacidad de escalar a cero. En un entorno de nube, tener pods encendidos que no hacen nada es tirar el dinero. KEDA puede apagar completamente una carga de trabajo y despertarla en el milisegundo en que llega un evento, lo que supone un ahorro económico masivo para tareas esporádicas o procesos por lotes.
El Cluster Autoscaler y la Infraestructura
De nada sirve que el HPA quiera crear cien pods si el nodo físico donde viven ya no tiene más sitio. El Cluster Autoscaler es la capa final que gestiona los nodos del clúster. Cuando detecta pods en estado «Pending» porque no caben en ninguna máquina, le pide al proveedor de nube (como GKE, AKS o EKS) que levante más máquinas virtuales automáticamente.
En entornos muy exigentes, existen soluciones como los nodos virtuales o Azure Container Instances (ACI) que permiten un estallido de capacidad (bursting) casi instantáneo. Esto evita que los usuarios experimenten lentitud mientras el Cluster Autoscaler tarda unos minutos en aprovisionar un nodo físico completo, proporcionando una experiencia de usuario fluida incluso en ráfagas de tráfico violentas.
Cómo combinar HPA, VPA y KEDA sin romper el clúster
Aquí es donde muchos administradores se pegan un susto. Intentar usar HPA y VPA basándose en la misma métrica (por ejemplo, CPU) es una receta para el desastre, ya que ambos lucharán por el control y crearán un comportamiento errático. La regla de oro es: si el HPA escala por CPU, el VPA no debe tocar la CPU.
La estrategia más inteligente es utilizar HPA con métricas personalizadas (como peticiones por segundo o profundidad de cola vía KEDA) y dejar que el VPA optimice la memoria y la CPU en segundo plano. De este modo, el HPA gestiona la cantidad de instancias para soportar la carga, mientras que el VPA se asegura de que cada instancia tenga la cantidad justa de recursos para no desperdiciar ni fallar.
Para aquellos que gestionan plataformas multiusuario o SaaS, la clave está en no confiar ciegamente en la automatización desde el día uno. Lo ideal es empezar con el VPA en modo recomendación, analizar los patrones de uso durante unos días y, una vez validado que no habrá caídas por falta de memoria, pasar al modo automático con límites estrictamente definidos.
La implementación exitosa de estas estrategias depende de una infraestructura sólida, un monitoreo constante con herramientas como Prometheus y una configuración coherente que priorice la estabilidad sobre el ahorro extremo. Al integrar el escalado horizontal, vertical y basado en eventos, se logra un entorno elástico que optimiza el gasto en la nube y garantiza que la aplicación sea siempre resiliente ante cualquier imprevisto de tráfico.
