Rete personalizzata per i pod

Come creare un cluster

Le procedure seguenti illustrano la creazione di un VPC e un cluster di test, oltre alla configurazione di una rete personalizzata per tale cluster. Ti consigliamo di non utilizzare il cluster di test per i carichi di lavoro di produzione poiché alcune funzionalità da utilizzare con il cluster di produzione non sono trattate in questo argomento. Per ulteriori informazioni, consulta Creazione di un cluster Amazon EKS.

1. Definisci alcune variabili da utilizzare nei passaggi rimanenti.

   export cluster_name=my-custom-networking-cluster
   account_id=$(aws sts get-caller-identity --query Account --output text)
   

2. Crea un VPC.

   1. Crea un VPC utilizzando un modello Amazon EKS AWS CloudFormation .

      aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
        --template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
        --parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
        ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
        ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
        ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
        ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27
      

      La AWS CloudFormation creazione dello stack richiede alcuni minuti. Utilizza il comando seguente per verificare lo stato di implementazione dello stack.

      aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus  --output text
      

      Non passare alla fase successiva finché l'output del comando non è CREATE_COMPLETE.

   2. Definisci le variabili con i valori degli ID delle sottoreti private creati dal modello.

      subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
          --query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
      subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
          --query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
      

   3. Definisci le variabili con le zone di disponibilità delle sottoreti recuperate nel passaggio precedente.

      az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
      az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
      

3. Crea un ruolo IAM del cluster.

   1. Per creare un file JSON della policy di attendibilità IAM, esegui il comando seguente.

      cat >eks-cluster-role-trust-policy.json <<EOF
      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      EOF
      

   2. Crea il ruolo IAM del cluster Amazon EKS. Se necessario, inserisci il prefisso eks-cluster-role-trust-policy.json nel percorso del computer in cui hai eseguito la scrittura del file nella fase precedente. Il comando associa il criterio di attendibilità creato nella fase precedente al ruolo. Per creare un ruolo IAM, è necessario assegnare l'azione iam:CreateRole (autorizzazione) al principale IAM che sta creando il ruolo.

      aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
      

   3. Allega al ruolo la policy gestita da Amazon EKS, denominata AmazonEKSClusterPolicy. Per allegare una policy IAM a un principale IAM, è necessario assegnare al principale che sta allegando la policy una delle azioni IAM (autorizzazioni) seguenti: iam:AttachUserPolicy o iam:AttachRolePolicy.

      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
      

4. Crea un cluster Amazon EKS e configura il dispositivo per comunicare con esso.

   1. Crea un cluster.

      aws eks create-cluster --name my-custom-networking-cluster \
         --role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
         --resources-vpc-config subnetIds=$subnet_id_1","$subnet_id_2
       

      Nota

      Potresti ricevere un messaggio di errore indicante che una delle zone di disponibilità nella richiesta non dispone di capacità sufficiente per creare un cluster Amazon EKS. In questo caso, l'output di errore contiene le zone di disponibilità in grado di supportare un nuovo cluster. Riprova a creare il cluster con almeno due sottoreti che si trovano nelle zone di disponibilità supportate per il tuo account. Per ulteriori informazioni, consulta Capacità insufficiente.

   2. La creazione del cluster richiede diversi minuti. Utilizza il comando seguente per verificare lo stato di implementazione del cluster.

      aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
      

      Non passare alla fase successiva finché l'output del comando non è "ACTIVE".

   3. Configura kubectl per comunicare con il cluster.

      aws eks update-kubeconfig --name my-custom-networking-cluster
      

Questo tutorial richiede il VPC creato nella Fase 1: creazione di un VPC e di un cluster di test. Per un cluster di produzione, modificare i passaggi in base al VPC, sostituendo tutti i example values con i propri.

1. Verifica che la versione del Amazon VPC CNI plugin for Kubernetes attualmente installata sia la più recente. Per determinare la versione più recente per il componente aggiuntivo del tipo Amazon EKS e aggiornarla, consulta la pagina Aggiornamento di un componente aggiuntivo. Per determinare la versione più recente per il componente aggiuntivo del tipo autogestito e aggiornarla, consulta la pagina Utilizzo del componente aggiuntivo Amazon VPC CNI plugin for Kubernetes di Amazon EKS.

2. Recupera l'ID del VPC in cui si trova il cluster e memorizzarlo in una variabile per l'utilizzo nei passaggi successivi. Per un cluster di produzione, sostituisci my-custom-networking-cluster con il nome del cluster.

   vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
   

3. Associa un blocco di instradamento interdominio senza classi (CIDR) aggiuntivo al VPC del cluster. Il blocco CIDR non può sovrapporsi a blocchi CIDR esistenti già associati.

   1. Visualizza i blocchi CIDR attualmente associati al tuo VPC.

      aws ec2 describe-vpcs --vpc-ids $vpc_id \
          --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
      

      Di seguito viene riportato un output di esempio:

      ----------------------------------
      |          DescribeVpcs          |
      +-----------------+--------------+
      |    CIDRBlock    |    State     |
      +-----------------+--------------+
      |  192.168.0.0/24 |  associated  |
      +-----------------+--------------+

   2. Associa un blocco CIDR aggiuntivo al VPC. Per ulteriori informazioni, consulta Associazione di blocchi CIDR IPv4 aggiuntivi al VPC nella Guida per l'utente di Amazon VPC.

      aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
      

   3. Verifica che il nuovo blocco sia associato.

      aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
      

      Di seguito viene riportato un output di esempio:

      ----------------------------------
      |          DescribeVpcs          |
      +-----------------+--------------+
      |    CIDRBlock    |    State     |
      +-----------------+--------------+
      |  192.168.0.0/24 |  associated  |
      |  192.168.1.0/24 |  associated  |
      +-----------------+--------------+

   Non andare al passaggio successivo finché il nuovo State del blocco CIDR non è associated.

4. Crea tutte le sottoreti che vuoi utilizzare in ogni zona di disponibilità in cui si trovano le sottoreti esistenti. Specifica un blocco CIDR all'interno del blocco CIDR associato al VPC in una fase precedente.

   1. Crea nuove sottoreti. È necessario creare le sottoreti in un blocco CIDR VPC diverso rispetto alle sottoreti esistenti, ma all'interno delle stesse zone di disponibilità. In questo esempio si crea una sottorete nel nuovo blocco CIDR in ogni zona di disponibilità in cui esistono le sottoreti private attuali. Gli ID delle sottoreti create vengono memorizzati in variabili da utilizzare nei passaggi successivi. I valori Name corrispondono a quelli assegnati alle sottoreti create utilizzando il modello Amazon EKS VPC in un passaggio precedente. I nomi non sono obbligatori. È possibile utilizzare nomi diversi.

      new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
          --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
          --query Subnet.SubnetId --output text)
      new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
          --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
          --query Subnet.SubnetId --output text)
      

      Importante

      Per impostazione predefinita, le nuove sottoreti sono implicitamente associate alla tabella di instradamento principale del VPC. Questa tabella di instradamento consente la comunicazione tra tutte le risorse implementate nel VPC, ad eccezione delle risorse con indirizzi IP esterni ai blocchi CIDR associate al VPC. Per modificare questo comportamento, associa la tabella di instradamento alle sottoreti. Per ulteriori informazioni, consulta Tabelle di instradamento per sottoreti nella Guida per l'utente di Amazon VPC.

   2. Per visualizzare le sottoreti attuali nel tuo VPC.

      aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
          --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
          --output table
      

      Di seguito viene riportato un output di esempio:

      ----------------------------------------------------------------------
      |                           DescribeSubnets                          |
      +------------------+--------------------+----------------------------+
      | AvailabilityZone |     CidrBlock      |         SubnetId           |
      +------------------+--------------------+----------------------------+
      |  us-west-2d      |  192.168.0.0/27    |     subnet-example1        |
      |  us-west-2a      |  192.168.0.32/27   |     subnet-example2        |
      |  us-west-2a      |  192.168.0.64/27   |     subnet-example3        |
      |  us-west-2d      |  192.168.0.96/27   |     subnet-example4        |
      |  us-west-2a      |  192.168.1.0/27    |     subnet-example5        |
      |  us-west-2d      |  192.168.1.32/27   |     subnet-example6        |
      +------------------+--------------------+----------------------------+

      Come puoi vedere, le sottoreti create nel blocco CIDR 192.168.1.0 si trovano nelle stesse zone di disponibilità di quelle create nel blocco CIDR 192.168.0.0.

Configurazione di risorse Kubernetes

1. Imposta la variabile di ambiente AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG su true nel aws-node DaemonSet.

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

2. Recupera l'ID del gruppo di sicurezza del cluster e memorizzalo in una variabile da utilizzare nel passaggio successivo. Amazon EKS crea automaticamente questo gruppo di sicurezza durante la creazione del cluster.

   cluster_security_group_id=$(aws eks describe-cluster --name $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
   

3. Crea una risorsa personalizzata ENIConfig per ogni sottorete in cui vuoi implementare i Pods.

   1. Crea un file univoco per ogni configurazione di interfaccia di rete.

      I comandi seguenti creano file ENIConfig separati per le due sottoreti create in una fase precedente. Il valore di name deve essere univoco. Il nome corrisponde alla zona di disponibilità in cui si trova la sottorete. Il gruppo di sicurezza del cluster viene assegnato a ENIConfig.

      cat >$az_1.yaml <<EOF
      apiVersion: crd.k8s.amazonaws.com/v1alpha1
      kind: ENIConfig
      metadata: 
        name: $az_1
      spec: 
        securityGroups: 
          - $cluster_security_group_id
        subnet: $new_subnet_id_1
      EOF
      

      cat >$az_2.yaml <<EOF
      apiVersion: crd.k8s.amazonaws.com/v1alpha1
      kind: ENIConfig
      metadata: 
        name: $az_2
      spec: 
        securityGroups: 
          - $cluster_security_group_id
        subnet: $new_subnet_id_2
      EOF
      

      Per un cluster di produzione, puoi apportare le seguenti modifiche ai comandi precedenti:

      • Sostituisci $cluster_security_group_id con l'ID di un gruppo di sicurezza esistente da utilizzare per ciascun ENIConfig.

      • Quando possibile, assegna a ENIConfigs lo stesso nome della zona di disponibilità che utilizzerai per ENIConfig. Per una serie di motivi, tuttavia, potrebbe essere necessario utilizzare nomi diversi per ENIConfigs e le zone di disponibilità. Ad esempio, se nella stessa zona di disponibilità sono presenti più di due sottoreti e si desidera utilizzarle entrambe con reti personalizzate, saranno necessari più ENIConfigs per la stessa zona di disponibilità. Dal momento che ogni ENIConfig richiede un nome univoco, non puoi assegnare lo stesso nome della zona di disponibilità a più ENIConfigs.

        Se i nomi di ENIConfig non sono tutti uguali a quelli delle zone di disponibilità, sostituisci $az_1 e $az_2 con i nomi scelti nei comandi precedenti e prendi nota dei nodi con ENIConfig come descritto più avanti in questo tutorial.

      Nota

      Nel caso in cui non si specifichi un gruppo di sicurezza valido da utilizzare con un cluster di produzione:

      • se si utilizza la versione 1.8.0 o successiva del Amazon VPC CNI plugin for Kubernetes, vengono impiegati i gruppi di sicurezza associati all'interfaccia di rete elastica primaria del nodo.

      • se si utilizza una versione del Amazon VPC CNI plugin for Kubernetes precedente alla 1.8.0, il gruppo di sicurezza di default per il VPC viene assegnato alle interfacce di rete secondarie.

      Importante

      • AWS_VPC_K8S_CNI_EXTERNALSNAT=false è un'impostazione predefinita per la configurazione del plugin CNI di Amazon VPC per Kubernetes. Per impostazione predefinita, il traffico destinato agli indirizzi IP che non si trovano all'interno di uno dei blocchi CIDR associati al VPC utilizza i gruppi di sicurezza e le sottoreti dell'interfaccia di rete primaria del nodo. Le sottoreti e i gruppi di sicurezza definiti in ENIConfigs al fine di creare interfacce di rete secondarie non vengono utilizzati per questo traffico. Per ulteriori informazioni su questa impostazione, consulta SNAT per Pods.

      • Se si utilizzano gruppi di sicurezza anche per i Pods, il gruppo di sicurezza specificato in una SecurityGroupPolicy viene utilizzato al posto di quello specificato in ENIConfigs. Per ulteriori informazioni, consulta Gruppi di sicurezza per Pods.

   2. Applica ogni file delle risorse personalizzato creato in precedenza al cluster con i comandi seguenti.

      kubectl apply -f $az_1.yaml
      kubectl apply -f $az_2.yaml
      

4. Verifica che ENIConfigs sia stato creato.

   kubectl get ENIConfigs
   

   Di seguito viene riportato un output di esempio:

   NAME         AGE
   us-west-2a   117s
   us-west-2d   105s

5. Se stai abilitando la rete personalizzata su un cluster di produzione e hai assegnato a ENIConfigs un nome diverso da quello dalla zona di disponibilità per cui lo stai utilizzando, passa alla fase successiva per implementare i nodi Amazon EC2.

   Consenti a Kubernetes di applicare automaticamente ENIConfig per una zona di disponibilità a tutti i nuovi nodi Amazon EC2 creati nel cluster.

   1. Per il cluster di test in questo tutorial, passa alla fase successiva.

      Per il cluster di produzione, verifica la presenza di un'annotation con il codice k8s.amazonaws.com/eniConfig per la variabile di ambiente ENI_CONFIG_ANNOTATION_DEF nelle specifiche del container per aws-node DaemonSet.

      kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF
      

      Se viene restituito un output, l'annotazione è presente. Se non viene restituito alcun output, la variabile non viene impostata. Per un cluster di produzione, puoi scegliere di utilizzare la presente impostazione o quella riportata nel passaggio successivo. L'utilizzo di questa impostazione sovrascrive quella del passaggio successivo. In questo tutorial viene utilizzata l'impostazione riportata nel passaggio successivo.

   2. Aggiorna il tuo aws-node DaemonSet per applicare automaticamente ENIConfig per una zona di disponibilità a tutti i nuovi nodi Amazon EC2 creati nel cluster.

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

Per implementare i nodi Amazon EC2

1. Creare un ruolo IAM del nodo.

   1. Per creare un file JSON della policy di attendibilità IAM, esegui il comando seguente.

      cat >node-role-trust-relationship.json <<EOF
      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      EOF
      

   2. Eseguire questo comando per impostare una variabile per il nome del ruolo. Puoi sostituire myCustomNetworkingAmazonEKSNodeRole con un nome a tua scelta.

      export node_role_name=myCustomNetworkingAmazonEKSNodeRole
      

   3. Crea il ruolo IAM e memorizza il nome della risorsa Amazon (ARN) restituito in una variabile da utilizzare in una fase successiva.

      node_role_arn=$(aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json" \
          --query Role.Arn --output text)
      

   4. Allega al ruolo IAM le tre policy gestite IAM richieste.

      aws iam attach-role-policy \
        --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
        --role-name $node_role_name
      aws iam attach-role-policy \
        --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
        --role-name $node_role_name
      aws iam attach-role-policy \
          --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
          --role-name $node_role_name
      

      Importante

      Per semplicità, in questo tutorial la policy AmazonEKS_CNI_Policy è allegata al ruolo IAM del nodo. Tuttavia, in un cluster di produzione, si consiglia di allegare la policy a un ruolo IAM separato da utilizzare solo con Amazon VPC CNI plugin for Kubernetes. Per ulteriori informazioni, consulta Configurazione dell'Amazon VPC CNI plugin for Kubernetesutilizzo dei ruoli IAM per gli account di servizio (IRSA).

2. Creare uno dei seguenti tipi di gruppi di nodi. Per determinare il tipo di istanza da implementare, consulta Scelta di un tipo di istanza Amazon EC2. Per questo tutorial, utilizza l'opzione Gestito, senza un modello di avvio o con un modello di avvio senza un ID AMI specificato. Se prevedi di utilizzare il gruppo di nodi per i carichi di lavoro di produzione, ti consigliamo di familiarizzare con tutte le opzioni del gruppo di nodi gestito e autogestito prima di implementare il gruppo di nodi.

   • Gestito: implementare il gruppo di nodi utilizzando una delle opzioni seguenti:

     • Senza un modello di avvio o con un modello di avvio senza un ID AMI specificato: esegui il comando seguente. Per questo tutorial, utilizza i example values. Per un gruppo di nodi di produzione, sostituisci tutti i example values con i tuoi. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura.

       aws eks create-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup \
           --subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
       

     • Con un modello di avvio con un ID AMI specificato

       1. Determina il numero massimo di Pods consigliato da Amazon EKS per i nodi. Segui le istruzioni riportate in Per ogni tipo di istanza Amazon EC2, Amazon EKS consiglia un numero massimo di Pods, aggiungendo --cni-custom-networking-enabled alla fase 3 di questo argomento. Annota l'output restituito per l'utilizzo in un passaggio successivo.

       2. Nel modello di avvio, specifica un ID AMI ottimizzato per Amazon EKS o un'AMI personalizzata sviluppata con l'AMI ottimizzato per Amazon EKS, quindi implementa il gruppo di nodi utilizzando un modello di avvio e fornisci i seguenti dati utente nel modello di avvio. Questi dati utente passano argomenti nel file bootstrap.sh. Per ulteriori informazioni sul file bootstrap, consulta bootstrap.sh su GitHub. Puoi sostituire 20 con il valore del passaggio precedente (consigliato) o con un tuo valore desiderato.

          /etc/eks/bootstrap.sh my-cluster --use-max-pods false --kubelet-extra-args '--max-pods=20'
          

          Se si è creata un'AMI personalizzata che non è stata sviluppata con l'AMI ottimizzata per Amazon EKS, bisogna creare autonomamente la configurazione.

   • Autogestito

     1. Determina il numero massimo di Pods consigliato da Amazon EKS per i nodi. Segui le istruzioni riportate in Per ogni tipo di istanza Amazon EC2, Amazon EKS consiglia un numero massimo di Pods, aggiungendo --cni-custom-networking-enabled alla fase 3 di questo argomento. Annota l'output restituito per l'utilizzo in un passaggio successivo.

     2. Implementa il gruppo di nodi utilizzando le istruzioni in Avvio di nodi Amazon Linux autogestiti. Specificate il testo seguente per il BootstrapArgumentsparametro. Puoi sostituire 20 con il valore del passaggio precedente (consigliato) o con un tuo valore desiderato.

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

   Nota

   Se vuoi che i nodi presenti in un cluster di produzione supportino un numero significativamente più elevato di Pods, esegui nuovamente lo script in Per ogni tipo di istanza Amazon EC2, Amazon EKS consiglia un numero massimo di Pods. Aggiungi inoltre l'opzione --cni-prefix-delegation-enabled al comando. Ad esempio, per un tipo di istanza m5.large viene restituito 110. Per istruzioni su come abilitare questa funzionalità, consulta Aumentare la quantità di indirizzi IP disponibili per i nodi Amazon EC2. Puoi utilizzare questa funzionalità con una rete personalizzata.

   La creazione di gruppi di nodi richiede diversi minuti. Puoi verificare lo stato della creazione di un gruppo di nodi gestiti con il comando seguente.

   aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text
   

   Non andare al passaggio successivo finché l'output restituito non è ACTIVE.

3. Ai fini di questo tutorial, puoi ignorare questo passaggio.

   Per un cluster di produzione, se hai assegnato a ENIConfigs un nome diverso da quello della zona di disponibilità in cui lo stai utilizzando, devi annotare i nodi con il nome ENIConfig da utilizzare con il nodo. Questo passaggio non è necessario se disponi di una sola sottorete in ogni zona di disponibilità e hai assegnato a ENIConfigs gli stessi nomi delle zone di disponibilità. Questo perché il Amazon VPC CNI plugin for Kubernetes associa automaticamente il ENIConfig corretto al nodo se questa opzione è stata abilitata in una fase precedente.

   1. Ottieni l'elenco dei nodi nel cluster.

      kubectl get nodes
      

      Di seguito viene riportato un output di esempio:

      NAME                                          STATUS   ROLES    AGE     VERSION
      ip-192-168-0-126.us-west-2.compute.internal   Ready    <none>   8m49s   v1.22.9-eks-810597c
      ip-192-168-0-92.us-west-2.compute.internal    Ready    <none>   8m34s   v1.22.9-eks-810597c

   2. Determina in quale zona di disponibilità si trova ogni nodo. Esegui il comando seguente per ogni nodo restituito nel passaggio precedente.

      aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
      --query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'
      

      Di seguito viene riportato un output di esempio:

      [
          {
              "AvailabilityZone": "us-west-2d",
              "SubnetId": "subnet-Example5"
          }
      ]

   3. Annota ogni nodo con la risorsa ENIConfig creata per l'ID della sottorete e la zona di disponibilità. Puoi annotare solo un nodo con un ENIConfig, ma più nodi con lo stesso ENIConfig. Sostituisci i example values con i valori in tuo possesso.

      kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
      kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
      

4. Se in un cluster di produzione erano presenti nodi con Pods in esecuzione prima di passare all'utilizzo della funzionalità di rete personalizzata, completa le attività seguenti:

   1. Assicurati di avere dei nodi disponibili abilitati per la funzionalità di rete personalizzata.

   2. Cordonare ed espellere i nodi per interrompere normalmente i Pods. Per ulteriori informazioni, consulta Espulsione di un nodo in modo sicuro nella documentazione di Kubernetes.

   3. Termina i nodi. Se i nodi si trovano in un gruppo di nodi gestito esistente, puoi eliminare il gruppo di nodi. Copia il comando seguente sul tuo dispositivo. Apportare le seguenti modifiche al comando, se necessario, quindi esegui il comando modificato:

      • Sostituisci my-cluster con il nome del tuo cluster.

      • Sostituisci my-nodegroup con un nome per il gruppo di nodi.

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

   Solo i nuovi nodi registrati con l'etichetta k8s.amazonaws.com/eniConfig useranno la nuova funzionalità di rete personalizzata.

5. Verifica che ai Pods venga assegnato un indirizzo IP da un blocco CIDR associato a una delle sottoreti create in una fase precedente.

   kubectl get pods -A -o wide
   

   Di seguito viene riportato un output di esempio:

   NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE     IP              NODE                                          NOMINATED NODE   READINESS GATES
   kube-system   aws-node-2rkn4             1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   aws-node-k96wp             1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
   kube-system   coredns-657694c6f4-smcgr   1/1     Running   0          56m     192.168.1.23    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   coredns-657694c6f4-stwv9   1/1     Running   0          56m     192.168.1.28    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   kube-proxy-jgshq           1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   kube-proxy-wx9vk           1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>

   Ai Pods coredns vengono assegnati indirizzi IP dal blocco CIDR 192.168.1.0 aggiunto al VPC. Senza una rete personalizzata, ai pod sarebbero stati assegnati indirizzi provenienti dall'unico blocco CIDR originariamente associato al VPC, ossia il blocco CIDR 192.168.0.0.

   Se una spec del Pod's contiene il valore hostNetwork=true, viene assegnato l'indirizzo IP principale del nodo, non un indirizzo proveniente dalle sottoreti aggiunte. Per impostazione predefinita, questo valore è impostato su false. Questo valore è impostato su true per i Pods kube-proxy e Amazon VPC CNI plugin for Kubernetes (aws-node) in esecuzione nel cluster. Per questo motivo al kube-proxy e ai Pods aws-node del plugin non vengono assegnati indirizzi 192.168.1.x nell'output precedente. Per ulteriori informazioni su un'Pod'shostNetworkimpostazione, consulta PodSpec v1 core nel riferimento all'KubernetesAPI.

Per eliminare le risorse del tutorial

1. Se il gruppo di nodi creato era solo a scopo di test, eliminalo.

   aws eks delete-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup
   

   Anche dopo che l' AWS CLI output indica che il cluster è stato eliminato, il processo di eliminazione potrebbe non essere effettivamente completo. Questo processo di eliminazione richiede alcuni minuti. Verifica che il processo sia completo con il comando seguente.

   aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text
   

   Non continuare finché l'output restituito non è simile al seguente.

   An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.

2. Se il gruppo di nodi creato era solo a scopo di test, elimina il ruolo IAM del nodo.

   1. Scollega le policy dal ruolo.

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
      

   2. Elimina il ruolo.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSNodeRole
      

3. Elimina il cluster.

   aws eks delete-cluster --name $cluster_name
   

   Verifica l'eliminazione del cluster con il comando seguente.

   aws eks describe-cluster --name $cluster_name --query cluster.status --output text
   

   Quando viene restituito un output simile al seguente, il cluster è stato eliminato correttamente.

   An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.

4. Elimina il ruolo IAM del cluster.

   1. Scollega le policy dal ruolo.

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
      

   2. Elimina il ruolo.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
      

5. Elimina le sottoreti create in una fase precedente.

   aws ec2 delete-subnet --subnet-id $new_subnet_id_1
   aws ec2 delete-subnet --subnet-id $new_subnet_id_2
   

6. Elimina il VPC creato.

   aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc