Escalar una aplicación en Kubernetes significa garantizar que tu sistema responda al tráfico real sin caerse ni desperdiciar recursos. Aquí aprenderás cómo funcionan los tres mecanismos de escalamiento (horizontal pod autoscaler, vertical pod autoscaler y cluster autoscaler), cuándo conviene cada uno y cómo configurarlos paso a paso en Minikube.

¿Qué opciones de escalamiento existen en Kubernetes?

Kubernetes ofrece tres formas distintas de crecer según la demanda, y cada una opera en una capa diferente de la arquitectura.

• Horizontal Pod Autoscaler (HPA): crea más pods iguales dentro del mismo ReplicaSet cuando el tráfico aumenta.
• Vertical Pod Autoscaler (VPA): reemplaza un pod por otro con más CPU y RAM asignadas.
• Cluster Autoscaler: escala la infraestructura, añadiendo nodos master o worker en proveedores como AWS, Azure o GCP.

La jerarquía importa: un pod vive dentro de un ReplicaSet, y ese ReplicaSet vive dentro de un Deployment [00:34]. Sobre esa estructura, el HPA decide cuántas réplicas necesitas en cada momento.

¿Qué hace exactamente el horizontal pod autoscaler? Genera nuevos pods dentro del mismo ReplicaSet cuando una métrica (típicamente CPU o memoria) supera un umbral, por ejemplo 70% u 80% de uso.

¿Cuándo conviene escalar horizontal y cuándo vertical?

El escalamiento horizontal añade copias idénticas del pod. Si pasas de 1 usuario a 40, el HPA puede levantar 2, 10 o 20 pods para repartir la carga [02:30]. El vertical, en cambio, borra el pod actual y lo recrea más grande, con más RAM y más CPU.

Ahí está la tensión: el VPA puede dejar tu aplicación inoperativa por segundos o minutos mientras destruye y reconstruye el pod. Por eso, en la mayoría de escenarios productivos conviene el HPA, porque evita degradación del servicio.

• Usa HPA cuando recibes muchas peticiones simultáneas y necesitas distribuirlas.
• Usa VPA cuando una sola instancia necesita más músculo y puedes tolerar el reinicio.
• Usa Cluster Autoscaler cuando el clúster entero se queda sin CPU o memoria a nivel de nodos.

¿Cómo se configura un HPA en un archivo YAML?

El HPA es un objeto de Kubernetes con su propio manifiesto. Usa el apiVersion autoscaling/v2 y el kind HorizontalPodAutoscaler [06:40].

En la especificación defines tres cosas clave:

1. El Deployment objetivo (por ejemplo, backend o frontend).
2. El mínimo y máximo de réplicas que tolerarás.
3. La métrica de escalamiento, normalmente porcentaje de CPU.

Para el backend del ejemplo se fijó un umbral de 80% de CPU, con recursos request de 50 milicpus y 128 MB de RAM, y limits de 100 milicpus y 150 MB [08:10]. Para el frontend, al ser una app sencilla con NGINX sirviendo HTML y JavaScript, el umbral se bajó a 20% para forzar el escalamiento durante la demo, con un mínimo de 1 y máximo de 3 réplicas.

La diferencia entre requests y limits es la frontera con el VPA: el pod arranca con los recursos del request y puede crecer hasta el limit, pero no más allá.

¿Por qué el HPA aparece como unknown al inicio?

Cuando ejecutas kubectl get hpa justo después de aplicar los manifiestos, verás que la métrica de CPU aparece como unknown. Esto pasa porque Kubernetes necesita un componente que recolecte métricas en tiempo real.

¿Qué es el metrics server? Es un addon de Kubernetes que expone el consumo de CPU y memoria de cada pod, y sin él el HPA no puede decidir cuándo escalar.

En Minikube se habilita con un solo comando:

bash minikube addons enable metrics-server

En clústeres productivos no siempre es plug and play: muchas veces toca instalarlo con archivos YAML manuales o con un gestor de paquetes como Helm [16:20]. El pod del metrics-server puede tardar unos minutos en levantarse (en la demo tomó cerca de tres minutos) según la CPU y memoria asignadas al clúster.

Una vez activo, puedes correr kubectl top pods para ver qué pods consumen más recursos y ajustar tus requests y limits a la realidad de tu aplicación.

¿Cómo se prueba el escalamiento generando tráfico real?

Para que el HPA actúe, necesitas tráfico que mueva la aguja de CPU. El flujo de la demo fue así:

1. Abrir un túnel con minikube tunnel para exponer el servicio LoadBalancer.
2. Lanzar peticiones repetidas con el comando watch apuntando a la URL del frontend en el puerto 80.
3. Revisar el consumo con kubectl top pods y kubectl get hpa.

El resultado en la demo fue revelador: incluso bombardeando peticiones cada 0.1 segundos, el frontend solo llegó al 2% de CPU, muy lejos del 20% configurado. Razón: el frontend solo devuelve un HTML estático servido por NGINX, no hay lógica que cargue el procesador.

¿Cómo escala Kubernetes a nivel de infraestructura?

Cuando el problema ya no son los pods sino los nodos, entra el cluster autoscaler. Este componente trabaja por fuera de los objetos internos de Kubernetes y habla directamente con tu proveedor cloud.

Puede crecer en dos direcciones:

• Nodos master: el que recibe peticiones, hace schedule manager y mantiene el estado en etcd.
• Nodos worker: los que ejecutan tus cargas de trabajo reales.

Así, una arquitectura que empezó con un solo nodo master puede pasar a tener dos, tres o cuatro, garantizando alta disponibilidad y permitiendo que tus Deployments sigan creciendo dinámicamente.

El reto natural para llevar esto más lejos es construir un backend con lógica real (un REST API) y un frontend con framework moderno como Next, React o Angular que consuma suficiente CPU para disparar el escalamiento. ¿Tú con qué stack lo armarías? Te leo en los comentarios.