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á.
Executando clusters IPv6 EKS
O EKS no modo IPv6 resolve o desafio de exaustão do IPv4, muitas vezes manifestado em clusters EKS de grande escala. O suporte do EKS para IPv6 está focado em resolver o problema de esgotamento do IPv4, que decorre do tamanho limitado do espaço de endereço IPv4. Essa é uma preocupação significativa levantada por vários de nossos clientes e é diferente do recurso de pilha dupla do Kubernetes. IPv4/IPv6
Em um cluster IPv6 EKS, os pods e os serviços receberão endereços IPv6, mantendo a compatibilidade com endpoints IPv4 antigos. Isso inclui a capacidade de endpoints IPv4 externos acessarem serviços no cluster e de pods acessarem endpoints IPv4 externos.
O suporte IPv6 do Amazon EKS aproveita os recursos nativos do VPC IPv6. Cada VPC é alocada com um prefixo de endereço IPv4 (o tamanho do bloco CIDR pode ser de /16 a /28) e um prefixo de endereço IPv6 /56 exclusivo (fixo) de dentro do GUA (Global Unicast Address) da Amazon; você pode atribuir um prefixo de endereço /64 a cada sub-rede em sua VPC. Os recursos IPv4, como tabelas de rotas, listas de controle de acesso à rede, emparelhamento e resolução de DNS, funcionam da mesma forma em uma VPC habilitada para IPv6. A VPC é então chamada de VPC de pilha dupla, seguindo as sub-redes de pilha dupla. O diagrama a seguir mostra o padrão básico de VPC IPv4IPv6 que oferece suporte a clusters baseados: EKS/IPv6
No mundo IPv6, cada endereço é roteável pela Internet. Por padrão, a VPC aloca CIDR IPv6 do intervalo público de GUA. No entanto, desde agosto de 2024,
O diagrama a seguir mostra um fluxo de saída de Internet IPv6 do Pod dentro de um cluster: EKS/IPv6
As melhores práticas para implementar sub-redes IPv6 podem ser encontradas no guia do usuário da VPC.
Em um cluster EKS IPv6, nós e pods recebem endereços IPv6 públicos. O EKS atribui endereços IPv6 a serviços com base em endereços Unicast IPv6 locais exclusivos (ULA). O CIDR do serviço ULA para um cluster IPv6 é atribuído automaticamente durante o estágio de criação do cluster e não pode ser especificado, ao contrário do IPv4. O diagrama a seguir mostra um padrão básico do plano de dados do plano de controle do cluster EKS/IPv6 baseado:
Visão geral do
EKS/IPv6 só é suportado no modo de prefixo (modo de atribuição de IP VPC-CNI Plug-in ENI). Saiba mais sobre o Modo de prefixo.
A atribuição de prefixo só funciona em instâncias do Nitro-based EC2, portanto, só EKS/IPv6 é suportada quando o plano de dados do cluster usa instâncias do EC2. Nitro-based
Em palavras simples, um prefixo IPv6 de /80 (por nó de trabalho) produzirá aproximadamente 10^14 endereços IPv6; o fator limitante não serão mais os IPs, mas a densidade do pod (em termos de recursos).
A atribuição do prefixo IPv6 ocorre somente no momento do bootstrap do nó de trabalho do EKS. Sabe-se que esse comportamento atenua cenários em que EKS/IPv4 clusters com alta rotatividade de Pod geralmente atrasam o agendamento de pods devido a chamadas de API limitadas geradas pelo plug-in VPC CNI (ipamd) com o objetivo de alocar endereços IPv4 privados em tempo hábil. Também é conhecido por fazer o ajuste avançado dos botões do VPC-CNI plug-in WARM_IP/ENI,
O diagrama a seguir amplia uma interface de rede elástica (ENI) IPv6 de nó de trabalho:
Cada nó de trabalho do EKS é atribuído com endereços IPv4 e IPv6, junto com as entradas DNS correspondentes. Para um determinado nó de trabalho, somente um único endereço IPv4 da sub-rede de pilha dupla é consumido. O suporte do EKS para IPv6 permite que você se comunique com endpoints IPv4 (AWS, local, internet) por meio de um modelo IPv4 somente de saída altamente opinativo. O EKS implementa um plug-in CNI local do host, secundário ao plug-in VPC CNI, que aloca e configura um endereço IPv4 para um pod. O plug-in CNI configura um endereço IPv4 não roteável específico do host para um pod a partir do 169.254.172. 0/22 alcance. O endereço IPv4 atribuído ao pod é exclusivo do nó de trabalho e não é anunciado além do nó de trabalho. 169.254.172. 0/22 fornece até 1024 endereços IPv4 exclusivos que podem oferecer suporte a grandes tipos de instância.
O diagrama a seguir mostra o fluxo de um pod IPv6 se conectando a um endpoint IPv4 fora do limite do cluster (fora da Internet):
No diagrama acima, os pods realizarão uma pesquisa de DNS para o endpoint e, ao receber uma resposta IPv4 “A”, o endereço IPv4 exclusivo somente do nó do pod será traduzido por meio da tradução de endereço de rede de origem (SNAT) para o endereço IPv4 privado (VPC) da interface de rede primária conectada ao EC2. Worker-node
nota
O padrão acima exige que o DNS64 seja desativado em sub-redes nas quais EKS/IPv6 os pods estão em execução. Quando o DNS64 está habilitado, o resolvedor de DNS retorna um endereço IPv6 sintetizado para IPv4-only endpoints junto com um endereço IPv4. Como resultado, o tráfego percorre a funcionalidade NAT64 do NAT Gateway (se incluída na arquitetura) em vez de permanecer dentro da VPC, conforme mostrado no padrão acima. Isso pode levar ao uso inesperado do NAT Gateway e aos custos associados.
EKS/IPv6 Os pods também precisarão se conectar a endpoints IPv4 pela Internet usando endereços IPv4 públicos para que exista um fluxo semelhante. O diagrama a seguir mostra o fluxo de um pod IPv6 conectado a um endpoint IPv4 fora do limite do cluster (roteável pela Internet):
No diagrama acima, os pods realizarão uma pesquisa de DNS para o endpoint e, ao receber uma resposta IPv4 “A”, o endereço IPv4 exclusivo somente do nó do pod será traduzido por meio da tradução de endereço de rede de origem (SNAT) para o endereço IPv4 privado (VPC) da interface de rede primária conectada ao EC2. Worker-node O endereço IPv4 do pod (IPv4 de origem: IP primário do EC2) é então roteado para o gateway NAT IPv4, onde o IP primário do EC2 é convertido (SNAT) em um endereço IP público IPv4 roteável pela Internet válido (IP público atribuído ao gateway NAT).
Qualquer Pod-to-Pod comunicação entre os nós sempre usa um endereço IPv6. O VPC CNI configura o iptables para lidar com IPv6 e, ao mesmo tempo, bloquear qualquer conexão IPv4.
Os serviços Kubernetes receberão somente endereços IPv6 (ClusterIP) de endereços Unicast IPv6 locais exclusivos (ULA).
Os serviços são expostos à Internet usando um balanceador de carga da AWS. O balanceador de carga recebe endereços IPv4 e IPv6 públicos, também conhecido como balanceador de carga de pilha dupla. Para clientes IPv4 que acessam serviços kubernetes de cluster IPv6, o balanceador de carga faz a tradução de IPv4 para IPv6.
O Amazon EKS recomenda a execução de nós de trabalho e pods em sub-redes privadas. Você pode criar balanceadores de carga públicos nas sub-redes públicas que balanceiam a carga do tráfego para pods executados em nós que estão em sub-redes privadas. O diagrama a seguir mostra um usuário IPv4 da Internet acessando um serviço baseado no EKS/IPv6 Ingress:
nota
O padrão acima exige a implantação da versão mais recente
Comunicação do plano de dados do plano de controle EKS
O EKS provisionará Cross-Account ENIs (X-ENIs) no modo de pilha dupla ()IPv4/IPv6. Os componentes do node do Kubernetes, como kubelet e kube-proxy, são configurados para oferecer suporte ao dual stack. O Kubelet e o kube-proxy são executados no modo HostNetwork e vinculam-se aos endereços IPv4 e IPv6 anexados à interface de rede primária de um nó. O servidor de API Kubernetes se comunica com pods e componentes de nós por meio do IPv6. X-ENIs Os pods se comunicam com os servidores de API por meio do X-ENIs, e a comunicação de pod para servidor de API sempre usa o modo IPv6.
Recomendações
Programação com base em recursos computacionais
Um único prefixo IPv6 é suficiente para executar vários pods em um único nó. Isso também remove efetivamente as limitações de ENI e IP no número máximo de pods em um nó. Embora o IPv6 remova a dependência direta dos Max-pods, ao usar anexos de prefixo com tipos de instância menores, como o m5.large, é provável que você esgote os recursos de CPU e memória da instância muito antes de esgotar seus endereços IP. Você deve definir manualmente o valor máximo de pod recomendado pelo EKS se estiver usando grupos de nós autogerenciados ou um grupo de nós gerenciados com um ID de AMI personalizado.
Você pode usar a fórmula a seguir para determinar o número máximo de pods que podem ser implantados em um nó para um cluster EKS IPv6.
((Number of network interfaces for instance type (number of prefixes per network interface-1)* 16) + 2
((3 ENIs)_((10 secondary IPs per ENI-1)_ 16)) + 2 = 460 (real)
Os grupos de nós gerenciados realizam automaticamente o cálculo do número máximo de pods para você. Evite alterar o valor recomendado do EKS para o número máximo de pods para evitar falhas no agendamento de pods devido a limitações de recursos.
Avalie a finalidade da rede personalizada existente
Se a rede https://docs.aws.amazon.com/eks/latest/best-practices/custom-networking.html personalizada estiver habilitada atualmente, o Amazon EKS recomenda reavaliar sua necessidade com IPv6. Se você optar por usar redes personalizadas para resolver o problema de esgotamento do IPv4, isso não será mais necessário com o IPv6. Se você estiver utilizando uma rede personalizada para atender a um requisito de segurança, como uma rede separada para nós e pods, é recomendável enviar uma solicitação de roteiro do EKS.
Pods Fargate em cluster EKS/IPv6
O EKS suporta IPv6 para pods em execução no Fargate. Os pods em execução no Fargate consumirão endereços IPv6 e IPv4 privados roteáveis da VPC gravados nos intervalos CIDR da VPC (). IPv4IPv6 Em palavras simples, a grande densidade do seu cluster de EKS/Fargate pods será limitada aos endereços IPv4 e IPv6 disponíveis. É recomendável dimensionar seus subnets/VPC CIDRs de pilha dupla para crescimento futuro. Você não poderá agendar novos pods Fargate se a sub-rede subjacente não contiver um endereço IPv4 disponível, independentemente dos endereços IPv6 disponíveis.
Implante o AWS Load Balancer Controller (LBC)
O controlador de serviço Kubernetes upstream in-tree não oferece suporte a IPv6. Recomendamos usar a versão mais recente "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
