Unterstützung für die Verbesserung dieser Seite beitragen

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.

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

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.

Rollback EKS-Automodus-Cluster

Wenn Sie ein Versions-Rollback auf einem Cluster initiieren, auf dem der EKS-Auto-Modus ausgeführt wird, verwaltet Amazon EKS automatisch das Rollback der Auto-Modus-Worker-Knoten, bevor die Steuerungsebene zurückgesetzt wird. Auf dieser Seite wird erklärt, wie das Node-Rollback im automatischen Modus funktioniert, wie es beschleunigt wird und wie es bei Bedarf abgebrochen werden kann.

Allgemeine Informationen zum Versions-Rollback, einschließlich der Voraussetzungen, zur Überprüfung von Erkenntnissen und zum gesamten Rollback-Prozess, finden Sie unter. Rollback des Clusters auf vorherige Kubernetes-Version

So funktioniert das Rollback im automatischen Modus

Der automatische Modus von EKS verwendet ein Karpenter-based System zur Verwaltung der Worker-Node-Infrastruktur, einschließlich Upgrades und Rollbacks der Kubernetes-Versionen. Wenn Sie UpdateClusterVersion mit der vorherigen Version (N-1) auf einem Cluster mit aktiviertem Auto-Modus aufrufen, führt EKS die folgende Sequenz aus:

Die Steuerungsebene bleibt auf der aktuellen (neueren) Version und bedient den Datenverkehr weiterhin normal, während die Knoten zurückgesetzt werden. Die Kubernetes-Richtlinie „Version Skew“ ermöglicht es Knoten, bis zu drei Nebenversionen auszuführen, die älter sind als der Kube-Apiserver, sodass dieser Zwischenstatus gültig ist.

Clusterstatus während des Rollbacks

Der Clusterstatus bleibt ACTIVE während der Knoten-Rollback-Phase bestehen. Verwenden Sie ListUpdates oderDescribeUpdate, um festzustellen, ob ein Rollback im Gange ist. Navigieren Sie in der Amazon EKS-Konsole zu Ihrem Cluster und öffnen Sie den Tab Update-Verlauf, um den Status der mit dem Rollback verknüpften Update-ID einzusehen.

Um den Fortschritt einzelner Knoten während des Rollbacks zu verfolgen, überprüfen Sie die Kubernetes-Version Ihrer Auto Mode-Knoten:

kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide

Kontrollen bei Störungen

Beim Rollback im automatischen Modus werden alle vorhandenen Unterbrechungskontrollen berücksichtigt. Diese Kontrollen bestimmen, wie schnell Knoten ausgetauscht werden können, und können die Rollback-Dauer erheblich beeinflussen.

NodePool Budgets für Störungen

NodePool Budgets für Störungen steuern, wie viele Knoten gleichzeitig unterbrochen werden können. Beim Rollback berücksichtigt Karpenter diese Budgets, wenn Knoten auf die vorherige Version umgestellt werden.

Beispiel NodePool mit einem Budget für Unterbrechungen, das den gleichzeitigen Austausch von 10% der Knoten ermöglicht:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted

Weitere Informationen zur Konfiguration von NodePool Unterbrechungsbudgets finden Sie unter Erstellen eines Knotenpools für EKS Auto Mode und Karpenter Disruption Budgets.

PodDisruptionBudgets

Kubernetes wird beim Austausch von PodDisruptionBudgets Knoten berücksichtigt. Wenn eine PDB die Entfernung von Pods verhindert, verzögert sich die Unterbrechung des Knotens bis zum. TerminationGracePeriod

Weitere Informationen finden Sie unter Schützen kritischer Workloads mit einer PDB und in der Kubernetes-PDB-Dokumentation.

Do-not-disrupt Anmerkungen

Die karpenter.sh/do-not-disrupt Anmerkung kann auf Knoten oder Pods gesetzt werden:

Auf Knoten: Blockiert Knotenunterbrechungen auf unbestimmte Zeit. Dies löst eine ERROR-Einsicht aus und muss entfernt werden, bevor das Rollback auf diesem Knoten fortgesetzt werden kann.

Auf Pods: Verzögert die Knotenunterbrechung bis zum TerminationGracePeriod. Dadurch wird eine WARNMELDUNG ausgelöst, der Rollback wird jedoch nicht dauerhaft blockiert.

Weitere Informationen zum Verhalten von Karpenter-Störungen finden Sie in der Dokumentation zu Karpenter-Störungen.

Beschleunigung des Rollbacks

Wenn das Rollback länger als erwartet dauert, können Sie die Unterbrechungskontrollen während des Rollbacks anpassen.

Erhöhen Sie das Budget NodePool für Störungen

Bearbeiten Sie die NodePool Ressource, um mehr gleichzeitiges Austauschen von Knoten zu ermöglichen:

kubectl edit nodepool default

Ändern Sie das Budget auf einen höheren Wert:

spec:
  disruption:
    budgets:
      - nodes: "50%"
        reasons:
          - Drifted

Entfernen Sie Anmerkungen vom Typ „Nicht stören“ von den Knoten

Listet die Knoten mit der Anmerkung auf und entfernt sie:

# List nodes with the annotation
kubectl get nodes -o json | jq '.items[] | select(.metadata.annotations["karpenter.sh/do-not-disrupt"] == "true") | .metadata.name'

# Remove from a specific node
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt-

Passen Sie an PodDisruptionBudgets

Wenn PDBs das Entfernen von Pods verlangsamen, passen Sie sie vorübergehend an:

kubectl edit pdb <pdb-name> -n <namespace>

Weitere Informationen zur Verwaltung von Unterbrechungskontrollen finden Sie unter Verhinderung von Pod- und Knotenunterbrechungen im Amazon EKS Auto Mode.

Ein Rollback abbrechen

Ein Rollback ist nur dann stornierbar, wenn Knoten ein Rollback durchführen. Sie können CancelUpdate während dieser Phase verwenden, um den Vorgang zu beenden.

aws eks cancel-update \
  --name my-cluster \
  --update-id <update-id> \
  --region us-west-2

Verhalten abbrechen

Nach der Kündigung

Nach erfolgreicher Kündigung wechseln die Knoten wie gewohnt zur aktuellen Cluster-Version. Das Update wechselt von Cancelling zuCancelled.

Nach der Kündigung können Sie sofort:

Wenn eine Stornierung nicht möglich ist

Cancel schlägt fehl, wenn das Node-Rollback bereits abgeschlossen ist und das Rollback der Steuerungsebene gestartet wurde, oder wenn das Update bereits mit dem Status Successful oder Failed abgeschlossen wurde.

Timeout für das Rollback

Das Rollback von Knoten im automatischen Modus hat ein konfigurierbares Timeout, das durch den Parameter in gesteuert wird. timeoutMinutes rollbackConfig Das Standard-Timeout beträgt 720 Minuten (12 Stunden). Sie können einen Wert zwischen 120 Minuten (2 Stunden) und 10080 Minuten (7 Tage) festlegen. Bei dem Timeout handelt es sich um eine Eigenschaft, die an das Minimum gebunden ist. Das heißt, es tritt frühestens zu dem von Ihnen angegebenen Zeitpunkt auf, kann aber auch kurz danach eintreten.

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --rollback-config timeoutMinutes=1440 \
  --region us-west-2

Wenn nicht alle Knoten das Rollback innerhalb des angegebenen Timeouts abgeschlossen haben:

Nach einem Timeout können Sie das Rollback erneut versuchen, wenn Sie sich noch innerhalb des 7-tägigen Rollback-Berechtigungsfensters seit dem ursprünglichen Upgrade befinden. In der Praxis gilt: Wenn das Node-Rollback am 7. Tag abläuft, ist das Rollback-Qualifikationsfenster wahrscheinlich ebenfalls abgelaufen, da beide 7 Tage betragen.

Um Zeitüberschreitungen zu vermeiden, sollten Sie die Erkenntnisse zur Rollback-Bereitschaft überprüfen, bevor Sie mit dem Rollback beginnen. Diese Erkenntnisse warnen vor Unterbrechungen, Budgets oder Anmerkungen, die den Node-Rollback-Prozess verlangsamen könnten.

Das Flag --force und der Automatikmodus

Das --force Flag on umgeht UpdateClusterVersion nur Cluster-Insight-Checks. Es hat keine Auswirkung auf das Verhalten bei Knotenunterbrechungen im automatischen Modus.

Auch mit--force:

Die einzige Möglichkeit, das Node-Rollback zu beschleunigen, besteht darin, die Unterbrechungskontrollen selbst anzupassen. Details dazu finden Sie unter Beschleunigung des Rollbacks.

Konflikte beim IaC-Timeout

Infrastructure-as-Code Für Tools gelten Timeout-Beschränkungen, die zu Konflikten mit der Dauer des Rollbacks im automatischen Modus führen können. CloudFormation erlaubt bis zu 36 Stunden pro Ressource. Wenn bei dem Vorgang ein Timeout auftritt, wird er als No-Op CloudFormation behandelt, was dazu führen kann, dass der Cluster in einem veränderten Zustand bleibt, in dem die Vorlage nicht die tatsächliche Clusterversion wiedergibt. Das Zurücksetzen der Version muss explizit initiiert werden. Terraform Enterprise/Cloud hat ein Timeout von ungefähr 24 Stunden, obwohl die clientseitigen Timeouts je nach Ablauf der Anmeldeinformationen und anderen Faktoren variieren können.

Um die Rollback-Dauer an Ihr IaC-Tool anzupassen, verwenden Sie den Parameter in, um ein geeignetes Timeout festzulegen. timeoutMinutes rollbackConfig Wenn bei Ihrem IaC-Tool eine Zeitüberschreitung eintritt, verwenden Sie die CancelUpdate API direkt, um die Kontrolle zurückzugewinnen. Wenn Sie über restriktive Budgets für Störungen verfügen, sollten Sie erwägen, den Rollback direkt über CLI oder API statt über IaC einzuleiten.

Systemaktualisierungen während des Knoten-Rollbacks

Während die Knoten im automatischen Modus zurückgesetzt werden, sorgt EKS weiterhin dafür, dass die Steuerungsebene sicher und verfügbar ist.

Customer-triggered Updates (wie UpdateClusterVersion oder UpdateClusterConfig) werden blockiert, während das Node-Rollback läuft. Wenn Sie ein Update mit hoher Priorität durchführen müssen, brechen Sie das Rollback zunächst mitCancelUpdate, führen Sie dann Ihr Update durch und starten Sie das Rollback erneut, sofern das Zulassungsfenster noch nicht abgelaufen ist.

Zugehörige Ressourcen