Wie behebe ich häufig auftretende Probleme mit Fehlern bei der Aktualisierung von Amazon-EKS-Knotengruppen?

Kurzbeschreibung

Neuere Versionen von Amazon EKS enthalten auch neue Versionen von Amazon AMIs für Knotengruppen-Updates. Kunden, deren Workload auf mehrere Knotengruppen verteilt ist, stehen vor der Herausforderung, ihre Knoten zu aktualisieren, um mit ihrem Freigabezyklus Schritt zu halten.

Wenn Sie ein Update für verwaltete Knotengruppen initiieren, aktualisiert Amazon EKS Ihre Knoten automatisch für Sie. Wenn Sie ein für Amazon EKS optimiertes AMI verwenden, wendet Amazon EKS automatisch die neuesten Sicherheitspatches und Betriebssystem-Updates auf Ihre Knoten als Teil der neuesten AMI-Freigabeversion an. Um das Update zu implementieren, startet AWS Auto Scaling die Knoten in jeder Availability Zone, in der sich die Knoten in der Knotengruppe befinden. Dieser Service sorgt auch für ein neues Gleichgewicht der Availability Zone. Da die vorhandenen Knoten nur einmal leer sind, ist der Startschritt erfolgreich. In der Herunterskalierungsphase werden die maximale Größe und die gewünschte Größe der Auto-Scaling-Gruppe um eins verringert, um zu den Werten vor der Aktualisierung zurückzukehren. Weitere Informationen finden Sie unter „Phase herunterskalieren“ im Aktualisierungsverhalten verwalteter Knoten.

Lösung

Während dieses Aktualisierungsvorgangs treten möglicherweise einige der folgenden Fehler auf, für die eigene Abhilfemaßnahmen erforderlich sind. Wenn Sie sich dieser Probleme im Voraus bewusst sind, können Sie Ausfallzeiten minimieren. Weitere Informationen zu Aktualisierungsfehlern finden Sie unter Aktualisierungsverhalten verwalteter Knoten.

Das Update ist aufgrund von PodEvictionFailure fehlgeschlagen

Error message : Reached max retries while trying to evict pods from nodes in node group.

Dieser Fehler weist darauf hin, dass das Upgrade durch PodEvictionFailure blockiert wurde. Wenn die Pods den Knoten nicht innerhalb von 15 Minuten verlassen und es kein Force-Flag gibt, schlägt die Upgrade-Phase mit einem PodEvictionFailure-Fehler fehl.

Die folgenden Gründe sind für den PodEvictionFailure-Fehler in der Upgrade-Phase aufgeführt:

Aggressives PDB (Pod Disruption Budget)

Aggressives PDB wird auf dem Pod definiert, wenn mehrere PDBs auf denselben Pod zeigen.

PDB gibt die Anzahl der Störungen an, die zu einem bestimmten Zeitpunkt für eine Klasse von Pods toleriert werden können (ein Budget von Fehlern). Immer wenn eine freiwillige Störung dazu führt, dass die Pods für einen Service unter das Budget fallen, wird der Betrieb unterbrochen, bis das Budget eingehalten werden kann. Das Knotenabflussereignis wird vorübergehend unterbrochen, bis mehr Pods verfügbar sind, sodass das Budget nicht durch das Entfernen der Pods überschritten wird. Weitere Informationen finden Sie unter Unterbrechungen auf der Kubernetes-Website.

Um eine reibungslose Aktualisierung der verwalteten Knotengruppen zu bestätigen, müssen Sie entweder die Budgets für die Pod-Unterbrechung vorübergehend entfernen oder die Option Erzwingen für die Aktualisierung verwenden. Diese Option berücksichtigt nicht die Budgets für Pod-Unterbrechungen. Stattdessen implementiert diese Option die Updates, indem sie die Knoten zum Neustart zwingt.

Hinweis: Wenn es sich bei der App um eine Quorum-basierte Anwendung handelt, kann die Option „Erzwingen“ dazu führen, dass die Anwendung vorübergehend nicht verfügbar ist.

Führen Sie den folgenden Befehl aus, um zu bestätigen, dass Sie PDBs in Ihrem Cluster konfiguriert haben:

$ kubectl get pdb --all-namespaces

Oder, wenn Sie die Prüfprotokollierung in der Amazon-EKS-Konsole aktiviert haben, gehen Sie wie folgt vor:

1.    Wählen Sie auf der Registerkarte Cluster den gewünschten Cluster (z. B. rpam-eks-qa2-control-plane) aus der Liste aus.

2.    Wählen Sie auf der Registerkarte Protokollierung die Option Prüfung aus. Dadurch werden Sie zur Amazon-CloudWatch-Konsole weitergeleitet.

3.    Wählen Sie in der CloudWatch-Konsole Protokolle aus. Wählen Sie dann Log Insights und führen Sie die folgende Abfrage aus:

fields @timestamp, @message
| filter @logStream like "kube-apiserver-audit"
| filter ispresent(requestURI)
| filter objectRef.subresource = "eviction" 
| display @logStream, requestURI, responseObject.message
| stats count(*) as retry by requestURI, responseObject.message

4.    Wählen Sie oben rechts Benutzerdefiniert aus, um das Datum für das Update zu ermitteln. Wenn die Aktualisierung der Knotengruppe aufgrund einer aggressiven PDB fehlschlägt, beschreibt resposeObject.message den Grund für den Fehler beim Entfernen des Pods.

5.    Wenn PDB den Fehler verursacht hat, ändern Sie die PDB mit dem folgenden Befehl. Aktualisieren Sie dann die Knotengruppe erneut:

$ kubectl edit pdb pdb_name;

Bereitstellung, der alle Taints toleriert

Nachdem jeder Pod entfernt wurde, wird der Knoten leer, da der Knoten in den vorherigen Schritten verunreinigt war. Wenn die Bereitstellung jedoch jeden Taint toleriert, ist es wahrscheinlicher, dass der Knoten nicht leer ist, was zu einem Fehler beim Entfernen des Pods führt. Weitere Informationen finden Sie auf der Kubernetes-Website unter Taints und Toleranzen.

Das Update ist aufgrund einer nicht gültigen Freigabeversion fehlgeschlagen

Error Message: Requested release version 1.xx is not valid for kubernetes version 1.xx.

Führen Sie den Befehl Upgrade erneut aus, um dieses Problem zu beheben. Mit diesem Befehl werden die Knotengruppen auf dieselbe Version wie die Kubernetes-Version der Steuerungsebene aktualisiert:

eksctl upgrade nodegroup --name=test --cluster=test --kubernetes-version=1.xx

Hinweis: Ersetzen Sie die Version 1.xx durch die Version, die von der Amazon-EKS-Steuerebene unterstützt wird.

Das Update ist fehlgeschlagen, da die Knotengruppe Gesundheitsprobleme hat

Error message: Nodegroup has health issue other than [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]

Dieser Fehler tritt auf, wenn Sie die Auto-Scaling-Gruppe der Knotengruppe manuell geändert haben, um eine andere Version der Amazon-Elastic-Compute-Cloud-Startvorlage (Amazon EC2) zu verwenden. Oder Sie haben möglicherweise die Version der Vorlage gelöscht, die der Knotengruppe zugeordnet ist. Die EKS-Knotengruppe verwendet eine Standardstartvorlage, die mit der Startvorlage der Auto-Scaling-Gruppe in Konflikt steht. Diese Startvorlage veranlasst EKS, die Knotengruppe als heruntergestuft anzuzeigen.

Wenn Sie die Startvorlage noch nicht gelöscht haben, ändern Sie die Version der Startvorlage der Auto-Scaling-Gruppe manuell zurück auf die entsprechende Version. Diese Aktion versetzt die Knotengruppe in einen gesunden und aktiven Zustand zurück. Sie können den Aktualisierungsvorgang jetzt erneut starten.

---