Autoscaling no Kubernetes na prática: HPA, VPA e Cluster Autoscaler sem mistério

Quando você sobe uma aplicação no Kubernetes e ela começa a receber tráfego real, uma pergunta aparece rápido: quantas réplicas eu deixo rodando? Se você dimensiona para o pico, paga por capacidade ociosa a maior parte do dia. Se dimensiona para a média, o serviço engasga na primeira campanha de marketing ou no horário de pico. Autoscaling existe justamente para tirar esse número da sua cabeça e colocá-lo sob controle de um loop automático que observa a carga e reage a ela.

O problema é que "autoscaling no Kubernetes" não é uma coisa só. São três mecanismos diferentes, que atuam em camadas diferentes, e que muita gente confunde ou tenta usar de forma sobreposta sem entender o conflito que isso gera. O HPA (Horizontal Pod Autoscaler) muda o número de pods. O VPA (Vertical Pod Autoscaler) muda o tamanho de cada pod. O Cluster Autoscaler muda o número de nós na infraestrutura. Cada um resolve um problema específico, e usá-los juntos exige entender como eles interagem — porque dois deles brigam entre si se você não tomar cuidado.

Neste guia você vai entender como cada escalador funciona por dentro, qual métrica ele observa, como configurar thresholds e janelas de estabilização para evitar oscilação, e as armadilhas operacionais que derrubam autoscaling em produção — a começar pela mais comum de todas, que é rodar pods sem requests declarados. Vamos do alicerce (requests e limits) até o topo (escalonamento orientado a eventos com KEDA).

Requests e limits: o alicerce de tudo#

Antes de falar de qualquer escalador, você precisa entender que autoscaling no Kubernetes é construído sobre requests e limits. Sem eles, nada funciona direito, e boa parte dos problemas de escalonamento que as pessoas relatam nasce aqui.

O requests é a quantidade de CPU e memória que o pod declara precisar para funcionar. O scheduler usa esse número para decidir em qual nó colocar o pod — ele só encaixa o pod num nó que tenha requests livre suficiente. O limits é o teto: a CPU é estrangulada (throttled) quando o pod passa do limite, e a memória causa um OOMKill se o pod ultrapassar o limite de RAM.

``yaml resources: requests: cpu: "250m" memory: "256Mi" limits: cpu: "500m" memory: "512Mi" ``

Por que isso importa tanto para o autoscaling? Porque o HPA calcula utilização em cima do requests, não do consumo absoluto. Quando você diz "escala quando a CPU passar de 70%", esse 70% é 70% do requests somado de todos os pods. Um pod que consome 180m de CPU com requests de 250m está a 72% de utilização. O mesmo pod, se você não tivesse declarado requests, deixaria o HPA sem denominador — e o autoscaler simplesmente não consegue calcular a porcentagem, marcando a métrica como <unknown> e não escalando nada.

Essa é a primeira armadilha, e a mais frequente: pod sem requests é invisível para o HPA baseado em utilização. Antes de configurar qualquer escalador, garanta que todo contêiner tem requests de CPU e memória declarados de forma realista. "Realista" aqui significa medido, não chutado — observe o consumo em produção ou em teste de carga por alguns dias antes de cravar o número.

Horizontal Pod Autoscaler: mais réplicas#

O HPA é o escalador que a maioria das pessoas conhece. Ele ajusta o número de réplicas de um Deployment, ReplicaSet ou StatefulSet com base em métricas observadas. A ideia é simples: se a carga por pod está alta, adicione pods; se está baixa, remova pods.

O loop de controle#

O HPA roda como um loop dentro do controller manager, por padrão a cada 15 segundos. A cada ciclo ele consulta as métricas atuais dos pods, aplica uma fórmula e decide o número desejado de réplicas. A fórmula central é direta:

`` réplicas desejadas = ceil( réplicas atuais × ( métrica atual / métrica alvo ) ) ``

Se você tem 4 réplicas rodando a 90% de CPU e o alvo é 70%, a conta dá ceil(4 × (90/70)) = ceil(5.14) = 6 réplicas. O HPA sobe para 6. No ciclo seguinte, com 6 réplicas dividindo a mesma carga, a utilização média cai, e o loop se estabiliza. É um controlador proporcional simples, e entender essa fórmula ajuda a prever como o sistema vai reagir a um pico.

De onde vêm as métricas? Para CPU e memória, o HPA lê o metrics-server, um componente leve que agrega o consumo de recursos reportado pelo kubelet de cada nó. O metrics-server não é instalado por padrão em muitos clusters — se o seu kubectl top pods não retorna nada, é sinal de que ele não está lá, e sem ele o HPA baseado em recursos não funciona.

Um manifesto de HPA na prática#

Aqui está um HPA moderno (API autoscaling/v2) que escala por CPU e memória ao mesmo tempo:

```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-web spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-web minReplicas: 3 maxReplicas: 20 metrics:

• type: Resource

resource: name: cpu target: type: Utilization averageUtilization: 70

• type: Resource

resource: name: memory target: type: Utilization averageUtilization: 80 ```

Quando você define mais de uma métrica, o HPA calcula o número desejado para cada uma e usa o maior — a métrica mais "faminta" ganha. Isso é importante: se a CPU pede 6 réplicas e a memória pede 4, o resultado é 6. O HPA nunca deixa uma métrica sozinha derrubar réplicas que outra métrica ainda considera necessárias.

Repare também nos minReplicas e maxReplicas. O mínimo protege contra o serviço ficar sem capacidade em vale de tráfego (e evita cold start no primeiro request depois de um período calmo). O máximo é uma trava de segurança: sem ela, um pico anômalo ou um loop de retry mal comportado poderia escalar para centenas de pods e estourar tanto o cluster quanto sua fatura.

Custom e external metrics#

CPU e memória resolvem muitos casos, mas nem todos. Um serviço que processa uma fila pode estar com CPU baixa e mesmo assim acumulando trabalho — o gargalo é o backlog, não o processador. Para esses casos o HPA aceita métricas custom (originadas de dentro do cluster, tipicamente requisições por segundo ou profundidade de fila expostas pela sua aplicação) e external (originadas de fora, como o tamanho de uma fila SQS ou o lag de um consumer group do Kafka).

Essas métricas não vêm do metrics-server. Elas passam por um adapter que implementa a Custom Metrics API ou a External Metrics API do Kubernetes. O mais comum é o Prometheus Adapter, que traduz consultas PromQL em métricas que o HPA consegue ler. Com ele você escala por "requisições por segundo por pod", que costuma ser um sinal muito mais fiel de carga real do que a CPU.

```yaml metrics:

• type: Pods

pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: "100" ```

Aqui o alvo é um valor absoluto: 100 requisições por segundo por pod. Se a média subir para 150, o HPA adiciona réplicas até a média por pod voltar para perto de 100. Note a diferença de type: Utilization é porcentagem do requests, AverageValue é um número bruto por pod, e Value é um número total agregado.

Estabilização e behavior: matando o thrashing#

O maior inimigo prático do HPA é o thrashing: o serviço escala para cima, a carga cai, ele escala para baixo, a carga sobe de novo, e você fica com réplicas nascendo e morrendo o tempo todo. Isso desperdiça recursos, aumenta cold starts e polui seus dashboards.

O Kubernetes resolve isso com a stabilization window e as behavior policies. A janela de estabilização faz o HPA olhar para trás antes de reduzir réplicas: em vez de reagir ao valor instantâneo, ele considera o pico dos últimos N segundos. Por padrão são 300 segundos (5 minutos) para scale-down, o que significa que o HPA só remove réplicas depois que a carga ficou baixa de forma sustentada por cinco minutos. Para scale-up a janela padrão é zero — subir é urgente, descer pode esperar.

```yaml behavior: scaleDown: stabilizationWindowSeconds: 300 policies:

• type: Percent

value: 50 periodSeconds: 60 scaleUp: stabilizationWindowSeconds: 0 policies:

• type: Percent

value: 100 periodSeconds: 30

• type: Pods

value: 4 periodSeconds: 30 selectPolicy: Max ```

As policies controlam a velocidade da mudança. No exemplo, o scale-up pode dobrar o número de pods a cada 30 segundos OU adicionar 4 pods a cada 30 segundos, o que for maior (selectPolicy: Max). O scale-down é mais conservador: remove no máximo 50% das réplicas por minuto, para não derrubar capacidade de forma abrupta e causar um novo pico. Ajustar essas políticas é o que separa um HPA nervoso de um HPA que respira com o tráfego. Suba rápido, desça devagar — essa é a regra prática que resolve a maioria dos casos de oscilação.

Vertical Pod Autoscaler: pods do tamanho certo#

Enquanto o HPA muda quantos pods você tem, o VPA muda o tamanho de cada pod. Ele observa o consumo histórico de CPU e memória e recomenda (ou aplica) novos valores de requests para que o pod não fique nem superdimensionado nem sufocado.

O VPA resolve um problema diferente do HPA. Pense num serviço que não escala bem horizontalmente — um job de processamento com estado, um banco, um serviço legado single-threaded. Adicionar réplicas não ajuda; o que ele precisa é de mais memória ou mais CPU por instância. É aí que o VPA brilha. Ele também é ótimo para acertar os requests iniciais que você chutou lá no começo: em vez de você ficar adivinhando, o VPA mede e corrige.

Os três modos#

O VPA opera em modos que definem o quão agressivo ele é:

• Off: ele só calcula e expõe recomendações, sem tocar em nada. Excelente para descobrir os valores certos de requests sem risco — você lê a recomendação com kubectl describe vpa e aplica manualmente quando quiser.
• Initial: ele define os requests apenas na criação do pod, e não mexe mais depois disso.
• Auto / Recreate: ele aplica as recomendações em pods já rodando. Como o Kubernetes tradicionalmente não permite mudar requests de um pod vivo, o VPA nesse modo despeja e recria o pod com os novos valores. Isso significa reinício, e é a fonte da principal ressalva de usar VPA em Auto em serviços sensíveis a disponibilidade.

```yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: worker-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: worker updatePolicy: updateMode: "Off" resourcePolicy: containerPolicies:

• containerName: "*"

minAllowed: cpu: "100m" memory: "128Mi" maxAllowed: cpu: "2" memory: "2Gi" ```

Começar em updateMode: "Off" é a recomendação para quase todo mundo. Você deixa o VPA observando por alguns dias, lê as recomendações, e ganha uma base de dados real sobre o que suas cargas realmente consomem — o que melhora até o dimensionamento manual e a configuração do próprio HPA.

O conflito HPA + VPA#

Aqui está o ponto que causa mais estrago quando ignorado: você não pode usar HPA e VPA sobre a mesma métrica no mesmo Deployment. O motivo é um loop de realimentação destrutivo. O HPA olha a utilização de CPU e adiciona réplicas quando ela sobe. O VPA olha o consumo e aumenta o requests de CPU quando ele sobe. Como a utilização é consumo / requests, os dois ficam brigando pelo mesmo número: o VPA sobe o denominador, o que derruba a utilização, o que faz o HPA remover réplicas, o que concentra carga, o que faz o VPA subir mais o requests... e o sistema oscila de forma imprevisível.

A regra prática é clara:

• Use HPA para CPU/memória e VPA em modo Off (só recomendação) no mesmo workload — o VPA te ajuda a acertar os requests, o HPA cuida das réplicas.
• Ou use VPA em Auto para CPU/memória e o HPA em cima de uma métrica custom que não seja CPU nem memória (por exemplo, requisições por segundo). Assim cada escalador olha um sinal diferente e eles não colidem.

Nunca deixe HPA e VPA disputando o mesmo recurso. Se você só tem essa regra na cabeça ao terminar de ler, já evitou um dos incidentes mais chatos de diagnosticar.

Cluster Autoscaler: mais nós#

HPA e VPA operam dentro da capacidade que o cluster já tem. Mas o que acontece quando o HPA quer subir 10 pods novos e não há espaço em nenhum nó para agendá-los? Sem uma terceira camada, esses pods ficam Pending para sempre, e seu autoscaling horizontal simplesmente não se materializa.

O Cluster Autoscaler fecha esse ciclo. Ele observa pods que não conseguem ser agendados por falta de recursos e, quando encontra pods Pending por esse motivo, adiciona nós ao cluster — pedindo uma nova máquina ao provedor de nuvem através dos node groups (Auto Scaling Groups na AWS, node pools no GKE e AKS, e equivalentes). No sentido inverso, quando um nó fica subutilizado por tempo suficiente e seus pods poderiam ser realocados em outros nós, ele drena e remove o nó, devolvendo a máquina e cortando custo.

Como ele decide#

O gatilho de scale-up do Cluster Autoscaler é justamente o pod Pending por falta de recursos — e é por isso que requests bem definidos são novamente essenciais. O Cluster Autoscaler raciocina inteiramente em cima de requests: ele calcula se o pod Pending caberia num nó novo do node group olhando o requests do pod contra a capacidade do tipo de máquina. Se seus pods não declaram requests, o Cluster Autoscaler pode achar que cabe tudo em qualquer lugar e nunca provisionar máquina nenhuma, mesmo com os nós sufocados de trabalho real.

O scale-down é mais cauteloso. Um nó só é candidato à remoção se estiver abaixo de um limiar de utilização (por padrão em torno de 50%) por um período contínuo (por padrão 10 minutos), e se todos os seus pods puderem ser reagendados em outros nós respeitando PodDisruptionBudgets, afinidades e taints. Pods de sistema, pods com armazenamento local e pods sem controlador que os recrie podem bloquear a remoção de um nó — o que às vezes explica por que um cluster teimosamente não encolhe.

A interação com o HPA é uma cadeia elegante quando bem configurada: o HPA decide que precisa de mais réplicas → cria pods → se não há espaço, os pods ficam Pending → o Cluster Autoscaler vê os Pending e adiciona um nó → o scheduler agenda os pods no nó novo. Cada camada faz uma coisa e a passagem entre elas é o que dá elasticidade real à infraestrutura. Vale registrar que existe também o Karpenter, uma alternativa mais moderna ao Cluster Autoscaler na AWS que provisiona nós de forma mais direta e flexível, sem depender de node groups pré-configurados — se você opera na AWS, vale conhecer.

KEDA: escalonamento orientado a eventos#

O HPA baseado em CPU tem um limite conceitual: ele reage ao sintoma (CPU alta) e não à causa (trabalho acumulado). Para cargas orientadas a eventos — consumidores de fila, processadores de stream, jobs disparados por mensagens — você quer escalar pelo tamanho da fila, e quer poder ir até zero quando não há trabalho, algo que o HPA sozinho não faz (ele respeita minReplicas, que precisa ser pelo menos 1 na forma tradicional).

O KEDA (Kubernetes Event-Driven Autoscaling) é a evolução natural aqui. Ele não substitui o HPA — na verdade ele gera um HPA por baixo dos panos — mas adiciona duas coisas cruciais: dezenas de scalers prontos (Kafka, RabbitMQ, SQS, Azure Service Bus, Redis, Prometheus, cron e muitos outros) e a capacidade de escalar de zero a um e de volta a zero. Quando uma fila está vazia, o KEDA desliga o serviço por completo; quando a primeira mensagem chega, ele ativa uma réplica e entrega o resto do escalonamento ao HPA que ele mesmo mantém.

```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: processador-fila spec: scaleTargetRef: name: processador minReplicaCount: 0 maxReplicaCount: 30 triggers:

• type: rabbitmq

metadata: queueName: pedidos mode: QueueLength value: "20" ```

Nesse exemplo, o KEDA mantém aproximadamente 20 mensagens por réplica: se a fila tem 200 mensagens pendentes, ele mira 10 réplicas. Fila vazia, zero réplicas, custo zero. Para arquiteturas de processamento assíncrono, isso é transformador — você escala pelo trabalho real que existe, não por um proxy indireto dele. Se o seu HPA custom com Prometheus Adapter está ficando complicado de manter, o KEDA quase sempre é o caminho mais limpo.

Armadilhas comuns em produção#

Já cobrimos algumas ao longo do texto, mas vale consolidar as que mais derrubam autoscaling na prática, porque quase todo incidente cai numa destas categorias:

• Pods sem requests. Repetimos porque é o número um. Sem requests, o HPA por utilização não calcula nada e o Cluster Autoscaler não sabe dimensionar nós. Declare sempre, e declare com base em medição.
• Thrashing por falta de estabilização. Se seu serviço fica subindo e descendo réplicas o tempo todo, ajuste a stabilizationWindowSeconds de scale-down e limite a velocidade com behavior policies. Suba rápido, desça devagar.
• Cold start ignorado. Se cada pod novo leva 40 segundos para ficar pronto (JVM aquecendo, cache carregando, conexões abrindo), o HPA que reage tarde vai deixar o serviço sofrer durante o pico inteiro. Combata isso com minReplicas mais generoso, com escalonamento antecipado por métrica custom (RPS sobe antes da CPU), e com readiness probes honestas que não deixem tráfego entrar antes do pod estar realmente pronto.
• HPA e VPA no mesmo recurso. O conflito de denominador que já detalhamos. Separe os sinais ou mantenha o VPA em Off.
• maxReplicas sem teto sensato ou baixo demais. Muito alto e um retry storm te leva à falência; muito baixo e você bate no teto durante o pico legítimo e o serviço degrada mesmo com o HPA "querendo" escalar. Dimensione o máximo pensando no pior caso plausível de tráfego.
• Métricas ausentes ou atrasadas. Se o metrics-server não está instalado, ou se o Prometheus Adapter está com scrape lento, o HPA opera com dados velhos ou nenhum dado. Monitore o próprio pipeline de métricas — um HPA cego é pior que nenhum HPA, porque te dá falsa sensação de segurança.
• PodDisruptionBudget ausente durante scale-down. Quando o Cluster Autoscaler ou o VPA em Auto vai remover/recriar pods, um PDB mal configurado (ou inexistente) pode derrubar réplicas demais de uma vez e causar indisponibilidade. Defina PDBs para os serviços críticos.

Como começar#

Se você está introduzindo autoscaling num serviço hoje, siga esta ordem e resista à tentação de pular etapas. Primeiro, acerte os requests e limits. Instale o metrics-server, rode o VPA em modo Off por alguns dias e use as recomendações dele — junto com o consumo observado em teste de carga — para cravar valores realistas. Sem esse alicerce, tudo que vem depois é castelo na areia.

Segundo, coloque um HPA simples por CPU, com minReplicas que sustente o vale de tráfego sem cold start e maxReplicas que cubra o pico com folga. Configure a stabilization window de scale-down para uns 300 segundos e observe o comportamento por uma ou duas semanas antes de refinar. Não comece com métrica custom; comece com CPU, entenda como seu serviço responde, e só então evolua.

Terceiro, se seu serviço tem uma métrica de carga mais fiel que a CPU — requisições por segundo, latência, profundidade de fila —, evolua o HPA para essa métrica custom via Prometheus Adapter. É quase sempre uma melhoria grande de qualidade de escalonamento, porque você passa a reagir à causa e não ao sintoma.

Quarto, se você opera em nuvem com capacidade elástica, ative o Cluster Autoscaler (ou Karpenter, na AWS) para que os pods do HPA tenham onde ser agendados. Sem essa camada, seu HPA promete uma elasticidade que a infraestrutura não entrega, e você descobre isso da pior forma, no meio de um pico, com pods presos em Pending.

E quinto, se sua carga é orientada a eventos, considere KEDA desde cedo — o modelo de escalar pela fila e ir até zero é tão superior para esse tipo de workload que raramente compensa insistir no HPA de CPU. Autoscaling bem feito não é sobre ligar todos os mecanismos de uma vez; é sobre entender qual problema você tem — muitos pods, pods pequenos demais, ou poucos nós — e aplicar a camada certa, medindo antes e depois. Comece pequeno, meça, e deixe cada escalador provar seu valor antes de adicionar o próximo.