Quando devo usar o HPA (Dimensionamento Automático de Pod Horizontal) no Kubernetes?

Resposta curta: Use o HPA quando sua carga de trabalho puder executar várias réplicas idênticas e a demanda flutuar — escale com base em CPU/memória, métricas da aplicação (RPS/latência) ou métricas externas de fila/acúmulo. Não use HPA para serviços stateful com uma única réplica ou quando o verdadeiro gargalo estiver na capacidade do nó ou nos limites de sistemas downstream (conexões de banco de dados, limites de taxa de terceiros).

TL; DR:

• Use o HPA para cargas de trabalho particionáveis horizontalmente em que as métricas por pod ou externa refletem a carga.
• Use métricas de recurso/personalizadas/externas (CPU, RPS, profundidade da fila); combine-as com o Cluster Autoscaler para a capacidade dos nós.
• Use KEDA para escala até zero orientada por eventos ou scalers externos; use a VPA no modo de recomendação para dimensionamento das solicitações.

Lista de verificação de decisão rápida (Sim/Não):

• A carga de trabalho é sem estado ou particionável entre muitas réplicas? (Sim, → candidato ao HPA)
• Você pode observar a carga como uma métrica por pod ou uma métrica externa (CPU, solicitações por segundo, profundidade da fila)? (Sim → HPA é apropriado)
• O cluster consegue agendar mais pods (Cluster Autoscaler ou capacidade ociosa)? (Sim → prosseguir; se não, habilite o escalonamento automático de nós)
• Os serviços downstream (pools de BD, APIs de terceiros) limitam a simultaneidade? (Sim, → adicionar limitação/pool de conexões ou preferir o dimensionamento vertical)

Matriz de decisão (carga de trabalho → melhor métrica → dimensionador recomendado):

Como o HPA funciona (loop de controle simples e campos importantes)

• Componentes: o controlador HPA (plano de controle) + provedores de métricas (servidor de métricas para métricas de recurso, API de métricas personalizadas/externas por meio de adaptadores ou KEDA).
• Laço de controle (visão geral): o controlador HPA consulta a API de métricas → calcula o desiredReplicas a partir de cada métrica configurada → seleciona o maior valor de desiredReplicas calculado → aplica os valores mínimos/máximos e o comportamento (políticas/estabilização) → atualiza spec.replicas no recurso de destino → repete. Consulte os documentos do HPA do Kubernetes para obter detalhes.
• Fórmula (como as réplicas desejadas são calculadas): desiredReplicas = ceil(current_total/target_per_pod). O controlador calcula um desiredReplicas para cada métrica configurada e usa o maior valor antes de aplicar min/max e comportamento (esse comportamento de precedência de métrica está documentado nos documentos do HPA).
• Campos importantes de autoscaling/v2: minReplicas, maxReplicas, métricas (Resource, Pods, Object, External), comportamento (políticas de scaleUp/scaleDown e stabilizationWindowSeconds).
• Use o comportamento para limitar a taxa de variação e evitar oscilações; stabilizationWindowSeconds é um parâmetro fundamental para a suavização da redução de escala.

Trecho de exemplo de comportamento (autoscaling/v2)

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
      - type: Percent
        value: 100
        periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
      - type: Pods
        value: 1
        periodSeconds: 60

Quando usar HPA (por tipo de métrica/casos de uso comuns)

1. CPU/memória (Métricas de recurso)
   • Use o HPA quando a utilização da CPU ou da memória por pod se correlaciona com as necessidades de capacidade e os pods definem as solicitações de recurso corretas. Típico para APIs Web e microsserviços sem estado.
   • Ponto de partida prático: utilização média de CPU de destino no intervalo de 60 a 80% e ajuste por teste de carga. O HPA calcula a utilização com base nas solicitações de recursos dos pods, portanto, elas precisam estar definidas.
2. Métricas personalizadas do cluster (Prometheus / métricas personalizadas)
   • Use hpa quando sinais no nível do aplicativo (solicitações/s, latência, consumidores/pod de fila) representam melhor a carga do que a CPU.
   • Exponha métricas com Prometheus + prometheus-adapter (custom.metrics.k8s.io) ou outro provedor de métricas personalizadas e direcione essas métricas no HPA.
3. Métricas externas (filas, listas de pendências de nuvem)
   • Use hpa (via API de métricas externas) ou KEDA quando o dimensionamento deve reagir a sinais externos, como comprimento da fila (RabbitMQ, Barramento de Serviço do Azure), Hubs de Eventos ou métricas de monitoramento de nuvem.
   • Se você precisar de escala até zero ou de um comportamento estritamente orientado por eventos, prefira o KEDA — ele se integra nativamente a escaladores externos e oferece suporte à escala até zero (documentação do KEDA).

Quando NÃO usar HPA

• Serviços com estado de réplica única (bancos de dados, estado exclusivo no pod): O HPA não é apropriado, a menos que você possa fragmentar/particionar com segurança.
• Quando o gargalo estiver no nível do nó (GPU, E/S de disco, CPU do nó), em vez de no nível de cada pod, prefira o escalonamento automático do pool de nós ou o escalonamento vertical.
• Quando sistemas downstream (pools de conexão com o banco de dados, caches, APIs de terceiros) têm limites rígidos de concorrência: escalar os pods sem aumentar a capacidade desses sistemas downstream pode agravar as falhas — confira "Considerações downstream & operacionais" abaixo.
• Se você precisar de escalonamento para zero, o HPA simples não consegue fazer isso; use o KEDA ou um controlador externo.

Várias métricas, precedência e um exemplo

• Se você configurar várias métricas, o controlador HPA calculará um valor de desiredReplicas para cada métrica de forma independente e, em seguida, selecionará o maior valor de desiredReplicas como base para o escalonamento. Depois disso, minReplicas/maxReplicas e políticas de comportamento são aplicadas (origem: documentos do HPA do Kubernetes).
• Exemplo: a meta de CPU calcula 5 réplicas, a meta de solicitações/s calcula 12 réplicas → o HPA escolherá 12 (depois, as políticas de mínimo/máximo e de comportamento podem modificar a alteração final aplicada).
• Para evitar um superdimensionamento repentino, combine uma política de `scaleUp` baseada em porcentagem com um `stabilizationWindowSeconds` de `scaleDown` adequado (consulte o trecho de comportamento acima).

HPA vs VPA vs Cluster Autoscaler vs KEDA (guia rápido)

• HPA: dimensiona horizontalmente as réplicas com base nas métricas. Melhor para cargas de trabalho particionáveis.
• VPA: ajusta requisições/limites de recursos do pod (vertical). Melhor para cargas de trabalho não paralelizáveis ou para definir padrões sensatos.
• Cluster Autoscaler (ou Karpenter): escala os nós para atender às solicitações de agendamento (capacidade no nível de nó). Use isto quando os pods ficarem com o status Pendente devido à falta de nós.
• KEDA: escalador automático orientado a eventos que integra gatilhos externos e oferece suporte ao escalonamento até zero para cargas de trabalho orientadas por eventos.

Padrão comum: usar o VPA no modo de recomendação para definir requests básicas, o HPA para dimensionar réplicas e o Cluster Autoscaler (ou Karpenter) para fornecer capacidade nos nós. Use o KEDA quando precisar de integração de escala a zero ou direta com fontes de eventos externas.

Observação: as ofertas gerenciadas do Kubernetes (AKS/GKE/EKS) podem pré-instalar provedores de métricas ou fornecer recursos integrados de dimensionamento automático. Documentação do dimensionamento automático de cluster do AKS

Etapas posteriores & considerações operacionais (armadilhas comuns)

• Pools de conexão de banco de dados: aumentar as réplicas eleva o número de conexões simultâneas. Reduza com o pool de conexões (por exemplo, PgBouncer), limitando a simultaneidade por pod ou aumentando o tamanho do pool de banco de dados antes de dimensionar pods.
• Limites de taxa de API e cotas de terceiros: verifique se os sistemas downstream podem lidar com o volume de solicitação que os pods dimensionados produzem; considere a limitação do lado do cliente.
• PDBs (PodDisruptionBudgets): os PDBs não impedem o HPA de aumentar a escala, mas podem afetar operações de manutenção e o comportamento durante a drenagem; garanta que as políticas de escalonamento estejam alinhadas aos PDBs.
• Efeitos de inicialização e aquecimento: initContainers, pré-aquecimento de cache ou partidas a frio prolongadas podem distorcer as métricas e causar oscilação — use sondas de prontidão/inicialização e janelas de estabilização.
• Abordagem operacional recomendada: configurar taxas de dimensionamento conservadoras, ajustar requests/limits de recursos e sondas, testar em ambiente não produtivo e adicionar limitação de taxa com base em SLO se os sistemas downstream forem um gargalo.

Lista de verificação de configuração e etapas de distribuição seguras

Verifique as métricas e o RBAC:

• Implantar o servidor de métricas para métricas de recurso (ou usar o provedor gerenciado).
• Implante o Prometheus + prometheus-adapter para métricas personalizadas (custom.metrics.k8s.io), se necessário.
• Para dimensionadores externos/de eventos, considere KEDA.

Escreva HPA (escalonamento automático/v2) com:

• minReplicas e maxReplicas,
• métricas e comportamentos explícitos (políticas de scaleUp/scaleDown),
• sondas de prontidão e de inicialização nos pods,
• solicitações de recursos sensatas para que as métricas de recurso sejam significativas.

Lista de verificação de teste seguro (como testar o HPA com segurança):

1. Teste em um namespace/cluster não produtivo com tamanhos de nós semelhantes e escalonamento automático habilitado.
2. Comece com um número mínimo e máximo conservador de réplicas e políticas graduais de aumento de escala (por exemplo, crescimento máximo de 100% por minuto).
3. Realize testes de carga graduais, monitore desiredReplicas em relação a currentReplicas e os pods pendentes.
4. Iterar em solicitações/limites, investigações de preparação e políticas de comportamento antes de aumentar a agressividade.

Notas sobre o escalonamento automático do AKS e dos nós:

• O AKS e outras ofertas de nuvem podem pré-instalar o servidor de métricas ou oferecer integração de dimensionamento automático gerenciado. Exemplo de CLI do AKS para habilitar o dimensionador automático de cluster: az aks nodepool update --resource-group myRG --cluster-name myAKS --name node-pool1 --enable-cluster-autoscaler --min-count 1 --max-count 5

Nota sobre o Karpenter: o Karpenter é uma abordagem alternativa de escalonamento automático de nós com foco no provisionamento rápido; considere essa abordagem quando for necessário provisionar nós rapidamente.

Exemplos funcionais de YAML

HPA baseado em CPU (escalonamento automático/v2):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapi-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapi
  minReplicas: 3
  maxReplicas: 12
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 60

HPA usando uma métrica personalizada exposta pelo Prometheus (via prometheus-adapter):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-requests-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"

Consulte documentos do prometheus-adapter para consultas de mapeamento

KEDA ScaledObject (Barramento de Serviço do Azure) — oferece suporte ao escalonamento até zero:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sb-queue-scaledobject
  namespace: workers
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: event-worker
  minReplicaCount: 0
  maxReplicaCount: 20
  pollingInterval: 30
  cooldownPeriod: 300
  triggers:
    - type: azure-servicebus
      metadata:
        queueName: orders-queue
        queueLength: "50"
      authenticationRef:
        name: keda-azure-credentials

Documentação do KEDA

Observabilidade, alertas e exemplos de SRE

Alertas sugeridos (exemplos copiados do Prometheus – ajustar nomes de métricas à configuração de exportação):

1. Alerta quando o HPA desejado > atual para > 5m (problema de capacidade de agendamento)

   alert: HPAUnschedulable
   expr: (kube_hpa_status_desired_replicas - kube_hpa_status_current_replicas) > 0
   for: 5m
   labels:
     severity: page
   annotations:
     summary: "HPA desired replicas exceed current replicas for >5m (possible scheduling issue)"
   

2. Alerta sobre pods pendentes em um namespace

   alert: PodsPendingHigh
   expr: sum(kube_pod_status_phase{phase="Pending", namespace="production"}) > 3
   for: 2m
   labels:
     severity: ticket
   annotations:
     summary: "High number of Pending pods in production"
   

3. Alerta sobre escalonamento recorrente (flapping)

   alert: HPAFlapping
   expr: increase(kube_hpa_status_replicas_last_transition_count[10m]) > 5
   for: 0m
   labels:
     severity: warning
   annotations:
     summary: "Frequent HPA scaling events detected"
   

Painéis de instrumentos mostrando:

• HPA: currentReplicas, desiredReplicas, lastScaleTime, valores das métricas usados pelo HPA
• Saúde do pod: pods pendentes, eventos de falha no agendamento, contagens de reinicialização dos pods
• Downstream: uso de conexão de BD, taxas de erro, taxas de erro de API externa/429

Comandos operacionais & depuração (referência rápida)

• Listar HPAs: kubectl get hpa -n
• Descreva o HPA (procure métricas atuais, desiredReplicas, lastScaleTime, eventos): kubectl describe hpa -n
• Campos a serem inspecionados na descrição da saída: currentReplicas, desiredReplicas, metrics (valores atuais/de destino), lastScaleTime, eventos (erros do provedor de métricas ou falhas de dimensionamento)
• Exibir o uso de recursos (requer metrics-server): kubectl top pods -n
• Verificar pods pendentes e falhas de agendamento: kubectl get pods -n | grep Pending, kubectl describe pod -n (procure por FailedScheduling)
• Verificar os logs do provedor de métricas: kubectl logs -n kube-system deploy/metrics-server, kubectl logs -n deploy/prometheus-adapter
• Aplicar manifesto HPA: kubectl apply -f hpa.yaml

Dicas de solução de problemas rápidas:

• Os relatórios de HPA desiredReplicas > currentReplicas e pods permanecem pendentes → capacidade de nó provavelmente insuficiente; habilite o Dimensionador Automático de Cluster ou aumente o pool de nós.
• O HPA mostra erros de métricas em eventos → verifique o RBAC/a configuração do adaptador e os logs do provedor de métricas.
• Escalonamento do HPA muito rápido/lento → ajuste as políticas de comportamento (limites por percentual/por número de pods) e as janelas de estabilização.

Configurações padrão e heurísticas recomendadas de ajuste

• Meta de CPU: comece com cerca de 60% de utilização média (faixa comum de 60 a 80%) e ajuste de acordo com a carga de trabalho.
• minReplicas: pelo menos 1 para disponibilidade; use KEDA se você precisar de minReplicas: 0.
• maxReplicas: definido com base no planejamento de capacidade e no custo; verifique se os limites do Cluster Autoscaler permitem adicionar nós até a capacidade necessária.
• stabilizationWindowSeconds: scaleDown ≈ 300s (5 min) é um ponto de partida comum para evitar reduções rápidas de escala; ajuste conforme a carga de trabalho.
• políticas de dimensionamento: limitar os aumentos percentuais por período (por exemplo, permitir no máximo 100% de crescimento por minuto) para evitar sobrecarregar os sistemas posteriores.
• Sondas de prontidão/inicialização: sempre defina essas sondas para que os pods não recebam tráfego até estarem totalmente prontos.

Observação: padrões de tempo específicos do controlador e o comportamento exato podem variar entre versões e distribuições do Kubernetes – verifique os documentos do HPA para sua versão do cluster

Armadilhas comuns e lista de verificação antes de habilitar o HPA

• Solicitações de recursos do pod ausentes ou incorretas → metas do HPA com base em recursos serão enganosas.
• Nenhum provedor de métricas (metrics-server/prometheus-adapter/KEDA) → o HPA não consegue ler as métricas.
• O cluster não tem capacidade nos nós e o Cluster Autoscaler não está habilitado → os pods permanecerão no estado Pending.
• Combinando HPA & VPA: evite que ambos os controladores alterem ativamente as solicitações de recursos — execute o VPA no modo de recomendação e deixe que o HPA escale as réplicas.
• Picos na inicialização (initContainers, caches frios) sem sondas → ajustar as janelas de estabilização ou aquecer as instâncias manualmente.
• Configuração incorreta do RBAC: verifique se os adaptadores de métricas e o controlador HPA têm permissões necessárias para ler as métricas.

Perguntas frequentes rápidas

P: Quais são os benefícios do HPA? A: Adapte automaticamente a contagem de réplicas às mudanças na carga, melhore a utilização e os custos e mantenha as metas de latência quando usado com as métricas certas e o escalonamento automático de nós.

P: Como o HPA calcula as réplicas desejadas? R: Ele lê métricas configuradas, computa desiredReplicas = ceil(current_total/target_per_pod) para cada métrica, usa o maior valor computado e aplica políticas de mínimo/máximo e comportamento (origem: documentos HPA).

Q: O HPA pode escalar até zero? A: Não — um HPA simples não pode ser escalado até zero. Use o KEDA para comportamento de escalonamento até zero (documentação do KEDA).

P: Como escalar com base no tamanho da fila ou em RPS? R: Expor o comprimento da fila/RPS como uma métrica externa ou personalizada (API de métricas externas ou adaptador prometheus) ou usar KEDA para dimensionamento controlado por eventos.

References

• Conceito de HPA do Kubernetes
• Guia/tarefas do Kubernetes HPA
• Servidor de Métricas
• Adaptador prometheus (métricas personalizadas)
• KEDA (dimensionamento automático controlado por eventos)
• Documentação do dimensionador automático de cluster do AKS