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.
# Bewährte Methoden für das Rollback der Cluster-Version
Mit dem Versions-Rollback von Amazon Elastic Kubernetes Service (Amazon EKS) können Sie die Kubernetes-Steuerebene Ihres Clusters innerhalb von 7 Tagen nach einem direkten Upgrade auf die vorherige Nebenversion zurücksetzen. Auf dieser Seite werden bewährte Methoden für die Planung, Ausführung und Operationalisierung eines Rollbacks als Teil Ihres Upgrade-Workflows beschrieben.
Einzelheiten zu den Voraussetzungen, schrittweise Anleitungen und eine API-Referenz finden Sie unter [Rollback des Clusters zur](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) vorherigen Kubernetes-Version.
## Erfahren Sie, wie das Modell der gemeinsamen Verantwortung für Rollback gilt
Wenn Sie ein Rollback der Cluster-Version einleiten, verwaltet Amazon EKS das Rollback der Steuerungsebene. Sie sind für die Datenebene, die Add-Ons und die Anwendungskompatibilität verantwortlich. Im Folgenden werden die Zuständigkeiten beschrieben:
+ **Amazon EKS verwaltet:** Rollback des Kubernetes-API-Servers und der Komponenten der Steuerungsebene. Für Auto-Mode-Cluster verwaltet Amazon EKS auch das Rollback von Worker-Knoten.
+ **Sie sind verantwortlich für:** Das Rollback von verwalteten Knotengruppen, selbstverwalteten Knoten und Hybridknoten. Sie müssen außerdem die Kompatibilität der Add-Ons überprüfen und sicherstellen, dass Ihre Anwendungen, benutzerdefinierten Controller und Tools von Drittanbietern ordnungsgemäß mit der vorherigen Version funktionieren.
Weitere Informationen zum Modell der gemeinsamen Verantwortung für Upgrades finden Sie unter Erläuterung [der Anwendung des Modells der gemeinsamen Verantwortung für Cluster-Upgrades](cluster-upgrades.md).
## Bei der Planung von Upgrades sollten Rollbacks berücksichtigt werden
Das Versions-Rollback funktioniert am besten, wenn Ihr Upgrade-Workflow so konzipiert ist, dass das Rollback-Fenster geöffnet bleibt.
+ **Separate Upgrades auf Steuerungsebene und Datenebene (Cluster ohne automatischen Modus).** Bei Clustern, die verwaltete Knotengruppen oder selbstverwaltete Knoten verwenden, sollten Sie erwägen, zuerst die Steuerungsebene zu aktualisieren und vor dem Upgrade der Worker-Knoten eine Back-Phase einzuplanen. Solange die Knoten eingeschaltet bleiben N-1, behält die Kubelet-Version Skew Insight den Status PASSING. Dadurch bleibt der Rollback-Pfad frei, ohne dass zuerst die Knoten zurückgesetzt werden müssen.
+ **Aktualisieren Sie Add-Ons auf kompatible Versionen.** Stellen Sie vor dem Upgrade der Steuerungsebene sicher, dass alle Add-Ons (verwaltet und selbstverwaltet) sowohl mit der aktuellen als auch mit der Zielversion von Kubernetes kompatibel sind. Dadurch bleibt der Einblick in die Add-On-Kompatibilität sowohl für das Upgrade als auch für das Rollback klar.
+ Verwenden Sie von Amazon EKS verwaltete Add-Ons, um von Erkenntnissen zur Rollback-Bereitschaft zu profitieren, die automatisch die Kompatibilität der Add-On-Versionen überprüfen.
+ Vermeiden Sie es, ein verwaltetes Add-on selbst zu verwalten (z. B. das Überschreiben der Version außerhalb des Lebenszyklus des EKS-Add-ons). Während des Rollbacks behandelt Insights die verwaltete Add-On-Konfiguration als Informationsquelle und erkennt keine von Ihnen eingeführte Versionsabweichung.
+ **Vermeiden Sie es, während der Backphase versionsspezifische APIs zu verwenden.** Wenn Sie Ressourcen erstellen, die APIs oder Funktionen verwenden, die während des 7-Tage-Fensters nur in der neuen Version verfügbar sind, müssen Sie diese entfernen, bevor Sie ein Rollback durchführen. Beschränken Sie die Einführung von APIs, die nur für neue Versionen verfügbar sind, bis Sie sicher sind, dass das Upgrade stabil ist.
+ **Führen Sie ein Upgrade früher durch, nicht später.** Da Rollback verfügbar ist, können Sie getrost kurz nach der Veröffentlichung einer neuen Version ein Upgrade durchführen, anstatt bis zu verlängerten Supportfristen zu warten. Durch ein früheres Upgrade haben Sie mehr Zeit für die Validierung und reduzieren die Kosten für erweiterten Support.
+ **Beachten Sie die Einschränkungen beim Rollback des erweiterten Supports.** Wenn Ihr Cluster am Ende des erweiterten Supports automatisch aktualisiert wurde, können Sie nicht zur vorherigen Version zurückkehren. Wenn Sie am Ende des Standard-Supports ein automatisches Upgrade erhalten haben, können Sie ein Rollback durchführen. Sie müssen jedoch zuerst die Upgrade-Richtlinie auf `EXTENDED` ändern.
Allgemeine Hinweise zur Upgrade-Planung, einschließlich Richtlinien für veraltete Versionen, Versionshinweise und Add-On-Kompatibilität, finden Sie unter [Bewährte Methoden für](cluster-upgrades.md) Cluster-Upgrades.
## Prüfen Sie vor dem Rollback die Erkenntnisse zur Rollback-Bereitschaft
Amazon EKS bietet unter der `ROLLBACK_READINESS` Kategorie Cluster-Einblicke Einblicke in die Rollback-Bereitschaft zu einem bestimmten Zeitpunkt. Diese Prüfungen sind Ihr primäres Instrument zur Bewertung der Rollback-Sicherheit.
+ **Überprüfen Sie die Erkenntnisse unmittelbar nach dem Upgrade.** Warten Sie nicht, bis etwas schief geht. Überprüfen Sie nach dem Upgrade die Informationen zur Rollback-Bereitschaft, damit Sie sich über Ihren aktuellen Rollback-Status informieren können.
+ **Gehen Sie proaktiv auf ERROR-Erkenntnisse ein.** Wenn Insights kurz nach einem Upgrade den Status FEHLER anzeigen, beheben Sie das Problem frühzeitig, solange das 7-Tage-Fenster noch geöffnet ist. Je länger Sie warten, desto wahrscheinlicher ist es, dass Ihr Clusterstatus divergiert und neue Blocker auftreten.
+ **Verstehen Sie, was Erkenntnisse bedeuten und welche nicht.** Insights überprüfen die von Amazon EKS verwalteten Add-On-Versionen, die API-Nutzung, den Versionsversatz und den Zustand des Clusters. Selbstverwaltete Add-Ons, benutzerdefinierte Controller oder die Kompatibilität auf Anwendungsebene werden nicht geprüft. Führen Sie Ihre eigene Kompatibilitätsprüfung für selbstverwaltete Add-Ons durch (z. B. Cluster-Autoscaler, Ingress-Controller, benutzerdefinierte Operatoren, Monitoring-Agents).
Eine vollständige Liste der Insight-Checks und des Statusverhaltens finden Sie unter [Rollback](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) des Clusters auf vorherige Kubernetes-Version.
## Bereiten Sie Knoten, die sich nicht im automatischen Modus befinden, auf das Rollback vor
Bei Clustern, die Managed Node Groups, selbstverwaltete Knoten oder AWS Fargate verwenden, sind Sie dafür verantwortlich, dass die Worker-Knoten mit der Ziel-Rollback-Version kompatibel sind.
+ **Verwaltete Knotengruppen.** Sie müssen Ihre verwalteten Knotengruppen auf die vorherige Version zurücksetzen, bevor Sie die Steuerungsebene zurücksetzen können. Verwenden Sie den `UpdateNodegroupVersion` Vorgang mit der vorherigen Kubernetes-Version. Das Rollback respektiert Ihre konfigurierten Update-Einstellungen (`maxUnavailable`, Update-Strategie).
+ **Self-managed und Hybridknoten.** Aktualisieren Sie Ihre Knoten-AMIs oder -Konfigurationen, sodass sie die vorherige Kubernetes-Version verwenden, bevor Sie die Steuerungsebene zurücksetzen.
+ **Fargate.** Ein Versions-Rollback wird für Fargate-Worker-Knoten nicht unterstützt. Löschen Sie Fargate-Pods, auf denen dieselbe Version wie die Steuerungsebene ausgeführt wird, bevor Sie den Rollback einleiten, oder verwenden Sie diese Option, `--force` um den Einblick in die Versionsverzerrung zu umgehen (was zu unerwartetem Verhalten führen kann, bis die Pods ersetzt werden).
Hinweise zur Konfiguration PodDisruptionBudget und Topologieverteilung zur Sicherstellung der Workload-Verfügbarkeit bei Knotenaktualisierungen finden Sie unter [Bewährte](cluster-upgrades.md) Methoden für Cluster-Upgrades.
## Verwaltung der Unterbrechungskontrollen im automatischen Modus von Amazon EKS für Rollbacks
Bei Clustern, auf denen Amazon EKS Auto Mode ausgeführt wird, kann die Node-Rollback-Phase der längste Teil des Vorgangs sein. Ihre Störungskontrolle bestimmt direkt, wie schnell das Rollback abgeschlossen wird.
+ **Überprüfen Sie die Budgets für Störungen, bevor Sie ein Rollback einleiten.** Amazon EKS bietet Einblicke in die Rollback-Bereitschaft für NodePool Unterbrechungsbudgets. Budgets, die auf 0 gesetzt sind, lösen eine ERROR-Analyse aus, wodurch ein Rollback auf unbestimmte Zeit blockiert wird. Restriktive Budgets und PodDisruptionBudgets (PDBs) lösen WARNING-Erkenntnisse aus, die den Rollback verlangsamen, aber weitere Fortschritte ermöglichen können. Gehen Sie auf ERROR Insights ein, bevor Sie den Rollback einleiten.
+ **Seien Sie darauf vorbereitet, die Budgets während des Rollbacks anzupassen.** Wenn das Rollback länger als erwartet dauert, können Sie die Budgets und PDBs für NodePool Störungen `kubectl` während des Rollbacks anpassen. Durch eine Erhöhung des Budgets können mehr Knoten gleichzeitig ausgetauscht werden.
+ **Entfernen Sie Anmerkungen, die nicht stören dürfen, von blockierenden Knoten.** Die `karpenter.sh/do-not-disrupt` Anmerkung auf Knoten blockiert das Rollback auf unbestimmte Zeit. Entfernen Sie es aus den Knoten, die ersetzt werden sollten.
+ **Verfolgen Sie den Fortschritt des Knoten-Rollbacks.** Wird verwendet`kubectl get nodes -l karpenter.sh/nodepool= -o wide`, um zu überwachen, welche Knoten durch das AMI der vorherigen Version ersetzt wurden.
+ ** CancelUpdate Bei Bedarf verwenden.** Wenn das Rollback zu lange dauert oder mehr Probleme verursacht, als es löst, brechen Sie das Rollback ab. Nach dem Abbruch konvergieren die Knoten wieder zur aktuellen Version, und Sie können einen anderen Ansatz wählen.
+ **Stellen Sie ein geeignetes Timeout ein.** Verwenden Sie den `timeoutMinutes` Parameter in`rollbackConfig`, um ihn an Ihre betrieblichen Erwartungen anzupassen. Die Standardeinstellung ist 720 Minuten (12 Stunden). Bei Clustern mit konservativen Budgets sollten Sie eine Erhöhung erwägen. Bei IaC-managed Clustern sollten Sie sich an das Timeout Ihres Tools halten.
Vollständige Rollback-Verfahren für den automatischen Modus und den `CancelUpdate` Vorgang finden Sie unter [Rollback von Amazon EKS-Auto-Mode-Clustern](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html).
## Überwachen Sie den Fortschritt des Rollbacks
Verwenden Sie während eines Rollbacks Folgendes, um den Status zu verfolgen und Probleme zu erkennen:
+ **DescribeUpdate Operation.** Wird verwendet`describe-update`, um den aktuellen Status des Rollback-Vorgangs (`InProgress`,, `Successful``Failed`,`Cancelled`) zu überprüfen. Um den Status der Stornierung zu verfolgen, überprüfen Sie das `cancellation` Objekt in der Antwort.
+ **Erkenntnisse aus Clustern.** Amazon EKS überprüft die Erkenntnisse erneut, bevor es mit dem Rollback der Steuerungsebene fortfährt (nachdem das Node-Rollback für den automatischen Modus abgeschlossen ist). Halten Sie Ausschau nach neuen ERROR-Erkenntnissen, die möglicherweise aufgetaucht sind.
+ **Clusterstatus.** Bei Clustern im automatischen Modus bleibt der Clusterstatus `ACTIVE` während des Knoten-Rollbacks bestehen und ändert sich `UPDATING` nur während des Rollbacks auf der Steuerungsebene. Verlassen Sie sich nicht ausschließlich auf den Clusterstatus, um zu wissen, dass ein Rollback im Gange ist — verwenden Sie. `DescribeUpdate`
+ **Knotenversionen.** Überprüfen Sie für den automatischen Modus die Kubernetes-Versionen der Knoten, um den Fortschritt beim Austausch der Knoten zu verfolgen. Überwachen Sie bei verwalteten Knotengruppen den Aktualisierungsstatus der Knotengruppe.
## Behandeln Sie mit Infrastruktur als Code (IaC) verwaltete Cluster
Für IaC-Tools (Infrastructure as Code) gelten Timeout-Beschränkungen, die zu Konflikten mit der Rollback-Dauer im automatischen Modus führen können.
+ **AWS CloudFormation** unterstützt bis zu 36 Stunden pro Ressource. Wenn der Rollback diesen Wert überschreitet, 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 Cluster-Version widerspiegelt. Das Standard-Rollback-Timeout beträgt 720 Minuten (12 Stunden).
+ **Terraform Enterprise/Cloud** hat ungefähr 24-Stunden-Timeouts, obwohl die clientseitigen Timeouts variieren.
+ **Passen `timeoutMinutes` Sie das Timeout Ihres IaC-Tools** an, um zu verhindern, dass das IaC-Tool das Timeout überschreitet, bevor Amazon EKS das Rollback abgeschlossen hat.
+ **Erwägen Sie, das Rollback CLI/API für Cluster im automatischen Modus mit restriktiven Budgets statt über IaC einzuleiten**. `CancelUpdate`Direkt verwenden, wenn bei der IaC-Ebene ein Timeout auftritt.
+ ** CloudFormation AWS-Stack-Rollback löst kein Versions-Rollback aus.** Wenn ein CloudFormation AWS-Stack-Update fehlschlägt, initiiert das automatische Zurücksetzen des Stacks auf eine vorherige Vorlagenversion kein Rollback der Cluster-Version. Sie müssen explizit ein Versions-Rollback initiieren.
## Verwenden Sie Rollback als Sicherheitsnetz, nicht als routinemäßigen Arbeitsablauf
Das Versions-Rollback soll Ihnen helfen, Probleme nach dem Upgrade zu beheben. Es funktioniert am besten, wenn es mit Ihren bestehenden Upgrade-Praktiken kombiniert wird.
+ **Rollback ergänzt das Testen, es ersetzt es nicht.** Nutzen Sie weiterhin Cluster-Einblicke, Tests vor dem Upgrade in Umgebungen außerhalb der Produktionsumgebung und schrittweise Rollouts. Rollback behandelt die Fälle, die durch Tests nicht erfasst catch können — Probleme, die nur in der Produktion auftreten.
+ **Rollback reduziert den Bedarf an manuellen Backup- und Snapshot-Verfahren als primärem Sicherheitsmechanismus.** Da systemeigenes Rollback verfügbar ist, müssen Sie sich bei Upgrades nicht mehr ausschließlich auf etcd-Snapshots oder benutzerdefinierte Rollback-Skripte für die Notfallwiederherstellung verlassen.
+ **Erkenntnisse werden nach bestem Wissen und zum richtigen Zeitpunkt bereitgestellt.** Amazon EKS wertet sie aus, wenn Sie einen Rollback auslösen. Änderungen, die nach dieser Prüfung vorgenommen wurden (z. B. das Erstellen von Ressourcen mit neuen APIs), werden nicht erfasst und können nach Abschluss des Rollbacks zu Problemen führen.
+ **Ein Rollback garantiert nicht die Wiederherstellung von Anwendungen.** Amazon EKS setzt die Kontrollebene sicher zurück, aber es liegt in Ihrer Verantwortung, Ihre Anwendungen, Konfigurationen und Abhängigkeiten anhand der vorherigen Version zu validieren.
## Rollback reduziert den Bedarf an blaugrünen Upgrades
Organizations, die zuvor Blue-Green-Cluster-Upgrades hauptsächlich verwendet haben, um einen „Revert-Path“ zu haben, können nun direkte Upgrades mit Versions-Rollback als Alternative in Betracht ziehen. In-place Upgrades mit Rollback bieten niedrigere Infrastrukturkosten (keine doppelten Cluster), eine konsistente Cluster-Identität (gleicher API-Endpunkt, OpenID Connect (OIDC) -Anbieter und Elastic Network Interfaces (ENIs)) und einfachere Abläufe.
Blue-green werden möglicherweise immer noch bevorzugt, wenn Sie mehrere Versionen gleichzeitig ändern, Workload-Migrationen ausgiebig testen oder den Datenverkehr während der Validierung vollständig isolieren müssen. Weitere Informationen finden Sie unter [Evaluieren von Blue/Green Clustern](cluster-upgrades.md) in den Best Practices für Cluster-Upgrades.
## Zugehörige Ressourcen
+ [Führen Sie ein Rollback des Clusters auf die vorherige Kubernetes-Version durch](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html)
+ [Setzen Sie Amazon EKS-Auto-Mode-Cluster zurück](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html)
+ [Bewährte Methoden für Cluster-Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
+ [Cluster-Erkenntnisse](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html)
+ [Lebenszyklus der Kubernetes-Version auf EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)