¿Cómo funciona el Horizontal Pod Autoscaler y cómo se relaciona con el Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

El **Horizontal Pod Autoscaler (HPA)** añade o quita **réplicas de Pod** según métricas observadas (CPU, memoria o personalizadas). El **Cluster Autoscaler (CA)** añade o quita **nodes** cuando los Pods no se pueden programar o los nodes están infrautilizados. Operan en capas distintas y trabajan juntos.

## Dos autoscalers, dos capas

```text
HPA  → escala PODS  (más/menos réplicas de un Deployment)     — reacciona a la CARGA
CA   → escala NODES (crece/encoge las máquinas del cluster)    — reacciona a Pods en PENDING
VPA  → (extra) ajusta los requests/limits de un Pod           — reacciona al dimensionado

Flujo típico: sube la carga → HPA añade Pods → los Pods no caben → CA añade un node →
              los Pods se programan. Baja la carga → HPA quita Pods → node ocioso → CA lo quita.
```

## Cómo funciona el control loop del HPA

```text
Cada ~15s el controller del HPA:
  1. lee la métrica actual (p. ej. CPU media entre los Pods) del metrics-server / API custom
  2. calcula:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. escala el Deployment hacia eso (acotado por minReplicas/maxReplicas)
Ejemplo: 4 Pods al 80% de CPU, objetivo 50% → 4 * 80/50 = 6.4 → 7 réplicas.
Las ventanas de estabilización amortiguan el flapping (sobre todo al escalar hacia abajo).
```

## Un manifest de HPA

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60      # mantener la CPU media ~60% del REQUEST
  behavior:                           # opcional: ajusta la velocidad de escalado arriba/abajo
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # métrica actual/objetivo, número de réplicas
kubectl top pods                      # requiere metrics-server
```

## Dependencias y advertencias importantes

```text
• El HPA por CPU/memoria REQUIERE metrics-server instalado; la utilización es relativa a los REQUESTS
  → si los requests están sin definir/mal, la aritmética del HPA no tiene sentido. Define los requests correctamente.
• Las métricas custom/externas (RPS, profundidad de cola) necesitan un adapter (Prometheus Adapter, KEDA).
• El HPA y un `replicas` manual entran en conflicto — deja que el HPA sea dueño del número de réplicas.
• El Cluster Autoscaler también necesita requests correctos: mira los REQUESTS de los Pods en Pending para
  decidir el escalado de nodes. Escalar nodes hacia arriba tarda minutos (aprovisionamiento), así que mantén holgura.
```

## Por qué es importante

El autoscaling es lo que permite a Kubernetes ajustar la capacidad a la demanda automáticamente, y entender las dos capas es conocimiento de nivel senior que separa clusters eficientes en coste y resilientes de los sobre o infra-aprovisionados. El modelo mental clave es que el **HPA escala Pods** en respuesta a la carga (ajustando el número de réplicas a partir de CPU, memoria o métricas custom observadas) mientras que el **Cluster Autoscaler escala nodes** en respuesta a la presión de scheduling (añadiendo máquinas cuando hay Pods en Pending, quitándolas cuando los nodes están ociosos); operan en capas distintas y cooperan: el HPA solo puede añadir Pods si hay sitio, y el CA proporciona ese sitio. Entender el control loop del HPA —la fórmula `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, la reconciliación periódica y las ventanas de estabilización que evitan el flapping— te permite configurarlo y depurarlo en vez de tratarlo como magia. Las advertencias son donde se ve el criterio senior: el HPA por CPU/memoria **requiere metrics-server** y calcula la utilización **relativa a los requests**, así que requests incorrectos o ausentes hacen que su aritmética no tenga sentido; las métricas custom (peticiones por segundo, profundidad de cola) necesitan un adapter como Prometheus Adapter o KEDA; y escalar nodes hacia arriba tarda minutos, por lo que la holgura importa. Como dimensionar bien la capacidad afecta directamente a la fiabilidad ante picos de tráfico y al gasto de cloud en periodos tranquilos, y como ambos autoscalers dependen de resource requests correctamente definidos, dominar el HPA y el Cluster Autoscaler es fundamental para operar Kubernetes en producción de forma eficiente y fiable.

Dos autoscalers, dos capas

Cómo funciona el control loop del HPA

Un manifest de HPA

Dependencias y advertencias importantes

Por qué es importante

Preguntas relacionadas