Autoscaling no Kubernetes: HPA, VPA e Cluster Autoscaler sem susto na fatura

Escalar automaticamente é uma das promessas mais atraentes do Kubernetes e uma das que mais decepciona quando mal configurada. Os sintomas são conhecidos: o número de réplicas oscila sem parar, a aplicação continua lenta no pico apesar de ter escalado, ou a fatura do mês vem com o dobro do esperado e ninguém sabe explicar.

O problema quase nunca é o mecanismo. É a métrica errada, a camada errada ou duas camadas brigando entre si.

As três camadas

Elas se complementam: o HPA cria mais pods, o Cluster Autoscaler cria os nós onde eles cabem, e o VPA ajusta o tamanho de cada pod.

E há uma incompatibilidade importante: HPA e VPA não devem atuar sobre a mesma métrica no mesmo workload. Se os dois olham CPU, um aumenta réplicas enquanto o outro aumenta o request de cada uma, e o resultado é oscilação e desperdício. Use VPA para memória e HPA para CPU ou para uma métrica de negócio, ou use apenas um dos dois.

HPA: a métrica é tudo

O HPA aumenta e reduz réplicas para manter uma métrica próxima de um alvo. A escolha dessa métrica decide se ele vai funcionar.

CPU é o padrão e serve bem para aplicações limitadas por processamento. Serve mal para aplicações limitadas por I/O — uma API que passa a maior parte do tempo esperando resposta do banco fica lenta com CPU baixa, e o HPA não reage.

Métricas melhores, quando disponíveis:

• Requisições por segundo por réplica. Direta, previsível e fácil de raciocinar.
• Tamanho da fila pendente. A melhor métrica que existe para processamento assíncrono: escala pelo trabalho acumulado, que é exatamente o que importa.
• Latência em percentil alto — com cuidado, porque latência alta pode vir de dependência lenta, e nesse caso adicionar réplicas piora a situação, sobrecarregando ainda mais a dependência.
• Conexões ativas, para serviços de conexão persistente.

Para fila, existe um mecanismo dedicado de escala por evento que consulta diretamente o sistema de mensageria e é bem mais adequado que adaptar o HPA. Vale conhecer antes de improvisar.

Os parâmetros que evitam oscilação

Escalar rápido para cima e devagar para baixo é a regra. O motivo é assimétrico: subir tarde causa indisponibilidade; descer cedo causa oscilação.

O que ajustar:

• Janela de estabilização na redução, de vários minutos. Sem ela, uma queda momentânea de carga remove réplicas que voltarão a ser necessárias em seguida.
• Política de crescimento permitindo subida rápida — dobrar, ou adicionar um número fixo por intervalo curto.
• Política de redução conservadora, removendo poucas réplicas por vez.
• Mínimo de réplicas que sustente a carga de base sem escalar, e nunca menor que dois em produção.
• Máximo de réplicas definido conscientemente. Ele é o seu limite de gasto e o seu limite de dano — sem ele, um erro de métrica pode criar centenas de pods.

E um detalhe frequentemente esquecido: o HPA depende de requests bem dimensionados. Ele calcula o uso como percentual do request. Request inflado significa uso percentual sempre baixo e HPA que nunca escala; request apertado significa escalada constante.

Cluster Autoscaler: onde o custo aparece

O Cluster Autoscaler adiciona nós quando há pods que não cabem em lugar nenhum, e remove nós que ficaram subutilizados.

O que trava a remoção de nó — e é aqui que o custo se acumula em silêncio:

• Pods sem controlador (criados soltos) não podem ser movidos, e seguram o nó indefinidamente.
• Pods com armazenamento local não migram.
• Orçamento de disrupção restritivo demais impede a remoção.
• Pods de sistema sem tolerância adequada.
• Anotação explícita impedindo o despejo daquele pod.

Diagnóstico prático: se o cluster cresce e nunca encolhe, procure nesta lista. Quase sempre é um ou dois pods segurando vários nós parcialmente vazios.

Complementos que importam:

• Grupos de nós separados por perfil — nós maiores para cargas grandes, menores para as pequenas —, para o autoscaler escolher com granularidade.
• Pods de baixa prioridade que ocupam espaço reservado e são despejados quando carga real chega. É a técnica que reduz o tempo de espera por nó novo, que pode ser de minutos.
• Limite máximo de nós, sempre. É o seu teto de gasto.

O tempo que ninguém considera

Autoscaling não é instantâneo, e a soma dos atrasos surpreende:

1. A métrica é coletada — dezenas de segundos de atraso.
2. O HPA avalia em intervalo definido.
3. O pod novo é agendado.
4. Se não há nó, o Cluster Autoscaler pede um — provisionamento leva minutos.
5. O nó inicializa e entra no cluster.
6. A imagem é baixada, se não estiver em cache.
7. A aplicação inicializa e passa na verificação de prontidão.

Do aumento de carga até a capacidade nova atender, podem se passar vários minutos. Para pico gradual, funciona. Para pico abrupto — promoção, notificação em massa, evento marcado —, não funciona.

O que resolve pico previsível: escalar antes, por agendamento. Não é elegante, é eficaz, e é o que separa quem passa pela Black Friday de quem escreve o postmortem dela.

Os pré-requisitos da aplicação

Autoscaling só funciona se a aplicação colaborar:

• Sem estado local. Pod novo precisa atender igual ao antigo; sessão em memória quebra isso.
• Inicialização rápida. Aplicação que leva três minutos para subir anula o benefício.
• Verificação de prontidão correta, para não receber tráfego antes da hora.
• Encerramento gracioso, drenando conexões ao ser removida na redução.
• Dependências que suportam a escala. Escalar de 5 para 50 réplicas significa dez vezes mais conexões ao banco. Sem pool adequado, você derruba o banco escalando a aplicação — e este é o incidente mais comum causado por autoscaling.

Esse último item precisa estar no desenho desde o começo. O limite de escala da aplicação é frequentemente o banco, não o cluster.

O custo: o que vigiar

• Teto de réplicas e de nós definidos. Sem eles, não há limite de gasto.
• Alerta de crescimento anômalo — número de nós subindo fora do padrão, especialmente fora do horário comercial.
• Relação entre reservado e usado por namespace. Request inflado aparece aqui e faz o cluster crescer sem necessidade.
• Revisão mensal dos parâmetros contra o comportamento real.
• Nós subutilizados que não estão sendo removidos.

Vale repetir um ponto de dimensionamento: em muitos clusters, o ganho de custo vem antes do autoscaling. Corrigir requests inflados costuma devolver mais capacidade do que qualquer política de escala — e a capacidade devolvida é imediata e gratuita.

Erros comuns

• HPA por CPU em aplicação limitada por I/O.
• HPA e VPA sobre a mesma métrica, brigando entre si.
• Requests inflados, e HPA que nunca escala.
• Sem janela de estabilização na redução, com oscilação constante.
• Sem máximo definido, sem teto de gasto.
• Mínimo de uma réplica em produção.
• Pods soltos ou com armazenamento local segurando nós vazios.
• Orçamento de disrupção impedindo remoção de nó.
• Esperar reação instantânea em pico abrupto.
• Não escalar antecipadamente para evento previsível.
• Escalar a aplicação e derrubar o banco por falta de pool.
• Aplicação com estado local escalando horizontalmente.
• Sem alerta de crescimento anômalo de nós.

Onde a Solvefy/Cloud entra

Configurar autoscaling que funciona começa antes dele: dimensionamento correto de requests, métrica adequada à natureza da carga, parâmetros assimétricos de subida e descida, tetos definidos, dependências preparadas para a escala e escala antecipada para eventos previsíveis. Fazemos esse trabalho com medição do seu ambiente e entregamos o painel de custo com o alerta de crescimento anômalo — porque autoscaling sem teto e sem alerta é uma fatura esperando para acontecer.

Seu cluster cresce sozinho e nunca encolhe? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.