La lección anterior terminó con una incomodidad. El HorizontalPodAutoscaler de api-reservas calcula todas sus decisiones como un porcentaje del requests.cpu, y ese requests.cpu: 500m es un número que alguien puso a ojo hace meses. En 07-02 lo recalibramos comparando con el consumo real, pero lo hicimos a mano, una tarde, mirando kubectl top y anotando en una hoja de cálculo. Si el requests está mal, el porcentaje del HPA miente y todas sus decisiones se apoyan en una referencia falsa.

Y el problema es más amplio que el HPA. Los requests y limits gobiernan la planificación (dónde cabe un pod), la clase de QoS (quién muere primero cuando falta memoria), el OOMKilled, el estrangulamiento de CPU, el consumo de la ResourceQuota del namespace y, en la nube, la factura. Todo eso descansa sobre números que en la mayoría de las organizaciones se escribieron una vez, copiando el manifiesto de otro servicio, y nadie ha vuelto a mirar.

El VerticalPodAutoscaler (VPA) existe para eso. No escala por carga: escala por conocimiento. Observa lo que tus contenedores consumen realmente durante días, calcula percentiles y te dice con datos qué deberían pedir. Esta lección cubre qué es, cómo funciona por dentro, cómo leer sus recomendaciones, por qué la mayoría de equipos serios lo usan como asesor y no como piloto automático, y por qué no puede convivir con el HPA sobre la misma métrica.

1. El problema real: nadie sabe qué pedir
2. Qué es el VPA y qué no es
3. No forma parte del núcleo: instalación
4. Los tres componentes y cómo colaboran
5. El objeto VerticalPodAutoscaler campo a campo
6. Los modos de actualización: Off, Initial, Recreate y Auto
7. El redimensionado en caliente y su estado actual
8. resourcePolicy: acotar, excluir y controlar
9. Leer una recomendación: target, lowerBound, upperBound, uncappedTarget
10. El modo Off como asesor: el flujo de trabajo real
11. La incompatibilidad clásica: VPA y HPA sobre la misma métrica
12. Aplicación a Rutas Norte, componente a componente
13. Interacción con LimitRange y ResourceQuota
14. Los límites del VPA
15. Errores comunes y consejos
16. Ejercicios
17. Conclusión

Pongamos números al problema. Estos son los requests que Rutas Norte lleva arrastrando desde el módulo 3, junto al consumo real medido durante dos semanas con Prometheus:

Cada fila cuenta una historia distinta y cada una cuesta dinero o disponibilidad:

• api-reservas con memoria corta. Pide 512Mi y usa 690Mi en el p95. Funciona porque el limit es 1Gi y hay memoria libre en los nodos... hasta que no la hay. El día que un nodo se llena, el kubelet desaloja pods, y un pod Burstable que consume por encima de su requests es de los primeros candidatos (módulo 3). Es una bomba de relojería.
• tienda-web sobredimensionado tres veces. Con 15 réplicas en el pico son 3 núcleos reservados de los que se usan 0,8. Esos 2,2 núcleos están bloqueados para el planificador: ningún otro pod puede usarlos aunque estén ociosos. Se traduce en nodos de más.
• informes-ocupacion muy infradimensionado. Pide 500m y necesita 1750m. Consecuencia: estrangulamiento brutal. Un informe que debería tardar 8 minutos tarda 40, y algunas noches no termina antes de la ventana de mantenimiento.
• El exportador de métricas. 20m de requests para un proceso que usa 4m. Parece poco, pero multiplicado por todos los pods de la plataforma son núcleos enteros desperdiciados.

Ahora la pregunta incómoda: ¿cómo se corrige esto? La respuesta habitual —«miramos Grafana y ajustamos»— tiene tres problemas. Requiere que alguien se acuerde. Requiere que ese alguien sepa qué percentil mirar. Y hay que repetirlo cada vez que la aplicación cambia, lo que en la práctica significa nunca.

El VPA automatiza exactamente ese trabajo.

El VerticalPodAutoscaler es un componente que:

1. Observa el consumo histórico de CPU y memoria de los contenedores de un conjunto de pods.
2. Calcula una recomendación de requests (y opcionalmente limits) basada en percentiles de ese histórico, con decaimiento exponencial para dar más peso a lo reciente.
3. Opcionalmente aplica esa recomendación, recreando los pods con los nuevos valores.

Y muy importante, lo que no es:

Esta distinción es la clave para entender la relación con el HPA. El HPA es un mecanismo de respuesta a la carga, con constante de tiempo de segundos. El VPA es un mecanismo de corrección del dimensionado, con constante de tiempo de días. No compiten en el mismo terreno... salvo cuando ambos miran la misma métrica, que es el conflicto del apartado 11.

Una forma útil de recordarlo: el HPA responde a la pregunta «¿cuántos?»; el VPA responde a la pregunta «¿de qué tamaño?».

A diferencia del HPA, que vive dentro del kube-controller-manager y está disponible en cualquier clúster, el VPA es un componente externo que hay que instalar. Vive en el repositorio kubernetes/autoscaler, junto al Cluster Autoscaler que veremos en 09-03.

Esto tiene consecuencias prácticas que conviene conocer antes de empezar:

• Debes comprobar la compatibilidad de versiones entre el VPA y tu Kubernetes. La tabla de compatibilidad está en el repositorio; usar una versión desajustada produce errores oscuros.
• Instala tres Deployments y un puñado de CRDs, RBAC y un webhook de admisión.
• En Kubernetes gestionado (10-06), muchos proveedores lo ofrecen como complemento activable con un interruptor (GKE lo tiene integrado desde hace años). Si estás en la nube, mira primero si tu proveedor te lo da hecho.

Requisito previo importante: el VPA necesita metrics-server (el mismo de 07-02) para el updater y el admission-controller, y su recomendador puede leer además de Prometheus si lo configuras. En minikube:

Y los CRDs registrados:

El segundo CRD, VerticalPodAutoscalerCheckpoint, merece una nota: ahí el recomendador persiste el histograma de consumo cada pocos minutos. Sin él, un reinicio del recomendador perdería todo el histórico acumulado y habría que volver a empezar el periodo de observación. Cuando alguien te diga «reinicié el VPA y ahora las recomendaciones son raras», el checkpoint es lo primero que hay que mirar.

Para desinstalar:

El VPA no es un proceso, son tres, con responsabilidades bien separadas. Entender esta separación explica casi todo su comportamiento.

Es el cerebro. Su trabajo:

• Lee el consumo de CPU y memoria de todos los pods que coinciden con algún targetRef de un objeto VPA.
• Mantiene, por contenedor, un histograma con decaimiento exponencial: las muestras viejas pesan menos que las recientes. La semivida por defecto es de 24 horas, lo que significa que una muestra de hace un día vale la mitad que una de ahora.
• Calcula percentiles sobre ese histograma y escribe la recomendación en status.recommendation del objeto VPA.
• Persiste el histograma en un VerticalPodAutoscalerCheckpoint para sobrevivir a reinicios.

Los percentiles que usa por defecto:

La asimetría es deliberada y muy sensata. Quedarse corto de CPU produce lentitud; quedarse corto de memoria produce OOMKilled. Por eso la memoria se calcula con el pico y la CPU con un percentil alto pero no extremo. Un contenedor puede sobrevivir perfectamente a picos de CPU por encima de su requests (se los presta el nodo si hay); a un pico de memoria por encima de su limit, no.

Detalle adicional: el recomendador observa los eventos OOMKilled y, cuando detecta uno, sube la recomendación de memoria de golpe (aproximadamente un 20 %) sin esperar a que el histograma se ajuste. Es una realimentación directa desde el fallo.

El recomendador funciona siempre, sea cual sea el updateMode. Incluso en modo Off está trabajando y publicando recomendaciones. Esto es precisamente lo que hace útil el modo asesor.

Es el brazo ejecutor. Cada minuto:

• Compara los recursos actuales de cada pod con la recomendación vigente.
• Si la diferencia supera un umbral (por defecto, si el valor actual está fuera del rango [lowerBound, upperBound]), decide que el pod hay que recrearlo.
• Desaloja el pod usando la API de desalojo (eviction), la misma que usa kubectl drain. Esto es fundamental: el actualizador respeta los PodDisruptionBudgets (09-05). Si tu PDB no permite el desalojo, el VPA espera pacientemente.
• No modifica el pod: lo mata. El Deployment lo recrea, y el nuevo pod pasa por el controlador de admisión.

Dos salvaguardas que evitan desastres:

• No desaloja un pod si no han pasado al menos 12 horas desde su creación (evita ciclos de recreación).
• Nunca desaloja todos los pods de un mismo controlador a la vez.

El actualizador solo actúa en los modos Recreate y Auto. En Off e Initial está inactivo.

Es un MutatingAdmissionWebhook registrado en la API. Cuando llega una petición de creación de pod:

• Comprueba si ese pod coincide con algún VPA activo.
• Si sí, reescribe los requests (y los limits, manteniendo la proporción) del pod antes de que se persista en etcd.
• El pod nace ya con los valores recomendados. El planificador lo coloca con esos números.

Este es el componente que hace que la recreación funcione. Sin él, el actualizador mataría un pod y el Deployment lo recrearía con los valores originales del manifiesto: un bucle infinito de desalojos inútiles.

Una consecuencia importante y a menudo sorprendente: el VPA no modifica el Deployment. Si haces kubectl get deployment api-reservas -o yaml seguirás viendo requests.cpu: 500m. Los pods reales tendrán otros valores. La mutación ocurre en el nivel del pod, en admisión. Para ver los valores efectivos:

Un riesgo derivado: si el webhook de admisión está caído o mal configurado, según su failurePolicy puede bloquear la creación de todos los pods del clúster o dejar que pasen sin mutar. El instalador oficial lo pone en Ignore por defecto, lo cual es lo seguro.

Nota sobre targetRef: a diferencia del HPA, no requiere que el objeto exponga el subrecurso /scale. Por eso el VPA sí puede aplicarse a un DaemonSet, mientras que el HPA no. Esto es útil de verdad: los agentes de Fluentd y de Falco que desplegamos en los módulos 7 y 8 son DaemonSets, y sus requests son igual de arbitrarios que los demás.

El updateMode es la decisión más importante del objeto.

El recomendador observa y publica en status.recommendation. Nada más. Ningún pod se toca, ningún manifiesto cambia. Es información pura.

Coste operativo: cero. Riesgo: cero. Valor: alto. Por eso es, con diferencia, el modo más usado en producción seria.

El controlador de admisión muta los pods cuando nacen por otra razón: un despliegue nuevo, un reinicio por caída de nodo, un escalado del HPA. El actualizador nunca desaloja nada.

Es un punto intermedio interesante: los valores se aplican de verdad, pero sin causar ni un solo reinicio adicional. La contrapartida es la lentitud: si api-reservas se despliega cada dos semanas, las recomendaciones tardan dos semanas en materializarse. Y crea un efecto desconcertante: dos pods del mismo Deployment, creados en momentos distintos, pueden tener recursos distintos.

El actualizador desaloja activamente los pods cuyos recursos se han desviado. Es autoescalado vertical de verdad, con la consecuencia inevitable: cada ajuste es un reinicio del pod.

Para worker-notificaciones es aceptable (procesa mensajes de una cola, un reinicio pierde como mucho el mensaje en vuelo, que la cola reentrega). Para postgres-reservas es otra historia, y lo discutimos en el apartado 12.

minReplicas: 2 es la protección esencial: el actualizador no desalojará si el controlador tiene menos réplicas que ese número. Con una sola réplica, un desalojo es una caída completa del servicio.

Semánticamente significa «usa el mejor mecanismo disponible». Hoy, en la práctica, Auto se comporta exactamente igual que Recreate en la mayoría de instalaciones. La intención declarada del proyecto es que, cuando el redimensionado en caliente sea estable, Auto lo use y deje de recrear pods.

Consejo operativo: usa Recreate explícitamente si eso es lo que quieres. Así, cuando el significado de Auto cambie con una actualización del VPA, tu comportamiento no cambiará por sorpresa.

Durante años, la limitación fundamental del escalado vertical en Kubernetes fue que los recursos de un contenedor eran inmutables: cambiarlos exigía recrear el pod.

Eso está cambiando. La funcionalidad se llama In-Place Pod Vertical Scaling (redimensionado vertical de pods en caliente), y permite modificar requests y limits de un contenedor en ejecución sin recrear el pod, mediante el subrecurso /resize.

Cada contenedor puede declarar una política de reinicio por recurso:

Y el cambio se aplica con:

El estado del proceso queda reflejado en el pod:

Esta es la parte importante para tomar decisiones:

• La funcionalidad ha avanzado a beta en Kubernetes 1.33 y sigue madurando. En 1.30-1.32 es alpha y requiere activar la feature gate InPlacePodVerticalScaling en el servidor de API y en los kubelets.
• Reducir la memoria en caliente no está resuelto de forma general: bajar el limit de memoria por debajo de lo que el proceso ya tiene mapeado puede provocar un OOMKilled inmediato. Por eso la política habitual para memoria es RestartContainer.
• La integración del VPA con esta funcionalidad existe pero no está completa ni es el camino por defecto.
• En Kubernetes gestionado (10-06), la feature gate puede no estar disponible: no controlas el plano de control.

Advertencia explícita: no construyas la estrategia de capacidad de producción sobre el redimensionado en caliente todavía. Es la dirección correcta y en un par de versiones será la forma natural de hacer las cosas, pero hoy:

1. Puede no estar disponible en tu clúster.
2. Su comportamiento con memoria tiene aristas.
3. El VPA no la explota plenamente.

Conócela, pruébala en rutas-norte-dev, síguele la pista. En rutas-norte-pro, el flujo de trabajo del apartado 10.

Dejar que un recomendador escriba números sin barandillas es una mala idea. El resourcePolicy es donde pones el criterio humano.

Por qué cada barandilla:

minAllowed. El recomendador se basa en el consumo observado. Si un servicio pasa la noche sin tráfico, su p90 de CPU es casi cero, y sin minAllowed la recomendación bajaría a 15m. Cuando llega el tráfico de la mañana, el pod se ahoga arrancando. El minAllowed codifica «esto es lo mínimo para arrancar y responder decentemente, aunque las métricas digan otra cosa».

maxAllowed. Dos motivos. Primero, planificación: un pod de 8 núcleos solo cabe en nodos grandes, y si tus nodos son de 4 núcleos ese pod se queda Pending para siempre. Segundo, detección de anomalías: si la recomendación llega al techo, hay algo que investigar (una fuga de memoria, una consulta patológica). El maxAllowed convierte un problema silencioso en una señal.

Regla práctica para el maxAllowed: nunca por encima de lo que cabe en un nodo real, con margen para el sistema. En nodos de 4 núcleos y 16 GiB, un maxAllowed razonable ronda 3 núcleos y 12Gi.

mode: "Off" a nivel de contenedor lo saca del VPA por completo: no se recomienda ni se muta. Cuándo hacerlo:

• Sidecars con recursos ya bien conocidos y estables. Un exportador de Prometheus consume 5m y 20Mi hoy, mañana y siempre. No necesita un recomendador.
• Sidecars de malla de servicio (el proxy de Istio, 08-04). Suelen tener su propia gestión de recursos y el VPA se pisa con ella.
• Contenedores con requests deliberadamente altos por razones que las métricas no ven: reservar CPU para picos de latencia crítica, por ejemplo.

Ojo con un detalle: si excluyes todos los contenedores del pod, el VPA no hará nada, lo cual es correcto, pero el objeto sigue existiendo y confunde. Bórralo mejor.

controlledResources es la pieza clave para convivir con el HPA: si el HPA escala por CPU, el VPA debe limitarse a la memoria (apartado 11).

controlledValues decide si el VPA toca también los limits:

El detalle de la proporción merece un ejemplo. Si el manifiesto tiene requests.cpu: 500m y limits.cpu: 1000m (proporción 1:2) y el VPA recomienda requests.cpu: 800m, con RequestsAndLimits pondrá limits.cpu: 1600m para mantener el 1:2. Es un comportamiento sensato pero que sorprende: el VPA puede subirte los limits por encima de lo que esperabas, y eso interactúa con la ResourceQuota del namespace (apartado 13).

Aquí está el valor real del VPA en modo Off. Veamos una recomendación completa.

Los límites lowerBound y upperBound no son percentiles del consumo: son el intervalo de confianza del recomendador. Cuanto menos histórico tenga, más ancho será. Un VPA con dos horas de datos dará un upperBound enorme; con dos semanas, un intervalo estrecho. La anchura del intervalo es un indicador directo de cuánto puedes fiarte de la recomendación.

Y son también el criterio de actuación del actualizador: en modos Recreate/Auto, el pod se desaloja cuando su valor actual sale del rango [lowerBound, upperBound]. Dentro del rango, se deja en paz. Esta banda es el equivalente vertical de la banda de tolerancia del HPA.

Contrastemos con lo que tenemos en el manifiesto:

La fila crítica es la memoria de api: 512Mi está por debajo del lowerBound de 573Mi. El VPA está diciendo, con datos de dos semanas, que ese contenedor tiene menos memoria reservada de la que necesita para funcionar con seguridad. Es exactamente el riesgo que intuíamos en el apartado 1, ahora cuantificado.

Y el exportador confirma la otra intuición: 20m reservados para algo que necesita 6m. Con 30 réplicas de api-reservas en el pico, son 420m de CPU reservados y nunca usados: casi medio núcleo bloqueado para el planificador.

Supongamos que ponemos maxAllowed.memory: 512Mi en el resourcePolicy. La recomendación quedaría:

Cuando target y uncappedTarget difieren, tu maxAllowed (o minAllowed) está mordiendo. Y aquí hay que pensar dos veces, porque hay dos interpretaciones opuestas y ambas son plausibles:

1. La barandilla está mal puesta. Fue un número conservador de hace meses y la aplicación ha crecido legítimamente. Súbela.
2. La barandilla está haciendo su trabajo. Hay una fuga de memoria y el consumo crece sin parar. El maxAllowed es lo único que impide que ese pod se coma un nodo entero.

Distinguir entre las dos requiere mirar la tendencia en Grafana (07-04): si la memoria crece de forma monótona y nunca baja, es fuga; si se estabiliza en una meseta más alta, es crecimiento legítimo. Un uncappedTarget que se aleja del target mes a mes es una fuga de memoria hasta que se demuestre lo contrario.

Para automatizar el flujo de trabajo:

Salida limpia, apta para meterla en un informe semanal o en un comentario automático de una pull request.

Aquí está la práctica que usan los equipos serios, y merece explicarse bien porque va a contracorriente de lo que sugiere el nombre «autoescalador».

La mayoría de organizaciones con Kubernetes en producción usan el VPA exclusivamente en modo Off. No como piloto automático, sino como asesor cuya recomendación revisa una persona antes de llegar a producción.

Paso 2, dos semanas y por qué. El histograma del recomendador tiene semivida de 24 horas, así que con dos o tres días ya hay señal. Pero dos semanas cubren dos ciclos semanales completos, incluidos fines de semana. En Rutas Norte esto importa mucho: el tráfico de sábado no se parece al de miércoles. Y si hay un cierre mensual o un evento periódico, hay que cubrirlo también.

Paso 6, el umbral del 20 %. Cambiar los recursos de un Deployment implica desplegarlo. No merece la pena hacerlo por un 5 %. El umbral del 20 % es una convención razonable: por debajo, el ruido supera a la señal.

Paso 7, la pull request. Aquí está el corazón del método. El cambio queda documentado:

Esa nota sobre el HPA es exactamente el tipo de razonamiento que se pierde cuando dejas que un controlador cambie los números por su cuenta.

Una práctica muy rentable: un VPA en modo Off sobre todos los Deployments, StatefulSets y DaemonSets de la plataforma, aunque nunca los apliques automáticamente. El coste es un objeto por controlador y algo de memoria en el recomendador. El beneficio es tener, en cualquier momento, la respuesta a «¿está bien dimensionado esto?».

Y un informe semanal comparando recomendación con manifiesto. Ese informe, revisado cada lunes en quince minutos, es probablemente la actividad de mayor retorno por minuto invertido en la operación de un clúster.

Esta es la trampa que hay que conocer sí o sí.

El VPA y el HPA no pueden gobernar el mismo recurso (CPU o memoria) sobre la misma carga de trabajo. Si lo intentas, se retroalimentan de forma destructiva.

Veamos por qué, con api-reservas y números concretos. Supongamos HPA por CPU con averageUtilization: 65 y VPA en modo Recreate controlando CPU.

El bucle es evidente: el HPA reduce el consumo por pod añadiendo réplicas; el VPA interpreta ese consumo menor como que los pods son grandes de más y baja el requests; al bajar el requests, el objetivo absoluto del HPA baja, y el HPA vuelve a escalar. La carga total no ha cambiado ni un vatio, pero hemos pasado de 4 réplicas de 500m a 10 réplicas de 263m, y el proceso continúa.

Cada iteración implica recrear pods (VPA) y crear/destruir pods (HPA). Es una espiral de inestabilidad que además hace muy difícil el diagnóstico, porque cada componente por separado parece estar comportándose bien.

La configuración recomendada para api-reservas, si quisieras VPA activo:

controlledResources: ["memory"] es la línea que hace que la convivencia sea posible. Sin ella, tienes el bucle.

La configuración más elegante aparece cuando el HPA escala por una métrica que no es CPU ni memoria: peticiones por segundo, longitud de una cola. Entonces:

• El HPA decide cuántos pods, según la demanda del negocio.
• El VPA decide de qué tamaño, según el consumo observado.
• No hay realimentación: la métrica de negocio no depende del requests.

Es exactamente lo que habilita KEDA en 09-04. Cuando worker-notificaciones escale por longitud de cola, un VPA completo sobre él será perfectamente seguro y muy útil.

Y esto conviene subrayarlo: el conflicto solo existe cuando el VPA actúa. En modo Off, el VPA no cambia nada, así que puede convivir con cualquier HPA sobre cualquier métrica sin el menor riesgo. Su recomendación de CPU será algo pesimista (medirá pods a los que el HPA ya ha aliviado la carga), pero seguirá siendo información válida.

Este es otro argumento a favor del modo Off: elimina toda una clase de problemas de un plumazo.

Decisiones concretas y justificadas para cada pieza de la plataforma.

Ambos tienen HPA por CPU desde 09-01. Ponemos VPA en modo Off, como asesores.

Con las mediciones del apartado 1, tienda-web es candidato claro a bajar de 200m a unos 70m de CPU. Con 15 réplicas en el pico, eso libera casi dos núcleos: menos nodos que arrancar (09-03) y menos factura.

Aquí sí lo activamos, y es el mejor candidato de la plataforma.

El caso más rentable de todos. Recordemos: pide 500m y necesita 1750m. Se estrangula, tarda cinco veces más de lo debido y algunas noches no termina.

Initial es la elección correcta para trabajos por lotes, y merece la pena entender por qué: un Job que se desaloja a los diez minutos de una ejecución de treinta pierde todo el trabajo y empieza de nuevo. Con Initial, cada ejecución nocturna nace con los recursos que el recomendador ha aprendido de las ejecuciones anteriores. El VPA aprende de la noche del lunes para la noche del martes.

Efecto esperado: de 40 minutos a unos 9. Y como se ejecuta a las 3 de la madrugada, con el clúster vacío, esos recursos extra no le quitan nada a nadie.

Aquí hay que pensar. Los datos:

• Es un StatefulSet con una sola réplica primaria.
• Tiene QoS Guaranteed (requests = limits), decisión deliberada del módulo 3 para que sea el último candidato al desalojo.
• Un reinicio implica cortar todas las conexiones, perder la caché de páginas de PostgreSQL y unos segundos de indisponibilidad total de la plataforma.
• Guarda datos personales de clientes: cualquier riesgo de corrupción es inaceptable.

Decisión: VPA en modo Off, con controlledValues: RequestsAndLimits.

El punto 4 del comentario merece énfasis, porque es el argumento de fondo: el dimensionado de una base de datos es una decisión de configuración, no de observación. Subir la memoria del contenedor sin ajustar shared_buffers en armonía con ella no mejora el rendimiento: solo desperdicia memoria. El VPA no sabe nada de postgresql.conf. Un operador de PostgreSQL (06-07) sí, y ese es el camino correcto para escalar una base de datos.

El VPA no vive solo. En el módulo 3 pusimos barandillas de namespace que interactúan con él de formas que conviene anticipar.

Recordemos el LimitRange de rutas-norte-pro:

Interacciones:

1. El max del LimitRange gana sobre el maxAllowed del VPA. Si el VPA recomienda 6 núcleos y el LimitRange topa en 4, el pod mutado será rechazado en admisión. El VPA es consciente de los LimitRange y ajusta su recomendación, pero si los cambias después de crear el VPA, puede haber un desfase.
2. El min puede elevar una recomendación baja. Si el VPA recomienda 20m y el LimitRange exige un mínimo de 50m, el pod acabará con 50m.
3. Los default desaparecen de la ecuación cuando el VPA muta el pod, porque el pod ya llega con valores explícitos.

Regla práctica: mantén el maxAllowed del VPA por debajo del max del LimitRange. Así el recorte se ve en uncappedTarget (información útil) en lugar de producir un rechazo en admisión (fallo confuso).

La ResourceQuota es más traicionera, porque el fallo aparece tarde y en otro sitio.

El problema surge de la interacción entre HPA y VPA sobre la cuota:

El fallo no aparece cuando se aplica el VPA: aparece semanas después, en el peor momento posible, y el mensaje de error está en los eventos del ReplicaSet, no en el HPA ni en el VPA. Es un fallo diferido y mal señalizado.

Comprobación obligatoria al aplicar cualquier recomendación del VPA:

El factor 0,8 deja margen para pods efímeros, trabajos y despliegues (que durante un rolling update consumen cuota de la versión vieja y la nueva a la vez).

Cálculo para Rutas Norte con la recomendación:

18,29 contra una cuota de 40, con margen del 80 % (32). Cabe con holgura. Y fíjate en que la recomendación del VPA reduce el consumo máximo respecto al escenario actual (que sería 15 + 3 + ... ≈ 21), porque tienda-web y el exportador estaban sobredimensionados. Ajustar bien los requests no solo ahorra dinero: da margen para escalar más.

Como vimos, el VPA mantiene la proporción requests:limits. Si tu proporción es 1:2 y el VPA sube el requests un 50 %, el limit sube también un 50 %. Y la ResourceQuota tiene una línea limits.cpu separada que también puede agotarse. Vigila las dos.

Terminamos con lo que el VPA no puede hacer. Conocer las limitaciones evita esperar de él lo que no da.

Un VPA recién creado no sabe nada. Sus primeras recomendaciones, en las primeras horas, son poco fiables: el upperBound será enorme y el target reflejará solo lo que ha visto. Regla: no tomes decisiones con menos de una semana de datos, y prefiere dos.

Corolario incómodo: para un servicio nuevo, el VPA no ayuda. Hay que estimar a mano, desplegar, y dejar que el VPA corrija después.

Con semivida de 24 horas, un cambio real de perfil tarda días en reflejarse plenamente. Esto es deliberado y correcto —no queremos que un pico de cinco minutos cambie los recursos de toda la plataforma—, pero significa que el VPA no sirve para responder a eventos:

• No sirve para el puente de mayo. Cuando el VPA se dé cuenta de que hace falta más CPU, el puente habrá terminado.
• No sirve para un despliegue que cambia radicalmente el perfil de consumo. Ahí hay que estimar a mano y dejar que el VPA valide después.

El VPA es para el régimen permanente, no para el transitorio. Los transitorios los cubre el HPA (09-01) y KEDA (09-04).

En modos Recreate y Auto, cada ajuste es un reinicio. El coste depende del componente:

El VPA respeta los PDB (09-05), lo cual mitiga el riesgo, pero no lo elimina: un PDB garantiza que no se caiga todo a la vez, no que el reinicio sea indoloro.

El VPA ve consumo de CPU y memoria. No ve:

• Que el puente de mayo empieza el viernes.
• Que ese pod atiende el proceso de pago y no puede reiniciarse durante una transacción.
• Que la memoria alta de anoche fue una ejecución de mantenimiento y no el régimen normal.
• Que shared_buffers de PostgreSQL debe cambiar en armonía con la memoria del contenedor.

Todo eso lo pone una persona. Y esa es, resumida en una frase, la justificación del modo Off.

• No gestiona recursos que no sean CPU y memoria. El almacenamiento efímero, las GPU y los recursos extendidos quedan fuera.
• Con updateMode activo, no debería usarse junto a un despliegue continuo agresivo: los desalojos del VPA y los rolling updates se solapan de forma poco predecible.
• Un solo VPA por carga de trabajo. Dos objetos VPA con targetRef al mismo Deployment producen comportamiento indefinido. Kubernetes no lo impide; tú sí debes.

Error 1: poner el VPA en modo Auto sobre CPU cuando ya hay un HPA por CPU. El error catastrófico de esta lección. El bucle de realimentación del apartado 11 tarda horas en manifestarse y es difícil de diagnosticar porque cada componente parece funcionar bien por separado. Si tienes HPA por CPU: controlledResources: ["memory"] o modo Off. Sin excepciones.

Error 2: aplicar la recomendación de un VPA de dos días. El upperBound desmesurado delata que hay poca historia. Espera dos semanas. Si tienes prisa, mira el lowerBound: si tu valor actual está por debajo, eso sí es una señal fiable incluso con pocos datos, porque significa que el contenedor ya se ha quedado corto en observaciones reales.

Error 3: no poner maxAllowed. Sin techo, una fuga de memoria hace que la recomendación crezca sin fin. En modo activo, acabarás con un pod pidiendo 30Gi que no cabe en ningún nodo y se queda Pending eternamente. El maxAllowed convierte esa fuga en una señal visible (uncappedTarget alejándose del target) en lugar de en una caída.

Error 4: creer que el VPA modifica el Deployment. No lo hace. El kubectl get deployment seguirá mostrando los valores del manifiesto. La mutación ocurre en el pod, en admisión. Para ver la realidad hay que mirar los pods, no el controlador. Esta confusión genera muchísimos tickets de «el VPA no funciona».

Error 5: VPA activo sobre una carga de una sola réplica. Un desalojo es una caída total. El minReplicas: 2 por defecto protege, pero si lo bajas a 1 «para que funcione», estás pidiendo cortes de servicio. Si tienes una sola réplica, o pones dos, o usas modo Off.

Error 6: olvidar la ResourceQuota. El apartado 13. Subir los requests sin recalcular requests × maxReplicas contra la cuota produce un fallo diferido que se manifiesta en el pico de tráfico, semanas después, con un mensaje de error en un sitio inesperado.

Consejo 1: empieza por los CronJobs. Son el caso más rentable y el de menor riesgo. Nadie espera una respuesta, el modo Initial es seguro, y el ahorro de tiempo de ejecución suele ser espectacular. informes-ocupacion pasando de 40 a 9 minutos es una victoria visible que compra credibilidad para el resto.

Consejo 2: exporta las recomendaciones a Prometheus. El VPA expone métricas, y kube-state-metrics publica kube_verticalpodautoscaler_status_recommendation_containerrecommendations_target. Con eso puedes construir en Grafana (07-04) un panel de «recomendado contra configurado» para toda la plataforma, y una alerta cuando la desviación supere el 30 %:

Consejo 3: un VPA en modo Off sobre absolutamente todo. Coste casi nulo, información permanente. Inclúyelo en la plantilla base de todo componente nuevo.

Consejo 4: usa el lowerBound como alerta de riesgo. Un contenedor cuyos requests están por debajo del lowerBound está en peligro real de desalojo o de OOMKilled. Es la señal más accionable que da el VPA, y merece una alerta.

Consejo 5: revisa el uncappedTarget mensualmente. Si crece mes a mes mientras el target se queda pegado al maxAllowed, tienes una fuga de memoria. El VPA la detecta antes de que se convierta en incidente.

Consejo 6: documenta en el manifiesto de dónde salen los números. Un comentario como # requests.memory: 800Mi -- recomendacion VPA 2026-05-11, p95 real 690Mi convierte un número mágico en una decisión trazable. El siguiente que lo lea sabrá si puede tocarlo.

Este es el describe del VPA de redis-cache tras tres semanas en modo Off:

El manifiesto actual dice:

Y el resourcePolicy del VPA:

Responde: (a) qué pasa con la CPU; (b) qué pasa con la memoria y por qué target y uncappedTarget difieren; (c) qué significa que upperBound sea exactamente 2048Mi; (d) qué QoS tiene el pod ahora y qué implica; (e) qué harías, con qué prioridad, y qué comprobarías antes.

tienda-web lleva tres días con un comportamiento extraño. El equipo reporta:

• El número de réplicas oscila entre 3 y 12 varias veces al día sin que el tráfico lo justifique.
• Los pods se reinician con frecuencia, con motivo Evicted.
• Los requests.cpu de los pods no coinciden con el manifiesto y cambian solos.

La configuración es:

Explica exactamente qué está pasando, con la secuencia temporal, y da dos soluciones alternativas con sus manifiestos y sus contrapartidas.

Rutas Norte añade exportador-contable, un componente que genera los ficheros de facturación para la gestoría. Perfil:

• Es un CronJob que se ejecuta el día 1 de cada mes a las 2:00.
• Cada ejecución tarda entre 20 y 90 minutos, según el volumen de reservas del mes.
• Consume mucha memoria: carga en memoria todas las reservas del mes para agregarlas.
• Si falla, hay que relanzarlo a mano y el equipo de administración se queda sin los ficheros ese día.
• Ha sido OOMKilled dos de los últimos cuatro meses.
• Actualmente: requests.memory: 1Gi, limits.memory: 2Gi, requests.cpu: 500m, limits.cpu: "1".
• El namespace tiene una ResourceQuota de 40 núcleos y 80Gi.

Diseña la estrategia completa: ¿VPA sí o no? ¿Qué modo? ¿Qué resourcePolicy? ¿Cuánto tiempo de observación necesitas y por qué es un caso especial? ¿Qué harías además del VPA? Escribe el manifiesto y justifica cada decisión.

Solución 1

(a) La CPU está sobredimensionada.

El manifiesto pide 500m; el upperBound es 390m. El valor actual está por encima del upperBound, lo que significa que el recomendador está seguro de que sobra CPU. El target es 245m: menos de la mitad de lo configurado. Como redis-cache es una sola réplica, el ahorro absoluto es modesto (255m), pero libera capacidad de planificación en un nodo.

(b) La memoria: target 1980Mi, uncappedTarget 3410Mi.

Esta es la observación crítica del ejercicio. El maxAllowed.memory es 2Gi = 2048Mi, y el uncappedTarget de 3410Mi está muy por encima. El recomendador quiere 3410Mi y las barandillas lo están recortando a 1980Mi.

Además, el requests actual (1Gi = 1024Mi) está por debajo del lowerBound (1420Mi). Doble señal de alarma: falta memoria reservada Y el recomendador quiere mucha más de la que le dejamos.

¿Fuga de memoria o crecimiento legítimo? En Redis hay una tercera posibilidad muy específica, y es la más probable: la caché ha crecido hasta llenar el espacio disponible. Redis, sin una política de expulsión configurada, sigue aceptando claves hasta agotar la memoria. El uncappedTarget creciente no indica un fallo del software: indica que maxmemory no está configurado en Redis y la caché crece sin control.

Comprobación:

Si maxmemory es 0, ese es el problema de fondo, y ningún ajuste de requests lo resuelve: solo retrasa el siguiente OOMKilled.

(c) upperBound exactamente 2048Mi.

No es casualidad: es el maxAllowed. Los límites de la recomendación también se recortan por las barandillas. Cuando ves un upperBound que coincide exactamente con tu maxAllowed, el recomendador te está diciendo que su intervalo de confianza está truncado, y que la recomendación real está fuera de lo que le permites.

(d) QoS del pod.

Como no todos los recursos tienen requests igual a limits, la QoS es Burstable, no Guaranteed (módulo 3).

Implicación seria: bajo presión de memoria en el nodo, un pod Burstable que consume por encima de su requests es candidato prioritario al desalojo. Y redis-cache está consumiendo 1980Mi con un requests de 1024Mi: casi el doble de lo reservado. Es de los primeros que caerán cuando el nodo se llene, y su caída descarga toda la carga sobre postgres-reservas justo cuando el nodo ya está bajo presión. Un efecto dominó de manual.

(e) Plan de acción, por prioridad.

Prioridad 1 (hoy): configurar maxmemory en Redis. Es la corrección de raíz.

Con esto, Redis deja de crecer sin control y empieza a comportarse como una caché de verdad. El uncappedTarget debería estabilizarse en las siguientes semanas.

Prioridad 2 (esta semana): subir el requests.memory a 2Gi e igualarlo al limit.

Esto consigue tres cosas: cubre el lowerBound, promueve el pod a QoS Guaranteed (deja de ser candidato prioritario al desalojo, coherente con su papel de amortiguador de PostgreSQL), y libera 200m de CPU.

Prioridad 3 (en un mes): revisar de nuevo. Con maxmemory puesto, comprobar que el uncappedTarget se ha estabilizado por debajo de 2Gi. Si sigue creciendo, hay algo más.

Comprobaciones antes de aplicar:

Ese último punto es el que se olvida siempre: cambiar los recursos de redis-cache implica reiniciarlo, y reiniciarlo vacía la caché. Durante los minutos siguientes, toda la carga de consultas de disponibilidad va directa a postgres-reservas. Hay que hacerlo un martes a las 4 de la mañana, no un viernes a las 10.

Solución 2

Qué está pasando: el bucle de realimentación HPA-VPA del apartado 11, en estado puro.

El HPA escala tienda-web por CPU. El VPA está en modo Auto sin controlledResources, lo que significa que controla CPU y memoria. Ambos gobiernan la CPU.

Secuencia temporal:

Los tres síntomas quedan explicados: la oscilación de réplicas (HPA reaccionando a objetivos móviles), los Evicted (el actualizador del VPA desalojando), y los requests que no coinciden con el manifiesto y cambian solos (el controlador de admisión mutando los pods).

Comandos que lo confirmarían:

Solución A (recomendada): VPA en modo Off.

Ventajas: elimina el conflicto por completo, sin reinicios sorpresa, el manifiesto sigue siendo la verdad, compatible con GitOps. Contrapartida: alguien tiene que aplicar la recomendación a mano.

Solución B: VPA activo solo sobre memoria.

Ventajas: la memoria se ajusta sola, sin intervención. Contrapartidas: sigue habiendo reinicios no planificados; el requests.cpu queda sin ajustar (habría que hacerlo a mano igual); durante el puente de mayo habría que pasar a Off para evitar reinicios en el peor momento.

Cuál elegir. Para tienda-web, la A. El ahorro de memoria de nginx es pequeño (hablamos de decenas de Mi por pod) y no compensa el riesgo de reinicios no planificados en la puerta de entrada de la plataforma. La solución B tendría sentido en una carga con consumo de memoria variable y grande, y que tolerase reinicios: worker-notificaciones es mejor candidato.

Acción inmediata mientras se decide:

Esto detiene la oscilación en el siguiente ciclo del actualizador, sin borrar nada.

Solución 3

¿VPA sí o no? Sí, rotundamente. Es un caso de libro: un trabajo por lotes con consumo variable que ya ha sido OOMKilled dos veces. El coste de un reinicio es cero (el Job es efímero) y el coste del fallo actual es alto (intervención manual, gestoría sin ficheros).

¿Qué modo? Initial. Igual que informes-ocupacion:

• Recreate no tiene sentido: desalojar un Job a los 40 minutos de una ejecución de 90 pierde todo el trabajo y empieza de cero. Sería peor que el OOMKilled.
• Off desaprovecha la ocasión: aquí sí queremos aplicación automática, porque el consumo varía cada mes con el volumen de reservas y nadie va a revisar la recomendación mensualmente.
• Initial aplica la recomendación en cada ejecución nueva. Perfecto.

El caso especial de la observación: la frecuencia mensual.

Este es el punto interesante del ejercicio. El histograma del recomendador tiene semivida de 24 horas. Una ejecución mensual significa que, cuando llega la siguiente, la muestra anterior tiene treinta semividas de antigüedad: su peso es 2⁻³⁰, es decir, cero.

El VPA, tal cual, es prácticamente inútil para un trabajo mensual. Cada ejecución empieza casi desde cero.

Tres formas de resolverlo, de menos a más recomendable:

1. Ajustar la semivida del recomendador. El vpa-recommender acepta --cpu-histogram-decay-half-life y --memory-histogram-decay-half-life. Subirlos a 720h (30 días) haría que la muestra del mes anterior pesara la mitad. Contrapartida: es un parámetro global del recomendador, afecta a todos los VPA del clúster y volvería lentísimas las recomendaciones de api-reservas. Solo viable con una segunda instancia del recomendador dedicada, lo cual es complejidad seria.

2. Ejecutar el trabajo con más frecuencia en pre. Programarlo semanalmente en rutas-norte-pre con datos representativos, dejar que el VPA aprenda ahí, y llevar la recomendación a producción a mano. Funciona, pero requiere datos de prueba realistas.

3. VPA en Initial + un minAllowed generoso + medición explícita. La opción pragmática y la que recomiendo.

Además del VPA, tres medidas que importan más:

Y el VPA:

Comprobación de la ResourceQuota:

Plan de seguimiento:

La lección de fondo del ejercicio: cuando la frecuencia de ejecución es mucho menor que la semivida del histograma, el VPA pierde casi toda su utilidad automática. En esos casos, la barandilla (minAllowed) importa más que la recomendación, y la medición manual de las primeras ejecuciones sigue siendo insustituible. El VPA no exime de pensar: acelera el pensar bien.

El VerticalPodAutoscaler no responde a la carga: responde a la ignorancia. Convierte los requests y limits de números que alguien copió de otro manifiesto en valores derivados del consumo real observado durante días.

Lo esencial:

• El VPA responde a «¿de qué tamaño?»; el HPA a «¿cuántos?». Ejes distintos, constantes de tiempo distintas: días frente a segundos.
• No está en el núcleo. Hay que instalarlo desde kubernetes/autoscaler, comprobar compatibilidad de versiones, y en la nube mirar primero si el proveedor lo ofrece.
• Tres componentes: el recomendador calcula (percentiles con decaimiento exponencial, p90 para CPU, pico para memoria), el actualizador desaloja respetando los PDB, y el controlador de admisión muta los pods al nacer. El Deployment nunca cambia.
• Off es el modo de los equipos serios. El manifiesto sigue siendo la verdad, no hay reinicios sorpresa, funciona con GitOps y cada cambio de recursos pasa por una revisión humana. Initial para trabajos por lotes; Recreate solo para cargas que toleran reinicios.
• target, lowerBound, upperBound, uncappedTarget. El target es lo que llevas al manifiesto; estar por debajo del lowerBound es una alarma; un uncappedTarget que se aleja del target mes a mes es una fuga de memoria hasta que se demuestre lo contrario.
• VPA y HPA sobre la misma métrica se destruyen mutuamente. El bucle es real y tarda horas en manifestarse. controlledResources: ["memory"] cuando el HPA escala por CPU, o modo Off. La combinación óptima es HPA por métrica de negocio (09-04) y VPA completo.
• El redimensionado en caliente llegará y cambiará las reglas, pero hoy no es base para una estrategia de producción.
• Cuidado con la ResourceQuota: requests recomendado × maxReplicas del HPA debe caber, o el fallo aparecerá en el pico de tráfico semanas después.

En Rutas Norte hemos dejado el VPA en modo Off sobre api-reservas, tienda-web, postgres-reservas y redis-cache, activo en Recreate sobre worker-notificaciones y en Initial sobre informes-ocupacion. Y hemos descubierto, con datos, que api-reservas tenía la memoria por debajo de su lowerBound y que tienda-web reservaba el triple de CPU de la que usa.

Con esto, cada pod pide lo que necesita y el número de pods se adapta al tráfico. Pero queda un supuesto oculto en todo lo que hemos hecho: hemos dado por sentado que, cuando el HPA pide treinta réplicas de api-reservas, hay sitio donde ponerlas. El clúster de Rutas Norte tiene cuatro nodos. Treinta pods de api-reservas más quince de tienda-web más los veinte de worker-notificaciones no caben. El planificador los dejará en Pending y el HPA no podrá hacer nada al respecto: habrá pedido las réplicas, el Deployment las habrá creado, y ahí se quedarán, en cola, mientras la venta del puente de mayo se cae exactamente igual que el año pasado.

En la próxima lección, Autoescalado de Clúster, subimos el último escalón: cómo hacer que el clúster añada nodos cuando los pods no caben, por qué retirarlos es mucho más delicado que añadirlos, cuánto tarda de verdad un nodo en estar listo (y por qué eso no salva una punta repentina), y el truco del sobreaprovisionamiento con pods de relleno que ya tenemos casi todas las piezas para entender.