Come posso utilizzare più intervalli CIDR con Amazon EKS?

Breve descrizione

Prima di completare i passaggi illustrati nella sezione Risoluzione, conferma di disporre di quanto segue:

• Un cluster Amazon EKS in esecuzione
• La versione più recente dell'Interfaccia della linea di comando AWS (AWS CLI)
• Autorizzazioni AWS Identity and Access Management (IAM) per gestire un Amazon Virtual Private Cloud (Amazon VPC)
• Uno strumento kubectl con autorizzazioni per creare risorse personalizzate e modificare il DaemonsSet
• Una versione installata di jq sul tuo sistema
  Nota: per scaricare e installare jq, consulta la pagina Download jq sul sito web di jq. 
• Un sistema basato su Unix con una shell Bash
• Un VPC già configurato

Nota:

• puoi associare blocchi CIDR privati (RFC 1918) e pubblici (non RFC 1918) al tuo VPC prima o dopo la creazione del cluster.
• Negli scenari con Carrier-Grade Network Address Translation (NAT), 100.64.0.0/10 è un intervallo di rete privata. L'intervallo di rete privata viene utilizzato nello spazio di indirizzi condiviso per le comunicazioni tra un fornitore di servizi e i suoi abbonati. Affinché i pod possano comunicare con Internet, è necessario disporre di un gateway NAT configurato nella tabella di routing. I cluster AWS Fargate non supportano i DaemonSet. Per aggiungere intervalli CIDR secondari ai profili Fargate, utilizza le sottoreti dei blocchi CIDR secondari del tuo VPC. Quindi, aggiungi un tag alle nuove sottoreti prima di aggiungerle al tuo profilo Fargate.

Importante: in alcune situazioni, Amazon EKS non è in grado di comunicare con i nodi che vengono avviati nelle sottoreti dai blocchi CIDR aggiunti a un VPC dopo aver creato un cluster. Quando aggiungi blocchi CIDR a un cluster esistente, la visualizzazione dell'intervallo aggiornato può richiedere fino a 5 ore.

Risoluzione

Nota: se ricevi messaggi di errore durante l'esecuzione dei comandi dell'Interfaccia della linea di comando AWS (AWS CLI), consulta la pagina Troubleshoot AWS CLI errors. Inoltre, assicurati che la versione di AWS CLI che stai utilizzando sia la più recente.

Nella risoluzione seguente, configura innanzitutto il tuo VPC. Quindi, configura il plugin CNI per utilizzare un nuovo intervallo CIDR.

Aggiungere altri intervalli CIDR per espandere la rete VPC

Completa i passaggi seguenti:

1. Trova i tuoi VPC.
   Se i tuoi VPC hanno un tag, esegui il comando seguente per trovare il tuo VPC:

   VPC_ID=$(aws ec2 describe-vpcs --filters Name=tag:Name,Values=yourVPCName | jq -r '.Vpcs[].VpcId')

   Se i tuoi VPC non hanno un tag, esegui il comando seguente per elencare tutti i VPC nella tua Regione AWS:

   aws ec2 describe-vpcs --filters  | jq -r '.Vpcs[].VpcId'

2. Per collegare il tuo VPC a una variabile VPC_ID, esegui il comando seguente:

   export VPC_ID=vpc-xxxxxxxxxxxx

   Per associare un altro blocco CIDR con l'intervallo 100.64.0.0/16 al VPC, esegui il comando seguente:

   aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16

Creare sottoreti con un nuovo intervallo CIDR

Completa i passaggi seguenti:

1.  Per elencare tutte le zone di disponibilità nella tua regione, esegui il comando seguente:

   aws ec2 describe-availability-zones --region us-east-1 --query 'AvailabilityZones[*].ZoneName'

   Nota: sostituisci us-east-1 con la tua regione.

2. Scegli la zona di disponibilità in cui desideri aggiungere le sottoreti, quindi assegnala a una variabile. Ad esempio:

   export AZ1=us-east-1a
   export AZ2=us-east-1b
   export AZ3=us-east-1c

   Nota: per aggiungere altre zone di disponibilità, crea variabili aggiuntive.

3. Per creare nuove sottoreti nel VPC con il nuovo intervallo CIDR, esegui i comandi seguenti:

   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)

4. (Facoltativo) Imposta una coppia chiave-valore per aggiungere un nome tag per le tue sottoreti. Ad esempio:

   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

Associare la nuova sottorete a una tabella di routing

Completa i passaggi seguenti:

1. Per elencare l'intera tabella di routing nel VPC, esegui il comando seguente:

   aws ec2 describe-route-tables --filters Name=vpc-id,Values=$VPC_ID |jq -r '.RouteTables[].RouteTableId'

2. Per esportare la tabella di routing nella variabile, esegui il comando seguente:

   export RTASSOC_ID=rtb-abcabcabc

   Nota: sostituisci rtb-abcabcabc con i valori del passaggio precedente.

3. Associa la tabella di routing a tutte le nuove sottoreti. Ad esempio:

   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

   Per ulteriori informazioni, consulta la sezione Routing nella pagina Example: Launching self-managed Amazon Linux nodes.

Configurare il plugin CNI per utilizzare il nuovo intervallo CIDR

Completa i passaggi seguenti:

1. Aggiungi l'ultima versione del plugin vpc-cni al cluster. Per verificare la versione nel cluster, esegui il comando seguente:

   kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

   Per attivare la configurazione di rete personalizzata per il plugin CNI, esegui il comando seguente:

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

2. Per aggiungere l'etichetta ENIConfig per identificare i nodi worker, esegui il comando seguente:

   kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=failure-domain.beta.kubernetes.io/zone

3. Per creare una risorsa personalizzata ENIConfig per tutte le sottoreti e le zone di disponibilità, esegui i comandi seguenti:

   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

   Nota: la risorsa ENIConfig deve corrispondere alla zona di disponibilità dei nodi worker.

4. Avvia i nodi worker in modo che il plugin CNI (ipamd) possa allocare gli indirizzi IP dal nuovo intervallo CIDR ai nuovi nodi worker.
   Se si utilizza una rete personalizzata, l'interfaccia di rete principale non verrà utilizzata per il posizionamento dei pod. In questo caso, prima sarà necessario aggiornare il valore max-pods con la formula seguente:

   maxPods = (number of interfaces - 1) \* (max IPv4 addresses per interface - 1) + 2

   Se utilizzi un gruppo di nodi autogestito, segui i passaggi descritti nella pagina Launching self-managed Amazon Linux nodes. Non specificare le sottoreti utilizzate nelle risorse ENIConfig. Specifica invece quanto segue nel parametro BootstrapArguments:

   --use-max-pods false --kubelet-extra-args '--max-pods=<20>'

   Se utilizzi un gruppo di nodi gestito senza un modello di avvio o un ID Amazon Machine Image (AMI) specificato, i gruppi di nodi gestiti calcoleranno automaticamente il valore massimo dei pod. Segui i passaggi descritti nella pagina Creating a managed node group. Oppure utilizza l'interfaccia a riga di comando di Amazon EKS per creare il gruppo di nodi gestito:

   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 utilizzi un modello di avvio di un gruppo di nodi gestito con un ID AMI specificato, specifica un ID AMI ottimizzato per Amazon EKS nel modello di avvio. Oppure utilizza un'AMI personalizzata basata sull'AMI ottimizzata per Amazon EKS. Quindi, usa un modello di avvio per implementare il gruppo di nodi e fornisci i seguenti dati utente nel modello di avvio:

   #!/bin/bash
   /etc/eks/bootstrap.sh <my-cluster-name> --kubelet-extra-args <'--max-pods=20'>

5. Annota il gruppo di sicurezza per la sottorete e applicalo alla risorsa ENIConfig associata:

   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

   Nota: sostituisci sg-xxxxxxx con il tuo gruppo di sicurezza.

6. Arresta i vecchi nodi worker.

7. Avvia una nuova implementazione per testare la configurazione:

   kubectl create deployment nginx-test --image=nginx --replicas=10   
   kubectl get pods -o wide --selector=app=nginx-test

   Nota: nella precedente implementazione di prova vengono aggiunti dieci nuovi pod e il nuovo intervallo CIDR è pianificato sui nuovi nodi worker.