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

Kurzbeschreibung

Wenn Sie ein Update für verwaltete Knotengruppen initiieren, aktualisiert Amazon EKS Ihre Knoten automatisch. Wenn Sie ein für Amazon EKS optimiertes AMI verwenden, wendet Amazon EKS automatisch die neuesten Sicherheitspatches und Betriebssystemupdates auf Ihre Knoten an.

Während dieses Aktualisierungsvorgangs tritt möglicherweise einer der folgenden Fehler auf. Folgen Sie den entsprechenden Schritten zur Fehlerbehebung für den Fehler, auf den Sie stoßen. Weitere Informationen zu Aktualisierungsfehlern finden Sie unter Aktualisierungsverhalten von verwalteten Knoten.

Lösung

Das Update ist aufgrund von PodEvictionFailure fehlgeschlagen

Der folgende Fehler weist darauf hin, dass ein PodEvictionFailure das Upgrade blockiert:

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

Wenn die Pods den Knoten nicht innerhalb von 15 Minuten verlassen und kein Force-Flag angezeigt wird, schlägt die Upgrade-Phase mit einem PodEvictionFailure-Fehler fehl.

Ein PodEvictionFailure-Fehler kann aus einem der folgenden Gründe auftreten:

Aggressives PDB (Pod Disruption Budget)

Wenn es mehrere PDB gibt, die auf denselben Pod verweisen, hat der Pod die Definition Aggressive PDB.

PDB gibt die Anzahl der Störungen an, die eine Klasse von Pods zu einem bestimmten Zeitpunkt tolerieren kann (oder ein „Fehlerbudget“). Wenn eine freiwillige Unterbrechung dazu führt, dass die Pods für einen Dienst unter das Budget fallen, wird der Betrieb unterbrochen, bis das Budget eingehalten werden kann. Das Node-Drain-Ereignis wird vorübergehend angehalten, bis mehr Pods verfügbar sind. Dadurch wird sichergestellt, dass Sie das Budget nicht überschreiten, indem Sie die Pods bereinigen. Weitere Informationen finden Sie unter Störungen auf der Kubernetes Website.

Um sicherzustellen, dass die verwalteten Knotengruppen reibungslos aktualisiert werden, entfernen Sie entweder vorübergehend die Budgets für Pod-Unterbrechungen oder verwenden Sie die Option „Force-Update“. Diese Option berücksichtigt nicht die Budgets für Pod-Unterbrechungen. Stattdessen werden die Knoten gezwungen, neu zu starten und somit die Updates zu implementieren.

**Hinweis:**Wenn es sich bei der App um eine Quorum-basierte Anwendung handelt, kann die Option Force 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 PDB in Ihrem Cluster konfiguriert haben:

$ kubectl get pdb --all-namespaces

Oder, wenn Sie die Audit-Protokollierung in der Amazon-EKS-Konsole aktiviert haben, gehen Sie wie folgt vor:

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

2. Wählen Sie auf der Registerkarte Protokollierung die Option Audit aus. Diese Aktion leitet Sie zur Amazon-CloudWatch-Konsole weiter.

3. Wählen Sie in der CloudWatch-Konsole Protokolle aus. Wählen Sie dann Protokolleinblicke 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 Benutzerdefiniert, um das Datum für das Update zu identifizieren. Wenn die Aktualisierung der Knotengruppe aufgrund einer aggressiven PDB fehlschlägt, beschreibt resposeObject.message den Grund für den Fehler bei der Bereinigung des Pods.

5. Wenn PDB den Fehler verursacht hat, ändern Sie die PDB. Führen Sie den folgenden Befehl aus, und führen Sie dann erneut ein Upgrade der Knotengruppe durch:

   $ kubectl edit pdb pdb_name;

Bereitstellung, die alle Taints toleriert

Nachdem jeder Pod bereinigt wurde, ist der Knoten leer, weil der Knoten in den vorherigen Schritten fehlerhaft wurde. Wenn die Bereitstellung jedoch jeden Taint toleriert, ist es wahrscheinlicher, dass der Knoten nicht leer ist. Dies führt dazu, dass die Pod-Bereinigung fehlschlägt. Weitere Informationen finden Sie unter Taints and Tolerations auf der Kubernetes Website.

Das Update ist aufgrund einer ungültigen Version fehlgeschlagen

Wenn Sie eine ungültige Version haben, wird möglicherweise die folgende Fehlermeldung angezeigt:

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

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

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, weil die Knotengruppe fehlerhaft ist

Wenn Ihre Knotengruppe fehlerhaft ist, wird bei einem fehlgeschlagenen Update der folgender Fehler angezeigt:

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

Dies deutet darauf hin, dass die Auto-Scaling-Gruppe der Knotengruppe die erwartete Version ihrer Amazon Elastic Compute Cloud (Amazon EC2)-Startvorlage nicht finden kann. Dieser Fehler tritt auf, wenn Sie die Version der Vorlage, die der Knotengruppe zugeordnet ist, manuell ändern oder löschen. Dadurch zeigt EKS die Knotengruppe als herabgestuft an.

Wenn Sie die Startvorlage nicht gelöscht haben, ändern Sie die Startvorlagenversion der Auto-Scaling-Gruppe manuell wieder auf die entsprechende Version. Durch diese Aktion wird die Knotengruppe wieder in einen fehlerfreien und aktiven Zustand versetzt, und Sie können den Aktualisierungsvorgang erneut einleiten.

Das Update ist fehlgeschlagen, weil neue Knoten der Knotengruppe nicht beitreten

Dieses Problem tritt auf, wenn die neuen Knoten der Knotengruppe dem Cluster nicht beitreten können. Infolgedessen wird die Knotengruppe auf ihre vorherige Version zurückgesetzt. In diesem Fall wird möglicherweise der folgende Fehler angezeigt:

„NodeCreationFailure
Couldn't proceed with upgrade process as new nodes are not joining node group ng-backend“

Es gibt mehrere Gründe, warum aktualisierte Knoten dem Cluster nicht beitreten können:

Sie haben eine Sicherheitsgruppenregel geändert, die von der vorhandenen Knotengruppe verwendet wird

Stellen Sie sicher, dass die ausgehenden Regeln der Sicherheitsgruppe des Knotens Port 443 für die Sicherheitsgruppe des Clusters zulassen.

Die Sicherheitsgruppe des Clusters lässt keinen Datenverkehr von der Knotensicherheitsgruppe zu

Stellen Sie sicher, dass die Regeln für eingehende Nachrichten des Clusters Port 443 aus der Sicherheitsgruppe des Knotens zulassen. Weitere Informationen finden Sie unter Anforderungen und Überlegungen zur Amazon-EKS-Sicherheitsgruppe.

Sie haben Ihre Knotengruppe mit einer benutzerdefinierten Startvorlage erstellt

Wenn Sie eine benutzerdefinierte Startvorlage aktualisieren, muss die neue Version der Vorlage die richtigen Benutzerdaten enthalten. Wenn Sie ein benutzerdefiniertes AMI verwenden, stellen Sie außerdem sicher, dass Sie das AMI korrekt konfiguriert haben, um dem Cluster beizutreten.

Um Probleme mit der Startvorlage zu beheben, erstellen Sie eine neue Knotengruppe mit derselben Startvorlage. Stellen Sie sicher, dass die Vorlage die neueste Version des benutzerdefinierten AMI verwendet. Prüfen Sie dann, ob der Knoten dem Cluster erfolgreich beitritt. Wenn der Knoten dem Cluster nicht beitritt, stellen Sie mit SSH eine Verbindung zur Knoten-Instance her und überprüfen Sie die Kubelet-Protokolle.

Es fehlen IAM-Berechtigungen

Prüfen Sie, ob die AWS Identity and Access Management (IAM)-Rolle für die Knotengruppe über die erforderlichen Berechtigungen verfügt.

ACL verweigern Datenverkehr

Die Zugriffskontrollliste (ACL) des Subnetzes eines Knotens kann ausgehenden Verkehr für Port 443 oder eingehenden Verkehr für einen kurzlebigen Port verweigern. Stellen Sie sicher, dass Sie diese Regeln für das Subnetz des Knotens zulassen.

In ähnlicher Weise kann die ACL des Subnetzes eines Clusters eingehenden Datenverkehr für Port 443 verweigern. Stellen Sie sicher, dass Sie diesen Datenverkehr für die Subnetze Ihres Clusters zulassen.

Neue Knoten können kein Plugin hinzufügen

Ein Amazon Virtual Private Cloud (Amazon VPC) CNI Plugin oder ein Kube-Proxy-Add-on wird möglicherweise nicht auf neuen Knoten angezeigt. Weitere Informationen finden Sie unter Wie löse ich Probleme mit Kubelet- oder CNI-Plug-ins für Amazon EKS?

Ein Subnetz hat Verbindungsprobleme

Das Subnetz, in dem Amazon EKS Knoten erstellt, verfügt möglicherweise nicht über Konnektivität zu den erforderlichen Endpunkten. Zu diesen Endpunkten können Amazon Elastic Container Registry (Amazon ECR), Amazon Simple Storage Service (Amazon S3) oder Amazon EC2 gehören. Die Konnektivität kann entweder über das Internet oder VPC-Endpunkte fehlschlagen. Überprüfen Sie bei VPC-Endpunkten die Sicherheitsgruppen der Knoten und Endpunkte, um sicherzustellen, dass sie den erforderlichen Datenverkehr zulassen. Wenn Sie ein NAT-Gateway oder ein Internet-Gateway verwenden, stellen Sie sicher, dass die Routing-Regel in der Routing-Tabelle Ihres Subnetzes korrekt ist. Stellen Sie außerdem sicher, dass das entsprechende NAT-Gateway oder Internet-Gateway vorhanden ist.