Verhalten der Aktualisierung verwalteter Knoten - Amazon EKS

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. 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. 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, können wir bis zu zwei Instances pro Availability Zone in Ihrer verwalteten Knotengruppe starten.

Die Aufskalierungsphase umfasst folgende Schritte:

  1. Erhöht die maximale Größe und die gewünschte Größe der Auto-Scaling-Gruppe um die größere Anzahl:

    • 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. Wendet ein eks.amazonaws.com/nodegroup=unschedulable:NoSchedule-Taint auf jedem Knoten in der Knotengruppe ohne die neuesten Labels an. Dadurch wird verhindert, dass Knoten, die bereits durch eine frühere fehlgeschlagene Aktualisierung aktualisiert wurden, verfälscht 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 möglicherweise nicht über die Kapazität der angeforderten Instance-Typen verfügt. Es wird empfohlen, beim Erstellen einer verwalteten Knotengruppe mehrere Instance-Typen zu konfigurieren.

  • Kunden, die EC2-Instance-Limits in ihrem Konto erreichen – 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 Hinweise zum Umgang mit benutzerdefiniertem LT/AMI finden Sie unter Angeben eines AMI.

  • Alle Änderungen, die einen Knoten fehlerhaft oder nicht bereit machen – 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. Wählt nach dem Zufallsprinzip einen Knoten aus, der für die Knotengruppe nicht verfügbar ist.

  2. 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. 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. Sendet eine Beendigungsanforderung an die Auto-Scaling-Gruppe für den abgesperrten Knoten.

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