Aumente a quantidade de endereços IP disponíveis para o nó do Amazon EKS
É possível aumentar o número de endereços IP que os nós podem atribuir a Pods atribuindo prefixos IP em vez de atribuir endereços IP secundários individuais aos nós.
Antes de iniciar o procedimento, conclua as seguintes tarefas:
-
Revise as considerações.
-
É necessário um cluster existente. Para implantar, consulte Criar um cluster do Amazon EKS..
-
As sub-redes nas quais seus nós do Amazon EKS estão devem ter blocos de Encaminhamento Entre Domínios Sem Classificação (CIDR)
/28
(para clustersIPv4
) ou/80
(para clustersIPv6
) suficientemente contíguos. Somente nós Linux podem existir em um clusterIPv6
. O uso de prefixos IP poderá falhar se os endereços IP estiverem espalhados pelo CIDR da sub-rede. Recomendamos o seguinte:-
Usar uma reserva CIDR de sub-rede para que, mesmo que algum endereço IP dentro do intervalo reservado ainda esteja em uso, após sua liberação, os endereços IP não sejam reatribuídos. Isso garante que os prefixos estejam disponíveis para alocação sem segmentação.
-
Usar novas sub-redes que sejam utilizadas especificamente para executar workloads às quais os prefixos IP estão atribuídos. Tanto as workloads Windows quanto as workloads Linux podem ser executadas na mesma sub-rede ao atribuir prefixos IP.
-
-
Para atribuir prefixos IP aos seus nós, eles devem ser baseados no AWS Nitro. As instâncias que não são baseadas em Nitro continuam a alocar endereços IP secundários individuais, mas têm um número significativamente menor de endereços IP a atribuir aos Pods do que as instâncias Nitro-based.
-
Somente para clusters com nós do Linux: se o cluster estiver configurado para a família
IPv4
, você deverá ter a versão1.9.0
ou posterior do complemento Amazon VPC CNI plugin for Kubernetes instalada. É possível verificar a versão atual com o comando a seguir.kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
Se o cluster estiver configurado para a família
IPv6
, a versão1.10.1
ou posterior do complemento deverá estar instalada. Se a versão do plug-in for anterior às versões exigidas, será necessário atualizá-lo. Para obter mais informações, consulte as seções de atualização de Atribuir IPs a pods com o Amazon VPC CNI. -
Para clusters somente com nós do Windows:
-
Seu cluster e a respectiva versão da plataforma devem ser iguais ou posteriores às versões na tabela a seguir. Para atualizar a versão do cluster, consulte Atualizar um cluster existente para a nova versão do Kubernetes. Se o seu cluster não estiver na versão mínima da plataforma, não será possível atribuir prefixos IP aos seus nós até que o Amazon EKS atualize a versão da sua plataforma.
Versão do Kubernetes Versão da plataforma 1.27
eks.3
1.26
eks.4
1.25
eks.5
É possível verificar a versão atual do Kubernetes e da plataforma ao substituir
my-cluster
no comando a seguir pelo nome do seu cluster e executar o comando modificado:aws eks describe-cluster --name
.my-cluster
--query 'cluster.{"Kubernetes Version": version, "Platform Version": platformVersion}' -
Suporte ao Windows habilitado para seu cluster. Para ter mais informações, consulte Implantar nós Windows em clusters EKS.
-
Configure seu cluster para atribuir prefixos de endereço IP aos nós. Conclua o procedimento na guia correspondente ao sistema operacional do seu nó.
- Linux
-
-
Habilite o parâmetro para atribuir prefixos a interfaces de rede para o DaemonSet CNI da Amazon VPC. Ao implantar um cluster da versão
1.21
ou superior, a versão1.10.1
ou superior do complemento Amazon VPC CNI plugin for Kubernetes é implantada com ele. Se você criou o cluster com a famíliaIPv6
, essa configuração foi definida comotrue
por padrão. Se você criou o cluster com a famíliaIPv4
, essa configuração foi definida comofalse
por padrão.kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
Importante
Mesmo que sua sub-rede tenha endereços IP disponíveis, se ela não tiver blocos
/28
contíguos disponíveis, você verá o erro a seguir nos logs do Amazon VPC CNI plugin for Kubernetes.
-
-
-
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
Isso pode acontecer devido à fragmentação dos endereços IP secundários existentes espalhados por uma sub-rede. Para resolver esse erro, crie uma nova sub-rede e inicie Pods lá ou use uma reserva CIDR de sub-rede do Amazon EC2 para reservar espaço em uma sub-rede para uso com atribuição de prefixo. Para obter mais informações, consulte Comportamento do endereçamento IP para sua sub-rede no Guia do usuário da Amazon VPC. ... Se você planeja implantar um grupo de nós gerenciados sem um modelo de inicialização ou com um modelo de inicialização no qual não especificou uma ID de AMI e está usando uma versão do Amazon VPC CNI plugin for Kubernetes igual ou posterior às versões listadas nos pré-requisitos, pule para a próxima etapa. Os grupos de nós gerenciados calculam automaticamente o número máximo de Pods para você.
+ Se você estiver implantando um grupo de nós autogerenciado ou um grupo de nós gerenciado com um modelo de lançamento no qual você especificou um ID de AMI, será necessário determinar o número recomendado do Amazon EKS de Pods máximos para seus nós. Siga as instruções em Pods máximos recomendados do Amazon EKS para cada tipo de instância do Amazon EC2, adicionando --cni-prefix-delegation-enabled
à etapa 3. Anote a saída para uso em uma etapa superior.
+ IMPORTANTE: Os grupos de nós gerenciados impõem um número máximo no valor de maxPods
. Para instâncias com menos de 30 vCPUs, o número máximo é 110 e, para todas as outras instâncias, o número máximo é 250. Esse número máximo é aplicado quer a delegação de prefixo esteja habilitada ou não. ... Se estiver usando um cluster 1.21
ou posterior configurado para IPv6
, pule para a próxima etapa.
+ Especifique os parâmetros em uma das opções a seguir. Para determinar qual opção é a certa para você e qual valor fornecer para ela, consulte WARM_PREFIX_TARGET, WARM_IP_TARGET e MINIMUM_IP_TARGET
+ Você pode substituir os valores de exemplo
por um valor maior que zero.
+
** WARM_PREFIX_TARGET
+
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
-
WARM_IP_TARGET
ouMINIMUM_IP_TARGET
– Se qualquer um dos dois valores for definido, substitui qualquer valor definido paraWARM_PREFIX_TARGET
.kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
-
Crie um dos seguintes tipos de grupos de nós com pelo menos um tipo de instância do Amazon EC2 Nitro Amazon Linux 2. Para obter uma lista dos tipos de instância do Nitro, consulte Instâncias criadas no Sistema Nitro no Guia do usuário do Amazon EC2. Este recurso não é compatível com o Windows. Para as opções que incluem
110
, substitua pelo valor da etapa 3 (recomendado) ou por seu próprio valor.-
Autogerenciado: implante o grupo de nós usando as instruções em Criar nós autogerenciados do Amazon Linux. Especifique o seguinte texto para o parâmetro BootstrapArguments:
--use-max-pods false --kubelet-extra-args '--max-pods=110'
Se estiver usando
eksctl
para criar o grupo de nós, poderá usar o comando a seguir.eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
-
Managed (Gerenciado) – Implante seu grupo de nós usando uma das seguintes opções:
-
Sem um modelo de inicialização ou com um modelo de inicialização sem uma ID de AMI especificada: conclua o procedimento em Criar um grupo de nós gerenciados para o seu cluster. Grupos de nós gerenciados agora calculam automaticamente o valor recomendado de
max-pods
do Amazon EKS para você. -
Com um modelo de lançamento com um ID de AMI especificado – Em seu modelo de lançamento, especifique um ID de AMI otimizado do Amazon EKS ou uma AMI personalizada criada a partir da AMI otimizada do Amazon EKS e, em seguida implante o grupo de nós usando um modelo de lançamento e forneça os seguintes dados do usuário no modelo de lançamento. Esses dados do usuário transmitem argumentos para o arquivo
bootstrap.sh
. Para obter mais informações sobre o arquivo de bootstrap, consulte bootstrap.shno GitHub. /etc/eks/bootstrap.sh my-cluster \ --use-max-pods false \ --kubelet-extra-args '--max-pods=110'
Se estiver usando
eksctl
para criar o grupo de nós, poderá usar o comando a seguir.eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
Se você criou uma AMI personalizada que não foi criada a partir da AMI otimizada do Amazon EKS, precisa criar a configuração você mesmo.
nota
Se você também quiser atribuir endereços IP aos Pods de uma sub-rede diferente da sub-rede da instância, será necessário habilitar o recurso nesta etapa. Para ter mais informações, consulte Implementar pods em sub-redes alternadas com rede personalizada.
- Windows
-
-
-
Habilite a atribuição de prefixos IP.
-
Abra o
ConfigMap
deamazon-vpc-cni
para edição.kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
-
Adicione as linhas a seguir à seção
data
:enable-windows-prefix-delegation: "true"
-
Salve o arquivo e feche o editor.
-
Confirme se a anotação foi adicionada ao
ConfigMap
.kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
Se a saída retornada não for
true
, é possível que um erro tenha ocorrido. Tente concluir a etapa novamente.Importante
Mesmo que sua sub-rede tenha endereços IP disponíveis, se ela não tiver blocos
/28
contíguos disponíveis, você verá o erro a seguir nos eventos do nó.
-
"failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request"
Isso pode acontecer devido à fragmentação dos endereços IP secundários existentes espalhados por uma sub-rede. Para resolver esse erro, crie uma nova sub-rede e inicie Pods lá ou use uma reserva CIDR de sub-rede do Amazon EC2 para reservar espaço em uma sub-rede para uso com atribuição de prefixo. Para obter mais informações, consulte Comportamento do endereçamento IP para sua sub-rede no Guia do usuário da Amazon VPC. … (Opcional) Especifique uma configuração adicional para controlar o comportamento de pré-escalabilidade e escalabilidade dinâmica do seu cluster. Para obter mais informações, consulte Opções de configuração com o modo de delegação de prefixo no Windows
+ .... Abra o amazon-vpc-cni
ConfigMap
para edição.
+
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
-
Substitua os
valores de exemplo
por um valor maior que zero e adicione as entradas necessárias à seçãodata
doConfigMap
. Se você definir um valor para umwarm-ip-target
ouminimum-ip-target
, o valor substituirá qualquer valor definido parawarm-prefix-target
.warm-prefix-target: "1" warm-ip-target: "5" minimum-ip-target: "2"
-
Salve o arquivo e feche o editor.
-
Crie grupos de nós Windows com pelo menos um tipo de instância do Nitro do Amazon EC2. Para obter uma lista dos tipos de instâncias do Nitro, consulte Instâncias criadas no Nitro System no Guia do Usuário do Amazon EC2. Por padrão, o número máximo de Pods podem ser implantados em um nó é 110. Se você quiser aumentar ou diminuir esse número, especifique as informações a seguir nos dados do usuário para a configuração do bootstrap. Substitua
max-pods-quantity
pelo seu valor máximo de pods.-KubeletExtraArgs '--max-pods=max-pods-quantity'
Se você estiver implantando grupos de nós gerenciados, essa configuração precisará ser adicionada ao modelo de inicialização. Para ter mais informações, consulte Personalizar nós gerenciados com modelos de execução. Para obter mais informações sobre os parâmetros de configuração do script de bootstrap do Windows, consulte Parâmetros de configuração do script de bootstrap. Depois que seus nós forem implantados, visualize-os no cluster.
+
kubectl get nodes
+ Veja um exemplo de saída abaixo.
+
NAME STATUS ROLES AGE VERSION ip-192-168-22-103.region-code.compute.internal Ready <none> 19m v1.XX.X-eks-6b7464 ip-192-168-97-94.region-code.compute.internal Ready <none> 19m v1.XX.X-eks-6b7464
-
Descreva um dos nós para determinar o valor de
max-pods
para o nó e o número de endereços IP disponíveis. Substitua192.168.30.193
pelo endereçoIPv4
no nome de um do seus nós retornado na saída anterior.kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
Veja um exemplo de saída abaixo.
pods: 110 vpc.amazonaws.com/PrivateIPv4Address: 144
Na saída anterior,
110
é o número máximo de Pods que o Kubernetes implantará no nó, mesmo que144
endereços IP estejam disponíveis.
-
-