La lección anterior terminó señalando el supuesto oculto de todo lo que llevamos construido: hemos dado por sentado que, cuando el HorizontalPodAutoscaler pide treinta réplicas de api-reservas, hay sitio donde ponerlas. No lo hay. El clúster de Rutas Norte tiene cuatro nodos, y treinta pods de api-reservas más quince de tienda-web más veinte de worker-notificaciones no caben en ellos ni de lejos.

El resultado de esa situación tiene un nombre y un aspecto muy concreto: pods en estado Pending, con un evento FailedScheduling que dice Insufficient cpu. Ya sabemos leerlo desde 06-05 y 07-06. Lo que no sabemos todavía es qué hacer al respecto de forma automática.

Este es el tercer y último nivel del escalado. El HPA cambia el número de pods. El VPA cambia el tamaño de cada pod. El autoescalado de clúster cambia el número de nodos. Sin él, los otros dos tienen un techo duro que no pueden atravesar.

Vamos a ver el Cluster Autoscaler en detalle: cómo decide ampliar, la parte delicada de reducir nodos (que es donde están todos los problemas reales), los tiempos que tarda de verdad un nodo en estar disponible, el patrón de sobreaprovisionamiento que compensa esos tiempos, y Karpenter como alternativa moderna. Terminaremos con el plan de capacidad concreto de Rutas Norte para el puente de mayo, con sus números y su coste.

1. El techo duro: cuando el HPA pide y no hay sitio
2. El síntoma exacto: Pending y FailedScheduling
3. Qué es el Cluster Autoscaler y dónde vive
4. Cómo decide ampliar: simulación y expanders
5. Grupos de nodos y su relación con el proveedor
6. La reducción de nodos: la parte delicada
7. Los motivos por los que un nodo no se puede vaciar
8. Diagnóstico: el ConfigMap de estado y los eventos
9. Los tiempos reales: cuánto tarda un nodo de verdad
10. Sobreaprovisionamiento con pods de relleno
11. Karpenter: la alternativa moderna
12. Cómo encajan los tres escaladores
13. Qué se puede practicar en minikube
14. El plan de capacidad de Rutas Norte y su coste
15. Errores comunes y consejos
16. Ejercicios
17. Conclusión

Pongamos el escenario con números reales. El clúster de Rutas Norte en producción:

Y el consumo en reposo, con todos los componentes en minReplicas:

Quedan unos 6,2 núcleos libres. Ahora llega el puente de mayo:

Quince pods de api-reservas se quedarán en Pending. El HPA habrá hecho su trabajo: pidió 30 réplicas y el Deployment las creó. El ReplicaSet las tiene registradas. Pero el planificador no encuentra dónde ponerlas, y ahí se quedan.

Y esto es lo peor del asunto: el HPA no lo sabe. En kubectl get hpa verás REPLICAS 30. En Grafana, el panel de réplicas dirá 30. La plataforma tendrá 15 pods listos y 15 fantasmas. Y como el HPA calcula la media de CPU solo entre los pods que sí existen y están listos, verá que están al 90 % y pedirá... nada más, porque ya está en maxReplicas.

El resultado es una plataforma que se cae con la ilusión de estar escalada.

Aprendamos a reconocerlo con precisión, porque es el disparador de todo lo demás.

Pending con 0/2 y sin reinicios: el pod existe en la API pero ningún nodo lo ha aceptado. No hay contenedores corriendo porque no hay dónde.

Dos líneas de oro:

Node: <none> — confirmación de que no está asignado a ningún nodo.

0/4 nodes are available: 4 Insufficient cpu — el planificador evaluó los cuatro nodos y los cuatro fallaron por CPU insuficiente. El mensaje siempre tiene la forma X/Y nodes are available: <razones>, y las razones se agrupan por causa. Las que verás en la práctica:

La línea NotTriggerScaleUp es la del Cluster Autoscaler, y en este ejemplo dice max node group size reached: el CA está instalado, ha visto el pod pendiente, y no puede hacer nada porque el grupo de nodos ya está en su tamaño máximo. Volveremos a este mensaje en el apartado 8, porque es la principal herramienta de diagnóstico.

Un comando muy útil para ver todos los pendientes de un vistazo:

Y para ver la ocupación real de los nodos:

Fíjate en que la columna que importa es Requests, no Limits. El planificador coloca pods según requests. Un nodo al 97 % de requests está lleno a efectos de planificación, aunque el consumo real sea del 30 %. Es la lección del módulo 3, ahora con consecuencias de capacidad.

El Cluster Autoscaler (CA) es un componente que ajusta el número de nodos del clúster. Como el VPA, vive en el repositorio kubernetes/autoscaler y no forma parte del núcleo de Kubernetes.

Su funcionamiento en una frase: observa los pods que no se pueden planificar y añade nodos; observa los nodos infrautilizados y los retira.

Corre como un Deployment dentro del propio clúster, normalmente en kube-system, con un ServiceAccount que tiene permisos amplios (leer pods y nodos, crear eventos, desalojar pods) y credenciales del proveedor de nube para manipular los grupos de nodos.

En Kubernetes gestionado (10-06) el proveedor lo instala y configura por ti: en EKS, AKS y GKE activas el autoescalado con un interruptor y el proveedor se encarga del resto. Es el escenario más habitual, y por eso conviene entender su comportamiento aunque nunca vayas a instalarlo a mano.

Ese tercer requisito es más importante de lo que parece. El CA asume que todos los nodos de un grupo son idénticos. Cuando simula si un pod cabría en un nodo nuevo del grupo A, usa la plantilla del grupo A. Si el grupo tiene máquinas heterogéneas, la simulación miente y el CA toma decisiones equivocadas. De ahí la recomendación universal: un tipo de máquina por grupo de nodos.

Y el cuarto requisito conecta con todo el módulo 3: un pod sin requests es invisible para el planificador a efectos de capacidad, y también para el CA. Aquí, otra vez, los requests son la base de todo.

El bucle del CA se ejecuta cada 10 segundos por defecto (--scan-interval).

1. Lista los pods no planificables. Los que llevan al menos --max-pod-provisioning-time en Pending con FailedScheduling.
2. Agrupa pods equivalentes. Los pods del mismo controlador con los mismos requisitos se tratan como un grupo, para no simular veinte veces lo mismo.
3. Para cada grupo de nodos, simula. «Si añado un nodo del grupo A, ¿cuántos de estos pods pendientes cabrían?» La simulación usa el planificador real, con todos sus predicados: recursos, taints, afinidades, distribución topológica, puertos de host.
4. Descarta los grupos que no ayudan. Si añadir un nodo del grupo B no permite planificar ni un solo pod (porque tiene un taint que el pod no tolera, por ejemplo), ese grupo se descarta.
5. Elige entre los grupos viables usando el expander.
6. Calcula cuántos nodos hacen falta y le pide al proveedor que amplíe el grupo.

Un detalle importante del paso 6: el CA puede añadir varios nodos a la vez. Si hay 15 pods pendientes de 520m cada uno y en un nodo de 4 núcleos caben 6, pedirá 3 nodos de golpe, no uno cada vez. Esto está limitado por --max-nodes-total y por el máximo del grupo.

Cuando varios grupos de nodos servirían, el expander decide cuál.

Ejemplo concreto de least-waste. Hay 3 pods pendientes que necesitan 500m y 512Mi cada uno (total: 1,5 núcleos y 1,5 GiB), y dos grupos disponibles:

least-waste elige el grupo A: ajusta mejor y no paga por 6 núcleos ociosos. most-pods elegiría el B (cabrían muchos más pods futuros). price elegiría el A si es más barato.

Configuración del expander:

La opción --balance-similar-node-groups merece mención porque resuelve un problema real de alta disponibilidad: si tienes un grupo de nodos por zona de disponibilidad, esta bandera hace que el CA reparta los nodos nuevos equilibradamente entre zonas en lugar de amontonarlos en una. Sin ella, puedes acabar con doce nodos en la zona A y ninguno en la B, y una caída de zona te deja sin plataforma. Conecta directamente con lo que veremos en 09-05.

Un patrón muy rentable en la nube. Las instancias spot (interrumpibles) cuestan una fracción del precio, pero el proveedor puede reclamarlas con dos minutos de aviso.

El CA intenta primero el grupo de prioridad 100. Si el proveedor no tiene capacidad spot disponible, cae al de prioridad 50. Para worker-notificaciones, que tolera interrupciones sin problema, es la opción evidente. Para postgres-reservas, jamás.

El CA no crea máquinas: manipula grupos de nodos del proveedor. Cada proveedor tiene su nombre para lo mismo:

Un grupo de nodos tiene un tamaño mínimo, un máximo y un actual. El CA solo cambia el actual, dentro de esos límites. Todo lo demás (el tipo de máquina, la imagen, los taints y etiquetas iniciales) lo define el grupo.

Los grupos de Rutas Norte:

Tres decisiones de diseño que conviene entender:

Un grupo por zona. Necesario para que --balance-similar-node-groups reparta entre zonas y para que la afinidad de zona funcione. Con un único grupo multizona, el CA no puede garantizar en qué zona aparecerá el nodo nuevo, y eso rompe la distribución topológica de 09-05.

Un grupo dedicado a datos con taint. postgres-reservas y redis-cache tienen tolerations para rol=datos (06-05) y afinidad de nodo hacia ese grupo. Así las bases de datos viven en máquinas grandes con disco rápido y no comparten nodo con la avalancha de pods de api-reservas. El taint impide que los pods de la aplicación aterricen ahí.

El grupo de datos tiene max=3, muy bajo. Es deliberado: no queremos que el CA arranque máquinas grandes y caras por error. postgres-reservas no escala horizontalmente (09-01), así que ese grupo casi nunca necesita crecer.

Cuando el CA simula si un pod cabría en un nodo del grupo A, usa una plantilla. Si el nodo real, al arrancar, recibe etiquetas o taints que la plantilla no conocía, la simulación miente.

Caso típico y muy frustrante: un pod con nodeSelector: disco=ssd está Pending. El CA simula con la plantilla del grupo, que no tiene esa etiqueta, concluye que el pod no cabría ni con un nodo nuevo, y no escala. Pero los nodos reales del grupo sí reciben esa etiqueta al arrancar, mediante un script de arranque.

La solución es declarar las etiquetas y taints en la propia definición del grupo de nodos del proveedor (en AWS, con etiquetas k8s.io/cluster-autoscaler/node-template/label/... en el ASG), para que el CA las conozca antes de arrancar el nodo.

Ampliar es fácil: hay pods pendientes, se añaden nodos. Reducir es donde están todos los problemas, porque retirar un nodo implica desalojar los pods que tiene y confiar en que reaparecerán en otro sitio sin romper nada.

Cada 10 segundos, para cada nodo:

1. ¿Está por debajo del umbral de utilización? Por defecto, --scale-down-utilization-threshold=0.5: la suma de requests de sus pods es menor del 50 % de su capacidad asignable.
2. ¿Lleva así el tiempo suficiente? --scale-down-unneeded-time=10m: diez minutos consecutivos por debajo del umbral.
3. ¿Se puede vaciar? Simula si todos sus pods cabrían en otros nodos existentes. Si no caben, no se toca.
4. ¿Hay algún pod que impida el desalojo? La lista del apartado 7.
5. Si todo pasa: acordona el nodo, desaloja sus pods respetando los PDB, espera, y le pide al proveedor que lo elimine.

Parámetros principales:

--scale-down-delay-after-add es el parámetro clave para evitar el bailoteo de nodos. Sin él, el CA podría añadir un nodo, ver que el clúster queda infrautilizado y quitarlo inmediatamente. Diez minutos de gracia rompen ese ciclo.

Sobre el umbral de utilización, un cálculo importante:

Fíjate en que los DaemonSets cuentan para la utilización pero no impiden la eliminación (se ignoran en el paso 4, porque desaparecen con el nodo). Con muchos DaemonSets, la utilización base de un nodo vacío ya es alta, y eso hace que el CA reduzca menos de lo que esperarías. En clústeres con muchos agentes (logging, seguridad, malla de servicio, monitorización), es habitual tener que bajar el umbral al 30-40 % para que la reducción funcione.

Un nodo que solo tiene DaemonSets se considera vacío y se elimina por un camino rápido, sin la simulación completa. Por eso, tras una punta de tráfico, los nodos que quedan totalmente libres desaparecen bastante rápido, mientras que los que tienen un pod suelto tardan mucho más.

Esto explica un fenómeno que desconcierta a mucha gente: tras el puente de mayo, ocho nodos se van en veinte minutos y dos se quedan durante horas con un solo pod cada uno. La solución de fondo no es tocar el CA: es la distribución topológica y la consolidación (Karpenter, apartado 11).

Esta es la lista que hay que conocer de memoria, porque explica el 90 % de los casos de «tengo nodos vacíos que el autoescalador no quita y estoy pagando por ellos».

Es la herramienta de control más directa:

Cuándo tiene sentido "false":

• Un trabajo por lotes largo que perdería horas de cómputo si se reinicia. informes-ocupacion es un candidato: si tarda 40 minutos y el CA lo mata en el minuto 35, la noche se pierde.
• Una migración de base de datos en curso.
• Un pod con estado local irreproducible.

Y el valor contrario, "true", sirve para desbloquear situaciones:

Es la forma limpia de resolver el motivo 2 sin cambiar la bandera global del CA. En Rutas Norte, tienda-web usa un emptyDir para la caché de nginx: marcarlo como safe-to-evict: "true" permite que el CA retire sus nodos sin problema, porque esa caché se regenera sola.

El caso más frecuente y el más peligroso. Un PDB así:

Con una sola réplica de postgres-reservas y minAvailable: 1, ese pod nunca puede ser desalojado: hacerlo dejaría 0 disponibles. El nodo que lo aloje queda anclado permanentemente. El CA lo intentará, fallará, y lo registrará en sus eventos.

En este caso concreto el bloqueo es deseable (no queremos que el CA mueva la base de datos por su cuenta), pero el mismo patrón aplicado por error a un servicio cualquiera produce nodos zombis que nadie sabe por qué no se van. Lo desarrollamos a fondo en 09-05.

El CA publica su estado interno en un ConfigMap. Es el primer sitio donde mirar.

Cómo leerlo:

En la salida de arriba: el grupo A tiene 3 listos y 1 arrancando. El CA ya ha pedido el nodo; solo hay que esperar. Esta información es exactamente lo que necesitas durante un incidente para saber si el CA está trabajando o atascado.

Estados de ScaleDown que verás:

Cuando el CA decide no hacer nada, lo dice en un evento sobre el pod pendiente:

Este mensaje es un regalo: te dice exactamente por qué cada grupo de nodos fue descartado. Aquí: un grupo está al máximo y otro tiene un taint que el pod no tolera.

Mensajes habituales de NotTriggerScaleUp y su traducción:

Y para la reducción bloqueada:

Los logs del CA son la fuente definitiva cuando el ConfigMap y los eventos no bastan. Consérvalos en EFK (07-05): son imprescindibles para el análisis posterior de un incidente de capacidad.

Aquí está el dato que cambia la estrategia, y el que casi nunca se cuenta.

Sumando: entre 3 y 4 minutos en el caso bueno. En el caso malo (imagen grande no cacheada, región saturada, DaemonSets pesados) puede pasar de 6 minutos.

Desglose típico en tabla:

Volvamos al puente de mayo. La venta abre a las 10:00. El perfil de tráfico real:

Cinco minutos de latencia degradada y errores en el momento de mayor valor comercial del año. Miles de usuarios que abandonan la compra. El Cluster Autoscaler, por bien configurado que esté, no puede resolver una punta que sube en cuarenta segundos, porque la física de arrancar una máquina virtual no lo permite.

De aquí salen dos estrategias, y hacen falta las dos:

1. Sobreaprovisionamiento: tener capacidad ya arrancada y esperando (apartado 10).
2. Escalado anticipado: escalar antes del pico usando un disparador temporal, no reactivo. Es el disparador cron de KEDA que veremos en 09-04.

El patrón que resuelve el problema del apartado anterior, y que usa de forma brillante la PriorityClass y la preemption de 06-05.

Desplegamos pods que no hacen nada —duermen— pero reservan CPU y memoria, con una prioridad negativa. Efectos:

1. El CA cuenta esos requests como ocupación, así que mantiene nodos arrancados para alojarlos.
2. Cuando llega un pod real (prioridad 0 o superior) y no hay sitio, el planificador desaloja instantáneamente un pod de relleno y coloca el real en su hueco. La preemption tarda segundos, no minutos.
3. Los pods de relleno desalojados pasan a Pending, lo que dispara al CA para arrancar nodos nuevos... que rellenarán el colchón para la siguiente vez.

Es un colchón de capacidad autorregenerativo. Compras capacidad ociosa a cambio de tiempo de respuesta.

Paso 1: la PriorityClass negativa.

Dos detalles importantes:

• value: -10 garantiza que cualquier pod sin priorityClassName (prioridad 0) los supere.
• preemptionPolicy: Never hace que estos pods, al quedarse Pending, no intenten desalojar a otros. Sería absurdo que el colchón echase a un pod real.

Paso 2: el Deployment de relleno.

La imagen pause es la elección canónica: es la misma que Kubernetes usa internamente para el contenedor de infraestructura de cada pod, pesa menos de un megabyte, está ya en la caché de todos los nodos y su único trabajo es dormir.

Paso 3: comprobar que funciona.

Ahora forzamos una punta:

Y en los eventos de los pods de api-reservas:

Tres segundos desde la creación del pod hasta su planificación, en lugar de tres minutos y medio. Esa es la diferencia entre absorber la apertura de la venta y caerse.

Nada es gratis:

¿Merece la pena? En Rutas Norte, la respuesta es clara: cinco minutos de caída en la apertura del puente de mayo cuestan mucho más de 1.940 euros en billetes no vendidos. Pero es una decisión de negocio, no técnica, y debe tomarse con números encima de la mesa.

Optimización evidente: el colchón no tiene por qué ser constante. Un CronJob (06-03) que escale el Deployment de relleno de 2 a 6 réplicas los viernes por la tarde y lo devuelva a 2 los lunes reduce el coste anual a una fracción:

Y su pareja el lunes a las 6:00 con --replicas=2. El ServiceAccount operador-escalado necesita un Role con permiso sobre deployments/scale, exactamente como vimos en 08-01.

El Cluster Autoscaler tiene una limitación de diseño: trabaja con grupos de nodos predefinidos. Alguien tiene que decidir de antemano qué tipos de máquina existen, crear un grupo por cada uno, y mantenerlos.

Karpenter invierte el planteamiento: mira los pods pendientes, calcula qué máquina sería la mejor para ellos, y la arranca directamente, sin grupos.

En lugar de grupos de nodos, defines restricciones de qué tipos de máquina son aceptables:

Con esta definición, cuando aparecen 15 pods de api-reservas pendientes, Karpenter calcula que la mejor máquina para alojarlos es, pongamos, una c6i.4xlarge spot en la zona B, y la arranca. Sin que nadie haya creado nunca un grupo de nodos c6i.4xlarge.

Es la diferencia más práctica en el día a día. Karpenter revisa continuamente si el conjunto de pods actual cabría en una configuración de nodos más barata, y si es así, migra los pods y sustituye los nodos.

El escenario que resuelve: tras el puente de mayo, el CA deja cinco nodos con un pod cada uno, porque ninguno baja del umbral de utilización de forma que permita vaciarlo. Karpenter ve que esos cinco pods cabrían en un solo nodo, arranca ese nodo, migra los pods y elimina los cinco.

Es exactamente el problema que mencionamos al final del apartado 6, resuelto de raíz.

Cuándo elegir cada uno:

• Cluster Autoscaler si estás fuera de AWS, si tienes requisitos regulatorios sobre qué tipos de máquina son admisibles, si tu proveedor ya te lo da configurado y funciona, o si valoras la predecibilidad por encima del ahorro.
• Karpenter si estás en AWS, si el coste es una prioridad real, si tu carga es heterogénea (pods pequeños y pods grandes conviviendo), y si te compensa la reducción de trabajo operativo.

Para Rutas Norte, con cuatro nodos y una carga homogénea, el CA es más que suficiente. Si la plataforma creciera a cincuenta nodos con cargas variadas, Karpenter sería la decisión evidente. Volveremos a este tipo de decisiones en 10-06 y 11-06.

Una nota importante que la comparativa no debe ocultar: Karpenter tampoco arregla la punta de cuarenta segundos. Uno o dos minutos siguen siendo demasiado. El sobreaprovisionamiento sigue haciendo falta.

Ya tenemos las tres piezas. Veamos el flujo completo en orden temporal.

Las tres rutas y sus tiempos:

La conclusión estratégica es directa: el colchón de sobreaprovisionamiento no es un lujo, es lo que convierte un incidente de cinco minutos en uno de treinta segundos.

Y aún queda una ruta mejor, que no aparece en el diagrama porque no es reactiva: escalar antes de que llegue el tráfico. Si a las 9:30 ya tienes 25 réplicas y ocho nodos porque un disparador cron lo ordenó, a las 10:00 no hay ningún incidente. Eso es 09-04.

Los tres son necesarios y ninguno sustituye a otro. El HPA sin CA tiene un techo duro. El CA sin HPA nunca se dispara. El VPA los hace a ambos más precisos, porque los requests correctos son la base tanto del cálculo del HPA como de la simulación del CA.

Momento de honestidad: el Cluster Autoscaler no se puede probar de verdad en minikube. No hay proveedor de nube que arranque máquinas. El perfil rutas-norte tiene los nodos que le pediste al crearlo, y esos son todos.

1. Producir el síntoma y aprender a leerlo.

Verás exactamente el FailedScheduling con Insufficient cpu. Es el mismo mensaje que en producción.

2. El patrón de sobreaprovisionamiento con preemption. Esto funciona perfectamente, porque la preemption es una función del planificador, no del proveedor de nube.

Ver el Preempted con tus propios ojos y medir que ocurre en segundos es la parte más valiosa del ejercicio, y se practica sin nube.

3. Añadir y quitar nodos a mano, simulando lo que haría el CA.

Esa secuencia cordon → drain → eliminar es exactamente lo que hace el CA internamente. Practicarla a mano enseña más sobre la reducción de nodos que leer cualquier documentación, y es la base del procedimiento de mantenimiento que veremos en 09-05.

4. Practicar la anotación safe-to-evict y ver cómo bloquea un drenaje.

Para practicar el CA de verdad hacen falta: un clúster gestionado (10-06) con el autoescalado activado, o kind con el proveedor de pruebas del CA, o un entorno de nube personal. Recomendación práctica: una cuenta de pruebas de un proveedor durante una tarde, con un clúster pequeño y maxSize bajo, cuesta unos pocos euros y enseña muchísimo.

Cerramos con los números concretos. Este es el trabajo que hay que hacer antes de un puente de mayo, y que no se hizo el año pasado.

De los maxReplicas de 09-01 y los requests recalibrados con el VPA de 09-02:

El margen del 33 % no es capricho: cubre errores de estimación, un despliegue en curso durante el pico (que duplica temporalmente los pods de un componente), y la pérdida de una zona completa.

Precios ficticios pero de orden de magnitud realista:

Y la comparación que justifica todo el módulo:

La última fila es el objetivo: prácticamente el mismo coste que el dimensionado fijo insuficiente, con la capacidad del dimensionado para el pico. Ese es todo el valor del módulo 9 resumido en una línea.

Y un recordatorio de honestidad intelectual: el colchón reducido fuera de temporada solo funciona si el CronJob que lo amplía se ejecuta de verdad. Ponle una alerta: si el viernes a las 16:05 el Deployment de relleno no tiene 6 réplicas, alguien tiene que enterarse.

Error 1: creer que el HPA solo puede llevarte hasta donde hay capacidad, y no darse cuenta. El síntoma es silencioso: kubectl get hpa muestra 30 réplicas y todo parece bien. Solo kubectl get pods revela que 15 están Pending. Alerta obligatoria sobre pods pendientes:

Error 2: maxReplicas del HPA incoherente con el maxSize de los grupos de nodos. Un maxReplicas: 100 con grupos que topan en 8 nodos es una mentira: nunca llegarás a 100 réplicas. Calcula siempre Σ(maxReplicas × requests) y compáralo con Σ(maxSize × capacidad asignable). Documenta ese cálculo junto a los manifiestos.

Error 3: pods sin requests en un clúster con CA. Un pod sin requests es invisible para la simulación del CA: el autoescalador cree que un nodo tiene sitio de sobra cuando en realidad está saturado de pods que consumen sin declarar nada. El LimitRange del módulo 3 es la defensa: fuerza un defaultRequest a todo lo que se cree.

Error 4: esperar que el CA salve una punta repentina. Tres a seis minutos. Si tu tráfico sube en cuarenta segundos, el CA llega tarde. Sobreaprovisionamiento (apartado 10) y escalado anticipado (09-04). No hay tercera vía.

Error 5: PDB imposibles que anclan nodos para siempre. Un minAvailable igual al número de réplicas hace que ningún pod pueda desalojarse nunca, y el nodo que los aloje jamás se retirará. Estarás pagando por nodos infrautilizados sin saber por qué. Lo desarrollamos en 09-05, pero el diagnóstico está en los logs del CA: pdb-blocked.

Error 6: un solo grupo de nodos para todo. Sin separar los datos de la aplicación, una avalancha de pods de api-reservas puede aterrizar en el mismo nodo que postgres-reservas y competir por su CPU. Taints y grupos separados (06-05).

Error 7: nodos heterogéneos dentro de un mismo grupo. El CA usa una plantilla por grupo. Si el grupo mezcla máquinas de 2 y de 8 núcleos, la simulación miente y las decisiones son erráticas. Un tipo de máquina por grupo, siempre.

Consejo 1: --balance-similar-node-groups si tienes un grupo por zona. Sin ella, el CA puede amontonar todos los nodos nuevos en una zona y dejarte expuesto a una caída de zona. Es una línea de configuración con impacto directo en la disponibilidad.

Consejo 2: monitoriza cluster_autoscaler_unschedulable_pods_count. El CA expone métricas Prometheus. Las que importan:

Ese tercer indicador es especialmente valioso: un failed_scale_up significa que el proveedor te ha dicho que no. Cuota agotada, tipo de instancia sin disponibilidad en la zona, límite de la cuenta. Son problemas que solo se descubren cuando ya es tarde, salvo que los vigiles.

Consejo 3: ensaya el escalado antes del pico. Una semana antes del puente, lanza una prueba de carga contra rutas-norte-pre (09-06) y cronometra cuánto tarda el clúster en alcanzar la capacidad máxima. Ese número, medido y no estimado, es lo que te dice si el colchón es suficiente.

Consejo 4: sube el maxSize de los grupos antes de la temporada alta y bájalo después. Es un cambio de un minuto que evita el max node group size reached en el peor momento. Ponlo en la lista de comprobación previa al evento.

Consejo 5: guarda los logs del CA. Son la única fuente que explica por qué no se escaló o por qué un nodo no se retiró. Sin ellos, el análisis posterior de un incidente de capacidad es adivinar. EFK (07-05).

Consejo 6: revisa el umbral de reducción si tienes muchos DaemonSets. Con Fluentd, Falco, el CNI, el exportador de nodo y quizá un proxy de malla de servicio, la utilización base de un nodo vacío puede rondar el 25 %. Con el umbral por defecto del 50 %, la reducción casi nunca se dispara. Bajarlo al 35 % puede ahorrar nodos enteros.

El equipo de Rutas Norte ha configurado esto para el puente de mayo:

HPA:

Componentes fijos: postgres-reservas (1 réplica, 2 núcleos, 4Gi), redis-cache (1 réplica, 300m, 2Gi), Ingress (4 réplicas, 200m, 256Mi).

Grupos de nodos:

DaemonSets: 450m y 512Mi por nodo. Reserva del sistema: 500m y 2Gi por nodo.

ResourceQuota del namespace: requests.cpu: 40, requests.memory: 80Gi.

Calcula: (a) la CPU y memoria máximas que puede demandar la aplicación; (b) la capacidad asignable máxima real de los grupos; (c) si la configuración aguanta el pico; (d) el porcentaje de maxReplicas de api-reservas que es alcanzable en la práctica; (e) qué corregirías y en qué orden.

Tras el puente de mayo, el clúster sigue con 9 nodos aunque el tráfico volvió a la normalidad hace 5 horas. La factura preocupa. Esto es lo que ves:

Analiza cada nodo bloqueado, di si el bloqueo es legítimo o un error, y propón la corrección para cada caso. Calcula cuántos nodos se podrían retirar tras las correcciones y el ahorro mensual (95 €/nodo/mes).

Rutas Norte lanza una campaña de Black Friday distinta a todo lo anterior:

• Duración: 2 horas exactas, de 20:00 a 22:00 de un viernes.
• Tráfico esperado: x25 respecto a un día normal (mucho más que el puente de mayo).
• El pico llega en 20 segundos: se anuncia por radio y todo el mundo entra a la vez.
• Los billetes son limitados: si la plataforma no responde en los primeros 10 minutos, la campaña ha fracasado.
• Presupuesto: hasta 400 € para esa noche.
• Se conoce con tres semanas de antelación.

Diseña la estrategia completa de capacidad. ¿Qué combinación de HPA, CA, sobreaprovisionamiento y escalado programado usarías? ¿Cuántos nodos, cuánto colchón, con qué antelación? ¿Cuánto costaría? Escribe los manifiestos clave y una lista de comprobación con horarios concretos para esa noche.

Solución 1

(a) Demanda máxima de la aplicación:

(b) Capacidad asignable máxima real:

(c) ¿Aguanta el pico? NO.

Y hay un segundo problema que muchos pasarían por alto: la ResourceQuota.

(d) Porcentaje de maxReplicas de api-reservas alcanzable:

El maxReplicas: 40 es ficción: la realidad son 25 réplicas. Y peor: cuando el HPA pida las réplicas 26 a 40, se quedarán en Pending y nadie se enterará salvo que haya una alerta.

(e) Correcciones, por orden de prioridad:

Prioridad 1 (imprescindible): subir el maxSize de los grupos generales.

Prioridad 2: reducir el maxSize del grupo de datos.

Prioridad 3: revisar el maxReplicas: 40 de api-reservas.

Con 12 nodos generales caben 25 réplicas... espera, recalculemos con la nueva capacidad:

Prioridad 4: añadir el colchón de sobreaprovisionamiento. Sin él, las réplicas 5 a 40 tardarán entre 3 y 6 minutos en aparecer. Con 6 pods de relleno de 1 núcleo, las primeras 11 réplicas son instantáneas.

Prioridad 5: la alerta de pods pendientes. Sin ella, todo este cálculo se puede equivocar y nadie lo sabrá hasta que sea tarde.

Solución 2

Análisis nodo por nodo:

Caso 1: ip-10-0-1-88 — informes-ocupacion con safe-to-evict: false.

Legitimidad: condicional. Si el Job está ejecutándose ahora mismo, el bloqueo es correcto: matarlo perdería el trabajo. Pero el puente terminó hace 5 horas y informes-ocupacion es un CronJob nocturno.

Si aparece como Running desde hace horas, es un Job colgado: probablemente falló y se quedó atascado. Corrección:

Y prevención estructural en el CronJob:

Nodo recuperable: SÍ, tras limpiar el Job.

Caso 2: ip-10-0-2-73 — redis-cache-0.

Legitimidad: sí, plenamente. redis-cache es un StatefulSet de una réplica con volumen. El CA no puede moverlo con seguridad, y desde luego no debe hacerlo por su cuenta: reiniciar la caché descarga toda la carga sobre postgres-reservas.

Corrección: ninguna a corto plazo. A medio plazo, las opciones son:

• Anclar redis-cache al grupo de nodos de datos con afinidad y taint (06-05), para que no ocupe un nodo general.
• Aceptarlo: un nodo dedicado a la caché no es un desperdicio si está bien dimensionado.

La mejor corrección es la primera: redis-cache no debería estar en un nodo general. Es una decisión de arquitectura que ya deberíamos haber tomado.

Nodo recuperable: NO directamente, pero sí tras mover redis-cache al grupo de datos.

Caso 3: ip-10-0-1-15 — PDB bloqueando api-reservas.

Legitimidad: no, es un error de configuración. api-reservas es un Deployment con muchas réplicas: mover un pod debería ser trivial. Que el PDB lo impida significa que está mal.

Sospecha probable:

Tras el puente, el HPA ha bajado a 4-6 réplicas. Con minAvailable: 30 y 6 réplicas vivas, ningún pod puede desalojarse jamás: ya se está por debajo del mínimo.

Corrección:

Esta es la lección central de 09-05, adelantada: con HPA, los PDB en número absoluto son una trampa. El número de réplicas cambia solo, y un mínimo absoluto que era razonable en el pico se vuelve imposible en el valle.

Nodo recuperable: SÍ, inmediatamente tras corregir el PDB.

Caso 4: ip-10-0-3-22 — generador-carga sin controlador.

Legitimidad: no, es basura. Es el pod de prueba de carga del apartado 12 de 09-01, creado con kubectl run sin controlador y olvidado. Lleva días ahí anclando un nodo entero.

Prevención:

• Usa siempre --rm con kubectl run para pruebas.
• Una política de Kyverno (08-03) que rechace pods sin ownerReferences en rutas-norte-pro.
• Una revisión periódica de pods huérfanos:

Nodo recuperable: SÍ, inmediatamente.

Resumen y ahorro:

Comprobación tras las correcciones:

Debería pasar de NoCandidates a CandidatesPresent y luego a InProgress.

Lección de fondo del ejercicio: los nodos zombis nunca son culpa del Cluster Autoscaler. Siempre son consecuencia de algo mal configurado en las cargas: un PDB imposible, un Job colgado, un pod huérfano, un componente con estado en el sitio equivocado. El CA es el mensajero; los logs son el mensaje.

Solución 3

Análisis del escenario. Este caso es cualitativamente distinto al puente de mayo:

La conclusión clave: el escalado reactivo NO sirve aquí. Ni el HPA (15 s de detección + 30 s de arranque) ni el CA (3-6 min) llegan a tiempo para una subida de 20 segundos. Toda la capacidad tiene que estar ya arrancada y caliente antes de las 20:00.

Estrategia: preescalado total.

Paso 1: calcular la capacidad necesaria.

Paso 2: traducir a nodos.

Paso 3: los manifiestos.

Grupos de nodos para esa noche:

Fíjate en el detalle importante: el min de los grupos se sube a 3, no se confía en el CA. Poniendo el mínimo alto, el proveedor arranca las máquinas y el CA no puede retirarlas. La capacidad está garantizada por construcción, no por reacción.

Paso 4: el coste.

El resultado sorprende y es la enseñanza del ejercicio: dimensionar generosamente para dos horas es baratísimo. El coste de la infraestructura en la nube es proporcional al tiempo, y dos horas de sobredimensionamiento cuestan menos que un café por nodo. Con un presupuesto de 400 €, no hay ninguna excusa para escatimar capacidad esa noche.

Con el margen sobrante se pueden permitir mejoras:

• Subir a 12 nodos desde el principio en lugar de 8: +5,20 €.
• Duplicar las réplicas de redis-cache en modo réplica de lectura: +2 €.
• Mantener la capacidad hasta las 2:00 para vaciar la cola de notificaciones sin prisa: +15 €.

Todo eso cabe holgadamente.

Paso 5: la lista de comprobación de la noche.

Notas críticas sobre el plan:

1. La verificación de las 18:30 es la más importante. 88 pods creados no es lo mismo que 88 pods Ready. Si a las 18:30 hay 20 en Pending, hay dos horas para arreglarlo. Si te enteras a las 20:01, no hay nada que hacer.

2. El scaleDown: Disabled es innegociable. Sin él, un valle de un minuto entre las 20:15 y las 20:16 podría destruir 30 réplicas que tardarían minutos en volver.

3. worker-notificaciones no se escala durante la campaña. Es una decisión deliberada: los correos de confirmación pueden esperar dos horas, la venta no. Toda la capacidad va a la venta. Esta es la clase de compromiso explícito que distingue un plan de capacidad de una lista de deseos.

4. La regla de "no tocar nada" durante la campaña. Casi todos los incidentes graves en eventos de este tipo los causa alguien intentando arreglar algo bajo presión. Si los paneles están verdes, se mira y no se toca.

5. El precalentamiento de cachés a las 19:30 ahorra que los primeros 5.000 usuarios paguen el coste de las consultas frías a PostgreSQL. Es media hora de trabajo con un impacto enorme en los primeros minutos.

El autoescalado de clúster es el nivel que sostiene a los otros dos. Sin él, el HorizontalPodAutoscaler tiene un techo duro e invisible: pide réplicas, el Deployment las crea, y se quedan en Pending mientras los paneles muestran números que no se corresponden con la realidad.

Lo esencial:

• El síntoma es siempre el mismo: pods en Pending con FailedScheduling e Insufficient cpu. Reconocerlo y alertar sobre él es lo primero.
• El Cluster Autoscaler observa pods no planificables, simula qué grupo de nodos los alojaría, y elige con un expander. least-waste es el más razonable en general.
• Ampliar es fácil; reducir es donde están los problemas. Umbral de utilización, tiempo de espera, y una lista de bloqueadores que hay que conocer: pods sin controlador, almacenamiento local, PDB restrictivos, pods del sistema, y la anotación safe-to-evict: "false".
• Diagnosticar es leer tres sitios: el ConfigMap cluster-autoscaler-status, los eventos NotTriggerScaleUp sobre los pods pendientes, y los logs del CA con sus not suitable for removal.
• Un nodo tarda entre 3 y 6 minutos en pasar de la petición a servir tráfico. Eso no salva una punta que sube en cuarenta segundos, por bien configurado que esté todo.
• El sobreaprovisionamiento con pods de prioridad negativa convierte tres minutos y medio en tres segundos, a cambio de pagar capacidad ociosa. Es el uso más elegante de la PriorityClass y la preemption de 06-05, y se autorregenera.
• Karpenter elige la máquina en función de los pods pendientes en lugar de trabajar con grupos fijos, y consolida continuamente. Mejor en AWS y con cargas heterogéneas; el CA sigue siendo la opción sólida y predecible en el resto de casos.
• Los tres escaladores encajan en cascada: HPA crea pods → si no caben, Pending → el CA añade nodos. Y el colchón corta el camino largo.
• El plan de capacidad de Rutas Norte cuesta prácticamente lo mismo que el dimensionado fijo insuficiente del año pasado, pero con la capacidad del dimensionado para el pico. Ese es todo el valor del módulo.

Pero seguimos teniendo un problema de fondo que ninguna de las tres lecciones ha resuelto. Todo lo que hemos construido es reactivo: espera a que la CPU suba para actuar. Y hay dos casos donde eso simplemente no funciona.

El primero es worker-notificaciones. Durante el puente de mayo puede tener cuarenta mil correos esperando en la cola y la CPU al 20 %, porque su trabajo es esperar respuestas del servidor de correo, no calcular. Un HPA por CPU vería ese 20 % contra un objetivo del 70 % y concluiría que sobran réplicas: escalaría hacia abajo justo cuando más consumidores hacen falta.

El segundo es el propio momento de apertura de la venta. Sabemos que ocurre a las 10:00 en punto. Es información que tenemos con meses de antelación. Y sin embargo, todo nuestro sistema espera a las 10:00:15 para descubrir, por la CPU, algo que ya sabíamos en marzo.

En la próxima lección, Escalado por Eventos y Métricas Personalizadas con KEDA, resolvemos los dos. Veremos cómo el HPA puede consumir métricas de negocio a través de la API de agregación, qué es KEDA y por qué no sustituye al HPA sino que lo alimenta, cómo escalar worker-notificaciones por la longitud real de su cola —con escalado a cero incluido—, cómo escalar api-reservas por peticiones por segundo usando las métricas que instrumentamos en 07-03, y cómo programar un disparador que precaliente toda la plataforma media hora antes de que se abra la venta del puente de mayo.