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 de endereços IP

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

O plug-in CNI do Amazon VPC atribui a cada pod um endereço IP do (s) CIDR (s) da VPC. Essa abordagem fornece visibilidade total dos endereços dos pods 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 na VPC e no nível do nó. Isso ajudará você a mitigar os problemas de esgotamento de IP e 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 no nível do nó

https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.htmlA delegação de prefixo é um recurso do 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 é suportada pela rede personalizada.

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 do 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 para pods. Isso geralmente é chamado de rede personalizada.

Abordaremos quais variáveis do CNI do Amazon VPC você pode usar para otimizar o pool quente de IPs atribuído aos seus nós. Encerraremos esta seção com alguns outros padrões arquitetônicos que não são intrínsecos ao Amazon EKS, mas podem ajudar a mitigar a exaustão 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 a adoção do IPv6 como sua primeira opção ao escolher uma arquitetura de rede. O IPv6 fornece um espaço total de endereços IP significativamente maior, e os administradores de clusters podem se concentrar na migração e no dimensionamento de aplicativos sem se esforçarem para contornar os limites de 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. A especificação de 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, os pods e os serviços recebem endereços IPv6, mantendo a capacidade dos endpoints IPv4 antigos de se conectarem a serviços executados em clusters IPv6 e vice-versa. Toda a comunicação entre pods em um cluster sempre ocorre por 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 IPv6. https://catalog.workshops.aws/ipv6-on-aws/en-US

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 de arquitetura para otimizar o consumo de espaço de endereços IPv4 (RFC1918) com clusters do 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 VPC e 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 ferramenta CLI simples para criar e gerenciar clusters no EKS) /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.

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 de 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 de planilha EKS Subnet Calculator para planejar sua rede. A planilha calcula o uso de IP com base nas cargas de trabalho e na configuração da VPC ENI. O uso de 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 agendando pods dentro de sub-redes adicionais dedicadas. Embora a rede personalizada aceite um intervalo de VPC válido para o intervalo CIDR secundário, recomendamos que você use CIDRs do espaço de endereço 100.64.0.0/10 compartilhado (RFC 6598), pois é menos provável que sejam usados em um ambiente corporativo do que os intervalos RFC1918. Por exemplo, você pode usar 100.64.0.0/16 como CIDR secundário para sua VPC. Consulte as restrições de associação de blocos CIDR IPv4 para ver os intervalos CIDR secundários permitidos.

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

Descoberta de sub-rede aprimorada

O Enhanced Subnet Discovery fornece uma alternativa de configuração de rede simplificada para a exaustão de IP, marcando novas sub-redes para que possam ser descobertas pelo CNI do Amazon VPC. 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 for 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 a descoberta avançada de sub-redes no blog de contêineres da AWS.

Otimize a piscina aquecida do IP

Com a configuração padrão, o VPC CNI mantém um ENI inteiro (e IPs associados) na piscina aquecida. Isso pode consumir um grande número de IPs, especialmente em tipos de instâncias 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 de perto ao número de pods que você espera executar em seus nós. Isso garantirá que, à medida que os pods sejam criados, a CNI possa atribuir endereços IP do pool aquecido sem chamar a API do EC2.

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

Você pode ajustar os parâmetros CNI rapidamente, 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_TARGETA configuração para 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.

Considerações adicionais

Há outros padrões arquitetônicos não intrínsecos ao Amazon EKS que podem ajudar na exaustão de 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: