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

A Amazon VPC CNI atribui prefixos de rede às interfaces de EC2 rede da Amazon 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 VPC CNI complemento da Amazon para atribuir IPv4 e, em IPv6 CIDRs vez de atribuir, endereços IP secundários individuais às interfaces de rede.

O modo de prefixo é ativado por padrão nos IPv6 clusters e é a única opção suportada. O VPC CNI atribui um IPv6 prefixo /80 a um slot em um. ENI Consulte a IPv6seção 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 VPC CNI a Amazon para atribuir prefixos de IPv4 endereço /28 (16 endereços IP), em vez de atribuir IPv4 endereços individuais aos slots nas interfaces de rede. Quando ENABLE_PREFIX_DELEGATION definido como verdadeiro 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 EKS usuário para ativar o modo Prefix 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 c5.large instância tem um limite de 10 IPv4 endereços por interface de rede. Cada interface de rede dessa instância tem um IPv4 endereço primário. Se uma interface de rede não tiver IPv4 endereços secundários, você poderá atribuir até 9 prefixos à interface de rede. Para cada IPv4 endereço adicional atribuído a uma interface de rede, você pode atribuir um prefixo a menos à interface de rede. Analise a AWS EC2 documentação sobre endereços IP por interface de rede por tipo de instância e como atribuir prefixos às interfaces de rede.

Durante a inicialização do nó de trabalho, o VPC CNI atribui um ou mais prefixos ao primário. ENI 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 em uma piscina aquecida pode ser controlado definindo variáveis de ambiente.

À medida que mais pods forem programados, prefixos adicionais serão solicitados para os existentes. ENI Primeiro, as VPC CNI tentativas de alocar um novo prefixo a um existente. ENI Se estiver ENI lotado, ele VPC CNI tentará alocar um novo ENI para o nó. O novo ENIs será anexado até que o ENI limite máximo (definido pelo tipo de instância) seja atingido. Quando um novo ENI é anexado, o ipamd alocará um ou mais prefixos necessários para manter a configuração WARM_PREFIX_TARGETWARM_IP_TARGET, e. MINIMUM_IP_TARGET

Recomendações

Use o modo de prefixo quando

Use o modo de prefixo se você estiver enfrentando problemas de densidade de pods nos nós de trabalho. Para evitar VPC CNI erros, 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 da sub-rede (IPv4)” para obter detalhes da 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. Você pode considerar usar o max-pod-calculatorscript.sh para calcular o número máximo recomendado EKS de pods para um determinado tipo de instância. Consulte o guia do EKS usuário para ver, por exemplo, os 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 CNI personalizadas em que o primário não ENI é usado para pods. Com a atribuição de prefixos, você ainda pode anexar mais IPs em quase todos os tipos de instância do Nitro, mesmo sem a primária ENI usada para pods.

Evite o modo de prefixo quando

Se sua sub-rede estiver muito fragmentada e não tiver endereços IP disponíveis suficientes 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 obter 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 dos nós. Recomendamos configurar node.kubernetes.io/instance-type na parte de requisitos do provisionador se você estiver usando o Karpenter para escalonamento automatizado de nós. API

Configure WARM_PREFIX_TARGET para conservar endereços IPv4

O valor padrão do manifesto de instalação WARM_PREFIX_TARGET é 1. Na maioria dos casos, o valor recomendado de 1 for 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 IPv4 endereços por nó, use WARM_IP_TARGET e MINIMUM_IP_TARGET configurações, que são substituídos WARM_PREFIX_TARGET quando configurados. Ao WARM_IP_TARGET definir um valor menor que 16, você pode impedir que o CNI mantenha um prefixo inteiro em excesso anexado.

Prefiro alocar novos prefixos em vez de anexar um novo ENI

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

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

Quando EC2 aloca um IPv4 prefixo /28 para umENI, 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 muito usada com endereços IP secundários dispersos), o anexo do prefixo poderá falhar e você verá a seguinte mensagem de erro nos registros: VPC CNI

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 CIDRreservas de sub-rede para reservar espaço IP em uma VPC sub-rede para uso exclusivo por prefixos. Depois de criar uma reserva, o VPC CNI plug-in ligará EC2 APIs para atribuir prefixos que são alocados automaticamente do espaço reservado.

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

Evite o rebaixamento VPC CNI

O modo de prefixo funciona com a VPC CNI versão 1.9.0 e posterior. O downgrade do VPC CNI complemento da Amazon para uma versão inferior à 1.9.0 deve ser evitado quando o modo de prefixo estiver ativado e os prefixos forem atribuídos a. 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 expulsar com segurança todos os seus pods existentes. Para evitar interrupções no serviço, sugerimos implementar Pod Disruption Budgets em seus clusters de produção para cargas de trabalho críticas. Os pods em novos nós receberão um IP a partir 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 com segurança um grupo de nós.

📝 Edite esta página em GitHub