- A Corrida pelo Escalonamento de Nós
Se você trabalha ou está estudando sobre Kubernetes, já deve ter percebido que gerenciar containers é uma arte. No começo, tudo é lindo: você cria seus Pods, define os limites e vê a mágica acontecer. Mas o mundo real não é um ambiente de testes controlado. Na vida real, o e-commerce da sua empresa enfrenta picos massivos de acesso, as APIs começam a exigir mais recursos e o cluster precisa crescer (e rápido!) para aguentar o tranco.
No Kubernetes, quando suas aplicações crescem, nós precisamos de mais servidores físicos ou virtuais para rodar esses containers. Esse processo é chamado de escalonamento de nós (Node Autoscaling).
Por muito tempo, o padrão de mercado para resolver isso na AWS foi a dupla Cluster Autoscaler + Managed Node Groups (MNG). Mas, conforme as arquiteturas de microsserviços evoluíram, esse modelo tradicional começou a mostrar seus gargalos, abrindo espaço para o surgimento do queridinho do momento: o Karpenter.
A Analogia: Carros Idênticos vs. Alugar um Ônibus
Para entender o verdadeiro problema do passado, imagine que você é o organizador de uma viagem de última hora para a equipe da sua empresa. De repente, aparecem 50 pessoas confirmadas para ir.
No modelo tradicional (Cluster Autoscaler + MNG):
A sua regra diz que você só pode transportar pessoas usando carros Sedan de 5 lugares. O que o Autoscaler faz? Ele entra em pânico e compra 10 carros idênticos de uma vez para caber todo mundo. Não importa se vai sair muito mais caro, se vai faltar vaga no estacionamento ou se daria para resolver tudo de outro jeito: a regra dele é criar cópias do mesmo carro.
No modelo moderno (Karpenter): O Karpenter olha para as 50 pessoas esperando na calçada, calcula o tamanho do grupo e pensa: “Espera aí, em vez de comprar 10 carros, sai muito mais barato, rápido e eficiente eu alugar um único ônibus de 50 lugares agora mesmo”. Ele vai lá e traz o veículo exato para aquela necessidade.
É exatamente esse o problema do passado que enfrentamos com os Managed Node Groups tradicionais. Eles são robustos, mas funcionam empilhando cópias de máquinas idênticas em um grupo engessado, ignorando completamente se aquela é a melhor decisão financeira ou de performance para o cluster naquele exato momento.
2.AWS Managed Node Groups (MNG) e o Modelo Tradicional
Quando o Amazon EKS foi lançado, a forma padrão e mais segura de gerenciar os servidores (nós) do cluster era através dos Managed Node Groups (MNG). Nesse modelo, a AWS cuida de grande parte do trabalho pesado: ela provisiona as máquinas virtuais (EC2), configura o sistema operacional otimizado para o Kubernetes e conecta tudo ao seu cluster de forma automatizada.
Para fazer o cluster crescer ou diminuir conforme a demanda das aplicações, nós atrelamos a esse grupo uma ferramenta clássica chamada Cluster Autoscaler.
A lógica dele é bem simples: se o seu e-commerce recebe um pico de acessos e os pods da sua API começam a ficar travados em estado Pending por falta de memória ou CPU, o Cluster Autoscaler percebe isso, vai até o Auto Scaling Group (ASG) da AWS e pede: “Ei, crie mais uma máquina idêntica para nós”.
Vantagens do MNG
Estabilidade e Segurança de Grife: A AWS gerencia o ciclo de vida das máquinas. Se uma nova versão de segurança do Linux for lançada, você atualiza o nó com poucos cliques diretamente pelo console ou via Terraform.
Simplicidade Inicial: É o feijão com arroz que funciona. Muito previsível e amplamente documentado no mercado.
As Desvantagens (O Gargalo do Engessamento)
Lento para Escalar: O processo de detectar o pod travado, acionar o ASG, a AWS provisionar a EC2 e o nó ficar pronto (Ready) pode levar facilmente de 2 a 4 minutos. Para um e-commerce em plena Black Friday, 4 minutos de lentidão significam milhares de carrinhos abandonados.
Arquitetura Engessada: Se você configurou o seu Node Group para usar instâncias do tipo t3.medium, o Cluster Autoscaler só sabe criar máquinas t3.medium. Se um desenvolvedor subir um Pod gigante que precisa de 16GB de RAM, o Autoscaler vai empilhar várias máquinas menores em vez de criar uma única máquina grande que sairia mais barata e eficiente.
- Abordagem 2: Karpenter (O Autoscaler “Just-in-Time”)
Para quebrar as correntes dos grupos engessados e trazer velocidade real para o Kubernetes, a AWS criou e abriu para a comunidade o Karpenter, um autoscaler flexível e nativo de nuvem.
O Karpenter joga a lógica dos Auto Scaling Groups (ASGs) no lixo. Ele não trabalha com grupos de máquinas pré-definidos. Em vez disso, ele roda como um Controller dentro do seu cluster e fala direto com a API do Amazon EC2.
A genialidade do Karpenter está na sua capacidade de avaliar a demanda em tempo real. Quando um ou mais Pods ficam em estado Pending, o Karpenter abre o manifesto deles, calcula exatamente quanta CPU e memória eles precisam e faz uma pergunta cirúrgica para a AWS: “Qual é a máquina mais barata e disponível agora para aguentar esse tranco exato?”.
Se o melhor para aquele momento for uma máquina c5.xlarge, ele cria. Se logo em seguida entrar um processo batch que roda melhor em instâncias baratas do tipo Spot, ele traz uma instância Spot.
Vantagens do Karpenter
Velocidade de Fórmula 1: Como ele pula intermediários e fala direto com a API do EC2, ele consegue colocar um novo nó de pé e rodando em menos de 1 minuto (muitas vezes em até 30 segundos).
FinOps Nativo (Consolidação de Nós): O Karpenter é extremamente inteligente com o dinheiro da empresa. Se ele notar que você tem três máquinas rodando com apenas 10% de uso cada, ele move automaticamente os pods para uma única máquina menor e deleta as outras duas sobressalentes, reduzindo o custo da sua conta AWS na hora.
Flexibilidade Total: Você define regras amplas (chamadas de NodePools). Você pode dizer: “Karpenter, você tem permissão para escolher qualquer máquina das famílias m5, c5 ou t3, priorizando o que for mais barato”. Ele decide o resto.
Desvantagens do Karpenter
Complexidade de Configuração: Ele exige uma configuração inicial mais robusta de permissões de IAM (Roles e Policies da AWS) e uma mudança de mentalidade do time de infraestrutura.
Gerenciamento do SO por sua conta: Como as máquinas nascem de forma dinâmica e sob demanda, você precisa garantir que as imagens (AMIs) que ele está puxando estejam atualizadas, sem contar com aquela automação “mágica” de upgrade que o MNG oferece direto no console.
💾 Exemplo Prático: Configurando um NodePool no Karpenter
Para ilustrar a flexibilidade do Karpenter, veja abaixo um exemplo clássico de configuração de um manifesto de NodePool. Repare como nós não travamos um tamanho de máquina, mas sim as regras do jogo:
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: ecom-aplicacoes
spec:
template:
spec:
requirements:
# O Karpenter pode escolher arquiteturas Intel (amd64) ou ARM (arm64)
– key: kubernetes.io/arch
operator: In
values: [“amd64”, “arm64”]
# Ele tem liberdade para transitar entre instâncias Spot e On-Demand
– key: karpenter.sh/capacity-type
operator: In
values: [“on-demand”, “spot”]
# Restringimos apenas as famílias de instâncias ideais para o projeto
– key: node.kubernetes.io/instance-type
operator: In
values: [“m5.large”, “m5.xlarge”, “c5.large”, “c5.xlarge”, “t3.medium”]
limits:
cpu: 1000
disruption:
# Ativa a consolidação nativa automática para economizar dinheiro
consolidationPolicy: WhenUnderutilized
expireAfter: 720h
5.Qual estratégia adotar?
Não há dúvidas de que o Karpenter mudou drasticamente as regras do jogo de infraestrutura e FinOps no ecossistema AWS. Sua velocidade e flexibilidade entregam a elasticidade que ambientes modernos de microsserviços exigem, cortando desperdícios financeiros de forma agressiva.
No entanto, o Managed Node Groups ainda tem o seu valor devido à sua estabilidade imbatível e facilidade de gerenciamento de ciclo de vida.
Uma excelente prática de mercado adota um modelo híbrido:
Mantenha um MNG pequeno e fixo com instâncias On-Demand apenas para rodar os componentes vitais do cluster (como o CoreDNS, o próprio Controller do Karpenter e ferramentas de monitoramento).
Deixe toda a flutuação e carga das suas aplicações de e-commerce na mão do Karpenter, permitindo que ele crie e destrua instâncias gigantes ou do tipo Spot de forma dinâmica.
Combinando o melhor dos dois mundos, sua infraestrutura ganha resiliência, velocidade de resposta a picos de tráfego e uma eficiência de custos que vai deixar o time de FinOps muito feliz.
