Migrazione a un nuovo gruppo di nodi - Amazon EKS

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.

Migrazione delle applicazioni verso un nuovo gruppo di nodi con eksctl

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

eksctl version

Per ulteriori informazioni sull'installazione o l'aggiornamento di eksctl, consulta Installazione o aggiornamento 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

    L'output è il seguente:

    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 di versione non può essere successivo alla versione Kubernetes per il piano di controllo. Inoltre, non può essere più di due versioni secondarie precedenti rispetto alla versione Kubernetes per il piano di controllo. Si consiglia di utilizzare la stessa versione del piano di controllo. (Facoltativo) Se intendi assegnare ruoli IAM a tutti gli account del servizio Kubernetes in modo che i pod dispongano solo delle autorizzazioni minime necessarie e che nessun pod nel cluster richieda l'accesso ad Amazon EC2 Instance Metadata Service (IMDS) per altri motivi, ad esempio il recupero della Regione AWS corrente, ti consigliamo di bloccare l'accesso dei pod a IMDS. Per ulteriori informazioni, consulta Limita l'accesso al profilo di istanza assegnato al nodo (worker). IPer bloccare l'accesso del pod a IMDS, aggiungere 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.21 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --node-ami auto
  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

Per migrare le applicazioni a un nuovo gruppo di nodi con la AWS Management Console e AWS 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 RuoloIstanzaNodo per 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 se hai aggiunto le autorizzazioni per il Cluster Autoscaler Kubernetes, ad esempio.

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

    1. Registra gli ID del gruppo di sicurezza per entrambi i gruppi dei nodi. Questo viene illustrato con il valore GruppoSicurezzaNodo nell'output della pila AWS CloudFormation.

      È possibile utilizzare i seguenti comandi AWS CLI per ottenere gli ID del gruppo di sicurezza dai nomi della pila. In questi comandi, oldNodes è il nome della pila AWS CloudFormation per la pila precedente del nodo, mentre newNodes è il nome della pila verso cui si sta eseguendo la migrazione. 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 seguenti comandi AWS CLI aggiungono regole in ingresso per ciascun gruppo di sicurezza che consentono tutto il traffico su tutti i protocolli dall'altro gruppo di sicurezza. Questo consente ai pod 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.

    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 snippet ARN of instance role (not instance profile) con il valore RuoloIstanzaNodo 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 Kubernetes, dimensionare l'implementazione fino a 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 pod non vengono pianificati o riprogrammati sui nodi che stai sostituendo.

    kubectl taint nodes node_name key=value:NoSchedule

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

    K8S_VERSION=1.19 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 è riportato l'output. 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.19) con il seguente frammento di codice.

    K8S_VERSION=1.19 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, eliminare la pila AWS CloudFormation per terminare le istanze.

    Nota

    Se si dispone di policy IAM aggiuntive associate al vecchio ruolo IAM del gruppo di nodi (ad esempio, per aggiungere le autorizzazioni per il Cluster Autoscaler Kubernetes), distaccare tali policy aggiuntive prima di poter eliminare la pila AWS CloudFormation.

    1. Revocare le regole in ingresso create in precedenza per i gruppi di sicurezza dei nodi. In questi comandi, oldNodes è il nome della pila AWS CloudFormation per la pila precedente del nodo, mentre newNodes è il nome della pila verso cui si sta eseguendo la migrazione.

      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. Aprire la console di AWS CloudFormation all'indirizzo https://console.aws.amazon.com/cloudformation.

    3. Selezionare la pila del nodo precedente.

    4. Seleziona Delete (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.

    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 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 consultare Cluster Autoscaler su 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 . Aggiornamento del componente aggiuntivo autogestito CNI di Amazon VPC.

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

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