Otimizando a utilização do endereço IP - Amazon EKS

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

Otimizando a utilização do endereço IP

Os ambientes em contêineres estão crescendo em escala em um ritmo acelerado, graças à modernização dos aplicativos. Isso significa que cada vez mais nós e pods de trabalho estão sendo implantados.

O VPC CNI plug-in da Amazon atribui a cada pod um endereço IP VPC do CIDR (s). Essa abordagem fornece visibilidade total dos endereços do pod com ferramentas como registros de VPC fluxo e outras soluções de monitoramento. Dependendo do tipo de carga de trabalho, isso pode fazer com que um número substancial de endereços IP seja consumido pelos pods.

Ao projetar sua arquitetura AWS de rede, é importante otimizar o consumo de EKS IP da Amazon no nível do nó VPC e no nível do nó. Isso ajudará você a mitigar os problemas de exaustão de IP e a aumentar a densidade do pod por nó.

Nesta seção, discutiremos técnicas que podem ajudá-lo a atingir essas metas.

Otimize o consumo de IP em nível de nó

A delegação de prefixos é um recurso da Amazon Virtual Private Cloud (AmazonVPC) que permite atribuir IPv4 ou IPv6 prefixar suas instâncias do Amazon Elastic Compute Cloud (AmazonEC2). Ele aumenta os endereços IP por interface de rede (ENI), o que aumenta a densidade do pod por nó e melhora sua eficiência computacional. A delegação de prefixo também é compatível com redes personalizadas.

Para obter informações detalhadas, consulte as seções Delegação de prefixo com nós Linux e Delegação de prefixo com nós Windows.

Mitigue a exaustão de IP

Para evitar que seus clusters consumam todos os endereços IP disponíveis, é altamente recomendável dimensionar suas VPCs e suas sub-redes pensando no crescimento.

A adoção IPv6é uma ótima maneira de evitar esses problemas desde o início. No entanto, para organizações cujas necessidades de escalabilidade excedem o planejamento inicial e não podem ser adotadasIPv6, melhorar o VPC design é a resposta recomendada ao esgotamento do endereço IP. A técnica mais usada entre os EKS clientes da Amazon é adicionar um secundário não roteável CIDRs ao VPC e configurá-lo VPC CNI para usar esse espaço IP adicional ao alocar endereços IP aos pods. Isso geralmente é chamado de rede personalizada.

Abordaremos quais variáveis da Amazon VPC CNI você pode usar para otimizar o pool quente IPs atribuído aos seus nós. Encerraremos esta seção com alguns outros padrões de arquitetura que não são intrínsecos à Amazon, EKS mas que podem ajudar a mitigar o esgotamento de IP.

A adoção IPv6 é a maneira mais fácil de contornar as RFC1918 limitações; é altamente recomendável que você considere a adoção IPv6 como sua primeira opção ao escolher uma arquitetura de rede. IPv6fornece um espaço total de endereço IP significativamente maior, e os administradores de cluster podem se concentrar em migrar e escalar aplicativos sem se esforçar para contornar os limites. IPv4

EKSOs clusters da Amazon oferecem suporte IPv4 a ambos IPv6 e. Por padrão, os EKS clusters usam espaço IPv4 de endereço. Especificar um espaço de endereço IPv6 baseado no momento da criação do cluster permitirá o uso deIPv6. Em um IPv6 EKS cluster, pods e serviços recebem IPv6 endereços enquanto mantêm a capacidade de IPv4 endpoints legados se conectarem a serviços IPv6 executados em clusters e vice-versa. Toda a pod-to-pod comunicação dentro de um cluster sempre terminaIPv6. Dentro de a VPC (/56), o tamanho do IPv6 CIDR bloco para IPv6 sub-redes é fixado em /64. Isso fornece 2^64 (aproximadamente 18 quintilhões) de IPv6 endereços, permitindo escalar suas implantações. EKS

Para obter informações detalhadas, consulte a seção Running IPv6 EKS Clusters e, para obter experiência prática, consulte a EKS seção Compreendendo a IPv6 Amazon do workshop Get hands-on with. IPv6

EKSCluster em IPv6 modo

Otimize o consumo de IP em IPv4 clusters

Esta seção é dedicada aos clientes que estão executando aplicativos legados e/ou não estão prontos para migrarIPv6. Embora incentivemos todas as organizações a migrarem para IPv6 lá o mais rápido possível, reconhecemos que algumas ainda precisam procurar abordagens alternativas para escalar suas cargas de trabalho de contêineres. IPv4 Por esse motivo, também explicaremos os padrões arquitetônicos para otimizar IPv4 (RFC1918) o consumo de espaço de endereço com os EKS clusters da Amazon.

Plano de crescimento

Como primeira linha de defesa contra o esgotamento de IP, é altamente recomendável dimensionar suas sub-redes IPv4 VPCs e suas sub-redes pensando no crescimento, para evitar que seus clusters consumam todos os endereços IP disponíveis. Você não poderá criar novos pods ou nós se as sub-redes não tiverem endereços IP disponíveis suficientes.

Antes de criar VPC sub-redes, é recomendável trabalhar de trás para frente a partir da escala de carga de trabalho necessária. Por exemplo, quando clusters são criados usando eksctl (uma CLI ferramenta simples para criar e gerenciar clusters emEKS) /19 sub-redes são criadas por padrão. Uma máscara de rede de /19 é adequada para a maioria dos tipos de carga de trabalho, permitindo que mais de 8.000 endereços sejam alocados.

Importante

Quando você VPCs dimensiona as sub-redes, pode haver vários elementos (além de pods e nós) que podem consumir endereços IP, por exemplo, balanceadores de carga, RDS bancos de dados e outros serviços in-vpc.

Além disso, a Amazon EKS pode criar até 4 interfaces de rede elásticas (X-ENI) que são necessárias para permitir a comunicação com o plano de controle (mais informações aqui). Durante as atualizações do cluster, a Amazon EKS cria novos X- ENIs e exclui os antigos quando a atualização é bem-sucedida. Por esse motivo, recomendamos uma máscara de rede de pelo menos /28 (16 endereços IP) para sub-redes associadas a um cluster. EKS

Você pode usar a planilha de exemplo da Calculadora de EKS Sub-rede para planejar sua rede. A planilha calcula o uso do IP com base nas cargas de trabalho e na configuração. VPC ENI O uso do IP é comparado a uma IPv4 sub-rede para determinar se a configuração e o tamanho da sub-rede são suficientes para sua carga de trabalho. Lembre-se de que, se suas sub-redes ficarem VPC sem endereços IP disponíveis, sugerimos criar uma nova sub-rede usando os blocos originaisVPC. CIDR Observe que agora a Amazon EKS agora permite a modificação de sub-redes de cluster e grupos de segurança.

Expanda o espaço IP

Se você estiver prestes a esgotar o espaço RFC1918 IP, poderá usar o padrão de rede personalizada para conservar o roteável IPs agendando pods em sub-redes adicionais dedicadas. Embora a rede personalizada aceite um VPC intervalo válido para um CIDR intervalo secundário, recomendamos que você use CIDRs (/16) do NAT espaço CG-, 100.64.0.0/10 ou seja, 198.19.0.0/16 porque é menos provável que sejam usados em um ambiente corporativo do que RFC1918 os intervalos.

Para obter informações detalhadas, consulte a seção dedicada à rede personalizada.

Rede personalizada

Otimize a piscina IPs aquecida

Com a configuração padrão, o VPC CNI mantém um todo ENI (e associadoIPs) na piscina aquecida. Isso pode consumir um grande número deIPs, especialmente em tipos de instância maiores.

Se a sub-rede do cluster tiver um número limitado de endereços IP disponíveis, examine estas VPC CNI variáveis de ambiente de configuração:

  • WARM_IP_TARGET

  • MINIMUM_IP_TARGET

  • WARM_ENI_TARGET

Você pode configurar o valor de MINIMUM_IP_TARGET para corresponder aproximadamente ao número de pods que você espera executar em seus nós. Isso garantirá que, à medida que os pods forem criados, CNI eles possam atribuir endereços IP do pool aquecido sem chamar o. EC2 API

Lembre-se de que definir um valor WARM_IP_TARGET muito baixo causará chamadas adicionais para o EC2API, o que pode causar limitação das solicitações. Para clusters grandes, use junto com MINIMUM_IP_TARGET para evitar a limitação das solicitações.

Para configurar essas opções, você pode baixar o aws-k8s-cni.yaml manifesto e definir as variáveis de ambiente. No momento em que este artigo foi escrito, a versão mais recente está localizada aqui. Verifique se a versão do valor da configuração corresponde à VPC CNI versão instalada.

Atenção

Essas configurações serão redefinidas para os padrões quando você atualizar o. CNI Faça um backup doCNI, antes de atualizá-lo. Revise as configurações para determinar se você precisa reaplicá-las após a atualização ser bem-sucedida.

Você pode ajustar os CNI parâmetros rapidamente, sem tempo de inatividade para seus aplicativos existentes, mas deve escolher valores que suportem suas necessidades de escalabilidade. Por exemplo, se você estiver trabalhando com cargas de trabalho em lote, recomendamos atualizar o padrão WARM_ENI_TARGET para atender às necessidades de escala do pod. WARM_ENI_TARGETDefinir um valor alto sempre mantém o pool de IP aquecido necessário para executar grandes cargas de trabalho em lotes e, portanto, evitar atrasos no processamento de dados.

Atenção

Melhorar seu VPC design é a resposta recomendada ao esgotamento do endereço IP. Considere soluções como IPv6 SecondaryCIDRs. Ajustar esses valores para minimizar o número de Warm IPs deve ser uma solução temporária após a exclusão de outras opções. A configuração incorreta desses valores pode interferir na operação do cluster. Antes de fazer qualquer alteração em um sistema de produção, não deixe de revisar as considerações nesta página.

Monitore o inventário de endereços IP

Além das soluções descritas acima, também é importante ter visibilidade sobre a utilização do IP. Você pode monitorar o inventário de endereços IP das sub-redes usando o CNIMetrics Helper. Algumas das métricas disponíveis são:

  • número máximo que ENIs o cluster pode suportar

  • número de ENIs já alocados

  • número de endereços IP atualmente atribuídos aos pods

  • número total e máximo de endereços IP disponíveis

Você também pode definir CloudWatch alarmes para ser notificado se uma sub-rede estiver ficando sem endereços IP.

Atenção

Certifique-se de que a DISABLE_METRICS variável VPC CNI for esteja definida como falsa.

Outras considerações

Há outros padrões de arquitetura não intrínsecos à Amazon EKS que podem ajudar no esgotamento do IP. Por exemplo, você pode otimizar a comunicação VPCs ou compartilhar uma VPC entre várias contas para limitar a alocação de IPv4 endereços.

Saiba mais sobre esses padrões aqui:

📝 Edite esta página em GitHub