Aumente a quantidade de endereços IP disponíveis para seus nós do Amazon EC2 - Amazon EKS

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Role até o final desta página e selecione Editar esta página no GitHub. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Aumente a quantidade de endereços IP disponíveis para seus nós do Amazon EC2

Cada tipo de instância do Amazon EC2 oferece suporte a um número máximo de interfaces de rede elásticas e a um número máximo de endereços IP que podem ser atribuídos a cada interface de rede. Cada nó requer um endereço IP para cada interface de rede. Todos os outros endereços IP disponíveis podem ser atribuídos a Pods. Cada Pod exige seu próprio endereço IP. Como resultado, é possível ter nós com recursos de computação e memória disponíveis, mas que não são capazes de acomodar Pods adicionais porque o nó ficou sem endereços IP para atribuir aos Pods.

Neste tópico, você aprenderá a aumentar significativamente 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 seus nós. Cada prefixo inclui vários endereços IP. Se você não configurar o cluster para atribuição de prefixos IP, seu cluster deverá fazer mais chamadas da interface de programação de aplicações (API) do Amazon EC2 para configurar as interfaces de rede e os endereços IP necessários para a conectividade de Pod. À medida que os clusters aumentam de tamanho, a frequência dessas chamadas de API podem levar a tempos de execução de instâncias e Pod maiores. Isso resulta em atrasos na escalabilidade para atender à demanda de workloads grandes e com alto pico, além de adicionar custos e despesas gerais de gerenciamento, pois você precisará provisionar clusters e VPCs adicionais para atender aos requisitos de escalabilidade. Para obter mais informações, consulte Limites de escalabilidade do Kubernetes no GitHub.

Considerações

  • Cada instância do Amazon EC2 oferece suporte um número máximo de Pods. Se o grupo de nós gerenciados consistir em vários tipos de instância, o menor número de Pods máximos para uma instância no cluster é aplicado a todos os nós do cluster.

  • Por padrão, o número máximo de Pods que podem ser executados em um nó é 110, mas esse número pode ser alterado. Se você alterar o número e tiver um grupo de nós gerenciados existente, a próxima atualização da AMI ou do modelo de execução do seu grupo de nós resultará no surgimento de novos nós com o valor alterado.

  • Ao fazer a transição da atribuição de endereços IP para a atribuição de prefixos IP, recomendamos criar novos grupos de nós para aumentar o número de endereços IP disponíveis, em vez de fazer uma substituição contínua dos nós existentes. A execução de Pods em um nó com endereços IP e prefixos atribuídos pode causar inconsistência na capacidade de endereço IP anunciada, afetando as futuras workloads no nó. Para saber a forma recomendada de realizar a transição, consulte Substituir todos os nós durante a migração do modo de IP secundário para o modo de delegação de prefixo ou vice-versa no guia de práticas recomendadas do Amazon EKS.

  • Para clusters somente com nós Linux.

    • Depois de configurar o complemento para atribuir prefixos a interfaces de rede, você não poderá fazer downgrade do complemento Amazon VPC CNI plugin for  Kubernetes para uma versão inferior à 1.9.0 (ou 1.10.1) sem remover todos os nós em todos os grupos de nós do cluster.

    • Se você usa grupos de segurança para Pods, com POD_SECURITY_GROUP_ENFORCING_MODE = standard e AWS_VPC_K8S_CNI_EXTERNALSNAT =false, quando seus Pods se comunicarem com endpoints fora da VPC, os grupos de segurança do nó serão usados, em vez de quaisquer grupos de segurança que você possa ter atribuído a seus Pods.

      Se você também estiver usando grupos de segurança para Pods, com POD_SECURITY_GROUP_ENFORCING_MODE =strict, quando seus Pods se comunicarem com endpoints fora da sua VPC, os grupos de segurança do Pod's serão usados.

Pré-requisitos

  • 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. 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ão 1.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ã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 mais informações, consulte as seções de atualização de Trabalhando com o complemento Amazon VPC CNI plugin for Kubernetes do Amazon EKS.

  • 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 substituindo my-cluster no comando a seguir pelo nome do seu cluster e, em seguida, executando 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 do Windows em clusters do EKS.

Para aumentar a quantidade de endereços IP disponíveis para seus nós do Amazon EC2

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

    1. 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ão 1.10.1 ou superior do complemento Amazon VPC CNI plugin for 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 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.

    2. 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 você não especificou um ID de AMI, e estiver usando uma versão do Amazon VPC CNI plugin for Kubernetes equivalente ou superior às versões listadas nos pré-requisitos, avance 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 Máximo recomendado de Pods do Amazon EKS para cada tipo de instância do Amazon EC2, adicionando --cni-prefix-delegation-enabled na 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 versão 1.21 ou superior 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 certa para você e qual é o valor a ser fornecido para ela, consulte WARM_PREFIX_TARGET, WARM_IP_TARGET e MINIMUM_IP_TARGET no GitHub.

      Você pode substituir os example values 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 com o Windows. Para as opções que incluem 110, substitua pelo valor da etapa 3 (recomendado) ou por seu próprio valor.

      • Autogerenciado: cria 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 lançamento ou com um modelo de lançamento sem um ID de AMI especificado – Conclua o procedimento em Criar um grupo de nós gerenciados para 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 ter mais informações, consulte Rede personalizada para pods.

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

    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 ativado 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 example values 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 Windows com pelo menos um tipo de instância do Nitro do 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 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 pelos seus valores máximos 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.

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

  3. 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 dos nós retornados na saída da etapa 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 144 endereços IP estejam disponíveis.