As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Melhores práticas para redes
**dica**
[Explore as](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) melhores práticas por meio de workshops do Amazon EKS.
É fundamental entender a rede Kubernetes para operar seu cluster e seus aplicativos com eficiência. A rede Pod, também chamada de rede de cluster, é o centro da rede Kubernetes. O Kubernetes é compatível com plug-ins [Container Network Interface](https://github.com/containernetworking/cni) (CNI) para redes de clusters.
O Amazon EKS oferece suporte oficial ao plug-in CNI [da Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) para implementar a rede Kubernetes Pod. A VPC CNI fornece integração nativa com a AWS VPC e funciona no modo subjacente. No modo subjacente, os pods e os hosts estão localizados na mesma camada de rede e compartilham o namespace da rede. O endereço IP do pod é consistente do ponto de vista do cluster e da VPC.
Este guia apresenta a [Amazon VPC Container Network Interface (VPC](https://github.com/aws/amazon-vpc-cni-k8s) CNI) no contexto da rede de clusters Kubernetes. O VPC CNI é o plug-in de rede padrão compatível com o EKS e, portanto, é o foco do guia. O VPC CNI é altamente configurável para oferecer suporte a diferentes casos de uso. Este guia inclui ainda seções dedicadas sobre diferentes casos de uso, modos operacionais e subcomponentes do VPC CNI, seguidos pelas recomendações.
O Amazon EKS executa o Kubernetes upstream e é certificado em conformidade com o Kubernetes. Embora você possa usar plug-ins CNI alternativos, este guia não fornece recomendações para gerenciar CNI alternativos. Consulte a documentação do [EKS Alternate CNI](https://docs.aws.amazon.com/eks/latest/userguide/alternate-cni-plugins.html) para obter uma lista de parceiros e recursos para gerenciar CNI alternativos de forma eficaz.
## Modelo de rede Kubernetes
O Kubernetes define os seguintes requisitos em redes de cluster:
+ Os pods programados no mesmo nó devem ser capazes de se comunicar com outros pods sem usar NAT (Network Address Translation).
+ Todos os daemons do sistema (processos em segundo plano, por exemplo, [kubelet](https://kubernetes.io/docs/concepts/overview/components/)) em execução em um determinado nó podem se comunicar com os pods em execução no mesmo nó.
+ Os pods que usam a [rede host](https://docs.docker.com/network/host/) devem ser capazes de entrar em contato com todos os outros pods em todos os outros nós sem usar o NAT.
Consulte [o modelo de rede Kubernetes](https://kubernetes.io/docs/concepts/services-networking/#the-kubernetes-network-model) para obter detalhes sobre o que o Kubernetes espera de implementações de rede compatíveis. A figura a seguir ilustra a relação entre os namespaces da rede do pod e o namespace da rede do host.
## Interface de rede de contêineres (CNI)
O Kubernetes oferece suporte às especificações e plug-ins da CNI para implementar o modelo de rede Kubernetes. Uma CNI consiste em uma [especificação](https://github.com/containernetworking/cni/blob/main/SPEC.md) (versão atual 1.0.0) e bibliotecas para escrever plug-ins para configurar interfaces de rede em contêineres, junto com vários plug-ins compatíveis. A CNI se preocupa apenas com a conectividade de rede dos contêineres e com a remoção dos recursos alocados quando o contêiner é excluído.
O plug-in CNI é ativado passando ao kubelet a opção de linha de comando. `--network-plugin=cni` O Kubelet lê um arquivo de `--cni-conf-dir` (padrão/etc/cni/net.d) e usa a configuração CNI desse arquivo para configurar a rede de cada pod. O arquivo de configuração CNI deve corresponder à especificação CNI (mínimo v0.4.0) e todos os plug-ins CNI necessários referenciados pela configuração devem estar presentes no `--cni-bin-dir` diretório (padrão //bin). opt/cni Se houver vários arquivos de configuração CNI no diretório, o kubelet usa o arquivo de configuração que vem primeiro pelo nome em ordem lexicográfica.
## Nuvem Privada Virtual da Amazon (VPC) CNI
O AWS-provided VPC CNI é o complemento de rede padrão para clusters EKS. O complemento VPC CNI é instalado por padrão quando você provisiona clusters EKS. O VPC CNI é executado em nós de trabalho do Kubernetes. O complemento VPC CNI consiste no binário CNI e no plug-in IP Address Management (ipamd). A CNI atribui um endereço IP da rede VPC a um pod. O ipamd gerencia as interfaces de rede elásticas (ENIs) da AWS para cada nó do Kubernetes e mantém o pool quente de IPs. O VPC CNI fornece opções de configuração para pré-alocação de ENIs e endereços IP para tempos rápidos de inicialização do pod. Consulte a [CNI da Amazon VPC](vpc-cni.md) para ver as melhores práticas recomendadas de gerenciamento de plug-ins.
O Amazon EKS recomenda que você especifique sub-redes em pelo menos duas zonas de disponibilidade ao criar um cluster. O Amazon VPC CNI aloca endereços IP para pods a partir das sub-redes dos nós. É altamente recomendável verificar as sub-redes para ver se há endereços IP disponíveis. Considere as recomendações de [VPC e sub-rede](subnets.md) antes de implantar clusters EKS.
O Amazon VPC CNI aloca um pool quente de ENIs e endereços IP secundários da sub-rede conectada à ENI primária do nó. Esse modo de VPC CNI é chamado de modo IP [secundário](vpc-cni.md). O número de endereços IP e, portanto, o número de pods (densidade de pods) é definido pelo número de ENIs e pelo endereço IP por ENI (limites), conforme definido pelo tipo de instância. O modo secundário é o padrão e funciona bem para clusters pequenos com tipos de instância menores. Considere usar o [modo de prefixo](prefix-mode-linux.md) se você estiver enfrentando desafios de densidade de pods. Você também pode aumentar os endereços IP disponíveis no nó para pods atribuindo prefixos aos ENIs.
O Amazon VPC CNI se integra de forma nativa com o AWS VPC e permite que os usuários apliquem as melhores práticas existentes de rede e segurança do AWS VPC para criar clusters Kubernetes. Isso inclui a capacidade de usar registros de fluxo de VPC, políticas de roteamento de VPC e grupos de segurança para isolamento de tráfego de rede. Por padrão, a CNI da Amazon VPC aplica o grupo de segurança associado à ENI primária no nó aos pods. Considere ativar [grupos de segurança para pods](sgpp.md) quando quiser atribuir regras de rede diferentes para um pod.
Por padrão, a VPC CNI atribui endereços IP aos pods da sub-rede atribuída à ENI primária de um nó. É comum sentir falta de endereços IPv4 ao executar grandes clusters com milhares de cargas de trabalho. O AWS VPC permite que você estenda os IPs disponíveis [atribuindo um CIDRs secundário](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#add-cidr-block-restrictions) para contornar o esgotamento dos blocos CIDR IPv4. O AWS VPC CNI permite que você use um intervalo CIDR de sub-rede diferente para pods. [Esse recurso da VPC CNI é chamado de rede personalizada.](custom-networking.md) Você pode considerar o uso de redes personalizadas para usar `100.64.0.0/10` e `198.19.0.0/16` CIDRs (CG-NAT) com EKS. Isso permite que você crie efetivamente um ambiente em que os pods não consumam mais nenhum endereço IP RFC1918 da sua VPC.
A rede personalizada é uma opção para resolver o problema de esgotamento do endereço IPv4, mas exige sobrecarga operacional. Recomendamos clusters IPv6 em redes personalizadas para resolver esse problema. Especificamente, recomendamos migrar para [clusters IPv6](ipv6.md) se você tiver esgotado completamente todo o espaço de endereço IPv4 disponível para sua VPC. Avalie os planos de sua organização para oferecer suporte ao IPv6 e considere se investir em IPv6 pode ter mais valor a longo prazo.
O suporte do EKS para IPv6 está focado em resolver o problema de exaustão de IP causado por um espaço de endereço IPv4 limitado. Em resposta aos problemas dos clientes com o esgotamento do IPv4, a EKS IPv6-only priorizou os pods em vez dos pods de pilha dupla. Ou seja, os pods podem acessar recursos IPv4, mas não recebem um endereço IPv4 do intervalo CIDR da VPC. A CNI da VPC atribui endereços IPv6 aos pods do bloco CIDR IPv6 da VPC gerenciado pela AWS.
## Calculadora de sub-rede
Este projeto inclui um [documento Excel de calculadora de sub-rede](https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx). Este documento de calculadora simula o consumo de endereço IP de uma carga de trabalho especificada em diferentes opções de configuração de ENI, como e. `WARM_IP_TARGET` `WARM_ENI_TARGET` O documento inclui duas folhas, uma primeira para o modo Warm ENI e uma segunda para o modo Warm IP. Consulte a [orientação do VPC CNI para obter](vpc-cni.md) mais informações sobre esses modos.
Entradas:
+ Tamanho CIDR da sub-rede
+ Alvo ENI quente *ou* alvo IP quente
+ Lista de instâncias
+ tipo, número e número de pods de carga de trabalho programados por instância
Saídas:
+ Número total de pods hospedados
+ Número de IPs de sub-rede consumidos
+ Número de IPs de sub-rede restantes
+ Detalhes do nível da instância
+ Número de Warm IPs/ENIs por instância
+ Número de ativos IPs/ENIs por instância