Come faccio a riportare un cluster EKS Anywhere allo stato operativo quando l'aggiornamento del cluster fallisce?

7 minuti di lettura
0

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:

  1. Risolvi e risolvi il problema che ha causato il fallimento della verifica.

  2. 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:

  1. Risolvi e risolvi il problema che ha causato il fallimento dell'aggiornamento. Controlla i log di eksctl per i dettagli sull'errore.

  2. 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
  1. 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
  1. 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
  1. 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
  1. 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
  1. 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)

AWS UFFICIALE
AWS UFFICIALEAggiornata un anno fa