Como o Horizontal Pod Autoscaler funciona, e como ele se relaciona com o Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

O **Horizontal Pod Autoscaler (HPA)** adiciona ou remove **replicas de Pod** com base em métricas observadas (CPU, memory ou customizadas). O **Cluster Autoscaler (CA)** adiciona ou remove **nodes** quando Pods não conseguem ser agendados ou nodes estão subutilizados. Eles operam em camadas diferentes e trabalham juntos.

## Dois autoscalers, duas camadas

```text
HPA  → escala PODS  (mais/menos replicas de um Deployment)    — reage à CARGA
CA   → escala NODES (aumenta/reduz as máquinas do cluster)    — reage a Pods PENDING
VPA  → (bônus) ajusta os requests/limits de um Pod            — reage ao right-sizing

Fluxo típico: carga sobe → HPA adiciona Pods → Pods não cabem → CA adiciona um node →
              Pods são agendados. Carga cai → HPA remove Pods → node ocioso → CA o remove.
```

## Como funciona o control loop do HPA

```text
A cada ~15s o controller do HPA:
  1. lê a métrica atual (ex.: CPU médio entre os Pods) do metrics-server / API customizada
  2. calcula:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. escala o Deployment em direção a isso (limitado por minReplicas/maxReplicas)
Exemplo: 4 Pods a 80% de CPU, alvo 50% → 4 * 80/50 = 6.4 → 7 replicas.
Stabilization windows amortecem oscilações (especialmente no scale-down).
```

## Um 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      # mantém o CPU médio ~60% do REQUEST
  behavior:                           # opcional: ajusta a velocidade de scale up/down
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # métrica atual/alvo, contagem de replicas
kubectl top pods                      # requer metrics-server
```

## Dependências & ressalvas importantes

```text
• HPA por CPU/memory REQUER o metrics-server instalado; a utilização é relativa aos REQUESTS
  → se os requests não estão definidos/estão errados, a conta do HPA não faz sentido. Defina os requests corretamente.
• Métricas customizadas/externas (RPS, tamanho de fila) precisam de um adapter (Prometheus Adapter, KEDA).
• HPA e `replicas` manual conflitam — deixe o HPA ser dono da contagem de replicas.
• O Cluster Autoscaler também precisa de requests corretos: ele olha os REQUESTS dos Pods Pending para
  decidir o scaling de nodes. O scale-up de node leva minutos (provisionamento), então mantenha folga.
```

## Por que isso importa

Autoscaling é o que permite ao Kubernetes ajustar automaticamente a capacidade à demanda, e entender as duas camadas é conhecimento de nível sênior que separa clusters eficientes em custo e resilientes daqueles super ou subprovisionados. O modelo mental-chave é que o **HPA escala Pods** em resposta à carga (ajustando a contagem de replicas a partir de CPU, memory ou métricas customizadas observadas) enquanto o **Cluster Autoscaler escala nodes** em resposta à pressão de scheduling (adicionando máquinas quando Pods estão Pending, removendo-as quando nodes estão ociosos) — eles operam em camadas diferentes e cooperam: o HPA só pode adicionar Pods se houver espaço, e o CA fornece esse espaço. Entender o control loop do HPA — a fórmula `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, a reconciliação periódica e as stabilization windows que evitam oscilações — permite configurá-lo e debugá-lo em vez de tratá-lo como mágica. As ressalvas são onde o julgamento sênior aparece: HPA por CPU/memory **requer o metrics-server** e calcula a utilização **relativa aos requests**, então requests incorretos ou ausentes tornam sua conta sem sentido; métricas customizadas (requisições por segundo, tamanho de fila) precisam de um adapter como Prometheus Adapter ou KEDA; e o scale-up de node leva minutos, então a folga importa. Como dimensionar a capacidade corretamente afeta diretamente a confiabilidade sob picos de tráfego e o gasto de cloud em períodos calmos, e como ambos os autoscalers dependem de resource requests definidos corretamente, dominar o HPA e o Cluster Autoscaler é fundamental para operar Kubernetes em produção de forma eficiente e confiável.

Dois autoscalers, duas camadas

Como funciona o control loop do HPA

Um manifest de HPA

Dependências & ressalvas importantes

Por que isso importa

Perguntas relacionadas