Vertical Pod Autoscaler

El HPA responde a la pregunta "¿cuántas réplicas necesito?". El Vertical Pod Autoscaler responde a otra muy distinta, y probablemente más frecuente: "¿de qué tamaño debería ser cada réplica?".

Porque casi nadie sabe cuántos milicores necesita su aplicación. Se copia el resources del microservicio de al lado, se redondea hacia arriba por si acaso, y el clúster acaba lleno de Pods que reservan medio núcleo para consumir treinta milicores. Esos requests inflados no son gratis: el scheduler los cree, reserva el hueco, y acabas pagando nodos para alojar aire.

Dos avisos antes de empezar:

El VPA no viene con Kubernetes. Es un componente del proyecto autoscaler que hay que instalar aparte (la inicialización de esta lección ya lo ha hecho por ti, con Helm).
Esta lección usa el VPA en su modo más útil y menos peligroso: solo recomendación.

Trabaja desde la pestaña dev-machine. Confirma primero que el recomendador está en marcha:

kubectl get pods -n vpa

kubectl get crd verticalpodautoscalers.autoscaling.k8s.io

Paso 1: Un Deployment con los requests inflados

Crea holgazan.yaml: un nginx que no hace absolutamente nada y que pide medio núcleo y 512Mi.

cat << 'EOF' > holgazan.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: holgazan
  namespace: tienda
spec:
  replicas: 2
  selector:
    matchLabels:
      app: holgazan
  template:
    metadata:
      labels:
        app: holgazan
    spec:
      containers:
      - name: nginx
        image: ghcr.io/iximiuz/labs/nginx:alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: 1
            memory: 1Gi
EOF

kubectl apply -f holgazan.yaml
kubectl top pods -l app=holgazan

Compara las dos cifras: lo que pide (500m) y lo que consume (unos pocos milicores). Multiplica esa diferencia por doscientos Pods y ya tienes la factura de la nube de mucha gente.

Paso 2: El VPA en modo recomendación

Crea vpa.yaml:

cat << 'EOF' > vpa.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: holgazan-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: holgazan
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: nginx
      minAllowed:
        cpu: 10m
        memory: 32Mi
      maxAllowed:
        cpu: 1
        memory: 1Gi
EOF

El YAML, explicado con preguntas y respuestas

¿Por qué apiVersion: autoscaling.k8s.io/v1 y no autoscaling/v2 como el HPA?

Porque el VPA no forma parte de Kubernetes: sus recursos llegan como CRDs instalados por el proyecto autoscaler, y por eso viven en su propio grupo de API. Es el mismo mecanismo de extensión que viste con la Gateway API.

¿Qué hace targetRef?

Señala el objeto cuyos Pods se van a analizar. Igual que el scaleTargetRef del HPA, apunta al controlador (aquí un Deployment), no a los Pods.

¿Cuáles son los updateMode y cuál es el peligroso?

Cuatro, y conviene conocerlos antes de tocar producción:

Off: solo calcula y publica recomendaciones. No toca nada. Es el que usamos aquí, y es donde debe empezar todo el mundo.
Initial: aplica la recomendación solo a los Pods nuevos, cuando se crean por otro motivo. Prudente.
Recreate y Auto: matan los Pods para recrearlos con los recursos corregidos. Aquí está la letra pequeña histórica del VPA: como los resources de un Pod eran inmutables, la única forma de cambiarlos era destruir el Pod. Un autoescalador que reinicia tus Pods sin avisar es exactamente tan alarmante como suena, y por eso el VPA se ha usado mucho menos de lo que merecía.

¿Y eso sigue siendo así?

Está cambiando: Kubernetes ha ido incorporando el redimensionado en caliente de los recursos de un Pod, sin recrearlo, y ese es el futuro natural del VPA en modo automático. Mientras tanto, la regla práctica no ha cambiado: en producción, Off y aplicar las recomendaciones tú, en tu repositorio, revisándolas.

¿Para qué sirven minAllowed y maxAllowed?

Son las barandillas, como el minReplicas y maxReplicas del HPA. Impiden que una recomendación absurda (por una métrica enloquecida o un pico puntual) deje al Pod sin recursos o pidiendo el nodo entero.

Aplícalo y espera. El recomendador necesita recoger unas cuantas muestras de metrics-server, así que dale unos minutos:

kubectl apply -f vpa.yaml

kubectl get vpa holgazan-vpa

kubectl describe vpa holgazan-vpa

Paso 3: Leer el veredicto

Cuando aparezca la sección Recommendation del describe, léela con calma, porque tiene cuatro cifras y cada una responde a una pregunta distinta:

kubectl describe vpa holgazan-vpa

target: lo que el VPA pondría como request ahora mismo. Es la cifra que te llevas al YAML.
lowerBound: por debajo de esto, el Pod se quedaría corto. Si tu request actual está por debajo, tienes un problema hoy.
upperBound: por encima de esto estás desperdiciando con seguridad. Compara los 500m que pediste con este número.
uncappedTarget: lo que recomendaría sin las barandillas de minAllowed y maxAllowed. Si difiere del target, tus límites están recortando la recomendación, y conviene saberlo.

Compara el target con tu 500m y tendrás, en un solo vistazo, la diferencia entre lo que creías que necesitabas y lo que necesitas.

El conflicto que tienes que conocer

Poner un HPA y un VPA sobre el mismo Deployment y la misma métrica es una mala idea. El HPA ve la CPU alta y añade réplicas; eso baja la CPU media por Pod; el VPA ve Pods que consumen poco y recorta sus requests; con requests más bajos, el mismo consumo se convierte en un porcentaje de utilización más alto; el HPA vuelve a escalar. Los dos se persiguen la cola.

Las combinaciones que sí funcionan: HPA sobre CPU y VPA solo en modo Off (recomendando, mientras tú decides), o HPA sobre una métrica personalizada (peticiones por segundo, longitud de cola) y VPA gobernando la CPU y la memoria. Cada uno mirando una señal distinta.

Resumen

El VPA corrige el tamaño del Pod; el HPA, el número de Pods.
No viene de serie: se instala como CRDs más un recomendador.
updateMode: Off es donde se empieza y donde se queda casi todo el mundo: el VPA como asesor, no como cirujano.
Cuatro cifras en la recomendación: target (la que copias), lowerBound, upperBound y uncappedTarget.
Nunca HPA y VPA sobre la misma métrica del mismo Deployment.

Course progress