Karpenter: como reduzir custos de Kubernetes sem sacrificar performance

Se o seu cluster Kubernetes usa Cluster Autoscaler com Auto Scaling Groups fixos, você já deve ter sentido as dores clássicas: escala lenta em picos, nós subdimensionados ou superdimensionados, e dificuldade real para usar Spot de forma agressiva sem quebrar workloads. O Karpenter foi criado para resolver exatamente isso.

O que o Karpenter faz de diferente

O Cluster Autoscaler trabalha em cima de grupos de nós pré-definidos (Auto Scaling Groups): ele escala esses grupos para cima ou para baixo, mas está limitado aos tipos de instância e configurações que você já definiu antes. O Karpenter elimina essa camada intermediária — ele conversa diretamente com a API da cloud (EC2, no caso da AWS) e provisiona o nó com o tipo de instância mais adequado para os pods pendentes no momento, sem precisar de um grupo pré-configurado para cada combinação possível.

• Provisionamento just-in-time: escolhe o tipo de instância certo (família, tamanho, arquitetura) com base nos requests reais dos pods pendentes, em vez de escalar um grupo genérico.
• Consolidação nativa: reagrupa periodicamente os workloads em menos nós quando isso reduz custo, sem precisar de uma ferramenta separada.
• Spot de verdade: escolhe entre múltiplos tipos de instância e zonas de disponibilidade para reduzir o risco de interrupção, respeitando um fallback para On-Demand quando configurado.
• Escala mais rápida: no lugar de esperar o ciclo de um Auto Scaling Group, o nó já sobe pronto para o tipo de carga que está pendente.

Quando vale a pena adotar

• Cargas de trabalho com picos de demanda variáveis ao longo do dia ou da semana.
• Clusters médios a grandes, onde o desperdício de bin-packing ruim já pesa na conta.
• Times que já usam ou querem usar Spot de forma mais agressiva sem gerenciar múltiplos Auto Scaling Groups manualmente.
• Ambientes EKS (o suporte é mais maduro na AWS; em outras clouds a adoção ainda está evoluindo).

Cuidados antes de colocar em produção

1. PodDisruptionBudgets corretos: a consolidação do Karpenter dreina e substitui nós ativamente — sem PDB configurado, isso pode derrubar réplicas de um serviço ao mesmo tempo.
2. Requests e limits realistas: o dimensionamento do nó é feito com base no que os pods pedem. Requests infladas ou subestimadas geram nós errados para a carga real.
3. Tratamento de interrupção de Spot: configure o handler de interrupção (via NodePool/NodeClass) para que o Karpenter drene o nó com antecedência ao aviso de término da cloud, e não durante.
4. Migração gradual: rode Karpenter e Cluster Autoscaler lado a lado em node pools separados antes de migrar 100% da carga, validando comportamento de scale-up, scale-down e consolidação com tráfego real.
5. Observabilidade de custo: acompanhe custo por workload antes e depois (Kubecost ou equivalente) para confirmar que a consolidação está de fato reduzindo gasto, não só trocando de instância.

Na prática, a maior parte dos problemas que vejo com Karpenter em produção não é do Karpenter em si — é configuração de PDB, requests e política de consolidação feitas às pressas. Se você está considerando migrar do Cluster Autoscaler e quer validar a configuração antes de rodar em produção, um diagnóstico técnico direcionado evita surpresa com interrupção de workload crítico.