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 CNI alternativos. Consulte a documentação do EKS Alternate CNI 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:

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 (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 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 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. 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 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 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 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 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 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. 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: