Comment rétablir un état de fonctionnement d'un cluster EKS Anywhere en cas d'échec de la mise à niveau du cluster ?
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)
Contenus pertinents
- demandé il y a 10 moislg...
- demandé il y a 5 moislg...
- demandé il y a 4 jourslg...
- demandé il y a un anlg...
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 3 mois