**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# Analisar as notas de release do Modo automático do EKS
Esta página documenta as atualizações do Modo automático do Amazon EKS. É possível verificar periodicamente esta página para ver anúncios sobre recursos, correções de erros, problemas conhecidos e funcionalidades obsoletas.
Para receber notificações de todas as alterações do arquivo de origem nesta página específica da documentação, você pode se inscrever no seguinte URL com um leitor de RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 17 de agosto de 2026
**Documentação**: foram adicionadas instruções para conceder aos controladores gerenciados do Modo Automático do EKS mais RBAC do Kubernetes por meio do grupo `eks:managed` na entrada de acesso `AWSServiceRoleForAmazonEKS` criada automaticamente. Isso desbloqueia casos de uso, como conceder ao controlador do balanceador de carga acesso a um `Secret` específico para que ele possa resolver a configuração do OIDC em um ALB `Ingress`. Para obter mais informações, consulte [Conceda RBAC do Kubernetes adicional aos controladores gerenciados do Modo Automático do EKS](auto-managed-rbac.md) e o passo a passo em [Conceda ao controlador do balanceador de carga do Modo Automático do EKS acesso a um segredo específico](auto-managed-rbac-example.md).
## 12 de agosto de 2026
**Recurso**: o controlador de balanceador de carga do Modo Automático do Amazon EKS agora é compatível com recursos do AWS Load Balancer Controller até a v3.4. Observe que o Gateway API ainda não é compatível.
+ Validação do JWT para Ingress: valide os JSON Web Tokens (JWTs) no nível da regra do receptor do Application Load Balancer (ALB) antes que as solicitações cheguem ao seu backend, por meio de uma nova ação no nível do Ingress. Para obter mais informações, consulte [O Application Load Balancer agora oferece suporte ao fluxo de credenciais do cliente com verificação JWT](https://aws.amazon.com/about-aws/whats-new/2025/11/application-load-balancer-jwt-verification/).
+ Grupos-alvo ponderados do Network Load Balancer (NLB): distribua o tráfego em vários grupos-alvo por peso em um serviço NLB. Isso é compatível com padrões de implantação azul/verde e canário, incluindo um peso de 0 quando pelo menos um outro grupo-alvo tem um peso diferente de zero. Para obter mais informações, consulte [Network Load Balancers now support Weighted Target Groups](https://aws.amazon.com/blogs/networking-and-content-delivery/network-load-balancers-now-support-weighted-target-groups/).
+ Eventos de reconciliação TargetGroupBinding: o Amazon EKS agora emite eventos do Kubernetes em caso de falhas de reconciliação de TargetGroupBinding, tornando os problemas de registro do alvo visíveis por meio de `kubectl describe` em vez de apenas pelos logs do controlador.
+ Ordem de sub-rede preservada: a anotação `aws-load-balancer-subnets` agora respeita a ordem especificada, em vez de reordenar as sub-redes internamente.
+ Balanceamento de carga entre zonas para o ALB: agora você pode desabilitar explicitamente o balanceamento de carga entre zonas nos Application Load Balancers.
## 5 de agosto de 2026
**Funcionalidade**: o controlador do balanceador de carga do Modo Automático do Amazon EKS agora é compatível com grupos de destino de vários clusters, alinhando-se ao comportamento do AWS Load Balancer Controller. Com esse recurso, você pode compartilhar o mesmo ARN do grupo de destino em vários recursos `TargetGroupBinding` para que um único grupo de destino possa atender a vários clusters do Kubernetes (na mesma VPC) ou aceitar destinos de outras fontes. Para obter mais informações, consulte [Compartilhar grupos de destino de vários clusters](auto-multi-cluster-target-groups.md).
## 27 de julho de 2026
**Funcionalidade**: o controlador do balanceador de carga do Modo Automático do Amazon Elastic Kubernetes Service (Amazon EKS) agora é compatível com os recursos do AWS Load Balancer Controller v2.13 e v2.14.
+ Regravação de URL para o Application Load Balancer (ALB): agora você pode transformar URLs de requisição e cabeçalhos de host antes que as requisições cheguem aos seus serviços de backend, sem alterar sua aplicação. Para obter mais informações, consulte [Introducing URL and host header rewrite with AWS Application Load Balancers](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-url-and-host-header-rewrite-with-aws-application-load-balancers/).
+ PrefixListsIDs e LoadBalancerName em IngressClassParams: agora você pode definir listas de prefixos de grupos de segurança e um nome de balanceador de carga personalizado para seu Application Load Balancer. Ambos são aceitos como anotações do Ingress e como campos em IngressClassParams (prefixListsIDs e loadBalancerName). Quando definida em IngressClassParams, a configuração se aplica a todos os Ingresses na IngressClass. Você não precisa mais anotar cada recurso do Ingress individualmente.
+ NLB de frontend para Ingress: agora você pode colocar um Network Load Balancer (NLB) na frente de um Application Load Balancer. Isso associa endereços IP estáticos do NLB e o AWS PrivateLink com os recursos de roteamento de camada 7 do ALB. Habilite esse recurso com a anotação alb.ingress.kubernetes.io/enable-frontend-nlb. Para obter mais informações, consulte [Application Load Balancer-type Target Group for Network Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/).
+ Compatibilidade com o receptor TCP\_UDP: os serviços do NLB agora podem usar receptores TCP\_UDP, que permitem tráfego TCP e UDP na mesma porta. Habilite esse recurso com a anotação service.beta.kubernetes.io/aws-load-balancer-enable-tcp-udp-listener.
+ Protocolo proxy por grupo de destino: agora você pode configurar os cabeçalhos do Proxy Protocol v2 no nível do grupo de destino individual usando a anotação service.beta.kubernetes.io/aws-load-balancer-proxy-protocol-per-target-group em vez de aplicar a configuração a todos os grupos de destino de maneira uniforme.
+ Campo targetType em IngressClassParams: agora você pode definir o tipo de destino padrão (instância ou IP) diretamente em IngressClassParams, eliminando a necessidade de anotar cada recurso do Ingress individualmente.
+ Descoberta de sub-rede por acessibilidade: a seleção de sub-rede não exige mais estritamente as tags kubernetes.io/role. O controlador agora recorre à análise de acessibilidade baseada na tabela de rotas quando as tags estão ausentes. Atualmente, o controlador não oferece suporte a esse fallback de balanceadores de carga com um tipo de endereço IP de pilha dupla.
+ Compatibilidade com o Gerenciador de endereços IP (IPAM) IPv4 para o ALB: um ALB voltado para a internet agora pode extrair seus endereços IPv4 públicos de um grupo do IPAM da Amazon Virtual Private Cloud (Amazon VPC) em vez de intervalos de endereços gerenciados pela AWS. Isso fornece blocos de endereços IP previsíveis para listas de permissões. Especifique o grupo com a anotação alb.ingress.kubernetes.io/ipam-ipv4-pool-id. Para obter mais informações, consulte [Simplify ALB’s public IP address assignment with VPC IPAM](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-albs-public-ip-address-assignment-with-vpc-ipam/).
**Recurso**: foi adicionada a política de consolidação `Balanced` para NodePools do Modo Automático do EKS. A configuração `spec.disruption.consolidationPolicy: Balanced` pontua cada ação de consolidação ao comparar a economia de custos de computação em relação ao custo de interrupção. Ela ignora ações em que a interrupção supera a economia. Se você atualmente usa `WhenEmpty`, pode mudar para `Balanced` a fim de obter a economia de custos da consolidação. Se você atualmente usa `WhenEmptyOrUnderutilized`, pode mudar para `Balanced` para eliminar a interrupção de pods a fim de obter benefícios marginais. `WhenEmpty` e `WhenEmptyOrUnderutilized` permanecem inalterados, e os NodePools existentes mantêm seu comportamento atual. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md) e [Interrupção](https://karpenter.sh/docs/concepts/disruption/) na documentação do Karpenter.
## 21 de julho de 2026
**Recurso**: foi adicionado suporte para configuração de interface de rede estática no NodeClass. Você agora pode configurar interfaces de rede do Elastic Fabric Adapter (EFA) usando `advancedNetworking.networkInterfaces` para provisionamento de capacidade dinâmica e estática, habilitando nós prontos para EFA para workloads distribuídas de treinamento e inferência. Para obter mais informações, consulte [Configuração da interface de rede estática](create-node-class.md#static-network-interfaces).
## 30 de junho de 2026
**Recurso**: o controlador de balanceador de carga do Modo Automático do EKS agora é compatível com recursos do AWS Load Balancer Controller v2.10, v2.11 e v2.12.
Do upstream v2.12.0:
+ Gerenciamento de prioridades das regras do receptor: o controlador agora pode definir e reordenar explicitamente as prioridades das regras do receptor, resolvendo conflitos de ordenação quando várias regras do Ingress têm como destino o mesmo receptor
Do upstream v2.11.0:
+ Reserva de unidades de capacidade de balanceadores de carga (LCU): agora você pode reservar unidades de capacidade nos Application Load Balancers (ALBs) e nos Network Load Balancers (NLBs), garantindo desempenho previsível para workloads com padrões de tráfego conhecidos
Do upstream v2.10.0:
+ Proteção Shield Avançado para o ALB: os recursos do ALB agora podem ser protegidos com o AWS AWS Shield Avançado por meio da anotação alb.ingress.kubernetes.io/shield-advanced-protection
+ Traga seu próprio TargetGroupBinding personalizado: agora você pode referenciar grupos de destino preexistentes não criados pelo controlador, permitindo a integração com a infraestrutura gerenciada externamente
+ Compatibilidade com o UDP para NLB de pilha dupla em clusters IPv6: os serviços do NLB em clusters IPv6 agora são compatíveis com receptores do protocolo UDP
+ Atributos de receptores HTTP e HTTPS do ALB: controle refinado sobre atributos em nível de receptor (por exemplo, comportamento de roteamento, modificações de cabeçalho) por meio de anotações
### Atualização nas políticas gerenciadas
A AWS atualizou as políticas AmazonEKSServiceRolePolicy e AmazonEKSLoadBalancingPolicy para oferecer suporte a esses novos recursos.
### Ação necessária para clientes que usam políticas personalizadas do IAM
Se você estiver fornecendo sua própria política personalizada do IAM para o perfil de cluster do Modo Automático do EKS em vez de usar a política AmazonEKSLoadBalancingPolicy gerenciada pela AWS, você deve garantir que sua política inclua as permissões listadas acima. A falha em atualizar sua política personalizada resultará em erros de acesso negado ao usar os novos recursos.
Para verificar a paridade, compare sua política personalizada com a [versão mais recente do AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html).
Especificamente, garanta que sua política inclua:
+ elasticloadbalancing:ModifyCapacityReservation, elasticloadbalancing:ModifyIpPools, elasticloadbalancing:ModifyListenerAttributes e elasticloadbalancing:SetRulePriorities
+ ec2:DescribeIpamPools e ec2:DescribeRouteTables
+ shield:CreateProtection, shield:DeleteProtection e shield:TagResource
## 9 de junho de 2026
**Atributo**: adicionado o monitoramento de verificação de status da instância ao Modo Automático do EKS. O controlador de computação agora consulta o `DescribeInstanceStatus` do EC2 para detectar eventos de manutenção agendados e falhas na verificação de status de uma instância ou do sistema, substituindo automaticamente os nós não íntegros.
## 4 de junho de 2026
**Documentação**: adicionada orientação sobre controle de custos de computação no Modo Automático do EKS, incluindo como a consolidação funciona, o que a bloqueia e os padrões recomendados para workloads de picos elevados. Para obter mais informações, consulte [Otimização de custos do Modo Automático do EKS](auto-cost-control.md).
## 3 de junho de 2026
**Recurso**: foi adicionado suporte para reservas de capacidade sujeitas a interrupção no Modo Automático do EKS. Para obter mais informações, consulte [Controle da implantação de workloads em reservas de capacidade com o modo automático do EKS](auto-odcr.md).
## 5 de maio de 2026
**Atributo**: adição de suporte a grupos de posicionamento do EC2 no Modo Automático do EKS. Para obter mais informações, consulte [Especificação das classes de nós](create-node-class.md#auto-node-class-spec).
## 10 de abril de 2026
**Novos tipos de instância compatíveis**: p6-b200, p6-b300, p5e, p5en, trn2, hpc8a, x8aedz, x8i. Para ver a lista completa de instâncias compatíveis, consulte [Saiba mais sobre as instâncias gerenciadas do modo automático do Amazon EKS](automode-learn-instances.md).
## 2 de abril de 2026
**Tarefa**: a validação de execução a seco do NodeClass agora usará tipos de instância selecionados dinamicamente com base nos NodePools vinculados.
## 2 de fevereiro de 2026
**Atributo**: foi adicionado suporte para desabilitar o tráfego v4egress de pods IPv6 em clusters IPv6 de modo automático do EKS. Para obter mais informações, consulte [Desabilite a saída de IPv4 dos pods IPv6 em clusters de IPv6.](create-node-class.md#enableV4Egress).
## 19 de dezembro de 2025
**Atributo**: adicionada compatibilidade com o modo IP secundário que provisiona endereços IP secundários em vez de prefixos aos nós automáticos. O modo mantém um IP secundário como MinimalIPTarget e economiza recursos de IP para clientes que não precisam aquecer mais IPs ou prefixos secundários. Para obter mais informações, consulte [Especificação das classes de nós](create-node-class.md#auto-node-class-spec) e [Modo de IP secundário para pods](create-node-class.md#secondary-IP-mode).
## 19 de novembro de 2025
**Recurso**: habilitamos a disponibilização e a descompactação em paralelo de Seekable OCI (SOCI) para as famílias de instâncias G, P e Trn que contam com o armazenamento NVMe local. A disponibilização e o desempacotamento paralelos de SOCI são sempre usados para essas famílias de instâncias com o modo automático do EKS, e não são necessárias alterações de configuração para ativá-los. Para obter mais informações sobre o SOCI, consulte o [blog de lançamento](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/).
## 19 de novembro de 2025
**Recurso**: adicionamos suporte para grupos de nós de capacidade estática que mantêm um número fixo de nós. Para obter mais informações, consulte [Grupos de nós de capacidade estática no modo automático do EKS](auto-static-capacity.md).
## 23 de outubro de 2025
**Recurso:** os usuários com clusters em regiões dos EUA agora podem solicitar o uso de AMIs compatíveis com FIPS especificando `spec.advancedSecurity.fips` na definição de NodeClass.
## 1.º de outubro de 2025
**Recurso:** o modo automático do EKS agora fornece suporte para a implantação de nós em zonas locais da AWS. Para obter mais informações, consulte [Implantação de nós do modo automático do EKS em zonas locais](auto-local-zone.md).
## 30 de setembro de 2025
**Recurso:** adicionamos suporte para instanceProfile ao `spec.instanceProfile` da NodeClass, que é mutuamente exclusivo em relação ao campo `spec.role`.
## 29 de setembro de 2025
No momento, o DRA não é compatível com o modo automático do EKS.
## 10 de setembro de 2025
**Obrigação:** os eventos disparados pelo controlador de computação do modo automático do EKS agora usarão o nome `eks-auto-mode/compute` em vez de `karpenter`.
## 24 de agosto de 2025
**Correção de erro:** as VPCs que usavam um conjunto de opções DHCP com um nome de domínio personalizado contendo letras maiúsculas faziam com que os nós não conseguissem se juntar ao cluster devido à geração de um nome de host inválido. Isso foi resolvido e nomes de domínio com letras maiúsculas agora funcionam corretamente.
## 15 de agosto de 2025
**Correção de erro:** o Atendente de Identidade de Pods agora só escuta no endereço local do link IPv4 em um cluster de EKS IPv4 para evitar problemas em que o pod não consiga acessar o endereço IPv6.
## 6 de agosto de 2025
**Recurso:** adicionada nova configuração em `spec.advancedNetworking.associatePublicIPAddress` no NodeClass que pode ser usada para evitar que endereços IP públicos sejam atribuídos aos nós do modo automático do EKS
## 30 de junho de 2025
**Atributo:** o NodeClass do modo automático agora usa a chave do KMS personalizada configurada para criptografar o volume raiz somente para leitura da instância, além do volume de dados de leitura/gravação. Anteriormente, a chave do KMS personalizada era usada somente para criptografar o volume de dados.
## 20 de junho de 2025
**Recurso:** suporte para controlar a implantação de workloads em reservas de capacidade sob demanda (ODCRs) do EC2. Isso adiciona a chave opcional `capacityReservationSelectorTerms` ao NodeClass, permitindo que você controle explicitamente quais ODCRs suas workloads usam. Para obter mais informações, consulte [Controle da implantação de workloads em reservas de capacidade com o modo automático do EKS](auto-odcr.md).
## 13 de junho de 2025
**Recurso:** suporte para sub-redes de pod separadas no `NodeClass`. Isso adiciona as chaves opcionais `podSubnetSelectorTerms` e `podSecurityGroupSelectorTerms` para definir as sub-redes e os grupos de segurança para os pods. Para obter mais informações, consulte [Sub-redes e grupos de segurança separados para Pods](create-node-class.md#pod-subnet-selector).
## 30 de abril de 2025
**Recurso:** suporte para proxies de rede de encaminhamento no `NodeClass`. Isso adiciona a chave opcional `advancedNetworking` para configurar seu proxy HTTPS. Para obter mais informações, consulte [Especificação das classes de nós](create-node-class.md#auto-node-class-spec).
## 18 de abril de 2025
**Funcionalidade:** suporte para resolver domínios locais (normalmente reservados para DNS multicast) via DNS unicast.
## 11 de abril de 2025
**Funcionalidade:** adicionados `certificateBundles` e `ephemeralStorage.kmsKeyID` ao `NodeClass`. Para obter mais informações, consulte [Especificação das classes de nós](create-node-class.md#auto-node-class-spec).
**Funcionalidade:** velocidade de extração de imagens aprimorada, especialmente para tipos de instância com armazenamento de instância local que podem aproveitar a descompactação mais rápida da imagem.
**Correção de erro:** resolvida uma condição de corrida que causava FailedCreatePodSandBox , Error while dialing: dial tcp 127.0.0.1:50051: connect: a conexão, às vezes, não ocorria para a programação de pods para um nó imediatamente na inicialização.
## 04 de abril de 2025
**Funcionalidade:** aumento de `registryPullQPS` de 5 para 25 e de `registryBurst` de 10 para 50 para reduzir a controle de utilização de extração de imagens imposta pelo cliente (`Failed to pull image xyz: pull QPS exceeded`)
## 31 de março de 2025
**Correção de erro:** corrigiu um problema em que, se um pod central do DNS estivesse sendo executado em um nó do Modo automático, as consultas ao DNS dos pods no nó atingiriam esse pod central do DNS em vez do servidor DNS local do nó. As consultas ao DNS de pods em um nó do Modo automático sempre irão para o DNS local do nó.
## 21 de março de 2025
**Correção de erro:** os nós do Modo automático agora resolvem `kube-dns.kube-system.svc.cluster.local` corretamente quando não há um serviço de `kube-dns` instalado no cluster. Resolve o problema do GitHub [\#2546](https://github.com/aws/containers-roadmap/issues/2546).
## 14 de março de 2025
**Funcionalidade**: saída `IPv4` habilitada em clusters `IPv6`. O tráfego `IPv4` que sai dos clusters `IPv6` do Modo automático agora será convertido automaticamente para o endereço `v4` da ENI primária do nó.