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á.
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 IPv4 atribuir IPv6 ou prefixar suas instâncias do Amazon Elastic Compute Cloud ( EC2Amazon). 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 adotadas 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 um secundário não roteável CIDRs à 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 de aquecimento 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 ao Amazon EKS, mas que podem ajudar a mitigar o esgotamento de IP.
Uso IPv6 (recomendado)
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 primeira opção ao escolher uma arquitetura de rede. 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. IPv4
Os clusters do Amazon EKS são compatíveis com IPv4 IPv6 e. Por padrão, os clusters EKS 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 de IPv6. Em um cluster IPv6 EKS, 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 termina IPv6. Em uma VPC (/56), o tamanho do bloco IPv6 CIDR para IPv6 sub-redes é fixado em /64. Isso fornece 2^64 (aproximadamente 18 quintilhões) de IPv6 endereços, permitindo escalar suas implantações no EKS.
Para obter informações detalhadas, consulte a seção Executando clusters do IPv6 EKS e, para obter experiência prática, consulte a seção Entendendo o IPv6 Amazon EKS do workshop Get
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 migrar IPv6. 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 clusters do Amazon EKS.
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 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
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, bancos de dados RDS e outros serviços in-vpc.
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 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 o exemplo da planilha EKS Subnet Calculator
Rede personalizada
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 intervalo VPC válido para o intervalo CIDR secundário, recomendamos que você use CIDRs (/16) do espaço CG-NAT, 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 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:
-
Associe um novo bloco CIDR à sua VPC.
-
Crie uma nova sub-rede no novo bloco CIDR e marque-a com “kubernetes”. io/role/cni” = “1".
-
Ative a configuração ENABLE_SUBNET_DISCOVERY do complemento CNI da Amazon VPC como “true” (padrão desde a versão 1.18.0).
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
Otimize a piscina IPs aquecida
Com a configuração padrão, a VPC CNI mantém uma ENI inteira (e associada IPs) 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:
-
WARM_IP_TARGET -
MINIMUM_IP_TARGET -
WARM_ENI_TARGET
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 aquecido sem chamar a EC2 API.
Lembre-se de que definir um valor WARM_IP_TARGET muito baixo causará chamadas adicionais para a EC2 API 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
Atenção
Essas configurações serão redefinidas para os padrões quando você atualizar o CNI. Faça um backup do CNI 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 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.
Atenção
Melhorar seu design de VPC é a resposta recomendada para o esgotamento do endereço IP. Considere soluções como IPv6 Secondary CIDRs. 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 CNI
-
número máximo de unidades ENIs que 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 para VPC CNI esteja definida como falsa.
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 VPCs ou compartilhar uma VPC em várias contas para limitar a alocação de IPv4 endereços.
Saiba mais sobre esses padrões aqui:
