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 plug-in CNI da Amazon VPC atribui a cada pod um endereço IP do (s) CIDR (s) da VPC. Essa abordagem fornece visibilidade total dos endereços do pod com ferramentas como VPC Flow Logs 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 de rede da AWS, é importante otimizar o consumo de IP do Amazon EKS no 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 (Amazon VPC) que permite atribuir prefixos IPv4 ou IPv6 às suas instâncias do Amazon Elastic Compute Cloud (Amazon EC2). 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.

Mitigar exaustão de IP

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

A adoção do 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 adotar o IPv6, melhorar o design da VPC é a resposta recomendada ao esgotamento do endereço IP. A técnica mais usada entre os clientes do Amazon EKS é adicionar CIDRs secundários não roteáveis à VPC e configurar a CNI da VPC para usar esse espaço IP adicional ao alocar endereços IP aos pods. Isso geralmente é chamado de rede personalizada.

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

Use IPv6 (recomendado)

A adoção do IPv6 é a maneira mais fácil de contornar as limitações do RFC1918; é altamente recomendável que você considere adotar o IPv6 como sua primeira opção ao escolher uma arquitetura de rede. O IPv6 fornece 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 do IPv4.

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

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

Otimize o consumo de IP em clusters IPv4

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

Plano de crescimento

Como primeira linha de defesa contra o esgotamento de IP, é altamente recomendável dimensionar suas VPCs e sub-redes IPv4 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 a VPC e as sub-redes, é recomendável retroceder a partir da escala de carga de trabalho necessária. Por exemplo, quando os clusters são criados usando eksctl (uma ferramenta CLI simples para criar e gerenciar clusters no EKS), as sub-redes /19 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.

Além disso, o 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, o Amazon EKS cria novas X-ENIs e exclui as antigas 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 o exemplo da planilha EKS Subnet Calculator para planejar sua rede. A planilha calcula o uso do IP com base nas cargas de trabalho e na configuração do VPC ENI. O uso do IP é comparado a uma sub-rede IPv4 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 as sub-redes em sua VPC ficarem sem endereços IP disponíveis, sugerimos criar uma nova sub-rede usando os blocos CIDR originais da VPC. Observe que agora o Amazon EKS agora permite a modificação de sub-redes de cluster e grupos de segurança.

Rede personalizada

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

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

Descoberta aprimorada de sub-rede

O Enhanced Subnet Discovery fornece uma alternativa simplificada de configuração de rede para o esgotamento de IP, marcando novas sub-redes para que possam ser descobertas pela CNI da Amazon VPC. Com o Enhanced Subnet Discovery, as cargas de trabalho atuais podem continuar em execução nas mesmas sub-redes e o Amazon Elastic Kubernetes Service (Amazon EKS) agora pode programar pods adicionais nas novas “sub-redes utilizáveis”.

Se as sub-redes atuais do seu cluster estiverem ficando sem endereços IP, você pode simplesmente adicionar outras sub-redes ao seu cluster Amazon EKS da seguinte forma:

Depois que o Enhanced Subnet Discovery estiver habilitado em seus clusters VPC e Amazon EKS, novas interfaces de rede elástica (ENIs) serão anexadas aos seus nós do Amazon EKS, conforme descrito no diagrama a seguir:

Para obter mais informações, consulte Amazon VPC CNI apresenta o Enhanced Subnet Discovery no blog de contêineres da AWS.

Otimize a piscina aquecida do IP

Com a configuração padrão, a VPC CNI mantém uma ENI inteira (e IPs associados) no pool aquecido. Isso pode consumir um grande número de IPs, especialmente em tipos de instância maiores.

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

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

Lembre-se de que definir um valor WARM_IP_TARGET muito baixo causará chamadas adicionais para a API do EC2 e isso poderá 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 à versão da VPC CNI instalada.

Você pode ajustar os parâmetros da CNI em tempo real, sem tempo de inatividade para seus aplicativos existentes, mas deve escolher valores que atendam às 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.

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 CNI Metrics Helper. Algumas das métricas disponíveis são:

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

Outras considerações

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

Saiba mais sobre esses padrões aqui: