Kubernetes costuma ser associado à promessa de elasticidade. Em ambientes grandes, a experiência real frequentemente segue outro caminho, com picos de demanda que levam minutos para escalar e longos períodos pagando por capacidade ociosa. O problema não está no Kubernetes em si. Ele está no modelo de provisionamento adotado para sustentar o cluster em escala.
Entretanto, há um movimento dentro da AWS para enfrentar essa situação. A discussão recente envolve migrações reais em larga escala, como o caso da Salesforce, e avanços no EKS Auto Mode, combinando a série Graviton e instâncias Spot para otimizar custo e operação. O ponto comum dessas iniciativas é tratar a capacidade como decisão de arquitetura em vez de ajuste reativo.
O que quebra no modelo tradicional
Durante anos, o padrão dominante no Amazon EKS combinou Auto Scaling Groups com o Cluster Autoscaler. Esse modelo funciona, inclusive, em produção. Em sistemas grandes, alguns sintomas começam a aparecer de forma consistente, como no exemplo a seguir.
A Salesforce operava mais de mil clusters Kubernetes na Amazon EKS. Cada cluster dependia de múltiplos grupos de nós, com configurações diferentes, tamanhos fixos e políticas conservadoras de redução de escala. O resultado foi uma camada operacional difícil de manter. Criar ou ajustar grupos de nós exigia coordenação manual. Escalar para picos de tráfego levava vários minutos e parte da capacidade permanecia ociosa por longos períodos, enquanto Workloads intensivos em memória ou com requisitos específicos sofriam para encontrar encaixe adequado.
Com isso, o autoscaling passava a impor limites à própria elasticidade do cluster. A operação também ficava distante dos times de aplicação, já que qualquer ajuste exigia intervenção centralizada.
A principal mudança acontece quando decide-se usar um modelo que deixa de girar em torno de grupos de nós e passa a olhar diretamente para os pods. O Karpenter adota exatamente esse princípio. Em vez de tentar expandir estruturas pré-definidas, ele provisiona nós sob medida para os pods que precisam ser agendados naquele momento. Isso reduz o tempo de escala de minutos para segundos, melhora o uso de CPU e memória e diminui o número de decisões manuais necessárias para manter o ambiente saudável.
Segundo a Datadog, o uso de nós provisionados pelo Karpenter cresceu 22% nos últimos dois anos, um sinal de adoção crescente desse modelo em ambientes reais de produção. Esse movimento também traz novos riscos, como interrupções mais frequentes se políticas não forem bem definidas. A diferença está no controle. Quando o provisionamento se baseia nos requisitos dos pods, o comportamento do cluster passa a refletir com mais fidelidade a demanda real das aplicações.
O novo triângulo de eficiência: Auto Mode, Graviton e Spot
Com o modelo de provisionamento mais flexível, surge espaço para capturar eficiência adicional. É nesse ponto que o EKS Auto Mode se conecta ao uso da série Graviton e instâncias Spot.
O Auto Mode simplifica a operação do cluster ao assumir tarefas como criação, substituição e consolidação de nós. Ele cria uma base estável para decisões de capacidade mais sofisticadas. Sobre essa base, o uso de processadores AWS Graviton entrega melhor relação custo-benefício e menor consumo de energia para workloads compatíveis. Em paralelo, instâncias Spot permitem reduzir custos de forma agressiva em cargas elásticas.
Para ter maturidade, é necessário ter guardrails. Spot não serve para tudo. Cargas com estado crítico e componentes sensíveis à interrupção precisam permanecer em On-Demand. ARM (arquitetura da série Graviton) também não é mágica. É necessário testar as imagens, entender as dependências e o comportamento geral em produção. É necessário calibrar os limites de latência, erro ou throughput para otimizar os custos e criar alertas para não transformar a fatura em um susto no final do mês.
Processo robusto é o segredo para seguir essa arquitetura. É necessário fazer uma classificação consciente do workload. Idealmente os times devem escolher começar por um cluster ou uma família de serviços para medir e migrar e usar uma janela controlada de testes com fácil rollback.
Conclusão
Em ambientes EKS com muitos nós, tratar capacidade como parte fundamental do design se torna inevitável. Ao usar Karpenter, podemos mudar o modelo de provisionamento. Com o Auto Mode, podemos reduzir o esforço operacional. E se não estiver usando Graviton + Spot, usá-los permite diminuir custos se apropriando da eficiência do ARM e utilizando máquinas Spot, não dedicadas. Em qual desses pontos sua operação encontra hoje mais fricção: na operação diária, na previsibilidade de custo ou no tempo de escala?
