Karpenter ou Cluster Autoscaler: qual usar no seu cluster EKS

Os dois fazem o mesmo trabalho visível: quando há pods que não cabem em nenhum nó, aparece capacidade nova, e quando há nós sobrando, eles saem. A diferença está em como cada um decide, e isso muda a conta no fim do mês.

Como cada um decide

O Cluster Autoscaler trabalha com grupos de nós. Na AWS, cada grupo é um Auto Scaling Group com um tipo de instância (ou uma lista curta) definido de antemão. Quando há pods pendentes, ele escolhe um grupo cujo modelo de nó comportaria o pod e aumenta o tamanho desse grupo. Quem decide o formato dos nós é você, ao criar os grupos.

O Karpenter não usa grupos. Ele lê os requisitos dos pods pendentes (CPU, memória, arquitetura, zona, tolerations) e cria instâncias EC2 diretamente, escolhendo entre muitos tipos que atendem a esses requisitos. Você descreve limites e preferências em um NodePool e um EC2NodeClass, e ele escolhe o formato dos nós a cada necessidade.

Onde a diferença aparece

O ganho de custo do Karpenter vem de duas coisas: ele não obriga você a adivinhar o tipo de instância certo para cada grupo, e a consolidação reempacota pods para liberar nós inteiros, não só nós vazios.

Quando manter o Cluster Autoscaler

• A plataforma é multi-cloud e você quer um único comportamento de autoscaling em todos os clusters.
• Os nós são controlados por grupos por razões de governança, compliance ou imagens muito específicas, e a variedade de instâncias não traz ganho.
• A carga é estável e já está bem dimensionada. Sem variação, a consolidação tem pouco a recuperar.
• O time ainda não tem requests de CPU e memória confiáveis. Nenhum dos dois autoscalers compensa requests inflados.

Quando o Karpenter vale a migração

• Cluster EKS com demanda variável (picos de API, jobs, filas, CI).
• Uso de Spot ou planos de usar, com várias famílias de instância disponíveis.
• Muitos grupos de nós só para cobrir combinações de tamanho, arquitetura e zona.
• Interesse em Graviton junto com instâncias x86 no mesmo cluster.

Um caminho seguro de migração

1. Antes de tudo, corrija os requests. Compare com o uso real, por exemplo com o rightsizing-check. Autoscaler nenhum resolve pods que pedem o triplo do que usam.
2. Instale o Karpenter ao lado do Cluster Autoscaler, com o controlador rodando em um grupo gerenciado pequeno, fora dos nós que ele próprio provisiona.
3. Crie um `NodePool` restrito a uma carga de teste, usando o gerador de NodePool para partir de um YAML válido na v1.
4. Habilite a consolidação com budgets de disrupção e PodDisruptionBudgets nas cargas críticas, antes de ampliar.
5. Mova as cargas por etapas, esvazie os grupos antigos e só então reduza o Cluster Autoscaler a zero.

Para saber o efeito financeiro antes de mexer em produção, use a calculadora de economia. O artigo Karpenter: como reduzir custos de Kubernetes detalha NodePool, EC2NodeClass e troubleshooting.

Em resumo

Para um cluster EKS com carga variável, o Karpenter costuma ser a escolha mais econômica, desde que os requests estejam corretos e a disrupção seja controlada. O Cluster Autoscaler continua sendo uma boa escolha para ambientes multi-cloud, estáveis ou muito controlados. Se quiser uma opinião sobre o seu caso, o assessment de eficiência é o ponto de partida.