Verhalten der Aktualisierung verwalteter Knoten

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. Es 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 den 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 20 (oder etwas höher als 10) maxUnavailable ist, würde der Prozess 20 neue Knoten starten.

2. Nach dem Skalieren der Auto-Scaling-Gruppe prüft es, 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 zu vermeiden, dass neue Pods geplant werden. 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 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.

Aktualisierungs-Phase

Die Aktualisierungs-Phase umfasst folgende Schritte:

1. 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.

2. Es entleert die Pods vom Knoten. 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. Für dieses Szenario können Sie das Force-Flag mit der update-nodegroup-version-Anforderung anwenden, um die Pods zu löschen.

3. Es sperrt den Knoten ab, nachdem jeder Pod entfernt wurde, und wartet 60 Sekunden. Dies geschieht, damit der Service-Controller keine neuen Anforderungen an diesen Knoten sendet und diesen Knoten aus der Liste der aktiven Knoten entfernt.

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

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.

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 toleriert 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.