Alle Phasen der Knotenaktualisierung verstehen - Amazon EKS
EinrichtungsphaseAufskalierungsphaseAktualisierungs-PhaseAbskalierungsphase

Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Alle Phasen der Knotenaktualisierung verstehen

Die Upgrade-Strategie für verwaltete Amazon-EKS-Worker-Knoten umfasst vier verschiedene Phasen, die in den folgenden Abschnitten beschrieben werden.

Einrichtungsphase

Die Einrichtungsphase umfasst folgende Schritte:

  1. Erstellt eine neue Amazon-EC2-Startvorlage für die Auto-Scaling-Gruppe, die Ihrer Knotengruppe zugeordnet ist. Die neue Version der Startvorlage verwendet das Ziel-AMI oder die vom Kunden bereitgestellte Startvorlagenversion für die Aktualisierung.

  2. Die Auto-Scaling-Gruppe wird so aktualisiert, dass sie die neueste Startvorlage verwendet.

  3. Es bestimmt die maximale Anzahl der parallel zu aktualisierenden Knoten mithilfe der updateConfig-Eigenschaft für die Knotengruppe. Der maximal nicht verfügbare Wert hat ein Kontingent von 100 Knoten. Der Standardwert beträgt einen Knoten. Weitere Informationen dazu finden Sie unter der Eigenschaft updateConfig in der Amazon-EKS-API-Referenz.

Aufskalierungsphase

Beim Upgrade der Knoten in einer verwalteten Knotengruppe werden die aktualisierten Knoten in derselben Availability Zone gestartet wie diejenigen, die aktualisiert werden. Um diese Platzierung zu garantieren, verwenden wir das Availability Zone Rebalancing von Amazon EC2. Weitere Informationen dazu finden Sie unter Availability-Zone-Rebalancing im Amazon-EC2-Auto-Scaling-Benutzerhandbuch. Um diese Anforderung zu erfüllen, ist es möglich, dass wir bis zu zwei Instances pro Availability Zone in Ihrer verwalteten Knotengruppe starten.

Die Aufskalierungsphase umfasst folgende Schritte:

  1. Es erhöht die maximale Größe und die gewünschte Größe der Auto-Scaling-Gruppe um den jeweils größeren Wert:

    • Bis zu doppelt so viele Availability Zones, in denen die Auto-Scaling-Gruppe bereitgestellt wird.

    • Die maximale Nichtverfügbarkeit der Aktualisierung.

      Wenn Ihre Knotengruppe beispielsweise über fünf Availability Zones und maxUnavailable als eine verfügt, kann der Upgrade-Prozess maximal zehn Knoten starten. Wenn jedoch maxUnavailable 20 ist (oder etwas größer als 10, würde der Prozess 20 neue Knoten starten).

  2. Nach dem Skalieren der Auto-Scaling-Gruppe wird überprüft, ob die Knoten, die die neueste Konfiguration verwenden, in der Knotengruppe vorhanden sind. Dieser Schritt ist nur erfolgreich, wenn er diese Kriterien erfüllt:

    • Mindestens ein neuer Knoten wird in jeder Availability Zone gestartet, in der der Knoten existiert.

    • Jeder neue Knoten sollte im Ready-Zustand sein.

    • Neue Knoten sollten Amazon-EKS-Labels angewandt haben.

      Dies sind die von Amazon EKS auf die Worker-Knoten in einer regulären Knotengruppe angewandten Labels:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      Dies sind die von Amazon EKS angewendeten Labels auf den Worker-Knoten in einer benutzerdefinierten Startvorlage oder AMI-Knotengruppe:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. Es markiert Knoten als nicht planbar, um die Planung neuer Pods zu vermeiden. Es kennzeichnet Knoten auch mit node.kubernetes.io/exclude-from-external-load-balancers=true, um die Knoten aus den Load Balancern zu entfernen, bevor die Knoten beendet werden.

Die folgenden sind bekannte Gründe, die zu einem NodeCreationFailure-Fehler in dieser Phase führen:

Nicht genügend Kapazität in der Availability Zone

Es besteht die Möglichkeit, dass die Availability Zone nicht über die Kapazität der angeforderten Instance-Typen verfügt. Es wird empfohlen, beim Erstellen einer verwalteten Knotengruppe mehrere Instance-Typen zu konfigurieren.

EC2-Instance-Limits in Ihrem Konto

Möglicherweise müssen Sie die Anzahl der Amazon-EC2-Instances erhöhen, die Ihr Konto gleichzeitig mit Service Quotas ausführen kann. Weitere Informationen dazu finden Sie unter EC2-Service-Quotas im Amazon-Elastic-Compute-Cloud-Benutzerhandbuch für Linux-Instances.

Anwenderbezogene Benutzerdaten

Anwenderbezogene Benutzerdaten können manchmal den Bootstrap-Prozess stören. Dieses Szenario kann dazu führen, dass kubelet nicht auf dem Knoten startet oder Knoten nicht die erwarteten Amazon-EKS-Labels auf ihnen erhalten. Weitere Informationen finden Sie unter Angeben eines AMI.

Alle Änderungen, die dazu führen, dass ein Knoten fehlerhaft ist oder nicht bereit ist

Knotenfestplattendruck, Speicherdruck und ähnliche Bedingungen können dazu führen, dass ein Knoten nicht in den Ready-Zustand wechselt.

Jeder Knoten wird in der Regel innerhalb von 15 Minuten gebootet

Wenn ein Knoten länger als 15 Minuten zum Bootstrapping und Beitritt zum Cluster benötigt, kommt es zu einer Zeitüberschreitung des Upgrades. Dies ist die Gesamtlaufzeit für das Booten eines neuen Knotens, gemessen von der Zeit, in welcher der neue Knoten benötigt wird, bis zu seinem Beitritt zum Cluster. Bei der Aktualisierung einer verwalteten Knotengruppe beginnt der Zeitzähler zu laufen, sobald die Größe der Auto-Scaling-Gruppe zunimmt.

Aktualisierungs-Phase

Die Aktualisierungsphase verläuft je nach Aktualisierungsstrategie auf zwei unterschiedliche Arten. Es gibt zwei Aktualisierungsstrategien: Standard und Minimal.

Wir empfehlen in den meisten Fällen die Standard-Strategie. Diese erstellt neue Knoten, bevor die alten beendet werden, sodass die verfügbare Kapazität während der Aktualisierungsphase erhalten bleibt. Diese Minimal-Strategie ist in Szenarien sinnvoll, in denen Sie hinsichtlich Ressourcen oder Kosten eingeschränkt sind, beispielsweise bei Hardware-Beschleunigern wie GPUs. Es werden die alten Knoten beendet, bevor neue erstellt werden, sodass die Gesamtkapazität niemals über die von Ihnen konfigurierte Menge hinausgeht.

Die Standard-Aktualisierungsstrategie umfasst folgende Schritte:

  1. Die Anzahl der Knoten (gewünschte Anzahl) in der Auto-Scaling-Gruppe wird erhöht, wodurch die Knotengruppe zusätzliche Knoten erstellt.

  2. Es wählt nach dem Zufallsprinzip einen Knoten aus, der aktualisiert werden muss, bis zum Maximum der für die Knotengruppe nicht verfügbar ist.

  3. Es entleert die Pods vom Knoten. Wenn die Pods den Knoten nicht innerhalb von 15 Minuten verlassen und es kein Erzwingungs-Flag gibt, scheitert die Aktualisierungsphase mit einem PodEvictionFailure-Fehler. Für dieses Szenario können Sie das Erzwingungs-Flag mit der update-nodegroup-version-Anforderung anwenden, um die Pods zu löschen.

  4. Der Knoten wird nach dem Entfernen jedes Pods gesperrt und wartet 60 Sekunden lang. Dies geschieht, damit der Service-Controller keine neuen Anfragen an diesen Knoten sendet und diesen Knoten aus seiner Liste der aktiven Knoten entfernt.

  5. Es sendet eine Beendigungsanforderung an die Auto-Scaling-Gruppe für den abgesperrten Knoten.

  6. Es wiederholt die vorherigen Aktualisierungsschritte, bis keine Knoten in der Knotengruppe mehr vorhanden sind, die mit der früheren Version der Startvorlage bereitgestellt wurden.

Die Minimal-Aktualisierungsstrategie umfasst folgende Schritte:

  1. Zunächst werden alle Knoten der Knotengruppe gesperrt, sodass der Service-Controller keine neuen Anfragen an diese Knoten sendet.

  2. Es wählt nach dem Zufallsprinzip einen Knoten aus, der aktualisiert werden muss, bis zum Maximum der für die Knotengruppe nicht verfügbar ist.

  3. Es entleert die Pods aus den ausgewählten Knoten. Wenn die Pods den Knoten nicht innerhalb von 15 Minuten verlassen und es kein Erzwingungs-Flag gibt, scheitert die Aktualisierungsphase mit einem PodEvictionFailure-Fehler. Für dieses Szenario können Sie das Erzwingungs-Flag mit der update-nodegroup-version-Anforderung anwenden, um die Pods zu löschen.

  4. Nachdem jeder Pod entfernt wurde und 60 Sekunden gewartet hat, sendet er eine Beendigungsanforderung an die Auto-Scaling-Gruppe für die ausgewählten Knoten. Die Auto-Scaling-Gruppe erstellt neue Knoten (entsprechend der Anzahl der ausgewählten Knoten), um die fehlende Kapazität zu ersetzen.

  5. Es wiederholt die vorherigen Aktualisierungsschritte, bis keine Knoten in der Knotengruppe mehr vorhanden sind, die mit der früheren Version der Startvorlage bereitgestellt wurden.

PodEvictionFailure-Fehler während der Aktualisierungsphase

Die folgenden sind bekannte Gründe, die zu einem PodEvictionFailure-Fehler in dieser Phase führen:

Aggressive PDB

Aggressive PDB ist auf dem Pod definiert oder es gibt mehrere PDBs, die auf denselben Pod zeigen.

Bereitstellung unterstützt alle Taints

Sobald jeder Pod entfernt wurde, wird erwartet, dass der Knoten leer ist, da der Knoten in den vorherigen Schritten verunreinigt ist. Wenn die Bereitstellung jedoch jeden Taint toleriert, ist der Knoten eher nicht leer, was zu einem Pod-Bereinigungsfehler führt.

Abskalierungsphase

Die Abskalierungsphase verringert die maximale Größe der Auto-Scaling-Gruppe und die gewünschte Größe um eins, um zu den Werten zurückzukehren, bevor die Aktualisierung gestartet wurde.

Wenn der Upgrade-Workflow feststellt, dass der Cluster-Autoscaler die Knotengruppe während der Herunterskalierungsphase des Workflows skaliert, wird er sofort beendet, ohne die Knotengruppe wieder auf ihre ursprüngliche Größe zu bringen.