Come faccio a riportare un cluster EKS Anywhere allo stato operativo quando l'aggiornamento del cluster fallisce?
Desidero utilizzare il comando eksctl per aggiornare un cluster di gestione Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere. Tuttavia, il processo di aggiornamento non riesce o viene interrotto prima del completamento.
Risoluzione
Quando esegui l'upgrade di un cluster di gestione Amazon EKS Anywhere, il processo include due fasi: la fase di verifica e la fase di aggiornamento. Le fasi di ripristino per un aggiornamento non riuscito dipendono dalla fase dell'aggiornamento interrotta.
Fase di verifica
Quando si aggiorna un cluster EKS Anywhere, eksctl esegue una serie di controlli preliminari per assicurarsi che il cluster sia pronto. Ciò si verifica prima dell'aggiornamento ed eksctl modifica il cluster in modo che corrisponda alle specifiche aggiornate.
Quando eksctl esegue questi controlli, viene visualizzato un messaggio simile al seguente esempio:
Performing setup and validations Connected to server Authenticated to vSphere Datacenter validated Network validated Creating template. This might take a while. Datastore validated Folder validated Resource pool validated Datastore validated Folder validated Resource pool validated Datastore validated Folder validated Resource pool validated Machine config tags validated Control plane and Workload templates validated Vsphere provider validation Validate certificate for registry mirror Control plane ready Worker nodes ready Nodes ready Cluster CRDs ready Cluster object present on workload cluster Upgrade cluster kubernetes version increment Validate authentication for git provider Validate immutable fields Upgrade preflight validations pass
Successivamente, eksctl continua a verificare i controller CAPI che vengono eseguiti nel cluster di gestione. Se uno di questi controller necessita di un aggiornamento, anche eksctl li aggiorna. Durante questo processo, eksctl crea anche un cluster di bootstrap KIND per aggiornare il cluster di gestione. Viene visualizzato un messaggio che riflette questo processo:
Ensuring etcd CAPI providers exist on management cluster before Pausing EKS-A cluster controller reconcile Pausing GitOps cluster resources reconcile Upgrading core components Creating bootstrap cluster Provider specific pre-capi-install-setup on bootstrap cluster Provider specific post-setup Installing cluster-api providers on bootstrap cluster
Se uno di questi controlli o azioni fallisce, l'aggiornamento si interrompe e il cluster di gestione rimane nella stessa versione originale.
Per maggiori dettagli sul controllo specifico che non è riuscito, controlla i log di eksctl.
Problemi durante la fase di verifica
Per ripristinare un errore in questa fase, completa i seguenti passaggi:
-
Risolvi e risolvi il problema che ha causato il fallimento della verifica.
-
Esegui nuovamente il comando eksctl anywhere cluster upgrade. È consigliabile utilizzare il flag \ -v9.
Fase di aggiornamento
Nella fase di aggiornamento, eksctl esegue le seguenti azioni principali:
- Sposta gli oggetti CAPI del cluster di gestione (come macchine, KubeAdmControlPlane ed etcdAdmCluster) nel cluster bootstrap
- Aggiorna i componenti etcd e piano di controllo
- Aggiorna i componenti del nodo di lavoro
Durante questa fase, viene visualizzato un messaggio simile all'esempio seguente:
Moving cluster management from bootstrap to workload cluster Applying new EKS-A cluster resource Resuming EKS-A controller reconcile Updating Git Repo with new EKS-A cluster spec GitOps field not specified, update git repo skipped Forcing reconcile Git repo with latest commit GitOps not configured, force reconcile flux git repo skipped Resuming GitOps cluster resources kustomization Writing cluster config file Cluster upgraded!
eksctl utilizza un processo continuo per eseguire l'aggiornamento in atto, simile alle distribuzioni Kubernetes. Inoltre, crea una nuova macchina virtuale (VM) con questo aggiornamento, quindi rimuove la vecchia macchina virtuale. Questo processo si applica a ciascun componente, uno alla volta, fino all'aggiornamento di tutti i componenti del piano di controllo.
Se una macchina virtuale non riesce a funzionare, l'aggiornamento fallisce e si interrompe dopo un intervallo di timeout impostato. Il processo a ciclo continuo mantiene in funzione la vecchia macchina virtuale per garantire che il cluster rimanga nello stato Pronto.
Problemi durante la fase di aggiornamento
Per ripristinare un errore durante questa fase, completa i seguenti passaggi:
-
Risolvi e risolvi il problema che ha causato il fallimento dell'aggiornamento. Controlla i log di eksctl per i dettagli sull'errore.
-
Per facilitare il processo di ripristino, imposta una variabile di ambiente:
- **CLUSTER\ _NOME:**Il nome del tuo cluster
- **STRUMENTI CLITOOLS\ _CONT:**Il nome del contenitore che esegue image-cli-tools rimasti nell'ambiente dopo l'interruzione dell'aggiornamento
- KINDKUBE: Il file Kubeconfig che usi per accedere al cluster di bootstrap KIND
- TUBO MGMT: Il file Kubeconfig che usi per accedere al tuo cluster di gestione
- EKSA\ _VSPHERE\ _USERNAME ed EKSA\ _VSPHERE\ _PASSWORD: Credenziali per accedere a vCenter
Vedi il seguente esempio di queste variabili:
CLUSTER_NAME=cluster3 CLITOOLS_CONT=eksa_1681572481616591501 KINDKUBE=$CLUSTER_NAME/generated/${CLUSTER_NAME}.kind.kubeconfig MGMTKUBE=$CLUSTER_NAME/$CLUSTER_NAME-eks-a-cluster.kubeconfig EKSA_VSPHERE_USERNAME=xxxxx EKSA_VSPHERE_PASSWORD=yyyyy
- Assicurati che i componenti CAPI del cluster di gestione, come macchine e cluster, siano nello stato Pronto. Inoltre, assicurati che il kubeApi-server nel tuo cluster di gestione sia reattivo. Per fare ciò, esegui il seguente comando:
kubectl --kubeconfig $KINDKUBE -n eksa-system get machines docker exec -i $CLITOOLS_CONT clusterctl describe cluster cluster3 --kubeconfig $KINDKUBE -n eksa-system kubectl --kubeconfig $MGMTKUBE -n kube-system get node
Riceverai un output simile al seguente esempio:
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION cluster3-2snw8 cluster3 cluster3-2snw8 vsphere://4230efe1-e1f5-c8e5-9bff-12eca320f5db Running 3m13s v1.23.17-eks-1-23-19 cluster3-etcd-chkc5 cluster3 vsphere://4230826c-b25d-937a-4728-3e607e6af579 Running 4m14s cluster3-md-0-854976576-tw6hr cluster3 cluster3-md-0-854976576-tw6hr vsphere://4230f2e5-0a4b-374c-f06b-41ac1f80e41f Running 4m30s v1.22.17-eks-1-22-24 $ docker exec -i $CLITOOLS_CONT clusterctl describe cluster cluster3 --kubeconfig $KINDKUBE -n eksa-system NAME READY SEVERITY REASON SINCE MESSAGE Cluster/cluster3 True 49s ├─ClusterInfrastructure - VSphereCluster/cluster3 True 4m53s ├─ControlPlane - KubeadmControlPlane/cluster3 True 49s │ └─Machine/cluster3-2snw8 True 2m51s └─Workers ├─MachineDeployment/cluster3-md-0 True 4m53s │ └─Machine/cluster3-md-0-854976576-tw6hr True 4m53s └─Other └─Machine/cluster3-etcd-chkc5 True 3m55s $ kubectl --kubeconfig $MGMTKUBE -n kube-system get node NAME STATUS ROLES AGE VERSION cluster3-md-0-854976576-tw6hr Ready [none] 18m v1.22.17-eks-a51510b cluster3-2snw8 Ready control-plane,master 19m v1.23.17-eks-a51510b
- Esegui il backup dei componenti CAPI del cluster di gestione:
mkdir ${CLUSTER_NAME}-backup docker exec -i $CLITOOLS_CONT clusterctl move --to-directory ${CLUSTER_NAME}-backup --kubeconfig $KINDKUBE -n eksa-system
- Riporta i componenti CAPI del cluster di gestione nel tuo cluster di gestione:
$ docker exec -i $CLITOOLS_CONT clusterctl move --to-kubeconfig $MGMTKUBE --kubeconfig $KINDKUBE -n eksa-system Performing move... Discovering Cluster API objects Moving Cluster API objects Clusters=1 Moving Cluster API objects ClusterClasses=0 Creating objects in the target cluster Deleting objects from the source cluster
Riceverai un output simile al seguente esempio:
$ docker exec -i $CLITOOLS_CONT clusterctl move --to-kubeconfig $MGMTKUBE --kubeconfig $KINDKUBE -n eksa-system Performing move... Discovering Cluster API objects Moving Cluster API objects Clusters=1 Moving Cluster API objects ClusterClasses=0 Creating objects in the target cluster Deleting objects from the source cluster
- Assicurati che i componenti CAPI del cluster di gestione, come macchine e cluster, non siano più nel cluster di bootstrap di KinD. Verifica che vengano visualizzati nel cluster di gestione. Per fare ciò, esegui i seguenti comandi:
kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system
Riceverai un output simile al seguente esempio:
$ kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system No resources found in eksa-system namespace. $ kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION cluster2-4n7qd cluster2 cluster2-4n7qd vsphere://4230fb07-2823-3474-c41f-b7223dec3089 Running 2m27s v1.23.17-eks-1-23-19 cluster2-etcd-h4tpl cluster2 vsphere://42303b36-1991-67a9-e942-dd9959760649 Running 2m27s cluster2-md-0-fd6c558b-6cfvq cluster2 cluster2-md-0-fd6c558b-6cfvq vsphere://423019a3-ad3f-1743-e7a8-ec8772d3edc2 Running 2m26s v1.22.17-eks-1-22-24
- Esegui nuovamente l'aggiornamento. Usa il flag **\ --force-cleanup -v9: **:
eksctl anywhere upgrade cluster -f cluster3/cluster3-eks-a-cluster.yaml --force-cleanup -v9
Informazioni correlate
Aggiorna vSphere, CloudStack, Nutanix o Snow cluster
Risoluzione dei problemi EKS-A
Il Cluster API Book (sul sito Web di Kubernetes)
Contenuto pertinente
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata un anno fa