**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](rollback-cluster.md) ## 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: 1. Überprüft die Voraussetzungen und aktualisiert die Erkenntnisse zur Rollback-Bereitschaft. 1. Führt Knoten mithilfe eines Karpenter-based Systems zur gewünschten Rollback-Version weiter, wobei die konfigurierten Unterbrechungskontrollen eingehalten werden. 1. Nachdem sich alle Knoten innerhalb der Kubernetes-Versionsverzerrungsrichtlinie für die gewünschte Rollback-Version befinden, überprüft EKS die Erkenntnisse erneut und fährt mit dem Rollback der Kontrollebene fort. 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. **Anmerkung** Sie lösen das Rollback mit derselben API und demselben Prozess aus, wie unter beschrieben. [Rollback des Clusters auf vorherige Kubernetes-Version](rollback-cluster.md) Es gibt keine separate API für das Rollback von Knoten im automatischen Modus. **Anmerkung** Die Node-Rollback-Phase (Schritt 2) kann je nach Ihren Unterbrechungsmaßnahmen zwischen Minuten und 7 Tagen dauern. Wenn das Node-Rollback nicht innerhalb des konfigurierten Timeouts abgeschlossen wird, wird das Update als fehlgeschlagen markiert. **Anmerkung** Während eines Rollbacks werden andere vom Kunden ausgelöste Updates der Steuerungsebene blockiert. Um ein anderes Update durchzuführen, brechen Sie das Rollback zunächst mithilfe der API ab. CancelUpdate ## Clusterstatus während des Rollbacks | Phase | Clusterstatus | Was passiert | | --- | --- | --- | | Das Rollback des Knotens ist im Gange | **ACTIVE** | Karpenter ersetzt Knoten durch die vorherige Version AMI. Die Kontrollebene ist fehlerfrei und bedient den Datenverkehr in der aktuellen Version. | | Rollback der Steuerungsebene | **WIRD AKTUALISIERT** | Die Komponenten des API-Servers und der Steuerungsebene werden auf die vorherige Version zurückgesetzt. | | Das Rollback ist abgeschlossen | **ACTIVE** | Der Cluster ist vollständig auf der Vorgängerversion installiert. | Der Clusterstatus bleibt `ACTIVE` während der Knoten-Rollback-Phase bestehen. Verwenden Sie `ListUpdates` oder`DescribeUpdate`, 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= -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. + Ein Budget von vier Drift blockiert einen Rollback `nodes: 0` auf unbestimmte Zeit. Dadurch wird ein ERROR Insight ausgelöst. + Ein restriktives Budget (z. B.`nodes: 1`) verlangsamt den Rollback, ermöglicht aber weitere Fortschritte. 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](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html) und [Karpenter Disruption](https://karpenter.sh/docs/concepts/disruption/#disruption-budgets) 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 + PDBs mit verzögerter Knotenunterbrechung`maxUnavailable: 0`. Dadurch wird eine WARNMELDUNG ausgelöst. + PDBs blockieren den Rollback nicht dauerhaft, können ihn aber erheblich verlangsamen. [Weitere Informationen finden Sie unter [Schützen kritischer Workloads mit einer PDB](https://docs.aws.amazon.com/prescriptive-guidance/latest/ha-resiliency-amazon-eks-apps/pdb.html) und in der Kubernetes-PDB-Dokumentation.](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) ### 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](https://karpenter.sh/docs/concepts/disruption/). ## 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 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 -n ``` **Warnung** Die Anpassung der Unterbrechungskontrollen wirkt sich auf die Verfügbarkeitsgarantien Ihrer Anwendungen aus. Stellen Sie sicher, dass Sie die Auswirkungen verstehen, bevor Sie Änderungen in der Produktion vornehmen. Weitere Informationen zur Verwaltung von Unterbrechungskontrollen finden Sie unter [Verhinderung von Pod- und Knotenunterbrechungen im Amazon EKS Auto Mode](https://repost.aws/articles/ARONpaMO8rQAqXM_BLmhyqWA/preventing-pod-and-node-disruption-in-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 \ --region us-west-2 ``` ### Verhalten abbrechen | Aspekt | Behavior | | --- | --- | | Wann stornierbar | Nur solange Knoten im automatischen Modus zurückgesetzt werden (bevor das Rollback der Steuerungsebene beginnt) | | Semantik | Best-effort Stopp. Stoppt den Node-Rollback-Vorgang. | | Mid-disruption Knoten | Befindet sich ein Knoten zum Zeitpunkt des Abbruchs mitten in einer Unterbrechung, schließt er seinen aktuellen Betrieb ab. | | Post-cancellation Status | Übergänge von `Cancelling` zu aktualisieren`Cancelled`. | | Cluster-Status | Bleibt `ACTIVE` durchgehend bestehen. | ### Nach der Kündigung Nach erfolgreicher Kündigung wechseln die Knoten wie gewohnt zur aktuellen Cluster-Version. Das Update wechselt von `Cancelling` zu`Cancelled`. Nach der Kündigung können Sie sofort: + Versuchen Sie erneut, das Rollback durchzuführen (sofern Sie sich noch innerhalb des 7-tägigen Teilnahmezeitfensters befinden). + Führen Sie ein anderes Cluster-Update durch. + Belassen Sie den Cluster unverändert in der aktuellen Version. ### 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. **Anmerkung** CloudFormation und Terraform unterstützen die API nicht direkt. CancelUpdate Wenn Sie ein über IaC initiiertes Rollback abbrechen müssen, müssen Sie die API direkt aufrufen. ## 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: 1. Beim Rollback wird das Timeout überschritten. 1. Die Knoten beginnen, zur aktuellen Cluster-Version zurückzukehren. 1. Die Steuerungsebene verbleibt in der aktuellen Version (sie wurde nie zurückgesetzt). 1. Der Aktualisierungsstatus wechselt zu`Failed`. 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`: + NodePool Budgets für Störungen werden weiterhin eingehalten. + PodDisruptionBudgets werden immer noch berücksichtigt. + Do-not-disrupt Anmerkungen werden weiterhin respektiert. + Das 7-tägige Node-Rollback-Timeout gilt weiterhin. Die einzige Möglichkeit, das Node-Rollback zu beschleunigen, besteht darin, die Unterbrechungskontrollen selbst anzupassen. Details dazu finden Sie unter [Beschleunigung des Rollbacks](#automode-speed-up-rollback). ## 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 mit`CancelUpdate`, führen Sie dann Ihr Update durch und starten Sie das Rollback erneut, sofern das Zulassungsfenster noch nicht abgelaufen ist. ## Zugehörige Ressourcen + [Rollback des Clusters auf vorherige Kubernetes-Version](rollback-cluster.md) + [Überblick über den EKS-Automodus](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) + [Erstellen eines Knotenpools für EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html) + [Aktualisieren Sie die Kubernetes-Version eines EKS-Auto-Mode-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/auto-upgrade.html) + [Verhinderung von Pod- und Knotenunterbrechungen im Amazon EKS Auto Mode](https://repost.aws/articles/ARONpaMO8rQAqXM_BLmhyqWA/preventing-pod-and-node-disruption-in-amazon-eks-auto-mode) + [Problembehebung im automatischen EKS-Modus](https://docs.aws.amazon.com/eks/latest/userguide/auto-troubleshoot.html) + [Dokumentation zur Störung in Karpenter](https://karpenter.sh/docs/concepts/disruption/) + [Kubernetes PodDisruptionBudgets](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)