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á.

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

É 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 (CNI) para redes de clusters.

O Amazon EKS oferece suporte oficial ao plug-in CNI da Amazon Virtual Private Cloud (VPC) 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 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 alternativas CNIs. Consulte a documentação do EKS Alternate CNI para obter uma lista de parceiros e recursos para gerenciar alternativas de CNIs forma eficaz.

Modelo de rede Kubernetes

O Kubernetes define os seguintes requisitos em redes de cluster:

Consulte o modelo de rede Kubernetes 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 (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 (default /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 diretório (). --cni-bin-dir default /opt/cni/bin 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.

Amazon Virtual Private Cloud (VPC) CNI

A VPC CNI fornecida pela AWS é 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 AWS Elastic Networking Interfaces (ENIs) para cada nó do Kubernetes e mantém o pool aquecido de. IPs O VPC CNI fornece opções de configuração para pré-alocação ENIs e endereços IP para tempos rápidos de inicialização do pod. Consulte a CNI da Amazon VPC 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 antes de implantar clusters EKS.

O Amazon VPC CNI aloca um pool quente de endereços IP ENIs secundários da sub-rede conectada à ENI primária do nó. Esse modo de VPC CNI é chamado de modo IP secundário. O número de endereços IP e, portanto, o número de pods (densidade de pods) são definidos pelo número 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 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 a. 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 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 IPv4 endereços ao executar grandes clusters com milhares de cargas de trabalho. O AWS VPC permite que você estenda a disponibilidade IPs atribuindo um secundário CIDRs 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. 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 o EKS. Isso permite que você crie efetivamente um ambiente em que os pods não consumam mais nenhum RFC1918 endereço IP da sua VPC.

A rede personalizada é uma opção para resolver o problema de esgotamento do IPv4 endereço, mas exige sobrecarga operacional. Recomendamos IPv6 clusters em redes personalizadas para resolver esse problema. Especificamente, recomendamos migrar para IPv6 clusters se você tiver esgotado completamente todo o espaço de IPv4 endereço disponível para sua VPC. Avalie os planos de suporte IPv6 da sua organização e considere se investir neles 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 IPv4 endereço limitado. Em resposta aos problemas de IPv4 exaustão dos clientes, a EKS priorizou IPv6 apenas pods em vez de pods de pilha dupla. Ou seja, os pods podem acessar IPv4 recursos, mas não recebem um IPv4 endereço do intervalo CIDR da VPC. A VPC CNI atribui IPv6 endereços aos pods do bloco CIDR da VPC gerenciado pela AWS. IPv6

Calculadora de sub-rede

Este projeto inclui um documento Excel de calculadora de sub-rede. 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 mais informações sobre esses modos.

Entradas:

Saídas: