Executando clusters IPv6 EKS

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á.

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á.

O IPv6 modo EKS in resolve o desafio de IPv4 exaustão que geralmente se manifesta em clusters EKS de grande escala. O suporte do EKS para IPv6 está focado em resolver o problema de IPv4 exaustão, 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 IPv4IPv6 Kubernetes/dual-stack. O IPv6 EKS/também fornecerá a flexibilidade de interconectar os limites da rede, minimizando IPv6 CIDRs assim as chances de sofrer sobreposição de CIDR, resolvendo assim um problema duplo (dentro do cluster, entre clusters). Ao implantar clusters EKS no IPv6 modo (--ip-family ipv6), a ação não é reversível. Em palavras simples, o IPv6 suporte ao EKS está habilitado durante toda a vida útil do seu cluster.

Em um cluster IPv6 EKS, os pods e os serviços receberão IPv6 endereços enquanto mantêm a compatibilidade com IPv4 endpoints antigos. Isso inclui a capacidade de IPv4 endpoints externos acessarem serviços no cluster e pods acessarem endpoints externos. IPv4

O IPv6 suporte do Amazon EKS aproveita os recursos nativos da IPv6 VPC. Cada VPC é alocada com um prefixo de IPv4 endereço (o tamanho do bloco CIDR pode ser de /16 a /28) e um prefixo de endereço /56 exclusivo (fixo) de dentro do GUA ( IPv6 endereço unicast global) da Amazon; você pode atribuir um prefixo de endereço /64 a cada sub-rede em sua VPC. IPv4 recursos, como tabelas de rotas, listas de controle de acesso à rede, peering e resolução de DNS, funcionam da mesma forma em uma IPv6 VPC habilitada. 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 que oferece suporte a clusters baseados em EKS/: IPV4 IPv6 IPv6

No IPv6 mundo, todo endereço é roteável pela Internet. Por padrão, a VPC aloca IPv6 CIDR do intervalo público do GUA. No entanto, desde agosto de 2024, você também pode usar IPv6 endereçamento privado VPCs e sub-redes com o Amazon VPC IP Address Manager (IPAM). Consulte esta publicação no blog da AWS Networking e a documentação da VPC para obter mais informações.

O diagrama a seguir mostra um fluxo de saída de IPv6 Internet do Pod dentro de um cluster IPv6 EKS/:

As melhores práticas para implementar IPv6 sub-redes podem ser encontradas no guia do usuário da VPC.

Em um cluster IPv6 EKS, nós e pods recebem IPv6 endereços públicos. O EKS atribui IPv6 endereços a serviços com base em endereços IPv6 unicast locais exclusivos (ULA). O CIDR do serviço ULA para um IPv6 cluster é atribuído automaticamente durante o estágio de criação do cluster e não pode ser especificado, ao contrário IPv4 de. O diagrama a seguir mostra um padrão básico de plano de dados do plano de controle de cluster IPv6 baseado em EKS/S:

Visão geral

O EKS/ só IPv6 é suportado no modo de prefixo (modo de atribuição de IP ENI do plug-in VPC-CNI). Saiba mais sobre o Modo de prefixo.

A atribuição de prefixo só funciona em EC2 instâncias baseadas em Nitro, portanto, o EKS/ só IPv6 é suportado quando o plano de dados do cluster usa instâncias baseadas em Nitro. EC2

Em palavras simples, um IPv6 prefixo de /80 (por nó de trabalho) produzirá aproximadamente 10^14 IPv6 endereços. O fator limitante não será IPs mais a densidade do pod (em termos de recursos).

IPv6 a atribuição de prefixo ocorre apenas no momento do bootstrap do EKS worker-node. Sabe-se que esse comportamento atenua cenários em que IPv4 clusters EKS/S de alta rotatividade de Pod geralmente atrasam o agendamento de Pod devido a chamadas de API limitadas geradas pelo plug-in VPC CNI (ipamd) com o objetivo de alocar endereços privados em tempo hábil. IPv4 Também é conhecido por fazer com que os botões avançados do plug-in VPC-CNI ajustem WARM_IP/ENI, MINIMUM_IP desnecessariamente.

O diagrama a seguir amplia uma interface de rede elástica ( IPv6 ENI) de nó de trabalho:

Cada nó de trabalho do EKS é atribuído com IPv6 endereços IPv4 e, juntamente com as entradas de DNS correspondentes. Para um determinado nó de trabalho, somente um único IPv4 endereço da sub-rede de pilha dupla é consumido. O suporte do EKS IPv6 permite que você se comunique com IPv4 endpoints (AWS, no local, Internet) por meio de um modelo somente de saída altamente opinativo. IPv4 O EKS implementa um plug-in CNI local do host, secundário ao plug-in VPC CNI, que aloca e configura um endereço para um pod. IPv4 O plug-in CNI configura um IPv4 endereço não roteável específico do host para um pod da faixa 169.254.172.0/22. O IPv4 endereço atribuído ao pod é exclusivo para o nó de trabalho e não é anunciado além do nó de trabalho. 169.254.172.0/22 fornece até 1024 endereços exclusivos que podem oferecer suporte a tipos de instâncias grandes. IPv4

O diagrama a seguir mostra o fluxo de um IPv6 pod conectado a um IPv4 endpoint 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 IPv4 endereço exclusivo exclusivo do Pod será traduzido por meio da tradução de endereços de rede de origem (SNAT) para o endereço privado ( IPv4 VPC) da interface de rede primária conectada ao nó de trabalho. EC2

O IPv6 EKS/Pods também precisará se conectar a IPv4 endpoints pela Internet usando IPv4 endereços públicos, para que exista um fluxo semelhante. O diagrama a seguir mostra o fluxo de um IPv6 pod conectado a um IPv4 endpoint 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 IPv4 endereço exclusivo exclusivo do Pod será traduzido por meio da tradução de endereços de rede de origem (SNAT) para o endereço privado ( IPv4 VPC) da interface de rede primária conectada ao nó de trabalho. EC2 O IPv4 endereço do pod (fonte IPv4: IP EC2 primário) é então roteado para o gateway IPv4 NAT, onde o IP EC2 primário é traduzido (SNAT) em um endereço IP público roteável pela Internet válido (IP IPv4 público atribuído ao gateway NAT).

Qualquer Pod-to-Pod comunicação entre os nós sempre usa um IPv6 endereço. O VPC CNI configura iptables para IPv6 manipular enquanto bloqueia qualquer conexão. IPv4

Os serviços do Kubernetes receberão somente endereços IPv6 (ClusterIP) de endereços unicast locais exclusivos (ULA). IPv6 O CIDR do serviço ULA para um IPv6 cluster é atribuído automaticamente durante o estágio de criação do cluster EKS e não pode ser modificado. O diagrama a seguir mostra o fluxo do Pod to Kubernetes Service:

Os serviços são expostos à Internet usando um balanceador de carga da AWS. O balanceador de carga recebe IPv6 endereços públicos IPv4 e, também conhecido como balanceador de carga de pilha dupla. Para IPv4 clientes que acessam serviços de IPv6 cluster kubernetes, o balanceador de carga faz a tradução. IPv4 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 IPv4 usuário da Internet acessando um serviço baseado em IPv6 EKS/Ingress:

Comunicação do plano de dados do plano de controle EKS

O EKS provisionará contas cruzadas 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 ambos IPv4 e aos IPv6 endereços conectados à interface de rede primária de um nó. O servidor de API do Kubernetes se comunica com os pods e os componentes do node por meio do X-is. ENIs IPv6 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 IPv6 prefixo é 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 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 IPv4 exaustão, ela não será mais necessária. 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 EKS/Cluster IPv6

O EKS é compatível com IPv6 pods executados no Fargate. Os pods executados no Fargate consumirão IPv4 endereços IPv6 privados roteáveis da VPC extraídos dos intervalos CIDR da VPC (). IPv4 IPv6 Em palavras simples, você está EKS/Fargate Pods cluster wide density will be limited to the available IPv4 and IPv6 addresses. It is recommended to size your dual-stack subnets/VPC CIDRs pronto para o crescimento futuro. Você não poderá agendar novos Fargate Pods se a sub-rede subjacente não contiver um endereço disponível, independentemente dos IPv4 endereços disponíveis. IPv6

Implante o AWS Load Balancer Controller (LBC)

O controlador de serviço Kubernetes upstream em árvore não é compatível. IPv6 Recomendamos usar a versão mais recente do complemento AWS Load Balancer Controller. O LBC só implantará um NLB de pilha dupla ou um ALB de pilha dupla após consumir a definição correspondente de serviço/entrada do Kubernetes anotada com: e "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"

O AWS Network Load Balancer não oferece suporte a tipos de endereço de protocolo UDP de pilha dupla. Se você tem requisitos rigorosos de baixa latência, streaming em tempo real, jogos online e IoT, recomendamos a execução de clusters. IPv4 Para saber mais sobre como gerenciar verificações de saúde para serviços UDP, consulte “Como rotear o tráfego UDP para o Kubernetes”.