Comment rétablir un état de fonctionnement d'un cluster EKS Anywhere en cas d'échec de la mise à niveau du cluster ?

Lecture de 7 minute(s)

Je souhaite utiliser la commande eksctl pour mettre à niveau un cluster de gestion Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere. Toutefois, le processus de mise à niveau échoue ou est interrompu avant d'être terminé.

Résolution

Lorsque vous mettez à niveau un cluster de gestion Amazon EKS Anywhere, le processus comprend deux phases : la phase de vérification et la phase de mise à niveau. Les étapes de restauration en cas d'échec d'une mise à niveau dépendent de la phase de la mise à niveau qui a été interrompue.

Phase de vérification

Lorsque vous mettez à niveau un cluster EKS Anywhere, eksctl exécute un ensemble de contrôles avant le contrôle pour s'assurer que votre cluster est prêt. Cela se produit avant la mise à niveau et eksctl modifie votre cluster pour qu'il corresponde à la spécification mise à jour.

Lorsque eksctl effectue ces vérifications, un message similaire à l'exemple suivant s'affiche :

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

Ensuite, eksctl continue à vérifier les contrôleurs CAPI qui s'exécutent dans votre cluster de gestion. Si l'un de ces contrôleurs a besoin d'une mise à niveau, eksctl le met également à niveau. Au cours de ce processus, eksctl crée également un cluster d'amorçage KinD pour mettre à niveau votre cluster de gestion. Un message s'affiche qui reflète ce processus :

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

Si l'une de ces vérifications ou actions échoue, la mise à niveau s'arrête et votre cluster de gestion reste dans la même version d'origine.

Pour plus de détails sur la vérification spécifique qui a échoué, consultez les journaux eksctl.

Problèmes lors de la phase de vérification

Pour remédier à une panne survenue à ce stade, procédez comme suit :

1. Dépannez et corrigez le problème à l'origine de l'échec de la vérification.

2. Exécutez la commande de mise à niveau du cluster eksctl anywhere à nouveau. Il est recommandé d'utiliser l'indicateur -v9.

Phase de mise à niveau

Au cours de la phase de mise à niveau, eksctl exécute les actions principales suivantes :

Déplace les objets CAPI de votre cluster de gestion (tels que les machines, KubeAdmControlPlane et EtcDadmCluster) vers le cluster d'amorçage
Améliore les composants de l'etcd et du plan de contrôle
Met à niveau les composants du nœud de travail

Au cours de cette phase, un message similaire à l'exemple suivant s'affiche :

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 utilise un processus continu pour effectuer la mise à niveau sur place, similaire aux déploiements de Kubernetes. Il crée également une nouvelle machine virtuelle (VM) avec cette mise à niveau, puis supprime l'ancienne machine virtuelle. Ce processus s'applique à chaque composant, un par un, jusqu'à ce que tous les composants du plan de contrôle soient mis à niveau.

Si une machine virtuelle ne s'exécute pas, la mise à niveau échoue et s'arrête après un délai défini. Le processus continu permet à l'ancienne machine virtuelle de continuer à fonctionner afin de garantir que votre cluster reste dans l'état Prêt.

Problèmes lors de la phase de mise à niveau

Pour remédier à une panne survenue au cours de cette phase, procédez comme suit :

1. Dépannez et corrigez le problème à l'origine de l'échec de la mise à niveau. Consultez les journaux eksctl pour plus de détails sur l'échec.

2. Pour faciliter le processus de restauration, configurez une variable d'environnement :

**CLUSTER_NAME:**Le nom de votre cluster
**CLITOOLS \ _CONT :**Le nom du conteneur qui exécute les outils image cli-tools laissés dans votre environnement après l'interruption de la mise à niveau
**KINDKUBE:**Le fichier Kubeconfig que vous utilisez pour accéder au cluster d'amorçage KinD
**MGMTKUBE:**Le fichier Kubeconfig que vous utilisez pour accéder à votre cluster de gestion
EKSA_VSPHERE_USERNAME and **EKSA_VSPHERE_PASSWORD:**Informations d'identification pour accéder à vCenter

Consultez l'exemple suivant de ces variables :

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

3. Assurez-vous que les composants CAPI de votre cluster de gestion, tels que les machines et les clusters, sont dans l'état Prêt. Assurez-vous également que le serveur kubeApi de votre cluster de gestion est réactif. Pour ce faire, exécutez la commande suivante :

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

Vous recevez une sortie similaire à l'exemple suivant :

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

4. Sauvegardez les composants CAPI de votre cluster de gestion :

mkdir ${CLUSTER_NAME}-backup
docker exec -i $CLITOOLS_CONT clusterctl move --to-directory ${CLUSTER_NAME}-backup  --kubeconfig $KINDKUBE -n eksa-system

5. Replacez les composants CAPI de votre cluster de gestion vers votre cluster de gestion :

$ 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

Vous recevez une sortie similaire à l'exemple suivant :

$ 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

6. Assurez-vous que les composants CAPI du cluster de gestion, tels que les machines et les clusters, ne figurent plus dans le cluster d'amorçage KinD. Vérifiez qu'ils apparaissent dans le cluster de gestion. Pour ce faire, exécutez les commandes suivantes :

kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system
kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system

Vous recevez une sortie similaire à l'exemple suivant :

$ 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

7. Exécutez à nouveau la mise à niveau. Utilisez l'indicateur --force-cleanup -v9:

eksctl anywhere upgrade cluster -f cluster3/cluster3-eks-a-cluster.yaml --force-cleanup -v9

Informations connexes

Mettre à niveau le cluster vSphere, CloudStack, Nutanix ou Snow

Résolution des problèmes liés à l'EKS-A

Le livre des API Cluster (sur le site Web de Kubernetes)

Sujets

Conteneurs

Balises

Amazon Elastic Kubernetes Service

Langue

Français

AWS OFFICIELA mis à jour il y a un an

Aucun commentaire

Contenus pertinents

Mise à jour de ApiGateway - Network Failure
KAT34
demandé il y a 10 mois
Appels sortants à partir de salesforce / Amazon Connect
benoit paternotte
demandé il y a 5 jours
Problème de facturation au niveau des instances réservée
Kevin
demandé il y a 5 mois
Reprise gestion AWS
Réponse acceptée
biotops
demandé il y a 10 mois
Mon loadbalancer ne marche pas comme il devrait
zerros
demandé il y a un an
Comment fonctionne le démarrage d'un cluster EKS Anywhere ?
AWS OFFICIELA mis à jour il y a un an
Comment puis-je résoudre un échec de mise à niveau avec mon cluster Amazon EKS ?
AWS OFFICIELA mis à jour il y a un an
Comment nettoyer les ressources EKS Anywhere sans eksctl lorsque la création du cluster échoue ?
AWS OFFICIELA mis à jour il y a un an
Comment puis-je planifier une stratégie de mise à niveau pour un cluster Amazon EKS ?
AWS OFFICIELA mis à jour il y a 3 mois