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 Windows
Na AmazonEKS, por padrão, cada pod executado em um host Windows recebe um endereço IP secundário pelo controlador de VPC recursos
Para aumentar a densidade de pods em hosts Windows, especialmente ao usar tipos de instância menores, você pode habilitar a Delegação de Prefixo para nós do Windows. Quando a delegação de prefixos está habilitada, IPv4 os prefixos /28 são atribuídos a ENI slots em vez de endereços IP secundários. A delegação de prefixo pode ser habilitada adicionando a enable-windows-prefix-delegation: "true"
entrada ao mapa de amazon-vpc-cni
configuração. Esse é o mesmo mapa de configuração em que você precisa definir a enable-windows-ipam: "true"
entrada para habilitar o suporte ao Windows.
Siga as instruções mencionadas no guia EKS do usuário para ativar o modo de Delegação de Prefixo para nós do Windows.
Figura: Comparação do modo IP secundário com o modo de delegação de prefixo
O número máximo de endereços IP que você pode atribuir a uma interface de rede depende do tipo e do tamanho da instância. Cada prefixo atribuído a uma interface de rede consome um slot disponível. Por exemplo, uma c5.large
instância tem um limite de 10
slots por interface de rede. O primeiro slot em uma interface de rede é sempre consumido pelo endereço IP principal da interface, deixando você com 9 slots para prefixos e/ou endereços IP secundários. Se esses slots receberem prefixos atribuídos, o nó poderá suportar (9 * 16) 144 endereços IP, enquanto que, se forem atribuídos endereços IP secundários, ele poderá suportar apenas 9 endereços IP. Consulte a documentação sobre endereços IP por interface de rede por tipo de instância e como atribuir prefixos às interfaces de rede para obter mais informações.
Durante a inicialização do nó de trabalho, o VPC Resource Controller atribui um ou mais prefixos ao primário ENI para acelerar a inicialização do pod, mantendo um pool aquecido de endereços IP. O número de prefixos a serem mantidos na piscina aquecida pode ser controlado definindo os seguintes parâmetros de configuração no mapa de amazon-vpc-cni
configuração.
-
warm-prefix-target
, o número de prefixos a serem alocados além da necessidade atual. -
warm-ip-target
, o número de endereços IP a serem alocados além da necessidade atual. -
minimum-ip-target
, o número mínimo de endereços IP disponíveis a qualquer momento. -
warm-ip-target
e/ou,minimum-ip-target
se definido,warm-prefix-target
substituirá.
À medida que mais pods forem programados no nó, prefixos adicionais serão solicitados para os existentes. ENI Quando um pod é programado no nó, o VPC Resource Controller primeiro tenta atribuir um IPv4 endereço a partir dos prefixos existentes no nó. Se isso não for possível, um novo IPv4 prefixo será solicitado, desde que a sub-rede tenha a capacidade necessária.
Figura: Fluxo de trabalho durante a atribuição do IPv4 endereço ao pod
Recomendações
Use Delegação de Prefixo quando
Use a delegação de prefixo se você estiver enfrentando problemas de densidade de pods nos nós de trabalho. Para evitar 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.
Por padrão, os nós max-pods
no Windows estão definidos como110
. Para a grande maioria dos tipos de instância, isso deve ser suficiente. Se você quiser aumentar ou diminuir esse limite, adicione o seguinte ao comando bootstrap nos dados do usuário:
-KubeletExtraArgs '--max-pods=example-value'
Para obter mais detalhes sobre os parâmetros de configuração de bootstrap para nós do Windows, visite a documentação aqui.
Evite a delegação 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.
Configure parâmetros para delegação de prefixo para conservar endereços IPv4
warm-prefix-target
,warm-ip-target
, e minimum-ip-target
pode ser usado para ajustar o comportamento do pré-escalonamento e do escalonamento dinâmico com prefixos. Por padrão, os seguintes valores são usados:
warm-ip-target: "1" minimum-ip-target: "3"
Ao ajustar esses parâmetros de configuração, você pode obter um equilíbrio ideal entre conservar os endereços IP e garantir a diminuição da latência do pod devido à atribuição do endereço IP. Para obter mais informações sobre esses parâmetros de configuração, visite a documentação aqui
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á o seguinte evento de nó:
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
Para evitar a fragmentação e ter espaço contíguo suficiente para criar prefixos, use as CIDRreservas de VPC sub-rede para reservar espaço IP em uma sub-rede para uso exclusivo por prefixos. Depois de criar uma reserva, os endereços IP dos blocos reservados não serão atribuídos a outros recursos. Dessa forma, o VPC Resource Controller poderá obter prefixos disponíveis durante a chamada de atribuição ao nó. ENI
É recomendável criar uma nova sub-rede, reservar espaço para prefixos e habilitar a atribuição de prefixos 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 delegação de prefixo ativada, você poderá pular a etapa de reserva do prefixo.
Substitua todos os nós ao migrar do modo IP secundário para o modo de delegação de prefixo ou vice-versa
É 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.
Ao usar grupos de nós autogerenciados, as etapas da transição seriam:
-
Aumente a capacidade do seu cluster para que os novos nós possam acomodar suas cargas de trabalho
-
Ativar/desativar o recurso de delegação de prefixo para Windows
-
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. -
Depois de confirmar que os pods estão em execução, você pode excluir os nós e grupos de nós antigos. Os pods em novos nós receberão um IPv4 endereço a partir de um prefixo atribuído ao nó. ENI
Ao usar grupos de nós gerenciados, as etapas da transição seriam:
-
Ativar/desativar o recurso de delegação de prefixo para Windows
-
Atualize o grupo de nós usando as etapas mencionadas aqui. Isso executa etapas semelhantes às anteriores, mas é gerenciado porEKS.
Atenção
Execute todos os pods em um nó no mesmo modo
Para Windows, recomendamos que você evite executar pods no modo IP secundário e no modo de delegação de prefixo ao mesmo tempo. Essa situação pode surgir quando você migra do modo IP secundário para o modo de delegação de prefixo ou vice-versa com a execução de cargas de trabalho do Windows.
Embora isso não afete seus pods em execução, pode haver inconsistência com relação à capacidade do endereço IP do nó. Por exemplo, considere um nó t3.xlarge que tem 14 slots para endereços secundários. IPv4 Se você estiver executando 10 pods, 10 slots no ENI serão consumidos por endereços IP secundários. Depois de habilitar a delegação de prefixo, a capacidade anunciada para o servidor kube-api seria (14 slots * 16 endereços IP por prefixo) 244, mas a capacidade real naquele momento seria (4 slots restantes * 16 endereços por prefixo) 64. Essa inconsistência entre a quantidade de capacidade anunciada e a quantidade real de capacidade (slots restantes) pode causar problemas se você executar mais pods do que endereços IP disponíveis para atribuição.
Dito isso, você pode usar a estratégia de migração conforme descrito acima para fazer a transição segura dos pods do endereço IP secundário para os endereços obtidos dos prefixos. Ao alternar entre os modos, os Pods continuarão funcionando normalmente e:
-
Ao alternar do modo IP secundário para o modo de delegação de prefixo, os endereços IP secundários atribuídos aos pods em execução não serão liberados. Os prefixos serão atribuídos aos slots gratuitos. Depois que um pod for encerrado, o IP secundário e o slot que ele estava usando serão liberados.
-
Ao alternar do modo de delegação de prefixo para o modo IP secundário, um prefixo será liberado quando todos os itens IPs dentro de seu intervalo não estiverem mais alocados aos pods. Se algum IP do prefixo for atribuído a um pod, esse prefixo será mantido até que os pods sejam encerrados.
Problemas de depuração com delegação de prefixo
Você pode usar nosso guia de depuração aqui