Migrazione a un nuovo gruppo di nodi

Questo argomento consente di creare un nuovo gruppo di nodi, di migrare correttamente le applicazioni esistenti al nuovo gruppo e di rimuovere il precedente gruppo di nodi dal cluster. È possibile eseguire la migrazione a un nuovo gruppo di nodi utilizzando eksctl o la AWS Management Console.

eksctl

Migrazione delle applicazioni verso un nuovo gruppo di nodi con eksctl

Per ulteriori informazioni sull'utilizzo di eksctl per la migrazione, vedere Unmanaged nodegroups nella documentazione. eksctl

Questa procedura richiede eksctl versione 0.175.0 o successiva. Puoi verificare la versione con il comando seguente:

eksctl version

Per istruzioni sull'installazione o sull'aggiornamento di eksctl, consulta la sezione Installation nella documentazione di eksctl.

Nota

Questa procedura funziona solo per i cluster e per i gruppi di nodi creati con eksctl.

1. Recuperare il nome dei gruppi di nodi esistenti, sostituendo my-cluster con il nome del cluster.

   eksctl get nodegroups --cluster=my-cluster
   

   Di seguito viene riportato un output di esempio:

   CLUSTER      NODEGROUP          CREATED               MIN SIZE      MAX SIZE     DESIRED CAPACITY     INSTANCE TYPE     IMAGE ID
   default      standard-nodes   2019-05-01T22:26:58Z  1             4            3                    t3.medium         ami-05a71d034119ffc12

2. Avvia un nuovo gruppo di nodi con eksctl con il comando seguente. Nel comando, sostituire ogni example value con i propri valori. Il numero della versione non può essere successivo alla versione di Kubernetes per il piano di controllo (control-plane). Inoltre, non può essere più di due versioni secondarie precedenti rispetto alla versione Kubernetes per il piano di controllo (control-plane). Si consiglia di utilizzare la stessa versione del piano di controllo.

   Consigliamo di bloccare l'accesso dei Pod a IMDS se si verificano le seguenti condizioni:

   • Prevedi di assegnare ruoli IAM a tutti gli account di servizio Kubernetes in modo che i Pods dispongano solo delle autorizzazioni minime necessarie.

   • Nessuno Pods nel cluster richiede l'accesso al servizio di metadati delle istanze Amazon EC2 (IMDS) per altri motivi, come il recupero della corrente. Regione AWS

   Per ulteriori informazioni, consulta Limitazione dell'accesso al profilo dell'istanza assegnato al nodo worker.

   Per bloccare l'accesso del Pod a IMDS, aggiungi l'opzione --disable-pod-imds al seguente comando.

   Nota

   Per ulteriori flag disponibili e relative descrizioni, vedere https://eksctl.io/.

   eksctl create nodegroup \
     --cluster my-cluster \
     --version 1.29 \
     --name standard-nodes-new \
     --node-type t3.medium \
     --nodes 3 \
     --nodes-min 1 \
     --nodes-max 4 \
     --managed=false
   

3. Quando il comando precedente viene completato, verificare che tutti i nodi abbiano raggiunto lo stato Ready con il comando seguente:

   kubectl get nodes
   

4. Eliminare il gruppo di nodi originale con il comando seguente. Nel comando, sostituire ogni example value con i nomi dei cluster e dei gruppi di nodi:

   eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
   

AWS Management Console and AWS CLI

Per migrare le applicazioni in un nuovo gruppo di nodi con e AWS Management ConsoleAWS CLI

1. Avviare un nuovo gruppo di nodi seguendo i passaggi descritti in Avvio di nodi Amazon Linux autogestiti.

2. Al termine della creazione della pila, selezionala nella console e scegli Outputs (Uscite).

3. Registra il NodeInstanceRoleper il gruppo di nodi che è stato creato. Ciò è necessario per aggiungere i nuovi nodi Amazon EKS al cluster.

   Nota

   Se si dispone di policy IAM aggiuntive associate al vecchio ruolo IAM del gruppo di nodi, associa le stesse policy al nuovo ruolo IAM del gruppo di nodi per mantenere tale funzionalità nel nuovo gruppo. Questo vale, ad esempio, se hai aggiunto le autorizzazioni per il Cluster Autoscaler di Kubernetes.

4. Aggiorna i gruppi di sicurezza per entrambi i gruppi di nodi in modo che possano comunicare tra loro. Per ulteriori informazioni, consulta Considerazioni e requisiti relativi al gruppo di sicurezza Amazon EKS.

   1. Registra gli ID del gruppo di sicurezza per entrambi i gruppi dei nodi. Questo viene mostrato come NodeSecurityGroupvalore negli output dello AWS CloudFormation stack.

      È possibile utilizzare i seguenti AWS CLI comandi per ottenere gli ID dei gruppi di sicurezza dai nomi dello stack. In questi comandi, oldNodes è il nome AWS CloudFormation dello stack per lo stack di nodi precedente ed newNodes è il nome dello stack verso cui state migrando. Sostituisci ogni example value con i valori in tuo possesso.

      oldNodes="old_node_CFN_stack_name"
      newNodes="new_node_CFN_stack_name"
      
      oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      

   2. Aggiungi regole in ingresso per ciascun gruppo di sicurezza del nodo in modo da accettare il traffico tra loro.

      I AWS CLI comandi seguenti aggiungono regole in entrata a ciascun gruppo di sicurezza che consentono tutto il traffico su tutti i protocolli dell'altro gruppo di sicurezza. Ciò consente ai Pods in ogni gruppo di nodi di comunicare tra loro durante la migrazione del carico di lavoro verso il nuovo gruppo.

      aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \
      --source-group $newSecGroup --protocol -1
      aws ec2 authorize-security-group-ingress --group-id $newSecGroup \
      --source-group $oldSecGroup --protocol -1
      

5. Modifica la configmap aws-auth per mappare il nuovo ruolo dell'istanza del nodo in RBAC.

   kubectl edit configmap -n kube-system aws-auth
   

   Aggiungi una nuova voce mapRoles per il nuovo gruppo di nodi. Se il cluster si trova negli AWS GovCloud (Stati Uniti orientali) o AWS GovCloud (Stati Uniti occidentali) Regioni AWS, sostituiscilo con. arn:aws: arn:aws-us-gov:

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: ARN of instance role (not instance profile)
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes>
       - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes

   Sostituisci lo ARN of instance role (not instance profile) snippet con il NodeInstanceRolevalore registrato nel passaggio precedente. Quindi, salva e chiudi il file per applicare la configmap aggiornata.

6. Guarda lo stato dei nodi e attendi fino a quando i nuovi nodi si uniscono al cluster e raggiungono lo stato Ready.

   kubectl get nodes --watch
   

7. (Facoltativo) Se si sta utilizzando il Cluster Autoscaler di Kubernetes, ridurre l'implementazione fino a raggiungere zero (0) repliche per evitare azioni di dimensionamento conflittuali.

   kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
   

8. Utilizzare il comando seguente per il taint di ciascuno dei nodi che si desidera rimuovere con NoSchedule. In questo modo i nuovi Pods non vengono pianificati o riprogrammati sui nodi che stai sostituendo. Per ulteriori informazioni consulta Taint e tolleranze nella documentazione di Kubernetes.

   kubectl taint nodes node_name key=value:NoSchedule
   

   Se si aggiornano i nodi a una nuova versione di Kubernetes, è possibile identificare e fare il taint di tutti i nodi di una determinata versione di Kubernetes (in questo caso, 1.27) con il frammento di codice seguente. Il numero della versione non può essere successivo alla versione di Kubernetes per il piano di controllo (control-plane). Inoltre, non può essere più di due versioni secondarie precedenti rispetto alla versione Kubernetes del piano di controllo (control-plane). Si consiglia di utilizzare la stessa versione del piano di controllo.

   K8S_VERSION=1.27
   nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
   for node in ${nodes[@]}
   do
       echo "Tainting $node"
       kubectl taint nodes $node key=value:NoSchedule
   done
   

9. Determinare il provider DNS del cluster.

   kubectl get deployments -l k8s-app=kube-dns -n kube-system
   

   Di seguito viene riportato un output di esempio: Questo cluster utilizza CoreDNS per la risoluzione DNS, ma il cluster può invece restituire kube-dns):

   NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   coredns   1         1         1            1           31m

10. Se l'implementazione corrente è in esecuzione per un numero di volte inferiore a 2 repliche, scalare la distribuzione a 2 repliche. Sostituire coredns con kubedns se l'output del comando precedente ha avuto tale risultato.

    kubectl scale deployments/coredns --replicas=2 -n kube-system
    

11. Svuotare ciascuno dei nodi che si desidera rimuovere dal cluster con il comando seguente:

    kubectl drain node_name --ignore-daemonsets --delete-local-data
    

    Se si aggiornano i nodi a una nuova versione di Kubernetes, identificare e svuotare tutti i nodi di una determinata versione di Kubernetes (in questo caso, 1.27) con il frammento di codice seguente.

    K8S_VERSION=1.27
    nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
    for node in ${nodes[@]}
    do
        echo "Draining $node"
        kubectl drain $node --ignore-daemonsets --delete-local-data
    done
    

12. Una volta terminata tale operazione, revocare le regole in ingresso del gruppo di sicurezza autorizzate in precedenza. Quindi, elimina lo AWS CloudFormation stack per terminare le istanze.

    Nota

    Se hai collegato delle policy IAM aggiuntive al tuo vecchio gruppo di nodi (ruolo IAM, ad esempio aggiungendo autorizzazioni per Kubernetes Cluster Autoscaler), scollega quelle policy aggiuntive dal ruolo prima di poter eliminare lo stack. AWS CloudFormation

    1. Revocare le regole in ingresso create in precedenza per i gruppi di sicurezza dei nodi. In questi comandi, oldNodes c'è il nome AWS CloudFormation dello stack di nodi precedente ed newNodes è il nome dello stack verso cui stai migrando.

       oldNodes="old_node_CFN_stack_name"
       newNodes="new_node_CFN_stack_name"
       
       oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
       --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
       --output text)
       newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
       --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
       --output text)
       aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \
       --source-group $newSecGroup --protocol -1
       aws ec2 revoke-security-group-ingress --group-id $newSecGroup \
       --source-group $oldSecGroup --protocol -1
       

    2. Apri la console all'indirizzo https://console.aws.amazon.com/cloudformation AWS CloudFormation .

    3. Selezionare la pila del nodo precedente.

    4. Scegli Elimina.

    5. Nella finestra di dialogo di conferma Delete stack (Elimina stack) scegliere Delete stack.(Elimina stack).

13. Modifica il configmap aws-auth per rimuovere il precedente ruolo dell'istanza del nodo da RBAC.

    kubectl edit configmap -n kube-system aws-auth
    

    Eliminare la voce mapRoles per il precedente gruppo di nodo. Se il cluster si trova negli AWS GovCloud (Stati Uniti orientali) o AWS GovCloud (Stati Uniti occidentali) Regioni AWS, arn:aws: sostituiscilo con. arn:aws-us-gov:

    apiVersion: v1
    data:
      mapRoles: |
        - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
          username: system:node:{{EC2PrivateDNSName}}
          groups:
            - system:bootstrappers
            - system:nodes
        - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
          username: system:node:{{EC2PrivateDNSName}}
          groups:
            - system:bootstrappers
            - system:nodes>

    Salvare e chiudere il file per applicare la configmap aggiornata.

14. (Facoltativo) Se si sta utilizzando il Cluster Autoscaler di Kubernetes, dimensionare l'implementazione a 1 replica.

    Nota

    È inoltre necessario applicare i tag al nuovo gruppo Auto Scaling in modo appropriato (ad esempio, k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster) e aggiornare il comando di implementazione di Cluster Autoscaler per puntare al nuovo gruppo Auto Scaling contrassegnato. Per ulteriori informazioni, consulta Cluster Autoscaler on. AWS

    kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
    

15. (Facoltativo) Verificare che si sta utilizzando la versione più recente del plug-in CNI di Amazon VPC per Kubernetes. Potrebbe essere necessario aggiornare la versione CNI per utilizzare i tipi di istanze supportati più recenti. Per ulteriori informazioni, consulta Utilizzo del componente aggiuntivo Amazon VPC CNI plugin for Kubernetes di Amazon EKS.

16. Se il cluster utilizza kube-dns per la risoluzione DNS (vedere il passaggio precedente), ridurre orizzontalmente l'implementazione kube-dns a una replica.

    kubectl scale deployments/kube-dns --replicas=1 -n kube-system