O blog da AWS

A jornada para o IPv6 no Amazon EKS: Fundação (Parte 1)

Por Srinivas Jasti, gerente sênior de produtos da Amazon Web Services.

Introdução

Escalar a rede do Kubernetes é fundamental para lidar com o crescimento de serviços e preparar a infraestrutura para o futuro, à medida que o cenário digital continua evoluindo. A necessidade de um endereço IP exclusivo por pod se soma aos desafios de espaço limitado de endereços IPv4. O pool finito de endereços IPv4 disponíveis geralmente força os administradores de cluster Kubernetes a usar alternativas, como Network Address Translation (NAT) ou rede de sobreposição. Essa prática geralmente leva a gargalos de desempenho e ao aumento da sobrecarga no gerenciamento. Usar o espaço de endereço IPv6 é uma maneira mais elegante de gerenciar clusters Kubernetes em grande escala. O IPv6 fornece um espaço total de endereço IP significativamente maior, que permite que os administradores de cluster escalem os aplicativos sem se esforçarem para contornar os limites do IPv4.

À medida que mais organizações continuam a conteinerizar suas aplicações, elas estão avaliando a adoção do IPv6. O esgotamento do espaço público de IPv4 é frequentemente percebido como o principal fator. Depois de conversar com alguns desses clientes, descobrimos que o espaço limitado de endereços IPv4 privado (ou seja, RFC1918) é muitas vezes o fator dominante.

O desafio

A adoção do IPv6 pode ajudar a simplificar a configuração da rede e ajudar a operar em grande escala. No entanto, muitos clientes do EKS ainda veem a jornada para a adoção do IPv6 como complexa. Entrevistando alguns deles, aprendemos sobre duas preocupações principais:

  • Suporte do IPv6 para serviços de rede da AWS
  • Interoperabilidade do Amazon Elastic Kubernetes Service (Amazon EKS) com IPv6 e IPv4 (modo híbrido)

Nesta série de blogs, tentaremos desmistificar as principais preocupações e fornecer diretrizes, referenciando arquiteturas que se concentram em ajudar os clientes a migrar clusters do Amazon EKS para a família de endereços IPv6. Está além desta série aprofundar o IPv6 na AWS. Para uma visão holística do IPv6 na AWS (ou seja, planejamento, arquitetura e serviços da AWS), recomendamos que você leia este whitepaper: IPv6 na AWS. Nesta parte da série, vamos nos concentrar na fundação do IPv6 sobre a qual o Amazon EKS é construído.

Kubernetes e IPv6

A abordagem do Kubernetes upstream para IPv6 é uma rede de pilha dupla para pods e serviços.

Essencialmente, cada pod e serviço pode receber um endereço IPv4 e IPv6 roteável. Isso é conhecido como pod e serviço de pilha dupla.

A principal vantagem dessa abordagem é que os pods podem se conectar a endpoints IPv4 ou IPv6 sem depender de construções, como NAT64 ou DNS64, ou sem a necessidade de uma camada de interoperabilidade de passagem.

Consequentemente, essa abordagem de pilha dupla significa que cada pod consome um endereço IPv6 válido e um endereço IPv4 privado da sua Amazon Virtual Private Cloud (Amazon VPC) associada à sub-rede de pilha dupla. Essencialmente, isso significa que, de alguma forma, estamos de volta à estaca zero, enfrentando desafios de esgotamento do IPv4 privado e redes de sobreposição.

O Amazon EKS adotou uma abordagem diferente para oferecer suporte ao IPv6 e ainda não oferece suporte à abordagem de pilha dupla do Kubernetes upstream.

Amazon EKS e IPv6

Trabalhando baseado nos requisitos de nossos clientes, a equipe do Amazon EKS criou um mecanismo opinativo para oferecer suporte aos clusters baseados em IPv6 do Amazon EKS que seguem os cinco princípios a seguir:

  1. Permite a comunicação nativa IPv6 de Pod para Pod/Serviço no cluster.
  2. Permite que um Pod IPv6 se conecte perfeitamente (sem a sobrecarga do NAT64/DNS64) a um endpoint IPv4 (entre clusters/VPCs, internet, dentro da VPC, na região).
  3. Os pods IPv6 se conectando a endpoints IPv4 não consomem endereços IPv4 privados roteáveis das sub-redes VPC subjacentes, reduzindo assim o problema de esgotamento do espaço de endereçamento IPv4 privado.
  4. Permite que os clusters IPv4 do Amazon EKS coexistam com os clusters IPv6 do Amazon EKS. Portanto, os pods nos clusters IPv4 do Amazon EKS podem se conectar perfeitamente aos pods nos clusters IPv6 do Amazon EKS, sem construções externas de IPv4 para IPv6.
  5. Permite que os endpoints IPv4 e IPv6 se conectem aos pods IPv6 do Amazon EKS com balanceamento de carga, permitindo perfeitamente a entrada de dados de IPv4 para IPv6.

Os princípios acima são implementados por meio da implantação de um cluster EKS no modo IPv6 usando o plug-in VPC CNI da Amazon, que se integra completamente aos conceitos de pilha dupla do Amazon VPC. Para conectividade de entrada (ou seja, princípio 5), o Load Balancer Controller do Amazon EKS (LBC) é usado para consumir anotações específicas no serviço/ingress, o que resulta em um Network Load Balancer (NLB) ou Application Load Balancer (ALB) de pilha dupla.

Vamos nos aprofundar na arquitetura real com base nesses princípios.

Visão geral da solução

Etapa 1: A fundação

Na AWS, existem três modos de rede IP conhecidos que as Elastic Network Interfaces (ENI) podem operar: somente IPv4, somente IPv6 e pilha dupla. Primeiro, você precisa criar uma VPC de pilha dupla. No modo de pilha dupla, os recursos podem se comunicar por IPv4 e IPv6. Não é necessária uma camada de interoperabilidade separada.

Os clusters do Amazon EKS baseados em IPv6 suportam somente o modo VPC de pilha dupla. No modo VPC de pilha dupla, o VPC-CNI é a camada de interoperabilidade.

O diagrama a seguir mostra um modelo de VPC de pilha dupla:

VPC de pilha dupla como base obrigatória para clusters IPv6 do Amazon EKS                                          Figura 1: VPC de pilha dupla como base obrigatória para clusters IPv6 do Amazon EKS

Uma VPC de pilha dupla oferece suporte a blocos de endereços IPv4 e IPv6, conhecidos como CIDRs (Classless Inter-Domain Routing), em suas sub-redes. As sub-redes são criadas com blocos CIDRs alinhados aos intervalos IPv4 e IPv6 alocados, garantindo que os recursos possam se comunicar usando os dois tipos de endereço na mesma infraestrutura de VPC. Quando uma instância do Amazon Elastic Compute Cloud (Amazon EC2) é criada em uma sub-rede de pilha dupla, a ENI do Amazon EC2 consome um único endereço IPv4 e um endereço IPv6, que basicamente é chamado de instância do Amazon EC2 de pilha dupla.

Etapa 2: Cluster IPv6 do Amazon EKS

Depois que a Etapa 1 (ou seja, a VPC base) for criada conforme descrito anteriormente (Figura 1), podemos prosseguir com a implantação de um cluster IPv6 do Amazon EKS. Então, o que significa esse Amazon EKS no modo IPv6?

O Amazon EKS no modo IPv6 significa simplesmente:

  • O control plane do Amazon EKS é criado com a opção de API –ip-family ipv6. Além do control plane do Amazon EKS, as operações normais de bootstrap no serviço Amazon EKS alocarão um endereço IPv6 Unique Local Address (ULA) imutável. Esse intervalo IPv6 não pode ser roteado publicamente e será usado para atribuir endereços IPv6 para serviços no Kubernetes (ou seja, ClusterIP), que são somente IPv6 (veja 1 na Figura 2).
  • Quando os worker nodes do Amazon EKS são inicializados em sub-redes de pilha dupla (veja 2 na Figura 2) como parte do data plane do Amazon EKS, por padrão, a Amazon VPC CNI tentará criar e anexar um prefixo /80. Isso pode gerar cerca de 10^14 endereços IPv6 para pods — a exaustão de IP foi resolvida!

Qualquer pod criado nesse Amazon EC2 worker node de pilha dupla receberá um endereço IPv6 alocado a partir do prefixo /80. (Veja as etapas A a C no lado esquerdo da Figura 2).Cluster IPv6 do Amazon EKS sobre a VPC de pilha dupla obrigatória

                                                          Figura 2: Cluster IPv6 do Amazon EKS sobre a VPC de pilha dupla obrigatória

Aqui, é importante observar que todas as outras construções do Amazon EC2 e da VPC, como grupos de segurança do Amazon EC2, tabelas de roteamento e listas de controle de acesso de rede (NACLs) oferecem suporte ao IPv6. Você pode usar grupos de segurança do Amazon EC2 para definir regras que permitem tráfego de entrada e saída de rede de e para pods IPv6 diretamente.

Além disso, há uma consideração importante quando se trata de configurar a saída IPv6 para a Internet. Os endereços IPv6 são roteáveis publicamente. Portanto, para que os pods IPv6 saiam para a Internet, é recomendável criar um Egress-Only-Internet-Gateway (EIGW) e conectá-lo à VPC de pilha dupla e, em seguida, configurar a rota padrão IPv6 apropriada na tabela de roteamento da sub-rede (Figura 1). O NAT Gateway ainda é usado para permitir publicamente que endpoints IPv4 privados se conectem à Internet.

Depois que as etapas 1 e 2 forem concluídas e um cluster Amazon EKS baseado em IPv6 estiver configurado, os princípios agora estarão em ação. Experimente e crie um cluster Amazon EKS com nosso blueprint de terraform para EKS/IPv6.

Conclusão

Neste post, abordamos uma visão geral dos aspectos fundamentais de um cluster IPv6 do Amazon EKS. Explicamos como o Amazon EKS ajuda nossos clientes a criar clusters escaláveis usando IPv6, resolvendo o desafio do espaço limitado de endereços IPv4. O Amazon EKS no IPv6 ajuda a reduzir a sobrecarga operacional, mitigando a necessidade de camadas de interoperabilidade injustificadas desde o início e permitindo a comunicação com qualquer endpoint IPv4, bem como com serviços da AWS que suportam IPv6. É altamente recomendável que você comece a adotar o Amazon EKS/IPv6 hoje, em vez de esperar que toda a migração IPv6 organizacional se materialize. Nos próximos dois posts, vamos nos aprofundar nos padrões comuns de implementação e estratégias de migração.

Biografia do Autor
Srinivas Jasti Srinivas Jasti é gerente sênior de produtos da Amazon Web Services, com foco em Kubernetes e entrega de soluções que ajudam os clientes a acelerar sua jornada de modernização na AWS. Ele tem mais de uma década fde experiência na criação de produtos nos setores de redes corporativas, segurança e indústrias Wireless.

Biografia do Tradutor

Julius Maia é Gerente Técnico de Contas focado em clientes estratégicos de Media e Entretenimento localizados na Irlanda e Reino Unido. Julius é apaixonado por containers e cultura DevOps e acredita que “Conhecimento é poder”. Em seu tempo livre, Julius gosta de acampar, fazer trilhas e jogar video game.