EKS Auto Mode x Karpenter: três mudanças de outubro que pesam mais que a taxa de 12%

Quem decide entre EKS Auto Mode e Karpenter self-managed costuma resolver tudo em um número: a taxa de gerenciamento do Auto Mode, que nos exemplos públicos da AWS para a região Oregon é exatamente 12% sobre o preço On-Demand. Spot, Reserved Instances e Savings Plans continuam descontando a linha de EC2. Não descontam a linha do Auto Mode. Isso ainda é verdade, mas ficou incompleto depois de três mudanças publicadas em outubro de 2026: suporte a Gateway API no load balancer controller gerenciado, Balanced como novo padrão de consolidação no EKS 1.37 e o campo advancedCompute no NodeClass para ajustar kubelet e sysctl sem launch template.

A análise é do engenheiro Sarath Krishna Prasad, publicada no Towards AWS, cruzando documentação, release notes e a página de preços da AWS, com YAML validado localmente contra os schemas publicados.

Duas arquiteturas, uma API parecida

Auto Mode não é "EKS sem nodes". A AWS roda um controlador baseado em Karpenter mais rede, DNS, armazenamento em bloco, load balancing, Pod Identity e monitoramento de nodes como capacidades gerenciadas. Os nodes são instâncias EC2 gerenciadas rodando Bottlerocket travado: SELinux em modo enforcing, root somente leitura, sem SSH ou SSM, IMDSv2 com hop limit 1 e vida útil máxima de 21 dias.

O Karpenter self-managed compartilha a API NodePool (karpenter.sh/v1), mas quem opera o cluster é dono do controlador, do EC2NodeClass (karpenter.k8s.aws/v1), da escolha de AMI, da fila de interrupção de Spot e do upgrade do chart. A API compartilhada é o motivo de tanta gente tratar os dois como intercambiáveis. Os prefixos de NodeClass e de labels são o motivo de o copia-e-cola falhar:

# Auto Mode
nodeClassRef:
  group: eks.amazonaws.com
  kind: NodeClass
  name: private-compute
requirements:
  - key: eks.amazonaws.com/instance-category
    operator: In
    values: ["c", "m", "r"]

# Karpenter self-managed
nodeClassRef:
  group: karpenter.k8s.aws
  kind: EC2NodeClass
  name: default
requirements:
  - key: karpenter.k8s.aws/instance-category
    operator: In
    values: ["c", "m", "r"]

Se o repositório GitOps ainda usa karpenter.k8s.aws/instance-family, o Auto Mode simplesmente não entende a label e não provisiona o node certo.

Mudança 1: Gateway API sem instalar outro controlador

Em 26 de outubro (divulgado no What's New em 28 de outubro), o EKS Auto Mode passou a suportar a Kubernetes Gateway API. A ativação é via kubernetesNetworkConfig.elasticLoadBalancing.gatewayApi.crds.managed, escolhendo se a AWS ou o time operador é dono das CRDs, e apontando a GatewayClass para um de dois controladores: eks.amazonaws.com/gateway-alb para L7 ou eks.amazonaws.com/gateway-nlb para L4.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eks-auto-alb
spec:
  controllerName: eks.amazonaws.com/gateway-alb

Ingress e Service do tipo LoadBalancer continuam funcionando como antes, e os recursos de extensão (TargetGroupConfiguration, LoadBalancerConfiguration, ListenerRuleConfiguration) são os mesmos que o AWS Load Balancer Controller já usa. Para quem planejava migrar de Ingress para Gateway API, o Auto Mode entrega o caminho gerenciado de ALB/NLB sem adicionar mais um controlador para operar e atualizar. No Karpenter self-managed, essa peça (Load Balancer Controller, Envoy Gateway, Istio) continua sendo responsabilidade de quem mantém o cluster. A Gateway API em si não é exclusiva do Auto Mode; a ausência de um controlador separado, sim.

Mudança 2: Balanced vira o padrão de criação no EKS 1.37

A partir do EKS 1.37 (anunciado para NodePools do Auto Mode em 1º de outubro), novos NodePools passam a usar consolidationPolicy: Balanced em vez de WhenEmptyOrUnderutilized.

Na prática, WhenEmptyOrUnderutilized reorganiza o cluster por economias de poucos centavos por hora. Balanced pesa a economia contra o custo da disrupção e ignora os ganhos marginais, o que costuma ser o comportamento desejável em produção.

A pegadinha é típica de GitOps: o padrão só vale na criação do objeto. Deixar o campo consolidationPolicy fora do manifesto faz o objeto 1.37 mostrar Balanced em runtime enquanto o Git não tem nada escrito. Recriar o NodePool (hard-refresh no Argo CD, recreate no Flux, bootstrap de cluster novo) muda o comportamento mesmo com o YAML "sem alteração". Os pools embutidos general-purpose e system são reconciliados para Balanced de hora em hora e não aceitam override in-place; quem precisa da agressividade antiga tem que apontar para um NodePool customizado com WhenEmptyOrUnderutilized explícito.

disruption:
  consolidationPolicy: Balanced
  consolidateAfter: 30s

O upstream do Karpenter (v1.14) também ganhou Balanced, então não é exclusividade do Auto Mode. O que é exclusivo é a combinação dos pools gerenciados embutidos com o padrão de criação interagindo mal com a semântica de recreate do GitOps.

Mudança 3: advancedCompute fecha parte da reclamação sobre kubelet

Em 12 de outubro, o Auto Mode NodeClass ganhou spec.advancedCompute. Dá para declarar configurações de kubelet (namespaces de usuário, thresholds de eviction, rotação de log de container), um conjunto suportado de sysctls e pré-alocação de hugepages. O Auto Mode valida tudo no boot e marca os nodes como drifted quando a configuração muda, para que a substituição já saia com o ajuste novo.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: example
spec:
  subnetSelectorTerms:
    - tags:
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        aws:eks:cluster-name: example
  advancedCompute:
    kubelet:
      evictionHard:
        memory.available: 200Mi
        nodefs.available: 10%
      containerLogMaxSize: 10Mi

Isso não devolve AMI customizada, SSH ou agente arbitrário rodando no host. Mas tira da mesa a reclamação de "não dá para ajustar eviction sem launch template". Módulo de kernel, Windows, agente que assume host gravável ou AMI certificada continuam bloqueando o Auto Mode; eviction de kubelet ligeiramente diferente, não. Vale o aviso: mudar kubelet ou sysctl num NodeClass existente causa drift nos nodes. Definir um disruption budget no NodePool antes dessa mudança evita substituir mais nodes do que o planejado.

A taxa, sem floreio

Nos exemplos públicos de preço da AWS para Oregon (Exemplo 4 da página de pricing do EKS):

A AWS não chama contratualmente de percentual fixo, e vale puxar a taxa por tipo de instância na própria região; mas nos exemplos publicados o número bate exatamente em 12%. A cobrança do Auto Mode é independente da opção de compra do EC2: com Spot ilustrativo a 65% de desconto, aqueles 12% sobre o On-Demand viram algo perto de 34% sobre a linha de EC2 já descontada, para a mesma m5a.2xlarge.

É possível misturar nodes Auto Mode com managed node groups no mesmo cluster e pagar a taxa só na capacidade Auto Mode: essa é a forma de migração que a AWS prevê, e também como manter uma ilha de AMI customizada para os DaemonSets mais teimosos.

A taxa nunca foi a história inteira.

The fee was never the whole story.Sarath Krishna Prasad, autor no Towards AWS

O que muda na operação do dia a dia

Os padrões de segurança do Auto Mode afetam mais a resposta a incidente do que qualquer slide de arquitetura:

• IMDSv2 obrigatório com hop limit 1: pods sem hostNetwork não alcançam as credenciais do node via IMDS, então o caminho é Pod Identity ou IRSA.
• Sem SSH nem SSM no node: debug passa por ephemeral containers, NodeDiagnostic, console output e os logs vendidos pelo Auto Mode.
• Nodes expiram (pools embutidos por volta de 14 dias) e são forçados a sair aos 21 dias mesmo que um PodDisruptionBudget tente segurar o mundo.
• Add-ons que antes rodavam como pod (VPC CNI, kube-proxy, CoreDNS, EBS CSI, load balancer controller, Karpenter, Pod Identity agent) passam a ser capacidades gerenciadas, com menos visibilidade em kubectl get pods -n kube-system. Troubleshooting às vezes vira caso de suporte AWS mais CloudWatch, não kubectl logs.

Se o runbook da equipe começa com "dar SSM no node", adotar Auto Mode é mudança de processo, não só de checkbox.

Quando reabrir a conta e quando não vale

Faz sentido reconsiderar o Auto Mode quando a maioria destes pontos é verdadeira:

• Não há dependência de AMI customizada ou certificada
• Os agentes de segurança funcionam como DaemonSet normal sobre Bottlerocket travado, ou o fornecedor já suporta esse modelo
• Gateway API em ALB/NLB é desejada sem operar mais um controlador
• A equipe estava prestes a adotar Karpenter e prefere não ser dona do controlador, da fila de interrupção e do drift de AMI
• Trocar node toda semana (drift de AMI) e a cada 21 dias (vida máxima) é aceitável com PodDisruptionBudgets reais

Faz mais sentido ficar no Karpenter self-managed (ou em managed node groups) quando:

• O compute já está otimizado em Spot/Savings Plan e bem empacotado, tornando a taxa um prêmio relativo alto sobre um trabalho que já foi automatizado
• É preciso Windows, módulo de kernel customizado ou agente que assume host gravável
• A cadeia de suprimento da AMI precisa ser propriedade do próprio time
• É necessário log completo do autoscaler e do load balancer controller como pods dentro do cluster

A resposta híbrida, Auto Mode para a maioria das cargas chatas e uma ilha self-managed ou de managed node group para o que ainda precisa de host de verdade, costuma ser a mais realista para quem já opera cluster em produção. O próprio autor da análise documenta que o que checou foi parsing de YAML contra os schemas e recomputação das razões de preço; latência real de provisionamento, comportamento de interrupção Spot na conta específica e compatibilidade de DaemonSet com um agente de fornecedor continuam exigindo um piloto antes de qualquer decisão definitiva.

Fonte: Medium — tag aws