Horizontal Pod Autoscaler em APIs com tráfego variável: erros que geram falhas, lentidão ou retrabalho

Planejamento de métricas, capacidade e validação para escalar APIs com tráfego variável e reduzir ajustes emergenciais.

Configurar o Horizontal Pod Autoscaler em APIs é apenas parte do trabalho de absorver picos. A aplicação pode continuar lenta se o sinal de escala não representar o gargalo, se as novas réplicas demorarem a ficar prontas ou se o banco já estiver saturado.

O diagnóstico fica mais objetivo quando acompanha o caminho completo: demanda recebida, decisão de escala, criação dos Pods, entrada no atendimento e comportamento das dependências. Os exemplos a seguir são ilustrativos e devem ser ajustados às medições da sua aplicação.

Por que o HPA pode estar ativo e a API continuar lenta?

O HPA ajusta a quantidade desejada de réplicas conforme as métricas configuradas. Essa decisão não garante capacidade imediata: ainda é necessário criar, agendar e preparar os Pods para atender.

Separe três números no painel: réplicas desejadas, Pods existentes e Pods prontos. Uma diferença persistente entre eles ajuda a localizar a etapa que está atrasando a expansão.

Imagine uma rajada começando no instante zero. A latência p95 sobe, o HPA recomenda expansão e os Pods entram em inicialização. Até ficarem prontos, as réplicas antigas continuam sustentando a carga. Marcar esses eventos na mesma linha do tempo revela quanto do atraso pertence a cada etapa.

Acompanhe p95 e p99, taxa de erros e vazão atendida junto ao tráfego recebido. A média de latência, isoladamente, pode esconder a degradação das requisições mais lentas.

Erro 1: configurar requests e limits sem medir a aplicação

Ao usar uma meta percentual de CPU, o HPA considera o consumo em relação aos requests relevantes. No exemplo simplificado de um único contêiner, consumir 200m com request de 250m representa 80% de utilização; com request de 1000m, representa 20%.

O trabalho executado é igual, mas o percentual muda. Portanto, alterar requests também altera a interpretação desse sinal pelo autoscaler. Requests ausentes nos contêineres relevantes podem impedir o cálculo da utilização correspondente.

No gerenciamento de recursos, requests participam do dimensionamento para agendamento. Limits restringem o consumo: em Linux, limites de CPU podem provocar throttling, enquanto pressão associada ao limite de memória pode resultar em encerramento por falta de memória.

Antes de ajustar a meta, correlacione latência com consumo, períodos de CPU limitada, reinicializações e registros de OOMKilled. Um contêiner que recebe pouca CPU para processar sua carga pode apresentar lentidão mesmo quando existem recursos livres em outro ponto do cluster.

Meça cada réplica com uma combinação representativa de rotas, tamanhos de resposta e concorrência. Procure a faixa em que ela mantém os objetivos de latência e erros, incluindo margem para variações e inicialização.

Para organizar a configuração completa, consulte o guia de implementação do Horizontal Pod Autoscaler em APIs e relacione o dimensionamento de recursos aos resultados dos testes.

Erro 2: escolher métricas que não representam o gargalo

CPU é um sinal útil quando o processamento limita a capacidade. Uma rota que transforma documentos pode consumir mais CPU à medida que o tráfego cresce. Nesse cenário, distribuir o processamento entre réplicas pode aliviar a pressão.

Já uma rota que passa grande parte do tempo aguardando um serviço externo pode acumular requisições com CPU moderada. Aumentar réplicas só ajuda se o limite estiver na concorrência local e a dependência puder receber mais trabalho.

Para avaliar métricas customizadas no HPA, responda a três perguntas:

• Qual é a unidade? Requisições por segundo, requisições em andamento ou itens aguardando processamento têm significados diferentes.
• Como ocorre a agregação? Um total do serviço não equivale à média por Pod.
• O sinal melhora com mais réplicas? Se a pressão continuar igual ou piorar, investigue a hipótese de escala.

Uma meta por réplica deve nascer da capacidade medida. Requisições por segundo também exigem cuidado: cem chamadas leves podem custar menos que poucas chamadas de uma rota pesada.

Use latência como indicador de resultado. Antes de adotá-la diretamente como sinal de controle, teste o que acontece quando ela aumenta por lentidão no banco. Criar mais clientes para uma dependência saturada pode ampliar o problema.

A escolha deve demonstrar uma relação verificável entre demanda, sinal observado e capacidade adicional. Copiar metas de outra API elimina justamente essa validação.

Erro 3: ignorar métricas ausentes e condições do HPA

Quando a investigação começa com “o HPA não escala”, confira primeiro se ele está recebendo a informação necessária. Métrica indisponível não significa utilização baixa.

Substitua os nomes abaixo pelos recursos do seu ambiente:

kubectl get hpa -n minha-api
kubectl describe hpa api -n minha-api
kubectl get hpa api -n minha-api -o yaml
kubectl top pods -n minha-api
kubectl get events -n minha-api --sort-by=.metadata.creationTimestamp

Confira o alvo de escala, as métricas atuais, as metas e as condições AbleToScale, ScalingActive e ScalingLimited. Leia os motivos e eventos associados antes de mudar a configuração.

Para métricas de recursos, investigue a API de métricas, normalmente atendida pelo Metrics Server. Para métricas customizadas ou externas, acompanhe também o adaptador e a origem dos dados. O comando kubectl top não valida esses caminhos adicionais.

Diante de FailedGetResourceMetric, leia a mensagem completa: confira requests e disponibilidade da coleta. Em outras métricas, revise nome, seletor, permissões e atualização das amostras.

Métricas ausentes podem limitar a reação do controlador. Com múltiplas métricas, uma falha pode impedir a redução mesmo quando outra sugere diminuir réplicas. Corrigir o caminho dos dados vem antes de flexibilizar as metas.

Erro 4: esperar que novas réplicas atendam imediatamente

Meça separadamente o tempo de agendamento, download da imagem, inicialização e aquecimento. Somados ao tempo de detecção e decisão, esses intervalos determinam quando a expansão começa a produzir capacidade útil.

As probes têm funções distintas:

• Startup: permite acompanhar uma inicialização demorada; enquanto não tem sucesso, mantém as verificações de liveness e readiness suspensas.
• Readiness: indica se o contêiner está pronto para atender, influenciando a participação do Pod no tráfego dos Services.
• Liveness: identifica uma condição que justifica reiniciar o contêiner, respeitando os parâmetros configurados.

Evite usar uma liveness agressiva para compensar uma inicialização que normalmente demora. Isso pode reiniciar a aplicação antes de ela terminar de subir.

Em um cenário ilustrativo, cada réplica leva 45 segundos para inicializar. Uma rajada mais curta pode terminar antes que a expansão ajude. Nesse caso, avalie capacidade de reserva em minReplicas, redução do tempo de preparação ou expansão antecipada para eventos previsíveis.

Estime a reserva pela carga que as réplicas prontas conseguem atender dentro do SLO durante esse intervalo. Uma readiness superficial, que aprova o Pod antes de ele conseguir servir requisições reais, apenas antecipa os erros.

Erro 5: ajustar a expansão e a redução sem considerar o tráfego

Expansão e redução atendem a necessidades diferentes. A primeira busca acompanhar a demanda; a segunda precisa equilibrar consumo e manutenção de capacidade para novas rajadas.

Em autoscaling/v2, behavior.scaleUp e behavior.scaleDown permitem configurar políticas de variação e estabilização. As políticas limitam mudanças no período considerado; a janela de estabilização considera recomendações anteriores.

Na redução, a janela usa a maior recomendação dentro do intervalo. Isso ajuda a evitar a remoção de capacidade após uma queda breve. Ela não deve ser interpretada como um temporizador fixo iniciado ao final de cada pico.

Compare duas configurações em teste: uma que reduz mais cedo e outra que mantém capacidade por mais tempo. Repita a mesma sequência de rajadas e observe p95, erros, recriação de Pods e consumo.

Se a segunda rajada chega enquanto a aplicação está reconstruindo a capacidade recém-removida, existe um custo operacional na redução antecipada. Por outro lado, manter réplicas além do necessário também tem custo. Escolha com base nessa comparação.

Confira os campos disponíveis no cluster com kubectl explain hpa.spec.behavior --api-version=autoscaling/v2. Registre a versão e os parâmetros usados para tornar o experimento reproduzível.

Erro 6: definir maxReplicas sem capacidade nos nós e nas dependências

maxReplicas expressa um limite de escala, mas não reserva infraestrutura. Ao encontrar Pods Pending, examine eventos de agendamento, recursos disponíveis, cotas, afinidades e restrições de posicionamento.

Se houver expansão automática dos nós, inclua seu tempo no planejamento. Reproduza o cenário em que a API precisa crescer e os nós atuais já estão ocupados. Testar somente com capacidade livre pode esconder esse atraso.

Depois, calcule o impacto nas dependências. Em um exemplo ilustrativo, 20 réplicas com pools de até 30 conexões podem demandar 600 conexões. Esse potencial depende do uso dos pools e ainda exclui outros serviços, tarefas e acessos administrativos.

Considere também as réplicas adicionais que podem coexistir durante um rollout. O teto usado no planejamento do banco precisa refletir a operação completa.

Avalie limites de concorrência, filas limitadas e backpressure, isto é, mecanismos para reduzir a entrada de trabalho quando o sistema está saturado. Defina como rejeitar excesso de carga de forma controlada e acompanhe esse resultado nos objetivos de disponibilidade.

Se mais Pods elevam conexões, timeouts e tentativas repetidas sem aumentar a vazão útil, interrompa a expansão da hipótese: o próximo ajuste deve tratar a dependência ou o controle de carga.

Erro 7: permitir que deploys e automações disputem as réplicas

Uma sincronização que reaplica spec.replicas: 3 pode reduzir a capacidade durante um pico. O HPA volta a ajustar a escala, mas a disputa gera instabilidade e dificulta entender as mudanças observadas.

Revise manifests, templates, pipelines e regras de sincronização. Defina qual controlador administra a escala do alvo e evite autoscalers concorrentes sobre o mesmo recurso.

Ao migrar o controle para o HPA, planeje a retirada ou o tratamento de spec.replicas conforme o mecanismo de aplicação e a propriedade do campo. A transição exige cuidado para não provocar uma redução inesperada.

Para investigar alterações, compare o objeto aplicado com o repositório, examine metadata.managedFields e, quando disponíveis, os registros de auditoria. Relacione os horários com execuções de pipelines e sincronizações.

Versione as mudanças e registre o critério de reversão. Verifique também se um rollback da aplicação reaplica uma contagem fixa de réplicas ou restaura parâmetros antigos de escala.

Como validar o HPA com testes de carga representativos

Um teste de carga Kubernetes precisa demonstrar que a API atende ao objetivo durante a transição. Chegar ao número esperado de Pods, isoladamente, não comprova recuperação.

Defina antes do experimento os SLOs de latência e disponibilidade, as rotas avaliadas, o limite de erros e o tempo aceitável de recuperação. Use critérios do serviço; números arbitrários podem aprovar uma configuração inadequada.

1. Carga base: observe a aplicação estabilizada e registre a capacidade inicial.
2. Subida gradual: identifique quando a latência começa a degradar e quando a escala reage.
3. Rajada: meça o intervalo entre o aumento de demanda e a entrada de capacidade útil.
4. Queda de demanda: acompanhe redução de réplicas, conexões e conclusão de requisições em andamento.
5. Segunda rajada: verifique se a redução anterior prejudicou a resposta ao novo pico.

Escolha durações suficientes para observar coleta, inicialização, estabilização e, quando necessário, expansão de nós. Os volumes devem partir da capacidade medida da API.

Registre carga oferecida, vazão atendida, p95, p99, erros, réplicas desejadas e prontas, CPU, memória, filas e dependências. Segmente por rota quando seus custos forem diferentes.

Confira também o gerador: se ele estiver saturado ou reduzir involuntariamente a emissão quando as respostas ficam lentas, a demanda aplicada pode ser menor que a planejada.

Altere uma variável por vez e compare execuções equivalentes, considerando cache, dados e versão da aplicação. Aprove a mudança quando ela melhorar o critério definido sem transferir a saturação para outra parte do sistema.

Checklist para corrigir o HPA e reduzir intervenções recorrentes

Use esta sequência para transformar sintomas em uma mudança verificável:

• Confirmar o alvo, as condições e a disponibilidade das métricas do HPA Kubernetes.
• Revisar requests e limits Kubernetes com medições por réplica.
• Demonstrar que o sinal escolhido acompanha a necessidade de capacidade.
• Medir inicialização e validar readiness, startup e liveness.
• Conferir capacidade dos nós, cotas e limites das dependências.
• Comparar políticas de scale up e scale down sob rajadas recorrentes.
• Eliminar disputas de réplicas entre deploys, GitOps e autoscalers.
• Validar SLOs, recuperação e consumo em testes reproduzíveis.
• Definir responsável, acompanhamento em produção e condição de reversão.

Para cada ajuste, mantenha uma ficha com sintoma, hipótese, evidência, alteração, responsável, resultado esperado, resultado observado e condição de reversão.

Por exemplo: se réplicas desejadas sobem enquanto Pods ficam Pending por falta de CPU, a hipótese envolve capacidade de agendamento. Ajustar a meta do HPA antes de resolver essa evidência tende a produzir novas tentativas sem capacidade útil.

Use o checklist para revisar o HPA da sua API, registre o principal gargalo e valide uma mudança por vez em teste de carga. Continue acompanhando o blog Max Alex para aprofundar a operação de Kubernetes.