Wie setze ich einen EKS Anywhere-Cluster in einen funktionsfähigen Zustand zurück, wenn das Cluster-Upgrade fehlschlägt?
Ich möchte den Befehl eksctl verwenden, um einen Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere-Management-Cluster zu aktualisieren. Der Upgrade-Vorgang schlägt jedoch fehl oder wird vor dem Abschluss unterbrochen.
Lösung
Wenn Sie einen Amazon EKS Anywhere-Management-Cluster aktualisieren, umfasst der Prozess zwei Phasen: die Überprüfungsphase und die Upgrade-Phase. Die Wiederherstellungsschritte für ein fehlgeschlagenes Upgrade hängen davon ab, welche Phase des Upgrades unterbrochen wurde.
Überprüfungsphase
Wenn Sie einen EKS Anywhere-Cluster aktualisieren, führt eksctl eine Reihe von Preflight-Checks durch, um sicherzustellen, dass Ihr Cluster bereit ist. Dies geschieht vor dem Upgrade, und eksctl modifiziert Ihren Cluster so, dass er der aktualisierten Spezifikation entspricht.
Wenn eksctl diese Prüfungen durchführt, wird eine Meldung angezeigt, die dem folgenden Beispiel ähnelt:
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
Als Nächstes überprüft eksctl die CAPI-Controller, die in Ihrem Management-Cluster laufen. Wenn einer dieser Controller ein Upgrade benötigt, aktualisiert eksctl ihn anschließend ebenfalls. Während dieses Vorgangs erstellt eksctl auch einen KiND-Bootstrap-Cluster, um Ihren Management-Cluster zu aktualisieren. Sie sehen eine Meldung, die diesen Prozess widerspiegelt:
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
Wenn eine dieser Prüfungen oder Aktionen fehlschlägt, wird das Upgrade beendet und Ihr Management-Cluster verbleibt in der gleichen Originalversion.
Weitere Informationen zu der spezifischen Prüfung, die fehlgeschlagen ist, finden Sie in den eksctl-Protokollen.
Probleme während der Überprüfungsphase
Gehen Sie wie folgt vor, um einen Fehler in dieser Phase zu beheben:
1.Beheben Sie das Problem, das zum Fehlschlagen der Überprüfung geführt hat.
2.Führen Sie den Befehl eksctl anywhere cluster upgrade erneut aus. Es hat sich bewährt, das -v9-Flag zu verwenden.
Upgrade-Phase
In der Upgrade-Phase führt eksctl die folgenden Hauptaktionen aus:
- Verschiebt die CAPI-Objekte Ihres Management-Clusters (wie Maschinen, KubeadmControlPlane und EtcdadmCluster) in den Bootstrap-Cluster
- Aktualisiert die etcd- und Steuerungsebenenkomponenten
- Aktualisiert die Worker-Knotenkomponenten
In dieser Phase wird eine Meldung angezeigt, die dem folgenden Beispiel ähnelt:
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 verwendet einen Rolling-Prozess, um das Upgrade direkt durchzuführen, ähnlich wie bei Kubernetes-Bereitstellungen. Mit diesem Upgrade wird auch eine neue virtuelle Maschine (VM) erstellt und anschließend die alte VM entfernt. Dieser Prozess wird für die einzelnen Komponenten nacheinander angewendet, bis alle Komponenten der Steuerebene aktualisiert sind.
Wenn eine VM nicht ausgeführt werden kann, schlägt das Upgrade fehl und wird nach einem festgelegten Timeout-Intervall beendet. Der Rolling-Prozess hält die alte VM am Laufen, um sicherzustellen, dass Ihr Cluster im Status Bereit bleibt.
Probleme während der Upgrade-Phase
Gehen Sie wie folgt vor, um einen Fehler in dieser Phase zu beheben:
1.Beheben Sie das Problem, das zum Fehlschlagen des Upgrades geführt hat. Einzelheiten zum Fehler finden Sie in den eksctl-Protokollen.
2.Um den Wiederherstellungsprozess zu erleichtern, richten Sie eine Umgebungsvariable ein:
- **CLUSTER\ _NAME:**Der Name Ihres Clusters
- **CLITOOLS\ _CONT:**Der Name des Containers, in dem die image cli-tools ausgeführt werden, die nach einer Unterbrechung des Upgrades in Ihrer Umgebung verblieben sind
- **KINDKUBE:**Die Kubeconfig-Datei, die Sie für den Zugriff auf den KiND-Bootstrap-Cluster verwenden
- **MGMTKUBE:**Die Kubeconfig-Datei, die Sie für den Zugriff auf Ihren Management-Cluster verwenden
- EKSA_VSPHERE_USERNAME und **EKSA_VSPHERE_PASSWORD:**Anmeldeinformationen für den Zugriff auf vCenter
Sehen Sie sich das folgende Beispiel für diese Variablen an:
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.Stellen Sie sicher, dass sich die CAPI-Komponenten Ihres Management-Clusters, wie Maschinen und Cluster, im Status Bereit befinden. Stellen Sie außerdem sicher, dass der kubeApi-server in Ihrem Management-Cluster reagiert. Führen Sie dazu den folgenden Befehl aus:
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
Sie erhalten eine Ausgabe, die dem folgenden Beispiel ähnelt:
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.Sichern Sie die CAPI-Komponenten Ihres Management-Clusters:
mkdir ${CLUSTER_NAME}-backup docker exec -i $CLITOOLS_CONT clusterctl move --to-directory ${CLUSTER_NAME}-backup --kubeconfig $KINDKUBE -n eksa-system
5.Verschieben Sie die CAPI-Komponenten Ihres Management-Clusters zurück in Ihren Management-Cluster:
$ 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
Sie erhalten eine Ausgabe, die dem folgenden Beispiel ähnelt:
$ 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.Stellen Sie sicher, dass sich die CAPI-Komponenten des Management-Clusters, wie Maschinen und Cluster, nicht mehr im KinD-Bootstrap-Cluster befinden. Stellen Sie sicher, dass sie im Management-Cluster angezeigt werden. Führen Sie dazu die folgenden Befehle aus:
kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system
Sie erhalten eine Ausgabe, die dem folgenden Beispiel ähnelt:
$ 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.Führen Sie das Upgrade erneut aus. Verwenden Sie das Flag**--force-cleanup -v9**:
eksctl anywhere upgrade cluster -f cluster3/cluster3-eks-a-cluster.yaml --force-cleanup -v9
Ähnliche Informationen
Führen Sie ein Upgrade des vSphere-, CloudStack-, Nutanix- oder Snow-Clusters durch
Das Cluster-API-Buch (auf der Kubernetes-Website)
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 8 Monaten
- AWS OFFICIALAktualisiert vor 10 Monaten
- AWS OFFICIALAktualisiert vor 2 Jahren