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

Rede personalizada

Por padrão, o Amazon VPC CNI atribuirá aos pods um endereço IP selecionado na sub-rede primária. A sub-rede primária é a sub-rede CIDR à qual a ENI primária está conectada, geralmente a sub-rede do. node/host

Se o CIDR da sub-rede for muito pequeno, talvez o CNI não consiga adquirir endereços IP secundários suficientes para atribuir aos seus pods. Esse é um desafio comum para clusters IPv4 do EKS.

A rede personalizada é uma solução para esse problema.

A rede personalizada resolve o problema de exaustão de IP atribuindo os IPs do nó e do pod a partir de espaços de endereço VPC secundários (CIDR). O suporte de rede personalizado oferece suporte ao recurso personalizado EniConfig. O EniConfig inclui um intervalo CIDR de sub-rede alternativo (criado a partir de um CIDR de VPC secundário), junto com os grupos de segurança aos quais os pods pertencerão. Quando a rede personalizada está habilitada, o VPC CNI cria ENIs secundários na sub-rede definida em ENIConfig. O CNI atribui aos pods um endereço IP de um intervalo CIDR definido em um CRD eniConfig.

Como o ENI primário não é usado por redes personalizadas, o número máximo de pods que você pode executar em um nó é menor. Os pods da rede host continuam usando o endereço IP atribuído ao ENI primário. Além disso, o ENI primário é usado para lidar com a tradução da rede de origem e rotear o tráfego de pods para fora do nó.

Exemplo de configuração

Embora a rede personalizada aceite um intervalo de VPC válido para o intervalo CIDR secundário, recomendamos que você use CIDRs do espaço de endereço 100.64.0.0/10 compartilhado (RFC 6598), pois é menos provável que sejam usados em um ambiente corporativo do que outros intervalos RFC1918. Por exemplo, você pode usar 100.64.0.0/16 como CIDR secundário para sua VPC. Para obter informações adicionais sobre as associações de blocos CIDR permitidas e restritas que você pode usar com sua VPC, consulte Restrições de associação de blocos CIDR IPv4 na seção de dimensionamento de VPC e sub-rede da documentação da VPC.

Conforme mostrado no diagrama abaixo, a interface de rede elástica (ENI) primária do nó de trabalho ainda usa o intervalo CIDR primário da VPC (neste caso, 10.0.0). 0/16), mas os ENIs secundários usam o intervalo CIDR VPC secundário (neste caso, 100.64.0). 0/16). Agora, para que os Pods usem o 100.64.0. 0/16 Intervalo CIDR, você deve configurar o plug-in CNI para usar redes personalizadas. Você pode seguir as etapas conforme documentado aqui.

Se você quiser que o CNI use redes personalizadas, defina a variável de AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG ambiente comotrue.

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

QuandoAWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true, o CNI atribuirá o endereço IP do pod a partir de uma sub-rede definida em. ENIConfig O recurso ENIConfig personalizado é usado para definir a sub-rede na qual os pods serão agendados.

apiVersion : crd.k8s.amazonaws.com/v1alpha1
kind : ENIConfig
metadata:
  name: us-west-2a
spec:
  securityGroups:
    - sg-0dff111a1d11c1c11
  subnet: subnet-011b111c1f11fdf11

Ao criar os recursos ENIconfig personalizados, você precisará criar novos nós de trabalho e drenar os nós existentes. Os nós de trabalho e pods existentes permanecerão inalterados.

Recomendações

Use redes personalizadas quando

Recomendamos que você considere uma rede personalizada se estiver lidando com o esgotamento do IPv4 e ainda não puder usar o IPv6. O suporte do Amazon EKS para o espaço RFC6598 permite que você escale os pods além do RFC1918 e resolva os desafios de exaustão. Considere usar a delegação de prefixo com redes personalizadas para aumentar a densidade de pods em um nó.

Você pode considerar uma rede personalizada se tiver um requisito de segurança para executar pods em uma rede diferente com requisitos de grupos de segurança diferentes. Quando a rede personalizada está ativada, os pods usam sub-redes ou grupos de segurança diferentes, conforme definido no ENIConfig, do que a interface de rede primária do nó.

A rede personalizada é, de fato, uma opção ideal para implantar vários clusters e aplicativos EKS para conectar serviços de datacenter local. Você pode aumentar o número de endereços privados (RFC1918) acessíveis ao EKS em sua VPC para serviços como o Amazon Elastic Load Balancing e NAT-GW, ao mesmo tempo, usar CG-NAT espaço não roteável para seus pods em vários clusters. A rede personalizada com o gateway de trânsito e uma VPC de serviços compartilhados (incluindo gateways NAT em várias zonas de disponibilidade para alta disponibilidade) permite que você forneça fluxos de tráfego escaláveis e previsíveis. Esta postagem do blog descreve um padrão arquitetônico que é uma das formas mais recomendadas de conectar pods EKS a uma rede de datacenter usando redes personalizadas.

Evite redes personalizadas quando

Pronto para implementar o IPv6

A rede personalizada pode atenuar os problemas de esgotamento de IP, mas exige sobrecarga operacional adicional. Se você está implantando atualmente uma VPC de pilha dupla (IPv4/IPv6) ou se seu plano inclui suporte a IPv6, recomendamos implementar clusters IPv6. Você pode configurar clusters EKS IPv6 e migrar seus aplicativos. Em um cluster EKS IPv6, tanto o Kubernetes quanto os pods obtêm um endereço IPv6 e podem se comunicar de entrada e saída com os endpoints IPv4 e IPv6. Consulte as melhores práticas para executar clusters EKS IPv6.

Espaço esgotado CG-NAT

Além disso, se você estiver utilizando CIDRs do CG-NAT espaço ou não conseguir vincular um CIDR secundário à sua VPC de cluster, talvez seja necessário explorar outras opções, como usar um CNI alternativo. É altamente recomendável que você obtenha suporte comercial ou possua o conhecimento interno para depurar e enviar patches para o projeto de plug-in CNI de código aberto. Consulte o guia do usuário do Alternate CNI Plugins para obter mais detalhes.

Use o gateway NAT privado

Agora, o Amazon VPC oferece recursos de gateway NAT privado. O gateway NAT privado da Amazon permite que instâncias em sub-redes privadas se conectem a outras VPCs e redes locais com CIDRs sobrepostos. Considere utilizar o método descrito nesta postagem do blog para empregar um gateway NAT privado para superar problemas de comunicação nas cargas de trabalho do EKS causados pela sobreposição de CIDRs, uma reclamação significativa expressa por nossos clientes. A rede personalizada não pode resolver as dificuldades sobrepostas do CIDR por si só, e isso aumenta os desafios de configuração.

A arquitetura de rede usada na implementação desta postagem do blog segue as recomendações em Habilitar a comunicação entre redes sobrepostas na documentação do Amazon VPC. Conforme demonstrado nesta postagem do blog, você pode expandir o uso do gateway NAT privado em conjunto com os endereços RFC6598 para gerenciar os problemas de esgotamento de IP privado dos clientes. Os clusters EKS e os nós de trabalho são implantados no 100.64.0 não roteável. 0/16 O intervalo CIDR secundário da VPC, enquanto o gateway NAT privado e o gateway NAT são implantados nos intervalos CIDR roteáveis do RFC1918. O blog explica como um gateway de trânsito é usado para conectar VPCs a fim de facilitar a comunicação entre VPCs com intervalos CIDR não roteáveis sobrepostos. Para casos de uso em que os recursos do EKS no intervalo de endereços não roteável de uma VPC precisam se comunicar com outras VPCs que não têm intervalos de endereços sobrepostos, os clientes têm a opção de usar o emparelhamento de VPC para interconectar essas VPCs. Esse método pode proporcionar uma possível economia de custos, já que todo o trânsito de dados dentro de uma zona de disponibilidade por meio de uma conexão de emparelhamento VPC agora é gratuito.

Rede exclusiva para nós e pods

Se você precisar isolar seus nós e pods em uma rede específica por motivos de segurança, recomendamos que você implante nós e pods em uma sub-rede a partir de um bloco CIDR secundário maior (por exemplo, 100.64.0). 0/8). Após a instalação do novo CIDR em sua VPC, você pode implantar outro grupo de nós usando o CIDR secundário e drenar os nós originais para reimplantar automaticamente os pods nos novos nós de trabalho. Para obter mais informações sobre como implementar isso, consulte esta postagem do blog.

A rede personalizada não é usada na configuração representada no diagrama abaixo. Em vez disso, os nós de trabalho do Kubernetes são implantados em sub-redes do intervalo CIDR de VPC secundário da sua VPC, como 100.64.0. 0/10. Você pode manter o cluster EKS em execução (o plano de controle permanecerá no original subnet/s), mas os nós e pods serão movidos para um secundário subnet/s. Essa é outra técnica, embora não convencional, para mitigar o perigo de esgotamento de IP em uma VPC. Propomos drenar os nós antigos antes de reimplantar os pods nos novos nós de trabalho.

Automatize a configuração com rótulos de zona de disponibilidade

Você pode ativar o Kubernetes para aplicar automaticamente o EniConfig correspondente à Zona de Disponibilidade (AZ) do nó de trabalho.

O Kubernetes adiciona automaticamente a tag topology.kubernetes.io/zone aos seus nós de trabalho. O Amazon EKS recomenda usar a zona de disponibilidade como seu nome de configuração da ENI quando você tem apenas uma sub-rede secundária (CIDR alternativo) por AZ. Você pode então definir o rótulo usado para descobrir o nome da configuração ENI para. topology.kubernetes.io/zone Observe que a tag failure-domain.beta.kubernetes.io/zone foi descontinuada e substituída pela tag. topology.kubernetes.io/zone

kubectl set env daemonset aws-node -n kube-system "AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true"
kubectl set env daemonset aws-node -n kube-system "ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone"

Se você tiver várias sub-redes secundárias por zona de disponibilidade, precisará criar uma específica. ENI_CONFIG_LABEL_DEF Você pode considerar configurar nós ENI_CONFIG_LABEL_DEF como k8s.amazonaws.com/eniConfig e rotular nós com nomes EniConfig personalizados, como e. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1 k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2

Substitua os pods ao configurar a rede secundária

A ativação da rede personalizada não modifica os nós existentes. A rede personalizada é uma ação disruptiva. Em vez de fazer uma substituição contínua de todos os nós de trabalho em seu cluster depois de ativar a rede personalizada, sugerimos atualizar o CloudFormation modelo da AWS no Guia de introdução do EKS com um recurso personalizado que chama uma função Lambda para atualizar o aws-node Daemonset com a variável de ambiente para permitir a rede personalizada antes que os nós de trabalho sejam provisionados.

Se você tinha algum nó em seu cluster com pods em execução antes de mudar para o recurso de rede CNI personalizado, deveria isolar e drenar os nós para desligá-los normalmente e, em seguida, encerrar os nós. Somente os novos nós que correspondem ao rótulo ou às anotações do EniConfig usam redes personalizadas e, portanto, os pods programados nesses novos nós podem receber um IP do CIDR secundário.

Calcule o máximo de pods por nó

Como a ENI primária do nó não é mais usada para atribuir endereços IP de pod, há uma diminuição no número de pods que você pode executar em um determinado tipo de instância do EC2. Para contornar essa limitação, você pode usar a atribuição de prefixo com redes personalizadas. Com a atribuição de prefixo, cada IP secundário é substituído por um prefixo /28 nos ENIs secundários.

Considere o número máximo de pods para uma instância m5.large com rede personalizada.

O número máximo de pods que você pode executar sem atribuição de prefixo é 29

A ativação de anexos de prefixo aumenta o número de pods para 290.

No entanto, sugerimos definir os pods máximos para 110 em vez de 290 porque a instância tem um número bem pequeno de CPUs virtuais. Em instâncias maiores, o EKS recomenda um valor máximo de pods de 250. Ao utilizar anexos de prefixo com tipos de instância menores (por exemplo, m5.large), é possível que você esgote os recursos de CPU e memória da instância bem antes de seus endereços IP.

Identifique o uso existente do CG-NAT espaço

A rede personalizada permite mitigar o problema de esgotamento de IP, mas não pode resolver todos os desafios. Se você já usa CG-NAT espaço para seu cluster ou simplesmente não tem a capacidade de associar um CIDR secundário à sua VPC de cluster, sugerimos que você explore outras opções, como usar um CNI alternativo ou migrar para clusters IPv6.