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 de IP em vez de endereços IP secundários individuais aos nós.

Pré-requisitos

• É 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 clusters IPv4) ou /80 (para clusters IPv6) suficientemente contíguos. Somente nós Linux podem existir em um cluster IPv6. 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. As workloads do Linux e do Windows podem ser executadas na mesma sub-rede ao atribuir prefixos de 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 alocando endereços IP secundários individuais, mas têm um número significativamente menor de endereços IP para atribuir aos pods do que as instâncias baseadas em Nitro.

• Somente para clusters com nós do Linux: se o cluster estiver configurado para a família IPv4, você deverá ter a versão 1.9.0 ou mais recente do complemento do plug-in CNI da Amazon VPC para 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ão 1.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.

• Somente para clusters com nós do Windows

  • Você deve ter o suporte do Windows habilitado para o cluster. Para obter mais informações, consulte Implantar nós Windows em clusters EKS.

Atribuir prefixos de endereço IP aos nós

Configure seu cluster para atribuir prefixos de endereço IP aos nós. Conclua o procedimento que corresponda ao sistema operacional do seu nó.

Linux

1. Habilite o parâmetro para atribuir prefixos a interfaces de rede para o DaemonSet CNI da Amazon VPC. Ao implantar um cluster, a versão 1.10.1 ou mais recente do complemento do plug-in CNI da Amazon VPC para Kubernetes é implantada com ele. Se você criou o cluster com a família IPv6, essa configuração foi definida como true por padrão. Se você criou o cluster com a família IPv4, essa configuração foi definida como false 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 plug-in CNI da Amazon VPC para 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 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.

2. Caso planeje 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 um ID da AMI, e esteja usando uma versão do plug-in CNI da Amazon VPC para 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 autogerenciados ou um grupo de nós gerenciados com um modelo de execução em que 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

   Grupos de nós gerenciados impõem um número máximo para o 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.

3. Se você estiver usando um cluster 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, and MINIMUM_IP_TARGET no GitHub.

   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 ou MINIMUM_IP_TARGET – Se qualquer um dos dois valores for definido, substitui qualquer valor definido para WARM_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

4. 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 no 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.sh no 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 obter mais informações, consulte Implementar pods em sub-redes alternativas com rede personalizada.

Windows

1. Habilite a atribuição de prefixos IP.

   1. Abra o ConfigMap de amazon-vpc-cni para edição.

      kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml

   2. Adicione as linhas a seguir à seção data:

        enable-windows-prefix-delegation: "true"

   3. Salve o arquivo e feche o editor.

   4. 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 logs do plug-in CNI da Amazon VPC para 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 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.

2. (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 no GitHub.

   1. Abra o ConfigMap de amazon-vpc-cni para edição.

      kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml

   2. Substitua os valores de exemplo por um valor maior que zero e adicione as entradas necessárias à seção data do ConfigMap. Se você definir um valor para um warm-ip-target ou minimum-ip-target, o valor substituirá qualquer valor definido para warm-prefix-target.

        warm-prefix-target: "1"
        warm-ip-target: "5"
        minimum-ip-target: "2"

   3. Salve o arquivo e feche o editor.

3. Crie grupos de nós do Windows com pelo menos um tipo de instância do Nitro para Amazon EC2. 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. Por padrão, o número máximo de pods que 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 obter 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.

Determinar o máximo de pods e endereços IP disponíveis

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

2. 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. Substitua 192.168.30.193 pelo endereço IPv4 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 que endereços IP 144 estejam disponíveis.