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

Modo de prefixo para Linux

O Amazon VPC CNI atribui prefixos de rede às interfaces de rede do Amazon EC2 para aumentar o número de endereços IP disponíveis para os nós e aumentar a densidade de pods por nó. Você pode configurar a versão 1.9.0 ou posterior do complemento CNI do Amazon VPC para atribuir CIDRs IPv4 e IPv6 em vez de atribuir endereços IP secundários individuais às interfaces de rede.

O modo de prefixo é ativado por padrão em clusters IPv6 e é a única opção suportada. O VPC CNI atribui um prefixo IPv6 /80 a um slot em um ENI. Consulte a seção IPv6 deste guia para obter mais informações.

Com o modo de atribuição de prefixo, o número máximo de interfaces de rede elástica por tipo de instância permanece o mesmo, mas agora você pode configurar o CNI do Amazon VPC para atribuir prefixos de endereço IPv4 /28 (16 endereços IP), em vez de atribuir endereços IPv4 individuais aos slots nas interfaces de rede. Quando ENABLE_PREFIX_DELEGATION definido como verdadeiro, o VPC CNI aloca um endereço IP para um pod a partir do prefixo atribuído a um ENI. Siga as instruções mencionadas no guia do usuário do EKS para ativar o modo Prefixo IP.

O número máximo de endereços IP que podem ser atribuídos a uma interface de rede depende do tipo de instância. Todo prefixo que você atribui a uma interface de rede conta como um endereço IP. Por exemplo, uma instância c5.large tem um limite de 10 endereços IPv4 por interface de rede. Toda interface de rede para essa instância tem um endereço IPv4 primário. Se uma interface de rede não tiver endereços IPv4 secundários, será possível atribuir até nove prefixos à interface de rede. Para cada endereço IPv4 adicional que você atribuir a uma interface de rede, poderá atribuir um prefixo a menos à interface de rede. Consulte a documentação do AWS EC2 sobre endereços IP por interface de rede por tipo de instância e atribuição de prefixos às interfaces de rede.

Durante a inicialização do node de trabalho, o VPC CNI atribui um ou mais prefixos ao ENI primário. O CNI pré-aloca um prefixo para uma inicialização mais rápida do pod, mantendo uma piscina aquecida. O número de prefixos a serem mantidos na piscina aquecida pode ser controlado definindo variáveis de ambiente.

À medida que mais pods forem programados, prefixos adicionais serão solicitados para o ENI existente. Primeiro, o VPC CNI tenta alocar um novo prefixo para um ENI existente. Se a ENI estiver com capacidade máxima, a CNI da VPC tentará alocar uma nova ENI para o nó. Os novos ENIs serão anexados até que o limite máximo de ENI (definido pelo tipo de instância) seja atingido. Quando uma nova ENI é anexada, o ipamd alocará um ou mais prefixos necessários para manter a WARM_PREFIX_TARGET configuração, e. WARM_IP_TARGET MINIMUM_IP_TARGET

Recomendações

Use o modo de prefixo quando

Use o modo de prefixo se você estiver enfrentando problemas de densidade de pod nos nós de trabalho. Para evitar erros de CNI da VPC, recomendamos examinar as sub-redes em busca de blocos contíguos de endereços para o prefixo /28 antes de migrar para o modo de prefixo. Consulte a seção "Usar reservas de sub-rede para evitar a fragmentação de sub-rede (IPv4)" para obter detalhes sobre a reserva de sub-rede.

Para compatibilidade com versões anteriores, o limite máximo de pods é definido para suportar o modo IP secundário. Para aumentar a densidade do pod, especifique o max-pods valor para Kubelet e --use-max-pods=false como dados do usuário para os nós. Para obter mais informações, consulte Como os MaxPods são determinados no Guia do usuário do Amazon EKS. Consulte o guia do usuário do EKS para obter, por exemplo, dados do usuário.

./max-pods-calculator.sh --instance-type m5.large --cni-version ``1.9``.0 --cni-prefix-delegation-enabled

O modo de atribuição de prefixo é especialmente relevante para usuários de redes personalizadas CNI em que o ENI primário não é usado para pods. Com a atribuição de prefixo, você ainda pode anexar mais IPs em quase todos os tipos de instância do Nitro, mesmo sem o ENI primário usado para pods.

Evite o modo de prefixo quando

Se sua sub-rede estiver muito fragmentada e não tiver endereços IP disponíveis insuficientes para criar prefixos /28, evite usar o modo de prefixo. O anexo do prefixo pode falhar se a sub-rede da qual o prefixo é produzido estiver fragmentada (uma sub-rede muito usada com endereços IP secundários dispersos). Esse problema pode ser evitado criando uma nova sub-rede e reservando um prefixo.

No modo prefixo, o grupo de segurança atribuído aos nós de trabalho é compartilhado pelos pods. Considere usar grupos de segurança para pods se você tiver um requisito de segurança para alcançar a conformidade executando aplicativos com diferentes requisitos de segurança de rede em recursos computacionais compartilhados.

Use tipos de instância semelhantes no mesmo grupo de nós

Seu grupo de nós pode conter instâncias de vários tipos. Se uma instância tiver uma contagem máxima baixa de pods, esse valor será aplicado a todos os nós no grupo de nós. Considere usar tipos de instância semelhantes em um grupo de nós para maximizar o uso de nós. Recomendamos configurar o node.kubernetes. io/instance-digite a parte de requisitos da API do provisionador se estiver usando o Karpenter para escalonamento automatizado de nós.

Configurar WARM_PREFIX_TARGET para conservar endereços IPv4

O valor padrão do manifesto de instalação para WARM_PREFIX_TARGET é 1. Na maioria dos casos, o valor recomendado de 1 para WARM_PREFIX_TARGET fornecerá uma boa combinação de tempos rápidos de inicialização do pod e minimizará os endereços IP não utilizados atribuídos à instância.

Se você precisar conservar ainda mais os endereços IPv4 por nó, use WARM_IP_TARGET e use MINIMUM_IP_TARGET as configurações, que são WARM_PREFIX_TARGET substituídas quando configuradas. Ao WARM_IP_TARGET definir um valor menor que 16, você pode evitar que o CNI mantenha um prefixo de excesso inteiro anexado.

Prefiro alocar novos prefixos em vez de anexar um novo ENI

Alocar um prefixo adicional para uma ENI existente é uma operação de API do EC2 mais rápida do que criar e anexar uma nova ENI à instância. O uso de prefixos melhora o desempenho e, ao mesmo tempo, é econômico na alocação de endereços IPv4. A anexação de um prefixo normalmente é concluída em menos de um segundo, enquanto a anexação de uma nova ENI pode levar até 10 segundos. Para a maioria dos casos de uso, o CNI só precisará de um único ENI por nó de trabalho quando executado no modo prefixo. Se você puder pagar (na pior das hipóteses) até 15 IPs não utilizados por nó, é altamente recomendável usar o novo modo de rede de atribuição de prefixo e obter os ganhos de desempenho e eficiência decorrentes dele.

Use reservas de sub-rede para evitar a fragmentação de sub-rede (IPv4)

Quando o EC2 aloca um prefixo IPv4 /28 para um ENI, ele precisa ser um bloco contíguo de endereços IP da sua sub-rede. Se a sub-rede da qual o prefixo é gerado estiver fragmentada (uma sub-rede altamente usada com endereços IP secundários dispersos), o anexo do prefixo poderá falhar e você verá a seguinte mensagem de erro nos registros da CNI da VPC:

failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: There are not enough free cidr blocks in the specified subnet to satisfy the request.

Para evitar a fragmentação e ter espaço contíguo suficiente para criar prefixos, você pode usar as reservas CIDR da sub-rede VPC para reservar espaço IP dentro de uma sub-rede para uso exclusivo por prefixos. Depois de criar uma reserva, o plug-in VPC CNI chamará as APIs do EC2 para atribuir prefixos que são automaticamente alocados do espaço reservado.

É recomendável criar uma nova sub-rede, reservar espaço para prefixos e habilitar a atribuição de prefixos com VPC CNI para nós de trabalho em execução nessa sub-rede. Se a nova sub-rede for dedicada somente aos pods em execução no cluster EKS com a atribuição de prefixo VPC CNI ativada, você poderá pular a etapa de reserva de prefixo.

Evite fazer o downgrade da VPC CNI

O modo de prefixo funciona com a VPC CNI versão 1.9.0 e posterior. O downgrade do complemento CNI do Amazon VPC para uma versão inferior à 1.9.0 deve ser evitado quando o modo de prefixo estiver ativado e os prefixos forem atribuídos aos ENIs. Você deve excluir e recriar os nós se decidir fazer o downgrade do VPC CNI.

Substitua todos os nós durante a transição para a Delegação de Prefixo

É altamente recomendável criar novos grupos de nós para aumentar o número de endereços IP disponíveis, em vez de fazer a substituição contínua dos nós de trabalho existentes. Isole e drene todos os nós existentes para despejar com segurança todos os seus pods existentes. Para evitar interrupções no serviço, sugerimos implementar orçamentos de interrupção de pods em seus clusters de produção para cargas de trabalho críticas. Os pods em novos nós receberão um IP de um prefixo atribuído a um ENI. Depois de confirmar que os pods estão em execução, você pode excluir os nós e grupos de nós antigos. Se você estiver usando grupos de nós gerenciados, siga as etapas mencionadas aqui para excluir um grupo de nós com segurança.