Quando devo usar o Horizontal Pod Autoscaling (HPA) no Kubernetes?

Resposta curta: Use HPA quando a sua carga de trabalho pode executar múltiplas réplicas idênticas e a procura oscilar — escala em CPU/memória, métricas de aplicação (RPS/latência) ou métricas externas de fila/backlog. Não use HPA para serviços com estado de réplica única ou quando o verdadeiro gargalo for a capacidade dos nós ou limites a jusante (ligações à base de dados, limites de taxa de terceiros).

TL;DR:

• Utilize o HPA para cargas de trabalho que podem ser particionadas horizontalmente, em que as métricas por pod ou externas refletem a carga.
• Utilize métricas de recursos/personalizadas/externas (CPU, RPS, profundidade da fila); combine com o Cluster Autoscaler para gerir a capacidade dos nós.
• Utilize o KEDA para escalonamento até zero acionado por eventos ou dimensionadores externos; utilize o VPA em modo de recomendação para dimensionamento de pedidos de recursos.

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

• A carga de trabalho é sem estado ou particionável em várias réplicas? (Sim → candidato da HPA)
• É possível monitorizar a carga como métrica por pod ou métrica externa (CPU, pedidos por segundo, profundidade da fila)? (Sim → adequado para HPA)
• O cluster pode agendar mais pods (Cluster Autoscaler ou capacidade extra)? (Sim → continuar; se não, ativar o dimensionamento automático dos nós)
• Os serviços downstream (pools de bases de dados, APIs de terceiros) limitam a concorrência? (Sim, → adicionar throttling/pool de ligações ou preferir escalonamento vertical)

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

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

• Componentes: o controlador HPA (plano de controlo) + fornecedores de métricas (servidor de métricas para métricas de recursos, API de métricas personalizadas/externas via adaptadores ou KEDA).
• Ciclo de controlo (alto nível): o controlador HPA consulta a API de métricas → calcula o valor desiredReplicas a partir de cada métrica configurada → seleciona o maior valor de desiredReplicas calculado → aplica os valores mínimo/máximo e o comportamento (políticas/estabilização) → atualiza spec.replicas no recurso de destino → repete. Consulte a documentação HPA do Kubernetes para mais detalhes.
• Fórmula (como são calculadas as réplicas pretendidas): réplicas pretendidas = teto(total_atual / alvo_por_pod). O controlador calcula uma réplica desejada para cada métrica configurada, depois usa o maior valor antes de aplicar min/max e comportamento (este comportamento de precedência métrica está documentado na documentação HPA).
• Campos importantes de autoscaling/v2: minReplicas, maxReplicas, métricas (Resource, Pods, Object, External), o comportamento (as políticas scaleUp/scaleDown e stabilizationWindowSeconds).
• Utilize o comportamento para limitar a taxa de variação e evitar oscilações; stabilizationWindowSeconds é um parâmetro fundamental para suavizar o scaleDown.

Exemplo de excerto de código 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 recursos)
   • Use HPA quando a utilização de CPU ou memória por pod estiver correlacionada com as necessidades de capacidade e os pods definem pedidos de recursos corretos. Típico de APIs web e microserviços sem estado.
   • Ponto de partida prático: atingir a utilização média da CPU na faixa dos 60–80% e ajustar por testes de carga. O HPA calcula a utilização a partir dos pedidos dos pods, pelo que estes têm de estar definidos.
2. Métricas personalizadas dentro do cluster (Prometheus / métricas personalizadas)
   • Use o HPA quando os sinais ao nível da aplicação (pedidos/seg, latência, consumidores da fila/pod) representam melhor a carga do que a CPU.
   • Expor métricas com Prometheus + prometheus-adapter (custom.metrics.k8s.io) ou outro provedor de métricas personalizadas e usar essas métricas como alvo no HPA.
3. Métricas externas (filas, pendentes na nuvem)
   • Use HPA (via API de métricas externas) ou KEDA quando a escalabilidade deve reagir a sinais externos como o comprimento da fila (RabbitMQ, Azure Service Bus), Event Hubs ou métricas de monitorização cloud.
   • Se precisar de escalar até zero ou comportamento orientado por eventos rigoroso, prefira o KEDA — integra escaladores externos de forma nativa e suporta escala-a-zero (KEDA docs).

Quando NÃO usar HPA

• Serviços com estado de uma única réplica (bases de dados, estado exclusivo dentro do pod): o HPA não é apropriado, a menos que seja possível fragmentar/particionar de forma segura.
• Quando o gargalo está ao nível do nó (GPU, E/S do disco, CPU do nó) em vez de ao nível de cada pod: prefira o dimensionamento automático do grupo de nós ou o escalonamento vertical.
• Quando os sistemas a jusante (pools de ligações à base de dados, caches, APIs de terceiros) têm limites estritos de concorrência, escalar os pods sem aumentar a capacidade desses sistemas a jusante pode agravar as falhas — veja "Considerações operacionais e sobre sistemas a jusante" abaixo.
• Se precisar de escala até zero, o HPA simples não consegue alcançar isso; Use KEDA ou um controlador externo.

Múltiplas métricas, precedência e um exemplo

• Se configurar múltiplas métricas, o controlador HPA calcula um valor de Réplicas desejadas para cada métrica de forma independente e depois seleciona as maiores Réplicas desejadas como base para a escalabilidade. Depois disso, aplicam-se minReplicas/maxReplicas e políticas de comportamento (fonte: Kubernetes HPA docs).
• Exemplo: o alvo da CPU calcula 5 réplicas, o alvo de pedidos/seg calcula 12 réplicas → o HPA escolhe 12 (depois as políticas min/max e de comportamento podem modificar a alteração final aplicada).
• Para evitar um excesso súbito, combine uma política de scaleUp baseada em percentagens e uma scaleDown stabilizationWindowSeconds razoável (ver excerto de comportamento acima).

HPA vs VPA vs Cluster Autoscaler vs KEDA (orientação curta)

• HPA: escalona horizontalmente as réplicas com base em métricas. O melhor para cargas de trabalho particionáveis.
• VPA: ajusta solicitações/limites de recursos do pod (vertical). Ideal para cargas de trabalho não paralelizáveis ou para definir padrões sensatos.
• Escalador automático de cluster (ou Karpenter): dimensiona os nós para dar resposta a pedidos de agendamento (capacidade ao nível do nó). Use quando os pods permanecem pendentes devido à falta de nós.
• KEDA: autoescalador orientado a eventos que integra gatilhos externos e suporta escalabilidade até zero para cargas de trabalho de eventos.

Padrão comum: usar VPA em modo de recomendação para definir pedidos de referência, HPA para escalar réplicas e Cluster Autoscaler (ou Karpenter) para fornecer capacidade de nós. Utilize o KEDA quando precisar de redução para zero ou de integração direta com fontes externas de eventos.

Nota: as ofertas Kubernetes geridas (AKS/GKE/EKS) podem pré-instalar fornecedores de métricas ou fornecer funcionalidades de autoescalador integradas. Documentação do AKS Cluster Autoscaler

Considerações a jusante e operacionais (problemas comuns)

• Pools de ligações à base de dados: aumentar as réplicas aumenta as ligações simultâneas. Mitigue com pooling de ligações (por exemplo, PgBouncer), limitando a concorrência em cada pod ou aumentando o tamanho do pool da base de dados antes de aumentar o número de pods.
• Limites de taxa de API e quotas de terceiros: garantir que os sistemas a jusante conseguem gerir o volume de pedidos que os pods escalonados produzem; Considere a limitação do lado do cliente.
• PodDisruptionBudgets (PDBs): Os PDBs não impedem a expansão do HPA, mas podem afetar as operações de manutenção e o comportamento de drenagem; garantir que as políticas de escalabilidade estejam alinhadas com as PDBs.
• Efeitos de arranque e aquecimento: initContainers, aquecimento da memória cache ou tempos de arranque a frio longos podem distorcer métricas e causar oscilações — use sondas de prontidão e de arranque e janelas de estabilização.
• Abordagem operacional recomendada: definir taxas de escalonamento conservadoras, ajustar pedidos e limites e as sondas, testar em ambientes de não produção e adicionar limitação de débito orientada por SLO se os sistemas a jusante constituírem um estrangulamento.

Lista de verificação de configuração e passos seguros de implementação

Garantir métricas e RBAC:

• Implemente o servidor de métricas para métricas de recursos (ou use o fornecedor gerido).
• Implemente o Prometheus + adaptador prometheus para métricas personalizadas (custom.metrics.k8s.io) se necessário.
• Para dimensionadores externos ou de eventos, considere utilizar o KEDA.

Escreva HPA (autoscaling/v2) com:

• minReplicas e maxReplicas,
• métricas explícitas e comportamento (políticas de scaleUp/scaleDown),
• sondas de prontidão e de arranque nos pods,
• Pedidos de recursos sensatos para que as métricas de recursos sejam significativas.

Lista de verificação para testes seguros (como testar HPA de forma segura):

1. Teste num namespace/cluster não de produção com tamanhos de nós semelhantes e autoscaling ativado.
2. Comece com um número mínimo/máximo conservador de réplicas e políticas graduais de aumento de escala (por exemplo, um crescimento máximo de 100% por minuto).
3. Executar testes de carga graduais, monitorizar as réplicas desejadas versus as réplicas atuais e pods pendentes.
4. Ajuste os requests/limits, as sondas de prontidão e as políticas de comportamento antes de aumentar o nível de agressividade.

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

• O AKS e outras ofertas de cloud podem pré-instalar o metrics-server ou oferecer integração gerida com o autoescalador. Exemplo de CLI do AKS para ativar o autoescalador 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 ao dimensionamento automático de nós, centrada no aprovisionamento rápido; considere utilizá-lo quando for necessário o aprovisionamento rápido de nós.

Exemplos YAML funcionais

HPA baseado em CPU (autoscaling/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 ao Prometheus (via adaptador prometheus):

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 a documentação do prometheus-adapter para consultas de mapeamento

KEDA ScaledObject (Azure Service Bus) — suporta o 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 KEDA

Observabilidade, alertas e exemplos de SRE

Alertas sugeridos (exemplos copiáveis do Prometheus — ajuste os nomes das métricas para a sua configuração de exportação):

1. Alertar quando o HPA desejava > corrente durante > 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 para pods pendentes num 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 para dimensionamento frequente (oscilações frequentes)

   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 que mostram:

• HPA: currentReplicas, desiredReplicas, lastScaleTime, valores das métricas utilizados pelo HPA
• Estado do pod: pods pendentes, eventos de falha de agendamento, número de reinícios do pod
• A jusante: utilização da ligação à base de dados, taxas de erro, erro na API externa/taxas 429

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

• Liste HPAs: kubectl get hpa -n
• Descreva HPA (procure métricas atuais/atuais, desiredReplicas, lastScaleTime, eventos): kubectl describe hpa -n
• Campos a inspecionar descrevem a saída: currentReplicas, desiredReplicas, métricas (valores atuais/alvo), lastScaleTime, eventos (erros do fornecedor de métricas ou falhas de escalabilidade)
• Ver utilização de recursos (requer servidor de métricas): 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 registos de métricas dos fornecedores: kubectl logs -n kube-system deploy/metrics-server, kubectl logs -n deploy/prometheus-adapter
• Aplicar o manifesto HPA: kubectl apply -f hpa.yaml

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

• O HPA reporta que as réplicas desejadas. > Réplicas atuais e pods permanecem pendentes → provavelmente capacidade insuficiente dos nós; ativar o Cluster Autoscaler ou aumentar o pool de nós.
• O HPA mostra erros de métrica em eventos → verifica os registos RBAC/config do adaptador e do fornecedor de métricas.
• Escalar HPA demasiado rápido/lento → ajustar políticas de comportamento (limites percentuais/pods) e janelas de estabilização.

Predefinições e heurísticas de ajuste recomendadas

• Objetivo da CPU: começar por volta de 60% média de utilização (intervalo comum 60–80%) e ajustar por carga de trabalho.
• minRéplicas: pelo menos 1 para disponibilidade; usa KEDA se precisares de minReplicas: 0.
• maxReplicas: definido com base no planeamento de capacidade e custo; garantir que os limites do Cluster Autoscaler permitem adicionar nós até à capacidade necessária.
• stabilizationWindowSeconds: scaleDown ≈ 300s (5 min) é um ponto de partida comum para evitar reduções rápidas; ajuste consoante a carga de trabalho.
• Políticas de escalonamento: limitar os aumentos percentuais por período (por exemplo, permitir um crescimento máximo de 100% por minuto) para evitar sobrecarregar os sistemas subsequentes.
• Sondas de prontidão/inicialização: defina-as sempre para que os pods não recebam tráfego até estarem completamente prontos.

Nota: os padrões específicos de temporização dos controladores e o comportamento exato podem variar entre versões e distribuições do Kubernetes — consulte a documentação HPA para a versão do seu cluster

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

• Pedidos de recursos do pod em falta ou incorretos → os objetivos do HPA baseados nos recursos serão enganadores.
• Nenhum provedor de métricas (metrics-server/prometheus-adapter/KEDA) → o HPA não consegue ler métricas.
• O cluster não tem capacidade nos nós e Cluster Autoscaler não está ativado → os pods permanecerão em estado Pending.
• Combinar HPA e VPA: evite que ambos os controladores alterem ativamente as solicitações de recursos — configure o VPA para funcionar em modo de recomendação e deixe o HPA dimensionar o número de réplicas.
• Picos no arranque (initContainers, caches frias) sem sondas → ajustar as janelas de estabilização ou aquecer as instâncias manualmente.
• Má configuração do RBAC: garantir que os adaptadores de métricas e o controlador HPA têm as permissões necessárias para ler métricas.

FAQ rápida

P: Quais são os benefícios da HPA? A: Adaptar automaticamente o número de réplicas às alterações na carga, melhorar a utilização e reduzir os custos, e manter as metas de latência quando utilizada com as métricas certas e o dimensionamento automático dos nós.

P: Como é que o HPA calcula as réplicas desejadas? R: Lê métricas configuradas, calcula desiredReplicas = ceil(current_total / target_per_pod) para cada métrica, recolhe o maior valor calculado e depois aplica políticas de min/max e comportamento (fonte: HPA docs).

P: O HPA pode escalar até zero? R: Não — o HPA simples não pode escalar até zero. Utilize o KEDA para o comportamento de escalamento até zero (documentação do KEDA).

P: Como escalar com base no tamanho da fila ou no RPS? R: Expor o comprimento da fila/RPS como métrica externa ou personalizada (adaptador Prometheus ou API de métricas externas) ou use o KEDA para escalabilidade orientada a eventos.

Referências

• Conceito Kubernetes HPA
• Guia passo a passo/tarefas do Kubernetes HPA
• Servidor de Métricas
• Adaptador Prometheus (métricas personalizadas)
• KEDA (autoescalonamento orientado por eventos)
• Documentação do AKS Cluster Autoscaler