Cerramos el módulo 8 con una plataforma segura y auditable, pero con una confesión incómoda: los componentes de Rutas Norte siguen teniendo un número de réplicas fijo, escrito a mano. api-reservas tiene replicas: 4 y tienda-web tiene replicas: 3 porque alguien, hace meses, midió un martes cualquiera y le pareció suficiente. Ese número no sabe nada del puente de mayo. El año pasado la plataforma se cayó a los once minutos de abrir la venta, y la respuesta del equipo fue un kubectl scale a la carrera desde un portátil, en el andén de una estación, con el tren saliendo.

Esta lección elimina esa carrera. El HorizontalPodAutoscaler (HPA) es el objeto de Kubernetes que ajusta automáticamente el número de réplicas de un Deployment en función de métricas observadas. No es magia: es un controlador más, con su bucle de reconciliación —el mismo que estudiamos en el módulo 1—, una fórmula aritmética muy concreta y un puñado de parámetros que hay que entender bien para que el resultado sea estabilidad y no un péndulo de pods arrancando y muriendo.

Vamos a ver qué cargas se pueden escalar horizontalmente y cuáles no, la API autoscaling/v2 completa, la fórmula exacta con la que se calculan las réplicas deseadas, el bloque behavior que gobierna la velocidad de subida y bajada, y los dos manifiestos definitivos de api-reservas y tienda-web. Terminaremos con un conflicto que muerde a casi todos los equipos la primera vez: el HPA y el campo replicas del YAML versionado peleándose por el mismo número.

1. Escalar hacia fuera frente a escalar hacia arriba
2. Qué cargas admiten escalado horizontal y cuáles no
3. Anatomía del HorizontalPodAutoscaler en autoscaling/v2
4. Los cuatro tipos de métrica: Resource, Pods, Object y External
5. La fórmula exacta del controlador, paso a paso
6. La banda de tolerancia y el bailoteo de réplicas
7. Requisitos ineludibles: requests y metrics-server
8. Diagnóstico del temido <unknown>
9. El bloque behavior: políticas, periodos y ventana de estabilización
10. Varias métricas a la vez: gana la que pide más
11. Los HPA de Rutas Norte, manifiestos completos
12. Simulación de una punta de carga y observación en vivo
13. El conflicto entre el HPA y el campo replicas
14. Qué no escalar con HPA y el cuello de botella real
15. Errores comunes y consejos
16. Ejercicios
17. Conclusión

Hay exactamente dos formas de darle más capacidad a un servicio, y conviene tener los nombres claros porque el resto del módulo se apoya en ellos.

Escalar hacia arriba (scale up, escalado vertical) es darle más recursos a cada instancia: subir el requests/limits de CPU de 200m a 800m, la memoria de 256Mi a 1Gi. El número de pods no cambia; cada pod es más grande. En Kubernetes esto implica recrear el pod, porque los recursos de un contenedor forman parte de su especificación inmutable (con el matiz del redimensionado en caliente que veremos en 09-02).

Escalar hacia fuera (scale out, escalado horizontal) es poner más instancias del mismo tamaño: pasar de 4 pods de api-reservas a 12 pods idénticos. Cada pod sigue siendo igual de grande; hay más. En Kubernetes esto es cambiar un número entero: el replicas del Deployment.

La regla práctica: el escalado vertical resuelve el problema de una instancia mal dimensionada; el escalado horizontal resuelve el problema del volumen de tráfico. No son alternativas, son ejes distintos. Rutas Norte necesita los dos: acertar con el tamaño de cada pod (09-02) y multiplicar el número de pods cuando llega el puente de mayo (esta lección).

Un detalle importante que muchos pasan por alto: el escalado horizontal también mejora la disponibilidad, mientras que el vertical no. Doce pods de api-reservas repartidos entre nodos sobreviven a la caída de un nodo; un único pod gigantesco, no. Esta idea la retomaremos a fondo en 09-05.

El escalado horizontal solo funciona si cualquier réplica puede atender cualquier petición. Esto se llama ser sin estado (stateless), y es una propiedad de la aplicación, no de Kubernetes. Kubernetes te dejará escalar cualquier cosa; que el resultado sea correcto depende de cómo esté escrita la aplicación.

Repasemos los componentes de Rutas Norte:

El caso de postgres-reservas merece un párrafo. Es un StatefulSet con un volumen persistente por réplica. Si pusieras un HPA sobre él y el HPA decidiera pasar de 1 a 5 réplicas, Kubernetes crearía cinco pods postgres-reservas-0 a postgres-reservas-4, cada uno con su propio PVC vacío, cada uno arrancando una base de datos independiente y vacía. El Service repartiría las peticiones entre las cinco. El resultado sería una corrupción silenciosa de datos: unas reservas irían a una base de datos y otras a otra. Escalar una base de datos relacional es un problema de arquitectura de datos (réplicas de lectura, particionado, un operador que sepa hacerlo — 06-07), no un problema de contar pods.

Regla que conviene memorizar: si al añadir una réplica el sistema no responde más peticiones correctas por segundo, el HPA no es tu herramienta.

El HPA es un objeto de la API como cualquier otro. Su versión estable y actual es autoscaling/v2; las versiones v2beta1 y v2beta2 están eliminadas desde hace varias versiones y autoscaling/v1 solo permite CPU (el servidor la sigue sirviendo por compatibilidad, pero no la uses: pierdes behavior y todas las métricas que no sean CPU).

Este es el esqueleto completo, con comentarios sobre cada campo:

Tres puntos de partida que conviene fijar antes de seguir:

• scaleTargetRef apunta a un objeto que expone el subrecurso /scale. Deployments, ReplicaSets y StatefulSets lo exponen. Un DaemonSet no, porque su número de pods lo determina el número de nodos (06-02), y no tendría sentido.
• minReplicas y maxReplicas son barreras duras. El maxReplicas es tu red de seguridad económica y operativa: si un error de la aplicación dispara la CPU al 100 % sin que haya tráfico real, el HPA intentará escalar sin fin; el techo lo impide. Ponlo siempre, y ponlo pensando en qué pasaría si se alcanzase.
• minReplicas puede ser 0 desde Kubernetes 1.30 si la feature gate HPAScaleToZero está activa, pero eso requiere una métrica externa o de objeto y no está habilitado por defecto en la mayoría de clústeres. El escalado a cero de verdad lo haremos con KEDA en 09-04.

El HPA lo gestiona el horizontal-pod-autoscaler que vive dentro del kube-controller-manager. Su ciclo por defecto es de 15 segundos (--horizontal-pod-autoscaler-sync-period). En cada ciclo:

Nótese el final del flujo: el HPA no crea pods. Modifica el campo replicas del Deployment mediante el subrecurso /scale, y a partir de ahí el controlador de Deployments y el de ReplicaSets hacen su trabajo habitual (módulo 2). Es reconciliación encadenada, exactamente el patrón que vimos en 01-02.

El bloque metrics acepta cuatro tipos. Dos los usarás hoy; los otros dos se definen aquí y se explotan en 09-04.

Es la forma más común. Expresa el objetivo como porcentaje del requests del contenedor:

Esto significa: «mantén el consumo medio de CPU de los pods de api-reservas en torno al 65 % de lo que cada uno tiene reservado en requests.cpu». Si requests.cpu es 500m, el objetivo son 325m por pod.

Es fundamental entender que Utilization se calcula sobre requests, no sobre limits ni sobre la CPU del nodo. Un pod puede mostrar una utilización del 180 % si consume 900m con un requests de 500m; eso es perfectamente posible porque el requests es una reserva mínima, no un tope (módulo 3).

Expresa el objetivo en unidades absolutas, ignorando el requests:

«Mantén el consumo medio de memoria por pod en 700Mi.»

¿Cuándo usar cada uno?

Un aviso sobre memoria como métrica de HPA: casi nunca es buena idea. Muchos entornos de ejecución (la JVM, el recolector de basura de Node.js, PostgreSQL) no devuelven la memoria al sistema aunque ya no la necesiten. El consumo sube y se queda arriba. Un HPA por memoria escalaría hacia fuera y nunca volvería a bajar, porque la memoria de los pods viejos jamás baja del objetivo. Usa CPU, o mejor aún, una métrica de negocio (09-04).

Variante de Resource que mira un contenedor concreto en lugar de sumar todos los del pod. Es muy útil en Rutas Norte, donde varios pods llevan sidecars:

Sin esto, un sidecar que consume 50m constantes distorsiona el porcentaje del pod entero, y en pods pequeños la distorsión es grande. Si tu destino tiene sidecars, prefiere ContainerResource.

Los definimos ahora para que reconozcas la sintaxis, pero su uso real llega en 09-04.

Diferencia clave entre Value y AverageValue en Object y External: con Value el HPA compara el valor bruto con el objetivo; con AverageValue divide el valor entre el número de réplicas antes de comparar. Para una cola siempre quieres AverageValue («cada worker se hace cargo de 500 mensajes»), porque es lo que hace que el número de réplicas crezca con la cola.

Los tipos Pods, Object y External no funcionan de fábrica: necesitan un adaptador de métricas registrado en la capa de agregación de la API. Sin él, el HPA reportará <unknown> eternamente. Eso es exactamente lo que resuelve KEDA en 09-04.

Aquí está el corazón de la lección. Todo el comportamiento del HPA sale de una única expresión:

Donde techo() es el redondeo hacia arriba al entero siguiente. Vamos a aplicarla a api-reservas con números reales.

api-reservas está desplegado con estos recursos (los fijamos en el módulo 3):

Y su HPA tiene averageUtilization: 65, minReplicas: 4, maxReplicas: 30.

Objetivo absoluto por pod: 65 % de 500m = 325m.

Hay 4 réplicas. kubectl top pods muestra:

Media: (140 + 155 + 132 + 149) / 4 = 144m.

La fórmula pide 2 réplicas. Pero minReplicas es 4, así que se queda en 4. Correcto: no queremos bajar de 4 en producción por disponibilidad.

Sigue habiendo 4 réplicas, pero el tráfico se dispara:

Media: (910 + 940 + 895 + 925) / 4 = 917,5m. Ojo: están rozando su limit de 1000m, o sea, están sufriendo throttling (módulo 3).

El HPA quiere 12 réplicas. Está por debajo de maxReplicas: 30, así que se aplica (sujeto al behavior, que veremos en el apartado 9).

Observa la elegancia de la fórmula: multiplica el número actual por el factor de exceso. Si vas al triple del objetivo con 4 pods, pide 12 pods. Es una regla de tres que asume implícitamente que la carga se reparte por igual entre las réplicas, lo cual es cierto si el Service hace balanceo razonable y las peticiones son homogéneas.

Ahora hay 12 réplicas y la media baja a 120m:

Pide 5 réplicas. Bajará de 12 a 5, pero no de golpe: la ventana de estabilización y las políticas de scaleDown controlan el ritmo (apartado 9).

Estos matices explican comportamientos que de otro modo parecen erráticos:

1. Pods sin métricas. Si un pod no tiene métricas todavía (acaba de arrancar), el HPA lo excluye del promedio pero lo cuenta de forma conservadora: al escalar hacia arriba asume consumo 0 para ese pod (para no sobrestimar), y al escalar hacia abajo asume consumo igual al objetivo (para no infraestimar). El resultado es que el HPA es prudente en ambos sentidos mientras hay pods arrancando.

2. Pods no listos. Los pods que no han pasado su sonda readinessProbe se excluyen del cálculo al escalar hacia arriba. Esto evita el clásico bucle infernal: pods nuevos que aún no reciben tráfico, con CPU alta por el arranque, harían creer al HPA que hace falta escalar aún más.

3. --horizontal-pod-autoscaler-initial-readiness-delay (30 s por defecto): durante los primeros 30 segundos de vida de un pod, sus métricas se ignoran por completo. La justificación es clara: el arranque de Node.js consume mucha CPU compilando y cargando módulos, y no queremos que ese pico contamine la decisión.

4. --horizontal-pod-autoscaler-cpu-initialization-period (5 min por defecto): un margen adicional para métricas de CPU de pods recién listos.

La consecuencia práctica de los puntos 3 y 4 es que el HPA tiene una latencia de arranque de al menos medio minuto por decisión, y por eso el sobreaprovisionamiento de 09-03 y el precalentamiento por cron de 09-04 tienen sentido.

Si el HPA aplicase la fórmula literalmente cada 15 segundos, el número de réplicas oscilaría sin parar. Con 4 pods a 320m y un objetivo de 325m la fórmula da techo(4 × 0,984) = 4; con 330m da techo(4 × 1,015) = 5. Una fluctuación de 10m provocaría un pod arriba y abajo indefinidamente. A eso se le llama bailoteo o thrashing, y es caro: cada arranque consume CPU, calienta cachés desde cero y ensucia las métricas.

Kubernetes lo evita con una banda de tolerancia: si el cociente valorActual / valorObjetivo está entre 0,9 y 1,1 (es decir, dentro de un ±10 %), el HPA no hace nada.

Con nuestro objetivo de 325m, la zona muerta es:

Este umbral es global del clúster (--horizontal-pod-autoscaler-tolerance), no configurable por HPA... hasta hace poco. Desde Kubernetes 1.33 existe la feature gate HPAConfigurableTolerance, que permite fijar la tolerancia por métrica dentro del behavior:

Como feature gate opcional, no la des por hecha: comprueba la versión y la configuración de tu clúster antes de usarla en producción. En el clúster de minikube del curso trabajaremos con la tolerancia por defecto del 10 %.

Dos requisitos, y ninguno es negociable.

El HPA con métricas de tipo Resource lee de la API metrics.k8s.io, que sirve metrics-server. Lo instalamos en 07-02 con el addon de minikube. Verifícalo:

La columna AVAILABLE debe decir True. Si dice False (MissingEndpoints) o similar, el HPA no funcionará.

Si kubectl top funciona, el HPA tendrá datos. Si no, no hay HPA que valga. Es la primera comprobación siempre.

En minikube, si aún no lo tienes:

Esta es la trampa más frecuente. El objetivo Utilization se calcula como porcentaje del requests. Si un contenedor no declara requests.cpu, el HPA no tiene denominador, y su métrica queda como <unknown> para siempre. No hay mensaje de error espectacular; simplemente no escala.

Y ojo con los sidecars: si el pod tiene un contenedor sin requests.cpu, la métrica del pod entero queda inválida para el HPA cuando usas type: Resource. En Rutas Norte, api-reservas lleva un sidecar exportador de métricas; si ese sidecar no declara requests, el HPA de todo el Deployment se queda ciego. Dos soluciones:

1. Declarar requests también en el sidecar (recomendado, y además necesario para la QoS del módulo 3).
2. Usar type: ContainerResource apuntando solo al contenedor api.

Aplicamos las dos en Rutas Norte: cinturón y tirantes.

Tarde o temprano verás esto:

<unknown> significa: «el HPA no ha podido obtener el valor actual de esta métrica». No escala, y punto. El diagnóstico se hace siempre en el mismo orden:

Fíjate en el bloque Conditions y en los eventos del final. Las causas, ordenadas por frecuencia:

Ejemplo de salida real con el error de requests faltante:

El mensaje señala con nombre y apellidos el contenedor culpable: exportador-metricas. Añadirle requests.cpu resuelve el problema en el siguiente ciclo de 15 segundos.

Un truco de diagnóstico rápido: consulta directamente la API de métricas para ver qué está viendo el HPA.

Si esa llamada devuelve datos y el HPA sigue en <unknown>, el problema es de requests, no de metrics-server.

Hasta ahora hemos visto cuántas réplicas quiere el HPA. El bloque behavior decide a qué velocidad llega a ese número. Es la diferencia entre un autoescalado que funciona y uno que da miedo.

Campo a campo:

policies — cada política limita cuánto puede cambiar el número de réplicas en una ventana de periodSeconds:

• type: Percent con value: 100 y periodSeconds: 30 significa «en cualquier ventana de 30 segundos puedes como mucho duplicar el número de réplicas» (aumentar un 100 % sobre la base).
• type: Pods con value: 4 y periodSeconds: 30 significa «en cualquier ventana de 30 segundos puedes añadir como mucho 4 pods».

selectPolicy — cuando hay varias políticas, decide cuál manda:

Ejemplo del efecto de selectPolicy: Max en scaleUp con nuestras políticas y 4 réplicas actuales:

• Política de porcentaje: 100 % de 4 = permite añadir 4 → 8 réplicas.
• Política de pods: permite añadir 4 → 8 réplicas.
• Max toma el mayor: 8 réplicas.

Con 20 réplicas actuales:

• Porcentaje: 100 % de 20 = permite añadir 20 → 40 réplicas.
• Pods: permite añadir 4 → 24 réplicas.
• Max toma 40 (limitado luego por maxReplicas: 30 → 30).

Y con selectPolicy: Min habría elegido 24. Esto ilustra por qué Max al subir tiene sentido: cuando ya tienes muchas réplicas, el porcentaje te da margen para crecer rápido.

stabilizationWindowSeconds — es el parámetro más importante y el peor entendido. Funciona así: el HPA guarda un histórico de las recomendaciones de los últimos N segundos y usa el valor más conservador de esa ventana.

• En scaleUp, «más conservador» significa el mínimo de las recomendaciones recientes. Con una ventana de 60 s, si en el último minuto el HPA recomendó 12, 8 y 14 réplicas, escalará a 8. Efecto: ignora picos aislados.
• En scaleDown, «más conservador» significa el máximo de las recomendaciones recientes. Con una ventana de 600 s, si en los últimos 10 minutos recomendó 12, 5 y 6, mantendrá 12. Efecto: no baja hasta que la calma se sostiene diez minutos enteros.

Valores por defecto si no defines behavior:

Es decir, por defecto el HPA puede duplicarse cada 15 segundos y puede irse a minReplicas de golpe tras 5 minutos de calma. Lo primero suele estar bien; lo segundo es demasiado brusco para Rutas Norte.

Nuestra política es deliberadamente asimétrica, y conviene entender por qué:

Subir rápido. El coste de escalar de más durante unos minutos es unos céntimos de cómputo. El coste de escalar de menos durante unos minutos es que la venta del puente de mayo se cae y Rutas Norte pierde miles de euros en billetes no vendidos, más la reputación. Los costes son radicalmente asimétricos, y por tanto la respuesta debe serlo. stabilizationWindowSeconds: 0 en scaleUp: en cuanto la carga sube, se actúa.

Bajar despacio. El tráfico de una web de billetes es irregular por naturaleza: una punta a las 10:00, un valle a las 10:03, otra punta a las 10:05. Si bajásemos rápido, estaríamos destruyendo pods que hay que volver a crear treinta segundos después, con el coste de arranque en frío (conexiones a PostgreSQL, caché de rutas vacía) y una latencia peor para el usuario. stabilizationWindowSeconds: 600 en scaleDown: no bajamos hasta que la calma dura diez minutos. Y aun entonces, bajamos un 20 % cada dos minutos, no de golpe.

La formulación mental: el autoescalado hacia arriba es un mecanismo de disponibilidad; el autoescalado hacia abajo es un mecanismo de coste. La disponibilidad es urgente; el ahorro puede esperar diez minutos.

Un uso avanzado y muy práctico de selectPolicy: Disabled. Durante los tres días del puente de mayo, el equipo de Rutas Norte puede decidir que no quiere ninguna reducción de réplicas, ni siquiera lenta:

Se aplica el viernes por la mañana y se revierte el lunes. Es un interruptor de emergencia legítimo y mucho más seguro que borrar el HPA.

El campo metrics es una lista. Cuando hay varias, el HPA calcula la fórmula para cada una por separado y luego aplica una regla muy simple:

Se queda con el número de réplicas MÁS ALTO de todos los cálculos.

Es un OR de necesidad: basta con que una sola métrica pida más réplicas para que se escale. Nunca se promedian ni se combinan.

Ejemplo con dos métricas en api-reservas (5 réplicas actuales):

La CPU dice que sobran pods; las peticiones por segundo dicen que faltan muchos. Gana 12. Esta asimetría es intencionada y correcta: el HPA prefiere equivocarse por exceso de capacidad que por defecto.

Consecuencia práctica que hay que tener presente: si una de las métricas se queda en <unknown>, el HPA no puede garantizar que no haga falta escalar por ella. Su comportamiento en ese caso es conservador: si la métrica válida pide subir, sube; si pide bajar, no baja, porque no sabe si la métrica rota justificaría mantener las réplicas. Esto explica el desconcierto habitual de «mi HPA tiene una métrica en <unknown> y se ha quedado clavado arriba».

Vamos a escribir los dos manifiestos definitivos. Van en k8s/entornos/pro/, porque los valores de minReplicas difieren por entorno.

Un cálculo que justifica el maxReplicas: 30: cada pod reserva 500m de CPU y 512Mi de memoria. Treinta pods son 15 núcleos y 15 GiB solo de api-reservas. Sumando tienda-web, worker-notificaciones y las bases de datos, eso define el tamaño del clúster que necesitaremos en 09-03. El maxReplicas no es un número que se pone al azar: es un compromiso de capacidad.

Otro cálculo, sobre la velocidad de subida. Partiendo de 4 réplicas con Max entre «duplicar» y «+6 pods»:

De 4 a 30 réplicas en 90 segundos. Sumando unos 20-30 segundos de arranque de cada pod de Node.js, la plataforma pasa de su capacidad de martes a su capacidad máxima en unos dos minutos. Eso es lo que hay que comparar contra la velocidad a la que llega el tráfico.

tienda-web es nginx sirviendo activos estáticos. Su perfil es distinto: consume poquísima CPU por petición, arranca en un segundo y su límite real es el ancho de banda y el número de conexiones, no el cómputo.

Comparación razonada de ambos HPA:

La columna TARGETS muestra valorActual/objetivo. Si ves números en lugar de <unknown>, todo está bien conectado.

Vamos a provocar una punta en el entorno de desarrollo y ver el HPA trabajar. Usaremos el perfil de minikube del curso.

Para la demostración, un HPA de desarrollo con umbrales bajos para que reaccione rápido:

Un pod efímero que martillea el endpoint de búsqueda de rutas en bucle:

Explicación del comando:

• --rm -it crea el pod, se conecta a él y lo borra al salir con Ctrl+C.
• http://api-reservas usa el DNS interno del clúster (04-03): resuelve al Service del mismo namespace.
• El bucle infinito de wget genera peticiones tan rápido como pueda.

Para una punta más seria, varias réplicas del generador:

Lee la secuencia con la fórmula en la mano:

1. 3%/40% con 1 réplica: techo(1 × 0,075) = 1. Nada que hacer.
2. 187%/40% con 1 réplica: techo(1 × 4,675) = 5. Pero la política Pods: 3 cada 15s limita a 4. Ahí está el behavior en acción.
3. 142%/40% con 4 réplicas: techo(4 × 3,55) = 15. La política limita a 4+3 = 7.
4. 94%/40% con 7 réplicas: techo(7 × 2,35) = 17. Limitado a 10 por maxReplicas.
5. 38%/40% con 10 réplicas: ratio 0,95, dentro de la banda de tolerancia. Estable. Objetivo alcanzado.

Ahora detén el generador (Ctrl+C o borrando el Deployment) y observa la bajada:

Fíjate: la CPU cae inmediatamente al 2 %, pero las réplicas se quedan en 10 durante dos minutos completos. Esa es la stabilizationWindowSeconds: 120. Cumplida la ventana, baja a 1 de golpe (en esta demo no definimos políticas de scaleDown, así que aplica la de por defecto: 100 % cada 15 s).

Estos eventos son oro puro para el análisis posterior de un incidente: te dicen exactamente cuándo escaló, a cuánto y por qué. Recuerda que los eventos caducan (una hora por defecto); para el historial largo hace falta el registro centralizado del módulo 7.

Este es el error que muerde a todos los equipos exactamente una vez, y conviene que no sea en el puente de mayo.

El Deployment de api-reservas que llevamos escribiendo desde el módulo 2 dice:

Y ahora un HPA también gobierna ese mismo campo. Tenemos dos autoridades sobre el mismo número.

Mientras nadie aplique el YAML, no pasa nada: el HPA modifica el campo en el servidor y el objeto vive feliz con 22 réplicas. El problema aparece cuando alguien vuelve a aplicar el manifiesto.

Escenario real:

Quince segundos de caída total en el pico de venta del año. Todo por un campo que no debería estar ahí.

Y es peor con GitOps: si Argo CD (10-05) tiene el repositorio como fuente de verdad y detecta que el clúster tiene 22 réplicas cuando el Git dice 4, marcará el recurso como OutOfSync y, con sincronización automática, lo «corregirá» a 4. Cada vez. Tendrás un tira y afloja permanente entre el HPA y el operador de GitOps, con la plataforma oscilando entre 4 y 22 réplicas indefinidamente.

Al omitir replicas, el valor por defecto de la API es 1, pero solo en la creación inicial. En aplicaciones posteriores, el campo simplemente no se toca: kubectl apply compara con la anotación kubectl.kubernetes.io/last-applied-configuration, ve que replicas no estaba antes ni está ahora, y lo deja como está. El HPA sigue mandando.

Una consecuencia a tener en cuenta: la primera vez que crees el Deployment sin replicas, arrancará con 1 pod hasta que el HPA lo lleve a minReplicas en el siguiente ciclo (menos de 15 segundos). Es aceptable en un despliegue nuevo; si te molesta, crea el HPA primero.

Ese comentario explícito en el YAML no es decorativo: es documentación en el lugar donde alguien tomará la decisión equivocada. Escríbelo.

Ojo con una trampa de Server-Side Apply: si aplicas con SSA y el campo replicas sí está en tu manifiesto, tomarás la propiedad del campo y el HPA recibirá un conflicto. La API te lo dirá con un error explícito de conflicto de propietarios, lo cual es mejor que el fallo silencioso de kubectl apply clásico, pero sigue siendo un fallo.

Si ves kube-controller-manager entre los gestores, el HPA está escribiendo el campo. Es la confirmación de que la cadena funciona.

Terminamos con la lección más valiosa de todas, y la que más dinero ahorra.

Imagina esta secuencia en el puente de mayo:

1. Llega la avalancha de tráfico.
2. El HPA de api-reservas escala de 4 a 30 réplicas en dos minutos. Perfecto.
3. Las 30 réplicas abren, cada una, su pool de 20 conexiones a postgres-reservas. Total: 600 conexiones.
4. postgres-reservas tiene max_connections = 200.
5. Las 400 conexiones sobrantes son rechazadas. Los pods de api-reservas devuelven error 500.
6. La CPU de api-reservas sube (los reintentos y el manejo de errores consumen), así que el HPA quiere escalar más. maxReplicas lo corta en 30.
7. La plataforma está caída con 30 réplicas donde antes se caía con 4. Ha costado más dinero y no ha servido de nada.

Este patrón tiene nombre: desplazar el cuello de botella sin resolverlo. El HPA no lo detecta porque el HPA solo sabe de CPU: no sabe que la base de datos está saturada.

La capa que no escala determina la capacidad de todo el sistema. Es la ley del eslabón más débil aplicada a la arquitectura.

Con postgres-reservas como límite, las palancas reales son:

Ninguna de ellas es un HPA. La lección: antes de poner un HPA, identifica el recurso escaso. Si no es la CPU de los pods que vas a escalar, el HPA no te va a ayudar.

Pregúntate:

1. ¿La aplicación es realmente sin estado? ¿Puede cualquier réplica atender cualquier petición sin memoria local ni afinidad de sesión?
2. ¿La CPU es el recurso escaso? ¿O es la base de datos, el disco, la red, un servicio externo o un bloqueo global?
3. ¿La carga se reparte por igual? Si un endpoint concentra el 90 % del coste y un solo cliente lo llama, añadir réplicas no ayuda.
4. ¿Cuánto tarda un pod nuevo en ser útil? Si tarda tres minutos, el HPA llegará tarde a las puntas rápidas. Habrá que trabajar el arranque (09-06) o precalentar (09-04).
5. ¿Hay sitio en el clúster para las réplicas nuevas? Si no, el HPA solo generará pods Pending (09-03).
6. ¿El servicio de abajo aguanta N veces más carga? El pool de conexiones, la cuota de la API externa, el límite de tasa.

Solo si las seis respuestas son satisfactorias, el HPA hará lo que esperas.

Error 1: dejar el campo replicas en el manifiesto. Ya lo hemos desarrollado en el apartado 13, pero merece repetirse porque es el error número uno y sus consecuencias son inmediatas y visibles. Quítalo y deja un comentario en su lugar.

Error 2: escalar por memoria. Los entornos de ejecución con recolector de basura no devuelven memoria al sistema. El HPA sube y no vuelve a bajar nunca. Usa CPU, o una métrica de negocio (09-04). Si de verdad necesitas memoria, usa AverageValue en lugar de Utilization y ten expectativas realistas.

Error 3: poner el objetivo de utilización demasiado alto. Un averageUtilization: 90 parece eficiente, pero deja solo un 10 % de margen. Cuando el HPA detecta la subida, los pods nuevos tardan 30 segundos en estar listos, y durante esos 30 segundos los pods existentes están al 130 % y sufriendo throttling. El objetivo debe dejar hueco para el tiempo de arranque. Entre 50 % y 70 % es el rango sano; cuanto más lento arranque tu aplicación, más bajo el objetivo.

Error 4: maxReplicas sin plan de capacidad. Un maxReplicas: 200 en un clúster de tres nodos no te da 200 réplicas: te da un montón de pods Pending y una falsa sensación de seguridad. Calcula maxReplicas × requests y compáralo con la capacidad real (09-03).

Error 5: olvidar los requests en los sidecars. Un solo contenedor sin requests.cpu deja ciego al HPA de todo el Deployment. En Rutas Norte, el exportador de métricas de api-reservas es el sospechoso habitual.

Error 6: no comprobar que los pods nuevos son útiles. Un pod que arranca y pasa la readiness pero tiene el pool de conexiones vacío y la caché fría atiende peor que uno caliente. Durante los primeros segundos, escalar puede empeorar la latencia media. Ajusta las sondas (07-01) para que un pod solo se declare listo cuando de verdad lo esté.

Consejo 1: pon primero el HPA en modo observación. Créalo con minReplicas igual a maxReplicas (por ejemplo, ambos a 4). El HPA no podrá escalar, pero calculará y publicará las métricas en kubectl get hpa. Déjalo una semana, mira qué habría hecho, y solo entonces abre el rango. Es gratis y evita sustos.

Consejo 2: alerta cuando el HPA esté pegado al techo. Si api-reservas lleva media hora en 30 réplicas, el maxReplicas está limitando la capacidad y nadie se entera. Una alerta en Alertmanager (07-04):

Consejo 3: registra un panel con réplicas y métrica juntas. En Grafana, superponer «réplicas actuales» y «CPU media» en el mismo gráfico hace evidente si el HPA reacciona bien o va por detrás. Es el diagnóstico visual más útil que existe para un HPA.

Consejo 4: prueba el HPA antes de necesitarlo. Un ensayo de carga contra rutas-norte-pre una semana antes del puente de mayo cuesta una tarde y evita la caída del año. Lo haremos formalmente con k6 en 09-06.

Consejo 5: los eventos del HPA caducan. Una hora por defecto. Si quieres el histórico del incidente, necesitas EFK (07-05) o las métricas de kube-state-metrics en Prometheus.

tienda-web está desplegado con requests.cpu: 200m y un HPA con averageUtilization: 50, minReplicas: 3, maxReplicas: 15. En este momento hay 6 réplicas y kubectl top da:

Calcula: (a) el objetivo absoluto por pod; (b) el consumo medio; (c) el ratio y si está dentro de la banda de tolerancia; (d) las réplicas deseadas; (e) qué hará el HPA con este behavior:

Un compañero ha desplegado worker-notificaciones con este HPA y se queja de que nunca escala:

El Deployment es:

kubectl get hpa muestra <unknown>/70%. Identifica todos los problemas, escribe los comandos de diagnóstico que ejecutarías y las correcciones. Además, explica por qué incluso arreglando todo esto este HPA seguirá siendo una mala idea para este componente concreto.

Rutas Norte lanza panel-conductores, una aplicación web interna que usan los 40 conductores de la flota. Perfil de carga:

• De lunes a viernes, de 5:30 a 7:00, todos los conductores entran para consultar su ruta del día: la carga pasa de cero a su máximo en quince minutos.
• El resto del día hay uso esporádico, muy bajo.
• Por la noche no hay nadie.
• La aplicación es Node.js y tarda unos 25 segundos en estar lista.
• Es interna: una caída de dos minutos es molesta pero no cuesta dinero.
• El equipo tiene presión de costes: el clúster es compartido y hay ResourceQuota.

Escribe el HPA completo (autoscaling/v2) razonando cada decisión: minReplicas, maxReplicas, métrica, objetivo, y todo el behavior. Compara al menos tres decisiones con las del HPA de api-reservas y explica por qué difieren.

Solución 1

(a) Objetivo absoluto por pod:

(b) Consumo medio:

(c) Ratio y banda de tolerancia:

(d) Réplicas deseadas:

13 réplicas, por debajo de maxReplicas: 15.

(e) Qué hace el behavior:

Réplicas actuales: 6.

• Política Percent 100 % / 15 s: permite añadir el 100 % de 6 = 6 → hasta 12 réplicas.
• Política Pods 4 / 15 s: permite añadir 4 → hasta 10 réplicas.
• selectPolicy: Max toma el techo más alto: 12.

El HPA quiere 13 pero solo puede llegar a 12 en este paso. Escalará a 12 réplicas ahora.

En el siguiente ciclo (15 s después), con 12 réplicas y suponiendo que la carga total no cambia, el consumo medio bajará a unos 103m por pod. El nuevo ratio sería 1,03, dentro de la banda de tolerancia, así que se quedará en 12 y no llegará nunca a 13. Este es un comportamiento habitual y correcto: la tolerancia absorbe el último salto.

Observación adicional: los pods están al 103 % de su requests (206m contra 200m). No están sufriendo throttling porque su limit es mayor, pero están consumiendo más de lo reservado, lo que significa que dependen de la CPU sobrante del nodo. Es una señal de que el requests de tienda-web está infradimensionado y de que el VPA de 09-02 tendría algo que decir.

Solución 2

Hay cuatro problemas, uno detrás de otro.

Problema 1: el contenedor worker no declara requests.cpu.

Solo tiene limits. Sin requests, el HPA no tiene denominador para el porcentaje.

Matiz importante que muchos desconocen: cuando declaras limits sin requests, Kubernetes rellena automáticamente requests con el valor de limits. Así que este contenedor sí acaba teniendo requests.cpu: 500m. Como efecto secundario, la QoS del pod sería Guaranteed si todos los contenedores estuvieran así (módulo 3). Pero...

Problema 2: el contenedor exportador-metricas no declara ningún recurso.

Este sí es fatal. Sin limits ni requests, no hay relleno automático, y el HPA no puede calcular la utilización del pod. Este es el que produce el <unknown>. Además hace que la QoS del pod sea Burstable en lugar de Guaranteed.

Problema 3: no se sabe si metrics-server está disponible.

Hay que verificarlo antes que nada.

Problema 4 (de diseño, y el más importante): la CPU es la señal equivocada para este componente.

Comandos de diagnóstico, en orden:

La salida del paso 3 delataría el problema:

Corrección del Deployment:

Y, defensivamente, cambiar el HPA a ContainerResource para que el sidecar no distorsione el porcentaje:

Por qué sigue siendo mala idea aunque funcione:

worker-notificaciones consume mensajes de una cola de correos. Su trabajo por mensaje es sobre todo espera de entrada/salida: hablar con el servidor SMTP, esperar la respuesta de red. Eso consume muy poca CPU.

En el puente de mayo puede haber cuarenta mil correos esperando en la cola y el worker estar al 20 % de CPU, porque está bloqueado esperando al SMTP la mayor parte del tiempo. El HPA por CPU vería 20 % contra un objetivo de 70 % y concluiría que sobran réplicas: escalaría hacia abajo justo cuando más hacen falta consumidores.

La métrica correcta es la longitud de la cola: «quiero un worker por cada 500 mensajes pendientes». Eso no lo puede leer el HPA de fábrica; hace falta una métrica externa, y esa es exactamente la razón de ser de KEDA en 09-04.

Solución 3

Comparación razonada con el HPA de api-reservas:

Consideración adicional que merece nota: este perfil de carga —cero por la noche, avalancha a hora fija— es el candidato perfecto para un disparador cron que precaliente el servicio a las 5:15, en lugar de esperar a que la CPU suba y reaccionar tarde. Eso ya no lo hace el HPA de fábrica: es KEDA, y lo veremos en 09-04. Un HPA reactivo siempre va por detrás de una carga que sube en escalón; solo una señal anticipada resuelve ese caso de verdad.

El HorizontalPodAutoscaler convierte el número de réplicas de un dato fijo escrito a mano en una consecuencia observada del tráfico real. Es la diferencia entre dimensionar para un martes cualquiera y sobrevivir al puente de mayo sin que nadie tenga que abrir el portátil en el andén de una estación.

Lo esencial que te llevas de esta lección:

• Escalar hacia fuera y escalar hacia arriba son ejes distintos. El horizontal resuelve el volumen de tráfico y además mejora la disponibilidad; el vertical resuelve el dimensionado de cada instancia. Rutas Norte necesita los dos.
• Solo se escala horizontalmente lo que es realmente sin estado. api-reservas y tienda-web sí; postgres-reservas nunca, y el intento produciría corrupción de datos, no capacidad.
• La fórmula es una regla de tres: techo(replicasActuales × valorActual / valorObjetivo), con una banda de tolerancia del ±10 % que evita el bailoteo.
• Sin requests en todos los contenedores y sin metrics-server no hay HPA. El <unknown> de la columna TARGETS casi siempre apunta a un sidecar olvidado.
• El behavior es donde se decide si el autoescalado funciona. La asimetría de Rutas Norte —subir en cero segundos, bajar tras diez minutos de calma— refleja una asimetría real de costes: perder ventas es mucho más caro que sobrar capacidad un rato.
• Con varias métricas, gana la que pide más réplicas. Un OR de necesidad, deliberadamente conservador.
• El campo replicas debe desaparecer del manifiesto versionado. Si no, un kubectl apply inocente tirará la plataforma en el pico de venta, y con GitOps será una guerra permanente (10-05).
• Antes de poner un HPA, encuentra el recurso escaso. Escalar la capa web cuando el límite es la base de datos multiplica el coste sin añadir un solo billete vendido.

Rutas Norte tiene ya api-reservas y tienda-web respondiendo al tráfico por su cuenta. Pero seguimos arrastrando un problema del que hemos hablado varias veces sin resolver del todo: el HPA se apoya en el requests de CPU como referencia de todo su cálculo, y ese requests sigue siendo un número que pusimos a ojo. En 07-02 lo recalibramos comparando con el consumo real, pero lo hicimos a mano, una vez, mirando kubectl top durante una tarde. Si el requests está mal, el porcentaje del HPA miente, y con él todas sus decisiones.

En la próxima lección, Autoescalado Vertical de Pods, veremos el componente que resuelve exactamente ese problema: el VPA observa el consumo real durante días, calcula percentiles y te dice con datos qué requests y qué limits deberían tener tus contenedores. Descubriremos también por qué el VPA y el HPA no pueden gobernar la misma métrica sin pelearse, y cuál es el flujo de trabajo que usan los equipos serios: el VPA como asesor, no como piloto automático.