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 que geralmente se manifesta 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 legados. Isso inclui a capacidade de endpoints IPv4 externos acessarem serviços em cluster e pods acessarem endpoints IPv4 externos.
O suporte IPv6 do Amazon EKS aproveita os recursos IPv6 nativos da VPC. 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 (endereço unicast global) da Amazon; você pode atribuir um prefixo de endereço /64 a cada sub-rede em sua VPC. Os recursos do IPv4, como tabelas de rotas, listas de controle de acesso à rede, peering 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 da VPC IPv4IPv6 que oferece suporte a clusters baseados: EKS/IPv6
No mundo do IPv6, todo endereço é roteável pela Internet. Por padrão, a VPC aloca CIDR IPv6 do intervalo público do 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
Em um cluster IPv6 EKS, 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 de 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á mais os IPs, mas a densidade do pod (em termos de recursos).
A atribuição do prefixo IPv6 ocorre somente no momento da inicialização do EKS worker-node. Sabe-se que esse comportamento atenua cenários em que EKS/IPv4 clusters de alta rotatividade de Pod geralmente atrasam o agendamento de Pod devido a chamadas limitadas de API geradas pelo plug-in VPC CNI (ipamd) com o objetivo de alocar endereços IPv4 privados em tempo hábil. Também é conhecido por ajustar os botões avançados do VPC-CNI plug-in WARM_IP/ENI, MINIMUM_IP,
O diagrama a seguir amplia uma interface de rede elástica (ENI) de nó de trabalho IPv6:
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, no local, Internet) por meio de um modelo IPv4 altamente opinativo, somente de saída. 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 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 tipos de instâncias grandes.
O diagrama a seguir mostra o fluxo de um pod IPv6 conectado a um endpoint IPv4 fora do limite do cluster (sem 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 de nós 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 nas sub-redes em que os pods estão sendo executados. EKS/IPv6 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 passa pela funcionalidade NAT64 do NAT Gateway (se incluída na arquitetura) em vez de permanecer na 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 de nós 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 é traduzido (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 enquanto bloqueia qualquer conexão IPv4.
Os serviços Kubernetes receberão somente endereços IPv6 (ClusteriP) de endereços IPv6 Unicast (ULA) locais exclusivos.
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 conhecidos como balanceador de carga de pilha dupla. Para clientes IPv4 que acessam serviços kubernetes do cluster IPv6, o balanceador de carga faz a conversão de IPv4 para IPv6.
O Amazon EKS recomenda executar 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 os 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 em EKS/IPv6 Ingress:
nota
O padrão acima exige a implantação da versão mais recente do controlador
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 nó do Kubernetes, como kubelet e kube-proxy, são configurados para oferecer suporte a pilha dupla. O Kubelet e o kube-proxy são executados no modo HostNetwork e se vinculam a endereços IPv4 e IPv6 conectados à interface de rede primária de um nó. O servidor de API do Kubernetes se comunica com pods e componentes de nós por meio do é baseado em 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 do 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 uma ID de AMI personalizada.
Você pode usar a fórmula a seguir para determinar o número máximo de pods que você pode implantar em um nó para um cluster IPv6 EKS.
((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 calculam automaticamente o 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 personalizada estiver habilitada no momento, o Amazon EKS recomenda reavaliar sua necessidade com IPv6. Se você optar por usar uma rede personalizada para resolver o problema de esgotamento do IPv4, ela não será mais necessária 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, recomendamos que envie uma solicitação de roteiro do EKS
Fargate Pods em cluster EKS/IPv6
O EKS oferece suporte a IPv6 para pods executados no Fargate. Os pods executados no Fargate consumirão endereços IPv6 e VPC Routable Private IPv4 extraídos dos intervalos CIDR da VPC (). IPv4IPv6 Em palavras simples, a densidade ampla do 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á programar novos Fargate Pods 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 em árvore não é compatível com IPv6. Recomendamos usar a versão mais recente do complemento"alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
