Verstehen Sie jede Phase der Knotenaktualisierungen - Amazon EKS
EinrichtungsphaseAufskalierungsphaseAktualisierungs-PhaseAbskalierungsphase

Helfen Sie mit, diese Seite zu verbessern

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verstehen Sie jede Phase der Knotenaktualisierungen

Die Upgrade-Strategie von Amazon EKS Managed Worker Node besteht aus vier verschiedenen Phasen, die in den folgenden Abschnitten beschrieben werden.

Einrichtungsphase

Die Einrichtungsphase umfasst folgende Schritte:

  1. Es erstellt eine neue EC2 Amazon-Startvorlagenversion für die Auto Scaling Scaling-Gruppe, die Ihrer Knotengruppe zugeordnet ist. Die neue Version der Startvorlage verwendet die Zielversion AMI oder eine benutzerdefinierte Version der Startvorlage für das Update.

  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 finden Sie unter der updateConfigEigenschaft in der EKSAPIAmazon-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 EC2 das Availability Zone Rebalancing von Amazon. Weitere Informationen finden Sie unter Availability Zone Rebalancing im Amazon EC2 Auto Scaling 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 Scaling-Gruppe um den jeweils größeren der folgenden Werte:

    • 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 mit Labels versehen sein, die Amazon EKS verwendet hat.

      Dies sind die Labels, die Amazon auf die Worker-Knoten in einer regulären Knotengruppe EKS angebracht hat:

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

      • eks.amazonaws.com/nodegroup=$nodeGroupName

    Dies sind die Labels, die Amazon auf die Worker-Knoten in einer benutzerdefinierten Startvorlage oder AMI Knotengruppe EKS angebracht hat:

    +

    • 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 Knoten zu vermeiden Pods. Es kennzeichnet Knoten auch mitnode.kubernetes.io/exclude-from-external-load-balancers=true, um die Knoten vor dem Beenden der Knoten aus den Load Balancern zu entfernen.

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

Unzureichende 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, bei der Erstellung einer verwalteten Knotengruppe mehrere Instanztypen zu konfigurieren.

EC2Instanzlimits in Ihrem Konto

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

Benutzerdefinierte Benutzerdaten

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

Alle Änderungen, die dazu führen, dass ein Knoten fehlerhaft oder nicht betriebsbereit 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 den Pods vom Knoten. Wenn das Symbol Pods Wenn Sie den Knoten nicht innerhalb von 15 Minuten verlassen und es kein Force-Flag gibt, schlägt die Upgrade-Phase mit einem PodEvictionFailure Fehler fehl. In diesem Szenario können Sie das Force-Flag zusammen mit der update-nodegroup-version Aufforderung zum Löschen des Pods.

  3. Es sperrt den Knoten nach jedem Pod wird vertrieben und wartet 60 Sekunden. Dies geschieht, damit der Service Controller keine neuen Anfragen an diesen Knoten sendet und diesen Knoten aus seiner 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:

Aggressiv PDB

Aggressiv PDB ist definiert auf Pod oder es PDBs zeigen mehrere auf dasselbe Pod.

Einsatz, der alle Makel toleriert

Jeweils einmal Pod wurde entfernt, wird erwartet, dass der Knoten leer ist, da der Knoten in den vorherigen Schritten verunreinigt wurde. Wenn das Deployment jedoch jeden Makel toleriert, dann ist es wahrscheinlicher, dass der Knoten nicht leer ist, was zu Pod Räumung ist fehlgeschlagen.

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.

📝 Bearbeiten Sie diese Seite auf GitHub