New user sign up using AWS Builder ID
New user sign up using AWS Builder ID is currently unavailable on re:Post. To sign up, please use the AWS Management Console instead.
Como faço para usar vários intervalos CIDR com o Amazon EKS?
Quero usar vários intervalos CIDR com o Amazon Elastic Kubernetes Service (Amazon EKS) para resolver problemas com meus pods.
Breve descrição
Antes de concluir as etapas na seção Solução, confirme se você tem o seguinte:
- Um cluster Amazon EKS em execução
- A versão mais recente da AWS Command Line Interface (AWS CLI)
- Permissões do AWS Identity and Access Management (IAM) para gerenciar uma Amazon Virtual Private Cloud (Amazon VPC)
- Um kubectl com permissões para criar recursos personalizados e editar o DaemonsSet
- Uma versão instalada do jq em seu sistema
Observação: para baixar e instalar o jq, consulte Baixar jq no site do jq. - Um sistema baseado em Unix com um shell Bash
- Uma VPC que já está configurada
Observação:
- você pode associar blocos CIDR privados (RFC 1918) e públicos (sem RFC 1918) à sua VPC antes ou depois de criar seu cluster.
- Em cenários com conversão de endereços de rede (NAT) de nível de operadora, 100.64.0.0/10 é um intervalo de rede privada. O intervalo da rede privada é usado no espaço de endereço compartilhado para comunicações entre um provedor de serviços e seus assinantes. Para que os pods se comuniquem com a Internet, você deve ter um gateway NAT configurado na tabela de rotas. Os clusters do AWS Fargate não oferecem suporte a DaemonSets. Para adicionar intervalos CIDR secundários aos perfis do Fargate, use sub-redes dos blocos CIDR secundários da sua VPC. Em seguida, marque suas novas sub-redes antes de adicioná-las ao seu perfil do Fargate.
Importante: em algumas situações, o Amazon EKS não consegue se comunicar com nós que você executa em sub-redes a partir de blocos CIDR adicionados a uma VPC depois de criar um cluster. Quando você adiciona blocos CIDR a um cluster existente, o intervalo atualizado pode levar até 5 horas para aparecer.
Solução
Observação: se você receber mensagens de erro ao executar comandos da AWS Command Line Interface (AWS CLI), consulte Solucione erros da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.
Na solução a seguir, primeiro configure sua VPC. Em seguida, configure o plug-in CNI para usar um novo intervalo CIDR.
Adicione mais intervalos CIDR para expandir sua rede VPC
Conclua as seguintes etapas:
-
Encontre suas VPCs.
Se suas VPCs tiverem uma tag, execute o seguinte comando para encontrar sua VPC:VPC_ID=$(aws ec2 describe-vpcs --filters Name=tag:Name,Values=yourVPCName | jq -r '.Vpcs[].VpcId')
Se suas VPCs não tiverem uma tag, execute o seguinte comando para listar todas as VPCs na sua região da AWS:
aws ec2 describe-vpcs --filters | jq -r '.Vpcs[].VpcId'
-
Para anexar sua VPC a uma VPC_ID variável, execute o seguinte comando:
export VPC_ID=vpc-xxxxxxxxxxxx
Para associar outro bloco CIDR ao intervalo 100.64.0.0/16 à VPC, execute o seguinte comando:
aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16
Crie sub-redes com um novo intervalo CIDR
Conclua as seguintes etapas:
- Para listar todas as zonas de disponibilidade em sua região, execute o seguinte comando:
aws ec2 describe-availability-zones --region us-east-1 --query 'AvailabilityZones[*].ZoneName'
Observação: substitua us-east-1 pela sua região. 2. Escolha a zona de disponibilidade na qual você deseja adicionar as sub-redes e, em seguida, atribua a zona de disponibilidade a uma variável. Por exemplo:
export AZ1=us-east-1a export AZ2=us-east-1b export AZ3=us-east-1c
Observação: para adicionar mais zonas de disponibilidade, crie variáveis adicionais. 3. Para criar novas sub-redes sob a VPC com o novo intervalo CIDR, execute os seguintes comandos:
CUST_SNET1=$(aws ec2 create-subnet --cidr-block 100.64.0.0/19 --vpc-id $VPC_ID --availability-zone $AZ1 | jq -r .Subnet.SubnetId) CUST_SNET2=$(aws ec2 create-subnet --cidr-block 100.64.32.0/19 --vpc-id $VPC_ID --availability-zone $AZ2 | jq -r .Subnet.SubnetId) CUST_SNET3=$(aws ec2 create-subnet --cidr-block 100.64.64.0/19 --vpc-id $VPC_ID --availability-zone $AZ3 | jq -r .Subnet.SubnetId)
- (Opcional) Defina um par de valores-chave para adicionar uma tag de nome às suas sub-redes. Por exemplo:
aws ec2 create-tags --resources $CUST_SNET1 --tags Key=Name,Value=SubnetA aws ec2 create-tags --resources $CUST_SNET2 --tags Key=Name,Value=SubnetB aws ec2 create-tags --resources $CUST_SNET3 --tags Key=Name,Value=SubnetC
Associe sua nova sub-rede a uma tabela de rotas
Conclua as seguintes etapas:
-
Para listar toda a tabela de rotas na VPC, execute o seguinte comando:
aws ec2 describe-route-tables --filters Name=vpc-id,Values=$VPC_ID |jq -r '.RouteTables[].RouteTableId'
-
Para exportar a tabela de rotas para a variável, execute o seguinte comando:
export RTASSOC_ID=rtb-abcabcabc
Observação: substitua rtb-abcabcabc pelos valores da etapa anterior.
-
Associe a tabela de rotas a todas as novas sub-redes. Por exemplo:
aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET1 aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET2 aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET3
Para obter mais informações, consulte a seção Roteamento em Exemplo: VPC com servidores em sub-redes privadas e NAT.
Configure o plug-in CNI para usar o novo intervalo CIDR
Conclua as seguintes etapas:
-
Adicione a versão mais recente do plug-in vpc-cni ao cluster. Para verificar a versão no cluster, execute o seguinte comando:
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
Para ativar a configuração de rede personalizada para o plug-in CNI, execute o seguinte comando:
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
-
Para adicionar o rótulo EniConfig para identificar seus nós de processamento, execute o seguinte comando:
kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=failure-domain.beta.kubernetes.io/zone
-
Para criar um recurso personalizado ENIConfig para todas as sub-redes e zonas de disponibilidade, execute os seguintes comandos:
cat <<EOF | kubectl apply -f - apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ1 spec: subnet: $CUST_SNET1 EOF cat <<EOF | kubectl apply -f - apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ2 spec: subnet: $CUST_SNET2 EOF cat <<EOF | kubectl apply -f - apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ3 spec: subnet: $CUST_SNET3 EOF
Observação: o EniConfig deve corresponder à zona de disponibilidade de seus nós de processamento.
-
Inicie os nós de processamento para que o plug-in CNI (ipamd) possa alocar endereços IP do novo intervalo CIDR para os novos nós de processamento.
Se você usa uma rede personalizada, a interface de rede primária não é usada para o posicionamento do pod. Nesse caso, você deve primeiro atualizar os max-pods com a seguinte fórmula:maxPods = (number of interfaces - 1) \* (max IPv4 addresses per interface - 1) + 2
Se você usa um grupo de nós autogerenciados, siga as etapas em Lançamento de nós autogerenciados do Amazon Linux. Não especifique as sub-redes que você usou nos recursos EniConfig. Em vez disso, especifique o seguinte para o parâmetro BootstrapArguments:
--use-max-pods false --kubelet-extra-args '--max-pods=<20>'
Se você usar um grupo de nós gerenciadores sem um modelo de execução ou um ID de imagem de máquina da Amazon (AMI) especificado, os grupos de nós gerenciados calcularão automaticamente o valor máximo de pods. Siga as etapas em Como criar um grupo de nós gerenciados. Ou use a CLI do Amazon EKS para criar o grupo de nós gerenciados:
aws eks create-nodegroup --cluster-name <sample-cluster-name> --nodegroup-name <sample-nodegroup-name> --subnets <subnet-123 subnet-456> --node-role <arn:aws:iam::123456789012:role/SampleNodeRole>
Se você usar um modelo de execução de grupo de nós gerenciado com uma ID de AMI especificada, especifique uma ID de AMI otimizada para Amazon EKS em seu modelo de execução. Ou use uma AMI personalizada com base na AMI otimizada do Amazon EKS. Em seguida, use um modelo de execução para implantar o grupo de nós e forneça os seguintes dados do usuário no modelo de execução:
#!/bin/bash /etc/eks/bootstrap.sh <my-cluster-name> --kubelet-extra-args <'--max-pods=20'>
-
Anote o grupo de segurança da sub-rede e aplique o grupo de segurança ao EniConfig associado:
cat <<EOF | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ1 spec: securityGroups: - sg-xxxxxxxxxxxx subnet: $CUST_SNET1 EOF cat <<EOF | kubectl apply -f - apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ2 spec: securityGroups: - sg-xxxxxxxxxxxx subnet: $CUST_SNET2 EOF cat <<EOF | kubectl apply -f - apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ3 spec: securityGroups: - sg-xxxxxxxxxxxx subnet: $CUST_SNET3 EOF
Observação: substitua sg-xxxxxxxxxxxxpela ID do seu grupo de segurança.
-
Inicie uma nova implantação para testar a configuração:
kubectl create deployment nginx-test --image=nginx --replicas=10 kubectl get pods -o wide --selector=app=nginx-test
Observação: na implantação de teste anterior, dez novos pods foram adicionados e o novo intervalo CIDR é programado em novos nós de processamento.

Conteúdo relevante
- feita há 2 meseslg...
- feita há um mêslg...
- Resposta aceitafeita há um mêslg...
- feita há um mêslg...
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 3 meses
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há um ano