Amazon EKS Auto Mode e Karpenter ganham suporte a Dynamic Resource Allocation

O que mudou

O Amazon Elastic Kubernetes Service (EKS) Auto Mode e o Karpenter agora suportam Dynamic Resource Allocation (DRA) para dispositivos NVIDIA GPU e Elastic Fabric Adapter (EFA), segundo anúncio da AWS publicado em 9 de novembro de 2026 no What's New.

Antes do DRA, pedir GPU num Pod significava declarar um recurso genérico como nvidia.com/gpu: 1 e torcer para o scheduler encontrar um nó compatível. Com DRA, quem opera o cluster define objetos ResourceClaim ou ResourceClaimTemplate descrevendo exatamente que dispositivo o workload precisa: modelo de GPU, arquitetura, ou outros atributos do hardware.

Para treinamento distribuído e inferência de larga escala, isso permite declarar GPU e EFA alinhados por PCIe, garantindo que a placa de rede fique fisicamente próxima da GPU que ela alimenta, o que importa para latência em jobs multi-nó. O workload referencia esses objetos DRA na sua configuração, e o Karpenter calcula e lança automaticamente a instância EC2 de menor custo que atende aos requisitos.

No Amazon EKS Auto Mode, o driver DRA da NVIDIA e o driver DRA de EFA (chamado DRANET) já vêm embutidos: não é preciso instalar nem gerenciar esses componentes à parte. Basta declarar os objetos DRA e referenciá-los nos workloads. A AWS também adicionou uma proteção automática: o EKS Auto Mode impede que workloads usando DRA e workloads usando o device plugin tradicional, para o mesmo tipo de dispositivo, rodem no mesmo nó, evitando oversubscription silenciosa durante a migração entre os dois modelos.

Onde está disponível

O suporte a DRA no EKS Auto Mode e no Karpenter está disponível em todas as Regiões da AWS, exceto AWS GovCloud (US) e as Regiões da China. Isso inclui a região América do Sul (São Paulo), sa-east-1, já que ela não está na lista de exceções.

Há uma diferença de versão do Kubernetes entre os dois caminhos. No Karpenter standalone (fora do Auto Mode), o DRA funciona em qualquer versão do Kubernetes suportada. Já no EKS Auto Mode, o recurso exige Kubernetes 1.36 ou mais recente, então clusters em versões anteriores do Auto Mode precisam de upgrade antes de usar o recurso.

Quanto custa

A fonte não traz um preço separado para o DRA em si, e isso faz sentido: DRA é uma extensão da API do Kubernetes para descrever e alocar dispositivos, não um serviço gerenciado cobrado à parte. O que continua sendo cobrado, como antes, são as instâncias EC2 com GPU ou EFA que o Karpenter provisiona (famílias como P5 ou G6, por exemplo) e a tarifa do cluster EKS.

Na prática, o ganho financeiro do DRA não aparece como linha nova na fatura: ele aparece como redução de ociosidade, porque a alocação mais precisa por atributo (em vez de contagem bruta de GPUs) tende a evitar que instâncias caras fiquem reservadas para workloads que não as usam por inteiro.

Como começar

Para quem já roda EKS Auto Mode, o primeiro passo é confirmar a versão do cluster: é preciso Kubernetes 1.36 ou superior. Depois, o fluxo de trabalho segue o padrão da API nativa de DRA do Kubernetes:

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
  name: gpu-claim-template
spec:
  spec:
    devices:
      requests:
        - name: gpu
          deviceClassName: gpu.nvidia.com

O Pod referencia esse template no campo resourceClaims da sua especificação. O Karpenter observa os requisitos declarados e escolhe a instância EC2 de menor custo que atenda ao atributo pedido, sem que o time precise manter NodePools separados por modelo de GPU ou taints customizados para segregar hardware.

A documentação de DRA no Amazon EKS User Guide e a documentação do Karpenter, citadas no próprio anúncio, trazem o detalhamento completo da sintaxe de ResourceClaim e dos atributos suportados por driver.

O que muda para quem já usa

Para quem arquiteta e opera cluster EKS com workloads de GPU hoje, o impacto prático está em três frentes. Primeiro, cai a necessidade de segmentação manual de node pools por tipo de GPU: hoje é comum manter NodePools distintos com labels e taints só para garantir que o Pod certo caia na GPU certa, e o DRA move essa lógica para a declaração do próprio workload.

Segundo, o alinhamento PCIe entre GPU e EFA deixa de ser um ajuste artesanal de afinidade de nó. Isso importa especialmente para quem roda treinamento distribuído multi-nó, onde latência de rede entre GPUs é fator direto de throughput do job.

Terceiro, a migração de device plugin para DRA precisa de atenção: embora o EKS Auto Mode bloqueie automaticamente a mistura dos dois modelos num mesmo nó para o mesmo tipo de dispositivo, times que têm workloads de produção em GPU devem validar em ambiente de staging antes de migrar a frota inteira, já que mudar de nvidia.com/gpu para ResourceClaim altera a forma como o scheduler enxerga o recurso. Quem ainda está em Kubernetes anterior a 1.36 no Auto Mode não tem acesso ao recurso até concluir o upgrade de versão do cluster.

Fonte: AWS What's New