No EKS, escolher entre HPA, KEDA e Karpenter evita incidente de autoscaling em produção

Autoscaling em Kubernetes é sempre uma decisão em duas camadas: pods e nós. Um guia publicado pela Control Plane no DEV Community mapeia HPA, VPA, KEDA, Cluster Autoscaler, Karpenter e as opções gerenciadas, e mostra onde combinações erradas quebram em produção.

A decisão

Quem opera um cluster EKS enfrenta duas perguntas diferentes, não uma. A primeira é quantas réplicas de um pod devem existir agora. A segunda é quantas máquinas EC2 o cluster precisa para rodar essas réplicas. Um guia publicado pela Control Plane, fornecedora de plataforma gerenciada para Kubernetes, na tag #aws do DEV Community, organiza exatamente essa separação e data suas comparações como vigentes em novembro de 2026.

O ponto central do material, e o que vale carregar para a produção: não existe "o melhor autoscaler do Kubernetes". Existe um autoscaler de pod (HPA, VPA ou KEDA) e um autoscaler de nó (Cluster Autoscaler, Karpenter ou uma opção gerenciada como o EKS Auto Mode), e as duas escolhas são independentes. Errar a combinação, por exemplo rodar HPA e VPA no mesmo metric para o mesmo workload, não é um detalhe de configuração: é um dos erros que o próprio guia aponta como fonte de thrashing em produção, ao lado da ausência de PodDisruptionBudgets e de janelas de estabilização.

Vale o alerta de proveniência: a fonte é conteúdo publicado por um fornecedor que vende justamente a alternativa a operar essas ferramentas (a Control Plane roda a camada de nó para o cliente). Isso não invalida o mapeamento técnico, que bate com a documentação oficial de cada projeto, mas explica por que a seção de custo do próprio guia favorece a oferta gerenciada da empresa. Trato esse ponto separadamente adiante.

Lado a lado

A tabela abaixo usa os mesmos critérios do guia original para as seis opções, com o que cada uma ainda deixa sob responsabilidade do time que opera o cluster.

A linha que mais costuma passar despercebida é a do HPA: o HPAScaleToZero ainda é beta no Kubernetes 1.37 e só funciona com métricas object ou external, não com CPU ou memória. Quem precisa de scale-to-zero em qualquer versão de cluster suportada continua dependendo do KEDA, não do HPA nativo.

Quando escolher cada um

Para uma API web estável, com tráfego previsível, o par mais simples continua sendo HPA escalando em CPU ou memória, combinado com Cluster Autoscaler ou Karpenter no EKS. Um exemplo de HPA típico para um serviço checkout-api:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: checkout-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Para consumidores de fila, pipelines de eventos e workloads com ociosidade longa, o guia é direto: use KEDA. Um ScaledObject apontando para a profundidade de uma fila SQS, por exemplo, escala o deployment a zero quando não há mensagem pendente e reage à chegada de evento, independentemente da versão do cluster. Isso resolve o caso que o HPA nativo ainda não cobre bem fora do beta.

No lado dos nós, a escolha depende do quanto o time quer decidir sobre tipo de instância:

• Karpenter lê os requisitos de cada pod pendente (CPU, memória, zona, spot ou on-demand) e provisiona a instância que encaixa, sem grupo de nós pré-definido. É a opção com mais controle sobre estratégia de spot e instâncias especializadas (GPU, por exemplo), e é a que a AWS mantém como produção-pronta no EKS.
• Cluster Autoscaler trabalha sobre node groups definidos antecipadamente. Continua sendo a escolha certa para cluster multi-cloud, on-premises via Cluster API, ou GKE Standard, onde o Karpenter tem no máximo um provider mantido pela comunidade.
• EKS Auto Mode tira o Karpenter da mão do time: a AWS roda o provisionamento, a escala e o patch de sistema operacional. A troca é menos controle sobre tipo de instância e configuração de nó.

Um NodePool de Karpenter típico, para ilustrar o nível de controle que se perde ao migrar para o Auto Mode:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Para workloads que não escalam horizontalmente, como um serviço stateful de réplica única, o VPA entra como complemento, não como substituto. Desde a versão 1.6, o modo InPlaceOrRecreate chegou a general availability: ele redimensiona o pod em execução e só recorre a evict e recriação quando o resize in-place não é possível, reduzindo a janela de indisponibilidade que o modo Recreate sempre causava.

Custo

O material da fonte não traz número de preço de EKS Auto Mode, Karpenter ou Cluster Autoscaler: a AWS cobra pelo EC2 provisionado em qualquer uma das três rotas, e nenhuma delas tem uma taxa própria separada no guia. O custo real está no trabalho de operação, não na ferramenta em si.

Rodar Karpenter por conta própria significa manter NodePools, restrições de instância e política de consolidação atualizadas; o retorno é a liberdade de montar uma estratégia agressiva de spot, útil quando a fatura de EC2 pesa. Adotar EKS Auto Mode transfere esse trabalho para a AWS, inclusive o patch de sistema operacional, ao custo de menos controle sobre qual tipo de instância sobe.

A Control Plane, autora do guia, afirma que seus clientes veem de 30% a 50% de redução de custo de compute comparado a rodar direto em AWS, GCP ou Azure. É um número do próprio fornecedor, sem metodologia publicada no material, então vale tratá-lo como argumento comercial, não como benchmark independente: antes de considerar qualquer plataforma terceira para tirar a camada de nó do time, peça a metodologia por trás desse percentual.

Veredito

Se o cluster já roda com managed node groups e a prioridade é portabilidade entre nuvens ou um caminho de volta para on-premises, o par HPA mais Cluster Autoscaler continua sendo a base mais segura: é a combinação suportada em mais ambientes e a mais fácil de replicar fora da AWS.

Se a carga é dirigida por evento (fila SQS, lag de Kafka, agendamento por cron) e picos de tráfego batem em horários específicos, KEDA mais Karpenter é o par que o próprio guia chama de "cost-aware AWS stack": o KEDA zera réplicas na ociosidade e o Karpenter consolida nós quando sobra capacidade.

Se o time já decidiu que não quer mais gente dedicada a node group, tipo de instância e patch de AMI, o EKS Auto Mode com HPA ou KEDA por cima remove essa operação, com a ressalva de perder parte do controle fino sobre a frota de instâncias. Antes de assinar qualquer plataforma gerenciada de terceiros para substituir essa camada, vale comparar o número de redução de custo anunciado com uma medição própria, porque o dado publicado é do fornecedor que vende a solução.

Em qualquer uma das três rotas, duas regras do próprio material seguem valendo sem exceção: nunca deixar HPA e VPA atuando sobre a mesma métrica do mesmo workload, e configurar PodDisruptionBudgets antes de ligar a consolidação do Karpenter ou do Cluster Autoscaler, para que uma rodada de scale-down não derrube todas as réplicas de um serviço de uma vez.

Fonte

1. DEV Community — #aws: "The Best Kubernetes Autoscaling Tools in 2026"

Fonte: DEV Community — #aws