HPA: escalando pods automaticamente no Kubernetes

O que é HPA e como funciona no Kubernetes

O controlador de reconciliação que mantém o número ideal de pods

O Horizontal Pod Autoscaler (HPA) é um controlador do Kubernetes que monitora métricas de pods e ajusta automaticamente o número de réplicas de um Deployment, ReplicaSet ou StatefulSet para manter a métrica próxima ao valor alvo configurado. O HPA opera no loop de reconciliação do Kubernetes: a cada 15 segundos (configurável via --horizontal-pod-autoscaler-sync-period), consulta as métricas atuais via a Metrics API, calcula o número desejado de réplicas usando a fórmula desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue)), e ajusta a contagem de réplicas se necessário. O HPA respeita sempre os limites definidos em minReplicas e maxReplicas — nunca desce abaixo do mínimo nem sobe acima do máximo, independente das métricas. Para funcionar, o HPA requer que o metrics-server esteja instalado no cluster, pois é ele que coleta métricas de CPU e memória dos pods.

Configurando HPA com CPU e memória

O ponto de partida mais simples para scaling automático

A configuração básica de HPA com CPU exige que os pods tenham resource requests definidos — sem requests, o Kubernetes não consegue calcular o percentual de utilização. Um HPA que mantém a utilização de CPU dos pods em 50% com entre 2 e 10 réplicas é declarado com apiVersion autoscaling/v2 com targetAverageUtilization de 50 para o recurso cpu. Quando a utilização média dos pods excede 50%, o HPA adiciona réplicas; quando cai abaixo de um threshold calculado com histerese, remove réplicas. Memória como métrica de HPA funciona mas tem nuances importantes: muitos runtimes (JVM, .NET CLR, Go) retêm memória alocada mesmo quando ociosos, sem devolver ao SO, o que pode fazer o HPA adicionar pods desnecessários. Para aplicações que usam memória de forma proporcional à carga real (cache em memória, buffers de streaming), memória é uma métrica adequada de HPA.

Custom Metrics — scaling por requisições por segundo, latência ou filas

Métricas de negócio que refletem a pressão real sobre a aplicação

Custom metrics permitem que o HPA tome decisões de scaling com base em métricas específicas da aplicação — não apenas CPU e memória de infraestrutura. Requisições por segundo por pod, profundidade de fila de processamento, latência p95, número de conexões ativas, ou qualquer métrica exposta via Prometheus podem ser usadas para scaling. O Custom Metrics API é uma interface padronizada que o HPA usa para consultar métricas — o Prometheus Adapter implementa essa interface mapeando queries PromQL para métricas disponíveis via a API do Kubernetes. Um HPA que escala baseado em requisições por segundo é mais responsivo que um baseado em CPU: enquanto a CPU pode demorar alguns segundos para subir após um pico de tráfego (especialmente em aplicações I/O-bound onde cada requisição não usa muito CPU), o contador de requisições sobe imediatamente com o tráfego.

metrics-server — pré-requisito para HPA funcionar

Instalação e verificação do componente que alimenta o HPA

O metrics-server coleta métricas de CPU e memória de todos os pods e nodes do cluster, e as disponibiliza via a Metrics API do Kubernetes. Sem metrics-server instalado, o HPA falha ao tentar obter métricas e permanece inativo. A instalação é simples em clusters managed (EKS, GKE, AKS instalam por padrão), mas em clusters self-managed requer o deploy do manifesto oficial do metrics-server e configuração adequada de TLS. O comando kubectl top pods mostra o consumo atual de CPU e memória dos pods — se funcionar, o metrics-server está operacional. O metrics-server armazena apenas os dados mais recentes (sem histórico), diferente do Prometheus que armazena series históricas. Para HPA com custom metrics, o Prometheus Adapter é instalado adicionalmente e registra um segundo provider de métricas personalizado na Metrics API do Kubernetes.

Prometheus Adapter para métricas customizadas no HPA

Conectando PromQL ao Horizontal Pod Autoscaler

O Prometheus Adapter é um componente que traduz queries PromQL em respostas da Custom Metrics API do Kubernetes, permitindo que o HPA use qualquer métrica armazenada no Prometheus para tomar decisões de scaling. A configuração define regras de mapeamento: qual query PromQL executar, como extrair o nome do recurso Kubernetes (pod name, namespace) dos labels da métrica, e qual nome a métrica terá na Custom Metrics API. Um exemplo prático: a query sum(rate(http_requests_total[2m])) by (pod) calcula a taxa de requisições por segundo por pod — exposta como http_requests_per_second na Custom Metrics API e usada pelo HPA para manter a taxa em 100 rps por pod. Métricas externas (External Metrics API) seguem o mesmo padrão mas permitem usar métricas sem associação a um pod específico — como o tamanho de uma fila SQS ou o consumer lag do Kafka.

Min e Max replicas — limites e proteções

Evitar tanto o scale-to-zero acidental quanto o crescimento descontrolado

minReplicas é o número mínimo de pods que o HPA mantém mesmo quando a métrica está abaixo do threshold de scale-in. Definir minReplicas como zero permite scale-to-zero — nenhum pod rodando quando não há carga — o que economiza recursos mas introduz cold start latency (o tempo de inicialização de um novo pod quando a primeira requisição chega). Para aplicações com cold start rápido (containers sem JVM), minReplicas igual a zero pode ser adequado; para aplicações com inicialização lenta ou que precisam de disponibilidade constante, mantenha pelo menos 2 réplicas para sobreviver a uma falha de pod. maxReplicas é a proteção contra crescimento descontrolado — seja por uma métrica mal configurada, um ataque DDoS ou um bug que gera carga infinita. Calcule maxReplicas com base na capacidade do cluster e nos limites de conexões do banco de dados para evitar exaurir recursos compartilhados.

HPA vs VPA — horizontal vs vertical pod autoscaler

Quando adicionar pods versus quando aumentar recursos de um pod

HPA (Horizontal Pod Autoscaler) adiciona ou remove pods para distribuir a carga — funciona bem para aplicações stateless que escalam horizontalmente. VPA (Vertical Pod Autoscaler) ajusta os resource requests e limits dos pods com base no uso real observado — útil para determinar o sizing correto de pods e evitar both over-provisioning (recursos alocados mas não usados) e under-provisioning (pods com recursos insuficientes que são OOMKilled). HPA e VPA não devem ser usados simultaneamente com a mesma métrica — quando ambos tentam ajustar CPU, podem entrar em conflito. Uma estratégia comum é usar VPA em modo "Off" apenas para recomendações de sizing, aplicando os valores recomendados manualmente à medida que a aplicação amadurece, e usar HPA para o scaling dinâmico em produção. KEDA complementa tanto HPA quanto VPA adicionando scaling baseado em eventos externos.

Comportamento de scaling — stabilizationWindow e rates

Controle fino sobre a velocidade e suavidade do scaling

A seção behavior do HPA (disponível a partir de autoscaling/v2beta2) permite configurar o comportamento de scale-up e scale-down independentemente. stabilizationWindow define a janela de tempo em que o HPA considera o máximo (para scale-down) ou mínimo (para scale-up) das métricas coletadas, evitando scaling baseado em picos momentâneos. Uma stabilizationWindow de 300 segundos para scale-down garante que o HPA aguarda 5 minutos de carga consistentemente baixa antes de remover pods — prevenindo thrashing. policies permite configurar a taxa máxima de scaling: aumentar no máximo 4 pods por minuto, ou no máximo 50% das réplicas atuais a cada 60 segundos. Essas configurações permitem scaling agressivo para cima (resposta rápida a picos) e conservador para baixo (prevenção de thrashing e cold starts desnecessários).

Testar HPA com carga real

Validar que o scaling acontece no momento certo e na direção certa

Testar HPA requer simular carga controlada e observar o comportamento do autoscaler em tempo real. kubectl run --rm -it load-generator --image=busybox permite enviar requisições HTTP continuamente de dentro do cluster. Ao mesmo tempo, watch kubectl get hpa mostra o estado do HPA — métricas atuais, número desejado de réplicas e réplicas atuais — atualizando a cada 2 segundos. Os pontos a verificar durante o teste: o lag entre o aumento de carga e o primeiro scale-up (deve ser menor que o cooldown configurado mais o tempo de inicialização do pod), se as métricas são calculadas corretamente (especialmente para custom metrics), se as novas réplicas ficam ready dentro do tempo esperado, e se o scale-down acontece adequadamente após a carga ser removida. Testes de HPA devem fazer parte do processo de CI/CD para garantir que mudanças de configuração não quebrem o scaling em produção.

Conclusão — HPA como mecanismo central de resiliência no Kubernetes

Scaling automático que une eficiência de custo e disponibilidade

O HPA é um dos recursos mais poderosos do Kubernetes por combinar eficiência de recursos (sem pods ociosos) com capacidade de resposta a picos (novos pods em segundos). Uma configuração de HPA bem calibrada — com métricas adequadas ao perfil da aplicação, limites de min e max réplicas realistas, e comportamento de scaling configurado para evitar thrashing — é um componente fundamental de qualquer deployment de produção no Kubernetes. Evolua do HPA básico com CPU para métricas customizadas do Prometheus à medida que você entende melhor o perfil de carga real da sua aplicação. Continue em: Fundamentos obrigatórios antes de produção.