Graviton ou x86 no EKS: quando a migração para arm64 compensa

Instâncias Graviton, baseadas em processadores arm64 da AWS, costumam ter preço por hora menor que as equivalentes em x86, e a AWS divulga também uma relação preço-desempenho melhor. A pergunta que importa não é se o Graviton é mais barato na tabela, e sim quanto do seu cluster consegue rodar nele sem esforço desproporcional.

O que muda na prática

• Arquitetura da imagem. Uma imagem só roda em arm64 se tiver essa variante. Imagens com manifest multi-arquitetura funcionam nos dois tipos de nó, e imagens só amd64 falham ao iniciar em um nó arm64.
• Dependências nativas. Linguagens como Go, Java, Node.js e Python costumam rodar sem mudança, mas bibliotecas com código nativo, binários baixados no build e imagens de terceiros só amd64 precisam de verificação.
• Pipeline de build. É preciso construir imagens para as duas arquiteturas, por exemplo com docker buildx, e ter runners de CI que suportem isso.
• Agendamento. O rótulo kubernetes.io/arch diz ao scheduler onde cada pod pode rodar.

O que costuma bloquear

1. Imagens de terceiros só amd64, como agentes de segurança, sidecars e ferramentas legadas.
2. Binários e dependências nativas sem build para arm64.
3. Software com licença ou suporte amarrado a x86.
4. Pipelines de build que só produzem amd64, o que é o bloqueio mais fácil de resolver.

Para saber quais workloads do seu cluster estão nessa situação, o graviton-readiness lê os manifests e, com --check-images, o manifest de cada imagem, e separa o que está pronto do que não foi verificado.

Um canário com Karpenter

1. Faça o inventário com o graviton-readiness e escolha 1 ou 2 serviços sem dependências nativas.
2. Construa imagens multi-arquitetura para eles.
3. Crie um NodePool arm64 com taint, para que só os pods que tolerarem o taint caiam ali. O gerador de NodePool ajuda a montar o requisito de arquitetura.
4. Compare por algumas semanas: latência p95, taxa de erro, uso de CPU e custo por requisição, nos dois tipos de nó.
5. Expanda por etapas, e só então misture amd64 e arm64 no mesmo NodePool.

Evite liberar arm64 em um NodePool geral antes de ter certeza de que todas as imagens suportam essa arquitetura. Um pod com imagem só amd64 em nó arm64 vira falha de inicialização, não economia.

Como medir o ganho

O desconto por hora não é o resultado. Meça custo por requisição ou por unidade de trabalho, porque o desempenho por vCPU pode ser diferente do x86 para a sua carga. Se o serviço precisar de mais réplicas em arm64, parte da economia desaparece. Se precisar de menos, ela aumenta.

Como isso conversa com compromisso

Os Compute Savings Plans valem para qualquer família de instância, então uma migração para Graviton não deixa o compromisso sem uso. Já um EC2 Instance Savings Plan fica preso a uma família: antes de migrar, veja se há compromisso apontado para x86. Mais detalhes em Savings Plans ou Reserved Instances. O Spot também está disponível em instâncias Graviton, e a lógica de combinação está em Spot ou Savings Plans.

Quando ficar em x86

• Quando o custo de portar uma dependência é maior que a economia esperada.
• Quando um componente crítico só existe em amd64 e não há alternativa.
• Quando o serviço é pequeno e a economia absoluta não paga o esforço de testar e manter dois alvos de build.

Para estimar

A calculadora de economia inclui o efeito de Graviton junto com rightsizing, Spot e desligamento fora do horário. Os números são estimativas, e a medição real depende dos seus workloads. Se quiser apoio para inventariar, fazer o canário e medir no seu ambiente, o assessment de eficiência é o ponto de partida.