Come posso utilizzare più intervalli CIDR con Amazon EKS?

Breve descrizione

Per utilizzare più intervalli CIDR in Amazon EKS, completa i seguenti passaggi:

1. Aggiungi altri intervalli CIDR per espandere la rete del cloud privato virtuale (VPC).
2. Crea sottoreti con un nuovo intervallo CIDR.
3. Associa la nuova sottorete a una tabella di routing.
4. Configura il plugin Amazon Virtual Private Cloud (Amazon VPC) Container Network Interface (CNI) per utilizzare un nuovo intervallo CIDR.

Nota: è consigliabile utilizzare CIDR (/16) dallo spazio NAT (CGN) carrier-grade come 100.64.0.0/10 o 198.19.0.0/16. Puoi utilizzare un intervallo VPC valido come intervallo CIDR secondario nelle reti personalizzate. Tuttavia, è meno probabile che questi intervalli vengano utilizzati in ambito aziendale. Per ulteriori informazioni sui requisiti di rete personalizzati, consulta Considerazioni.

Risoluzione

Nota: se ricevi errori quando esegui i comandi dell'Interfaccia della linea di comando AWS (AWS CLI), consulta Risoluzione degli errori per AWS CLI. Inoltre, assicurati di utilizzare la versione più recente di AWS CLI.

Prerequisiti: devi avere le seguenti configurazioni:

• Cluster Amazon EKS in esecuzione
• Autorizzazioni AWS Identity and Access Management (AWS IAM) per gestire un Amazon VPC
• kubectl con autorizzazioni per creare risorse personalizzate e modificare il DaemonsSet
• Versione installata di jq nel sistema
  Nota: per scaricare e installare jq, consulta Download jq (Come scaricare jq) sul sito web jq.
• Sistema basato su Unix con una shell bash
• VPC configurato

Aggiungi altri intervalli CIDR per espandere la rete VPC

Completa i seguenti passaggi:

1. Per recuperare l'ID del cluster VPC e archiviarlo in una variabile, esegui questo comando AWS CLI describe-cluster:

   VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text)

   Nota: sostituisci CLUSTER_NAME con il nome del tuo cluster e REGION_CODE con la Regione AWS in cui hai distribuito il cluster.
2. Per associare un altro blocco CIDR con l'intervallo 100.64.0.0/16 al VPC, esegui questo comando associate-vpc-cidr-block:

   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 seguenti passaggi:

1. Per elencare tutte le zone di disponibilità nella Regione, esegui questo comando describe-availability-zones:

   aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName'

   Nota: sostituisci REGION_CODE con la Regione in cui hai distribuito le tue risorse.
2. Crea le sottoreti che desideri utilizzare in ogni zona di disponibilità in cui si trovano le sottoreti esistenti. Per creare nuove sottoreti nel VPC con il nuovo intervallo CIDR, esegui questi comandi create-subnet.

   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)

   Nota: sostituisci AZ1, AZ2 e AZ3 con le zone di disponibilità della sottorete esistenti.
3. (Facoltativo) Per impostare una coppia chiave-valore e aggiungere un tag nome alle sottoreti, esegui questo comando create-tags:

   aws ec2 create-tags --resources $CUST_SNET1 --tags Key=KEY,Value=VALUE
   aws ec2 create-tags --resources $CUST_SNET2 --tags Key=KEY,Value=VALUE
   aws ec2 create-tags --resources $CUST_SNET3 --tags Key=KEY,Value=VALUE

   Nota: sostituisci KEY con la chiave del tag e VALUE con il valore del tag.

Associa la nuova sottorete a una tabella di routing

Per impostazione predefinita, Amazon VPC associa le nuove sottoreti alla tabella di routing principale del VPC. Questa tabella di routing consente la comunicazione solo tra le risorse distribuite nel VPC. Per consentire la comunicazione con indirizzi IP esterni ai blocchi CIDR del VPC, devi creare una tabella di routing personalizzata per le sottoreti.

Configura il plugin CNI per utilizzare il nuovo intervallo CIDR

Completa i seguenti passaggi:

1. Assicurati di eseguire la versione del plugin corretta per la versione di Kubernetes. Per verificare la versione, esegui questo comando:

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

   Se non hai la versione corretta, aggiorna il plugin Amazon VPC CNI.

2. Per attivare la configurazione di rete personalizzata per il plugin Amazon VPC CNI, esegui questo comando:

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

3. Per identificare i nodi worker aggiungendo l'etichetta ENIConfig, esegui questo comando:

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

4. Per creare risorse personalizzate EniConfig per tutte le sottoreti e le zone di disponibilità, esegui questi comandi:

   cat <<EOF  | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ1
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET1
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ2
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET2
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ3
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET3
   EOF

   Nota: sostituisci cluster_security_group_id con l'ID del gruppo di sicurezza esistente che desideri utilizzare per ogni risorsa ENIConfig. I nomi delle risorse EniConfig sono gli stessi della zona di disponibilità in cui sono state create le nuove sottoreti.

5. Se utilizzi un gruppo di nodi self-managed, avvia i nodi worker self-managed per consentire al plugin di assegnare loro indirizzi IP. Per Sottoreti, utilizza le sottoreti originali che hai scelto quando hai creato il cluster invece delle nuove sottoreti che hai usato nelle risorse ENIConfig. Puoi inoltre utilizzare un gruppo di nodi gestiti con un modello di avvio per avviare i nodi. In entrambi i casi, devi identificare il valore max-pods corretto per il tipo di istanza. Questo perché la rete personalizzata in Amazon EKS non utilizza l'interfaccia di rete principale per il posizionamento dei Pod. Assicurati di aggiungere il parametro --cni-custom-networking-enabled quando esegui lo script max-pods-calculator.sh.
   Quindi esegui questo comando per specificare il valore max-pods per i nodi self-managed:

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

   Nota: sostituisci 20 con il valore max-pods che hai calcolato.
   Per un gruppo di nodi gestiti, aggiungi il seguente script ai Dati utente:

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

   Nota: sostituisci my-cluster-name con il nome del tuo cluster e 20 con il valore max-pods che hai calcolato. Nel modello di avvio, specifica l'ID di un'Amazon Machine Image (AMI) ottimizzata per Amazon EKS o un'AMI personalizzata creata a partire dall'AMI ottimizzata per Amazon EKS. Le AMI Amazon Linux 2023 (AL2023) utilizzano il processo nodeadm. Per comprendere come questo modifica la configurazione Dati utente, consulta Aggiornamento da Amazon Linux 2 ad Amazon Linux 2023.
   Se utilizzi un gruppo di nodi gestiti senza un modello di avvio o l'ID di un'AMI specificato, il gruppo di nodi gestiti calcola automaticamente il valore max-pods.

6. Una volta che i nuovi nodi sono pronti, svuota i nodi precedenti per chiudere correttamente i Pod. Per ulteriori informazioni, consulta Safely Drain a Node (Svuotamento di un nodo in sicurezza) sul sito web Kubernetes. Se i nodi si trovano in un gruppo di nodi gestiti esistente, esegui questo comando per eliminare il gruppo di nodi:

   aws eks delete-nodegroup --cluster-name CLUSTER_NAME --nodegroup-name my-nodegroup

   Nota: sostituisci CLUSTER\ _NAME con il nome del tuo cluster e my-nodegroup con il nome del tuo gruppo di nodi.

7. Per avviare una nuova distribuzione e testare la configurazione, esegui questo comando:

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

   Nota: il comando precedente aggiunge 10 nuovi Pod e li pianifica nel nuovo intervallo CIDR sui nuovi nodi worker.

Importante: un cluster può impiegare fino a 5 ore per riconoscere e inserire nella lista di indirizzi consentiti un nuovo blocco CIDR associato a un VPC. Durante questo intervallo di tempo, il piano di controllo (control-plane) di Amazon EKS non può comunicare con i Pod avviati nelle nuove sottoreti. Se api-server contatta i Pod con un webhook, un comando kubectl logs o un comando kubectl exec, potresti ricevere il seguente messaggio di errore:

"failed calling webhook "linkerd-proxy-injector.linkerd.io": failed to call webhook: Post "https://linkerd-proxy-injector.linkerd.svc:443/?timeout=10s": Address is not allowed"