**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.
# Saiba mais sobre as redes de VPC e sobre o balanceamento de carga no modo automático do EKS
Este tópico explica como configurar os recursos de balanceamento de carga e rede da Virtual Private Cloud (VPC) no Modo Automático do EKS. Embora o Modo Automático do EKS gerencie a maioria dos componentes de rede automaticamente, você ainda pode personalizar certos aspectos da configuração de rede do cluster por meio dos recursos do `NodeClass` e das anotações do balanceador de carga.
Quando você usa o Modo Automático do EKS, a AWS gerencia a configuração da interface de rede de contêineres (CNI) da VPC e o provisionamento de balanceador de carga para o cluster. Você pode influenciar os comportamentos de rede definindo objetos `NodeClass` e aplicando anotações específicas aos seus recursos de Service e Ingress, mantendo o modelo operacional automatizado fornecido pelo Modo Automático do EKS.
## Funcionalidade de redes
O modo automático do EKS oferece uma nova funcionalidade de redes para gerenciar a rede de nós e de pods. É possível configurá-la criando um objeto `NodeClass` no Kubernetes.
As opções de configuração para o plug-in CNI da AWS VPC anterior não se aplicarão ao modo automático do EKS.
### Configurar a rede com um `NodeClass`
O recurso `NodeClass` no Modo Automático do EKS possibilita a personalização de determinados aspectos dos recursos de redes. Por meio do `NodeClass`, você pode especificar seleções de grupos de segurança, controlar o posicionamento dos nós em sub-redes da VPC, definir políticas de SNAT, configurar políticas de rede e habilitar o registro em log de eventos de rede. Essa abordagem mantém o modelo operacional automatizado do Modo Automático do EKS e, ao mesmo tempo, fornece flexibilidade para a personalização da rede.
Você pode usar um `NodeClass` para:
+ Selecionar um grupo de segurança para nós
+ Controlar como os nós são posicionados nas sub-redes da VPC
+ Definir a política de SNAT do nó como `random` ou `disabled`
+ Habilitar as *políticas de rede* do Kubernetes, incluindo:
+ Definir a política de rede como Negar por padrão ou Permitir por padrão
+ Habilite o registro em log de eventos de rede em um arquivo.
+ Isole o tráfego de pods do tráfego de nós anexando os pods a sub-redes diferentes.
Saiba como [Criar um NodeClass do Amazon EKS](create-node-class.md).
### Considerações
Modo Automático do EKS é compatível com:
+ Políticas de rede do EKS.
+ As opções `HostPort` e `HostNetwork` para pods do Kubernetes.
+ Pods e nós em sub-redes públicas ou privadas.
+ Armazenamento em cache de consultas ao DNS no nó.
O Modo Automático do EKS **não** é compatível com:
+ Grupos de segurança por pod (SGPP). Para aplicar grupos de segurança distintos ao tráfego do Pod no Modo Automático, use `podSecurityGroupSelectorTerms` no `NodeClass` em vez disso. Para obter mais informações, consulte [Sub-redes e grupos de segurança separados para Pods](create-node-class.md#pod-subnet-selector).
+ Rede personalizada no `ENIConfig`. Você pode colocar pods em várias sub-redes ou isolá-los exclusivamente do tráfego de nós com [Sub-redes e grupos de segurança separados para Pods](create-node-class.md#pod-subnet-selector).
+ Configurações de IP warm, prefixo warm e ENI warm.
+ Configuração de destinos de IP mínimos.
+ Outras configurações compatíveis com a CNI de código aberto da AWS VPC.
+ Configurações de política de rede, como personalização do temporizador conntrack (o padrão é 300 s).
+ Exportação de logs de eventos de rede para o CloudWatch.
### Gerenciamento de recursos de rede
O Modo Automático do EKS lida com o gerenciamento de prefixo, endereçamento IP e interface de rede monitorando os recursos do NodeClass para as configurações de rede. O serviço executa várias operações importantes automaticamente:
**Delegação de prefixo**
O modo automático do EKS utiliza por padrão a delegação de prefixos (prefixos /28) para a rede dos pods e mantém um grupo de recursos IP definido previamente que é escalado com base no número de pods agendados. Quando é detectada fragmentação da sub-rede do pod, o modo automático provisiona endereços IP secundários (prefixos /32). Devido a esse algoritmo de rede de pods padrão, o modo automático calcula o número máximo de pods por nó com base na quantidade de ENIs e de IPs com suporte por tipo de instância (considerando o pior cenário de fragmentação). Para obter mais informações sobre o número máximo de ENIs e de IPs com suporte por tipo de instância, consulte [Máximo de endereços IP por interface de rede](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) no Guia do usuário do EC2. As famílias de instâncias da geração mais recente (Nitro v6 e versões posteriores) geralmente têm um número maior de ENIs e de IPs com suporte por tipo de instância, e o modo automático ajusta o cálculo do número máximo de pods de acordo.
Para clusters IPv6, apenas a delegação de prefixo é utilizada, e o modo automático sempre usa um limite máximo de 110 pods por nó.
**Gerenciamento do período de espera**
O serviço implementa um grupo de espera para prefixos ou endereços IPv4 secundários que não estão mais em uso. Depois que o período de espera expirar, esses recursos serão liberados de volta para a VPC. No entanto, se os pods reutilizarem esses recursos durante o período de espera, eles serão restaurados do grupo de espera.
**Compatibilidade com IPv6**
Para clusters IPv6, o Modo Automático do EKS provisiona um prefixo IPv6 `/80` por nó na interface de rede primária. Ao usar `podSubnetSelectorTerms`, o prefixo é alocado em uma interface de rede secundária na sub-rede do pod.
O serviço também garante o gerenciamento adequado e a coleta de resíduos de todas as interfaces de rede.
## Balanceamento de carga
Você configura os AWS Elastic Load Balancers provisionados pelo Modo Automático do EKS usando anotações nos recursos de Service e Ingress.
Para ter mais informações, consulte [Criar uma IngressClass para configurar um Application Load Balancer](auto-configure-alb.md) ou [Usar anotações de serviço para configurar Network Load Balancers](auto-configure-nlb.md).
### Considerações sobre o balanceamento de carga com o Modo Automático do EKS
+ O modo de direcionamento padrão é o modo de IP, não o modo de instância.
+ O Modo Automático do EKS é compatível apenas com o modo de grupo de segurança para Network Load Balancers.
+ A AWS não é compatível com a migração de balanceadores de carga do controlador de balanceador de carga autogerenciado da AWS para o gerenciamento pelo Modo Automático do EKS.
+ O campo `networking.ingress.ipBlock` na especificação `TargetGroupBinding` não é compatível.
+ Se os nós de processamento usarem grupos de segurança personalizados (não o padrão de nomenclatura `eks-cluster-sg- `), o perfil do cluster precisará de permissões adicionais do IAM. A política padrão gerenciada pelo EKS só permite que o EKS modifique grupos de segurança denominados `eks-cluster-sg-`. Sem permissão para modificar os grupos de segurança personalizados, o EKS não pode adicionar as regras de entrada necessárias que permitem que o tráfego de ALB e NLB chegue aos pods.
#### Considerações sobre o CoreDNS
O modo automático do EKS não usa a implantação tradicional do CoreDNS para fornecer resolução de DNS dentro do cluster. Em vez disso, os nós do modo automático empregam o CoreDNS, que é executado como um serviço do sistema diretamente em cada nó. Ao migrar um cluster tradicional para o modo automático, você pode remover a implantação do CoreDNS do cluster assim que as workloads forem movidas para os nós do modo automático.
**Importante**
Se você planeja manter um cluster com nós no modo automático e nós que não estejam no modo automático, deve manter a implantação do CoreDNS. Os nós que não operam no modo automático dependem dos pods do CoreDNS tradicionais para a resolução de DNS, pois não têm acesso ao serviço de DNS em nível de nó fornecido pelo modo automático.