Como faço para usar vários intervalos CIDR com o Amazon EKS?

8 minuto de leitura

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.

Encerre os nós de processamento antigos.

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.

Tópicos

Contêineres

Conteúdo relevante

Como faço para fornecer acesso externo a vários serviços do Kubernetes no meu cluster Amazon EKS?
AWS OFICIALAtualizada há 2 anos
Como resolvo o erro “Seu usuário ou função atual não tem acesso aos objetos do Kubernetes neste cluster EKS” no Amazon EKS?
AWS OFICIALAtualizada há um ano
O que eu faço se eu receber um erro “Parece que você não tem autorização” ao tentar usar o Amazon Lightsail?
AWS OFICIALAtualizada há 3 anos
Como faço para restringir endereços IP CIDR para um serviço do tipo LoadBalancer no Amazon EKS?
AWS OFICIALAtualizada há 3 anos