Wie setze ich einen EKS Anywhere-Cluster in einen funktionsfähigen Zustand zurück, wenn das Cluster-Upgrade fehlschlägt?

Lesedauer: 6 Minute

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

Relevanter Inhalt

Wie bereinige ich EKS-Anywhere-Ressourcen ohne eksctl, wenn die Clustererstellung fehlschlägt?
AWS OFFICIALAktualisiert vor 6 Monaten
Wie plane ich eine Upgrade-Strategie für einen Amazon EKS-Cluster?
AWS OFFICIALAktualisiert vor 8 Monaten
Wie behebe ich den Fehler „Sie müssen beim Server angemeldet sein (nicht autorisiert)“, wenn ich eine Verbindung zum Amazon-EKS-API-Server herstelle?
AWS OFFICIALAktualisiert vor 2 Jahren
Wie behebe ich Fehler bei Namespaces in einem beendeten Zustand in meinem Amazon EKS-Cluster?
AWS OFFICIALAktualisiert vor 2 Jahren

Wie setze ich einen EKS Anywhere-Cluster in einen funktionsfähigen Zustand zurück, wenn das Cluster-Upgrade fehlschlägt?

Lösung

Überprüfungsphase

Upgrade-Phase

Ähnliche Informationen

Relevanter Inhalt