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, a 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 primária ENI está conectada, geralmente a sub-rede do nó/host.
Se a sub-rede CIDR for muito pequena, CNI talvez não consiga adquirir endereços IP secundários suficientes para atribuir aos seus pods. Esse é um desafio comum para EKS IPv4 clusters.
A rede personalizada é uma solução para esse problema.
A rede personalizada resolve o problema de exaustão de IP atribuindo o nó e o pod IPs dos espaços de VPC endereço secundários (). CIDR O suporte de rede personalizado oferece suporte a recursos ENIConfig personalizados. ENIConfigIsso inclui um CIDR intervalo de sub-rede alternativo (extraído de um secundário VPCCIDR), junto com os grupos de segurança aos quais os pods pertencerão. Quando a rede personalizada está ativada, a VPC CNI cria uma secundária ENIs na sub-rede definida emENIConfig. O CNI atribui aos pods endereços IP de um CIDR intervalo definido em a. ENIConfig CRD
Como o primário não ENI é usado pela rede personalizada, o número máximo de pods que você pode executar em um nó é menor. Os pods da rede anfitriã continuam usando o endereço IP atribuído ao principalENI. Além disso, o primário ENI é 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 VPC intervalo válido para um CIDR intervalo secundário, recomendamos que você use CIDRs (/16) do NAT espaço CG-, ou seja, 100.64.0.0/10 ou 198.19.0.0/16, pois é menos provável que sejam usados em um ambiente corporativo do que outros intervalos. RFC1918 Para obter informações adicionais sobre as associações de CIDR blocos permitidas e restritas que você pode usar com o seuVPC, consulte as restrições de associação de IPv4 CIDR blocos na seção VPC e dimensionamento de sub-rede da VPC documentação.
Conforme mostrado no diagrama abaixo, a interface de rede elástica primária (ENI) do nó de trabalho ainda usa o VPC CIDR intervalo primário (nesse caso, 10.0.0.0/16), mas o secundário ENIs usa o VPC CIDR intervalo secundário (nesse caso, 100.64.0.0/16). Agora, para que os Pods usem a CIDR faixa 100.64.0.0/16, você deve configurar o plug-in para usar uma rede personalizada. CNI Você pode seguir as etapas conforme documentado aqui.
Se você quiser CNI usar uma rede personalizada, 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, eles CNI atribuirão o endereço IP do pod a partir de uma sub-rede definida emENIConfig. O recurso ENIConfig personalizado é usado para definir a sub-rede na qual os pods serão programados.
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 os pods existentes permanecerão inalterados.
Recomendações
Use redes personalizadas quando
Recomendamos que você considere a criação de redes personalizadas se estiver com IPv4 exaustão e ainda não puder usá-la. IPv6 O EKS suporte da Amazon para RFC6598
Você pode considerar uma rede personalizada se tiver um requisito de segurança para executar pods em uma rede diferente com requisitos de grupo de segurança diferentes. Quando a rede personalizada é ativada, os pods usam grupos de sub-rede ou de segurança diferentes, conforme definido na ENIConfig interface de rede primária do nó.
A rede personalizada é, de fato, uma opção ideal para implantar vários EKS clusters e aplicativos para conectar serviços de datacenter local. Você pode aumentar o número de endereços privados (RFC1918) acessíveis EKS em seus VPC quatro serviços, como Amazon Elastic Load Balancing e NAT -GW, enquanto usa NAT espaço CG- não roteável para seus pods em vários clusters. A rede personalizada com o gateway de trânsito
Evite redes personalizadas quando
Pronto para implementar IPv6
A rede personalizada pode mitigar os problemas de exaustão de IP, mas exige sobrecarga operacional adicional. Se você está implantando atualmente uma pilha dupla (IPv4/IPv6) VPC ou se seu plano inclui IPv6 suporte, recomendamos implementar clusters em vez disso. IPv6 Você pode configurar IPv6 EKS clusters e migrar seus aplicativos. Em um IPv6 EKS cluster, tanto o Kubernetes quanto os pods obtêm um IPv6 endereço e podem se comunicar de entrada e saída com ambos e com os endpoints. IPv4 IPv6 Analise as melhores práticas para executar IPv6 EKS clusters.
CG- Space esgotado NAT
Além disso, se você está utilizando atualmente a CIDRs partir do NAT espaço CG- ou não consegue vincular um secundário CIDR ao seu clusterVPC, talvez seja necessário explorar outras opções, como usar uma alternativa. CNI É altamente recomendável que você obtenha suporte comercial ou possua o conhecimento interno para depurar e enviar patches para o projeto de CNI plug-in de código aberto. Consulte o guia do usuário de CNIplug-ins alternativos para obter mais detalhes.
Use um NAT gateway privado
A Amazon VPC agora oferece recursos de NATgateway privado. O NAT gateway privado da Amazon permite que instâncias em sub-redes privadas se conectem a outras redes locais VPCs e a outras redes locais com sobreposição. CIDRs Considere utilizar o método descrito nesta postagem do blog
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 da AmazonVPC. Conforme demonstrado nesta postagem do blog, você pode expandir o uso do NAT gateway privado em conjunto com RFC6598 endereços para gerenciar os problemas de exaustão de IP privado dos clientes. Os EKS clusters e os nós de trabalho são implantados na CIDR faixa VPC secundária não roteável 100.64.0.0/16, enquanto o NAT gateway privado e o gateway são implantados nas faixas roteáveis. NAT RFC1918 CIDR O blog explica como um gateway de trânsito é usado para se conectar a VPCs fim de facilitar a comunicação VPCs com intervalos não roteáveis CIDR sobrepostos. Para casos de uso em que EKS os recursos em um intervalo VPC de endereços não roteáveis precisam se comunicar com outros VPCs que não tenham intervalos de endereços sobrepostos, os clientes têm a opção de usar o VPC peering para interconectá-los. VPCs Esse método pode proporcionar uma possível economia de custos, pois todo o trânsito de dados dentro de uma zona de disponibilidade por meio de uma conexão VPC emparelhada 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 CIDR bloco secundário maior (por exemplo, 100.64.0.0/8). Após a instalação do novo CIDR no seuVPC, você pode implantar outro grupo de nós usando o secundário CIDR 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 no 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 seu intervalo secundário VPCCIDR, como VPC 100.64.0.0/10. Você pode manter o EKS cluster em execução (o plano de controle permanecerá no original)subnet/s), but the nodes and Pods will be moved to a secondary subnet/s. Essa é mais uma técnica, embora não convencional, para mitigar o perigo de exaustão de IP em um. 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 permitir que o Kubernetes aplique automaticamente o correspondente ENIConfig à Zona de Disponibilidade (AZ) do nó de trabalho.
O Kubernetes adiciona automaticamente a tag topology.kubernetes.io/zonefailure-domain.beta.kubernetes.io/zone está obsoleta e foi substituída pela tag. topology.kubernetes.io/zone
-
Defina o
namecampo como a Zona de Disponibilidade do seuVPC. -
Ative a configuração automática com este comando:
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
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/eniConfigk8s.amazonaws.com/eniConfig=us-west-2a-subnet-1k8s.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 AWS CloudFormation modelo no Guia de EKS introdução com um recurso personalizado que chame uma função Lambda para atualizar o aws-node Daemonset com a variável de ambiente para habilitar 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 CNI rede personalizado, você deveria isolar e drenar os nós para desligar os
Calcule o máximo de pods por nó
Como o principal do nó não ENI é mais usado 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 EC2 instância. 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 no secundário. ENIs
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
-
3 ENIs - 1) * (10 secondary IPs per ENI - 1 + 2 = 20
Ativar anexos de prefixo aumenta o número de pods para 290.
-
(3 ENIs - 1) * ((10 secondary IPs per ENI - 1) * 16 + 2 = 290
No entanto, sugerimos definir max-pods para 110 em vez de 290 porque a instância tem um número bem pequeno de virtuais. CPUs Em instâncias maiores, 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 da instância CPU e da memória bem antes dos endereços IP.
nota
Quando o CNI prefixo aloca um prefixo /28 para umENI, ele precisa ser um bloco contíguo de endereços IP. Se a sub-rede da qual o prefixo é gerado estiver altamente fragmentada, o anexo do prefixo poderá falhar. Você pode evitar que isso aconteça criando um novo dedicado VPC para o cluster ou reservando um conjunto de sub-rede CIDR exclusivamente para anexos de prefixo. Visite CIDRReservas de sub-rede para obter mais informações sobre esse tópico.
Identifique o uso existente do espaço CG NAT
A rede personalizada permite que você reduza o problema de exaustão de IP, mas não pode resolver todos os desafios. Se você já usa NAT espaço CG para seu cluster ou simplesmente não tem a capacidade de associar um secundário CIDR ao seu clusterVPC, sugerimos que você explore outras opções, como usar uma alternativa CNI ou migrar para IPv6 clusters.
