Bewährte Methoden für das Rollback der Cluster-Version

Amazon EKS verwaltet: Rollback des Kubernetes-API-Servers und der Komponenten der Steuerungsebene. Bei Clustern im Auto-Modus verwaltet Amazon EKS auch das Rollback von Worker-Knoten.

Sie sind verantwortlich für: Rollback verwalteter Knotengruppen, selbstverwalteter 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 Vorgängerversion funktionieren.

Separate Upgrades der Steuerungsebene und der Datenebene (Cluster, die nicht im automatischen Modus ausgeführt werden). 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. Während die Knoten eingeschaltet bleiben N-1, bleibt die Kubelet-Version von Skew Insight im Status PASSING. Dadurch bleibt der Rollback-Pfad frei, ohne dass zuerst ein Rollback der Knoten durchgeführt werden muss.

Aktualisieren Sie Add-Ons auf kreuzkompatible 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 Überblick über die Kompatibilität der Add-Ons sowohl für das Upgrade als auch für das Rollback klar.

Vermeiden Sie es, während der Backphase versionsspezifische APIs zu verwenden. Wenn Sie während des 7-Tage-Fensters Ressourcen erstellen, die APIs oder Funktionen verwenden, die nur in der neuen Version verfügbar sind, müssen Sie sie vor dem Rollback entfernen. 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 auf verlängerte Support-Fristen zu warten. Ein früheres Upgrade gibt Ihnen mehr Zeit für die Validierung und reduziert die Kosten für den erweiterten Support.

Beachten Sie die Rollback-Einschränkungen für den erweiterten Support. 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 Standardsupports ein automatisches Upgrade erhalten haben, können Sie ein Rollback durchführen, aber Sie müssen zuerst die Upgrade-Richtlinie auf EXTENDED ändern.

Überprüfen Sie die Erkenntnisse sofort nach dem Upgrade. Warte nicht, bis etwas schief geht. Überprüfen Sie nach dem Upgrade die Erkenntnisse zur Rollback-Bereitschaft, damit Sie wissen, wie Ihr aktueller Rollback-Status aussieht.

Gehen Sie proaktiv auf ERROR-Erkenntnisse ein. Wenn Insights kurz nach einem Upgrade den Status FEHLER anzeigen, beheben Sie sie frühzeitig, solange das 7-Tage-Fenster noch geöffnet ist. Je länger Sie warten, desto wahrscheinlicher ist es, dass Ihr Cluster-Status abweicht und neue Blocker auftreten.

Verstehen Sie, was Erkenntnisse abdecken und was nicht. Insights überprüfen die von Amazon EKS verwalteten Zusatzversionen, die API-Nutzung, den Versionsversatz und den Cluster-Zustand. Sie überprüfen keine selbstverwalteten Add-Ons, benutzerdefinierte Controller oder die Kompatibilität auf Anwendungsebene. Sorgen Sie für Ihre eigene Kompatibilitätsüberprüfung für selbstverwaltete Add-Ons (z. B. Cluster-Autoscaler, Ingress-Controller, benutzerdefinierte Operatoren, Monitoring-Agents).

Verwaltete Knotengruppen. Sie müssen Ihre verwalteten Knotengruppen auf die vorherige Version zurücksetzen, bevor Sie ein Rollback der Steuerungsebene durchführen. Verwenden Sie den UpdateNodegroupVersion Vorgang mit der vorherigen Kubernetes-Version. Das Rollback berücksichtigt Ihre konfigurierten Aktualisierungseinstellungen (maxUnavailable, Aktualisierungsstrategie).

Self-managed und Hybridknoten. Aktualisieren Sie Ihre Knoten-AMIs oder -Konfigurationen, um die vorherige Kubernetes-Version zu verwenden, bevor Sie ein Rollback der Steuerungsebene durchführen.

Fargate. 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 das Rollback initiieren, oder verwenden Sie diese Option, --force um die Erkennung von Versionsverzerrungen zu umgehen (was zu unerwartetem Verhalten führen kann, bis die Pods ersetzt werden).

Prüfen Sie die Budgets für Störungen, bevor Sie das Rollback einleiten. Amazon EKS bietet Einblicke in die Rollback-Bereitschaft für NodePool Disruptionsbudgets. Bei Budgets, die auf 0 gesetzt sind, wird ein ERROR-Insight ausgelöst, wodurch ein Rollback auf unbestimmte Zeit blockiert wird. Restriktive Budgets und PodDisruptionBudgets (PDBs) lösen WARNING-Einblicke aus, die das Rollback verlangsamen, aber Fortschritte ermöglichen. Behandeln Sie die ERROR-Informationen, bevor Sie das 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 NodePool Disruptionsbudgets und PDBs kubectl während des Rollbacks anpassen. Durch eine Erhöhung des Budgets können mehr Knoten gleichzeitig ausgetauscht werden.

Entfernen Sie Anmerkungen, die nicht unterbrochen werden dürfen, von blockierenden Knoten. Die karpenter.sh/do-not-disrupt Anmerkung auf den Knoten blockiert das Rollback auf unbestimmte Zeit. Entfernen Sie sie von den Knoten, die ersetzt werden sollen.

Verfolgen Sie den Fortschritt des Knoten-Rollbacks. Wird verwendetkubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide, um zu überwachen, welche Knoten durch das AMI der Vorgängerversion 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 Abbrechen konvergieren die Knoten wieder zur aktuellen Version, und Sie können einen anderen Ansatz wählen.

Stellen Sie ein angemessenes Timeout ein. Verwenden Sie den timeoutMinutes Parameter inrollbackConfig, um ihn an Ihren betrieblichen Erwartungen auszurichten. Die Standardeinstellung ist 720 Minuten (12 Stunden). Bei Clustern mit konservativen Budgets sollten Sie erwägen, den Wert zu erhöhen. Richten Sie sich bei IaC-managed Clustern nach dem Timeout Ihres Tools.

DescribeUpdate Betrieb. Wird verwendetdescribe-update, um den aktuellen Status des Rollback-Vorgangs zu überprüfen (InProgress,Successful,Failed,Cancelled). Um den Fortschritt der Stornierung zu verfolgen, überprüfen Sie das cancellation Objekt in der Antwort.

Erkenntnisse bündeln. Amazon EKS überprüft die Erkenntnisse erneut, bevor mit dem Rollback der Steuerungsebene fortgefahren wird (nachdem das Node-Rollback für den Auto-Modus abgeschlossen ist). Halten Sie Ausschau nach neuen ERROR-Erkenntnissen, die möglicherweise erschienen sind.

Cluster-Status. Bei Clustern im Auto-Modus bleibt der Cluster-Status ACTIVE während des Node-Rollbacks erhalten und wechselt UPDATING nur während des Rollbacks auf der Steuerungsebene. Verlassen Sie sich nicht ausschließlich auf den Cluster-Status, um zu wissen, dass ein Rollback im Gange ist — verwenden Sie DescribeUpdate

Node-Versionen. Überprüfen Sie für den automatischen Modus die Kubernetes-Versionen des Knotens, um den Fortschritt des Knotenaustauschs zu verfolgen. Überwachen Sie bei verwalteten Knotengruppen den Aktualisierungsstatus der Knotengruppe.

AWS CloudFormation unterstützt bis zu 36 Stunden pro Ressource. Wenn das Rollback diesen Wert überschreitet, wird es als No-Op CloudFormation behandelt, was dazu führen kann, dass der Cluster in einen Drift-Zustand gerät, in dem die Vorlage nicht die tatsächliche Cluster-Version wiedergibt. 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 sich an das Timeout Ihres IaC-Tools an, um zu verhindern, dass das IaC-Tool das Timeout überschreitet, bevor Amazon EKS das Rollback abschließt.

Erwägen Sie, das Rollback CLI/API für Cluster im Auto-Modus mit restriktiven Budgets statt über IaC einzuleiten. Verwenden Sie es CancelUpdate direkt, wenn bei der IaC-Ebene ein Timeout auftritt.

Das 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 frühere Vorlagenversion kein Rollback der Cluster-Version. Sie müssen explizit ein Versions-Rollback einleiten.

Ein Rollback ergänzt das Testen, es ersetzt es nicht. Nutzen Sie weiterhin Cluster-Einblicke, Tests vor dem Upgrade in Nicht-Produktionsumgebungen und gestaffelte Rollouts. Rollback behandelt die Fälle, die durch Tests nicht erkannt werden können — Probleme, die nur in der Produktion auftreten.

Rollback reduziert den Bedarf an manuellen Sicherungs- und Snapshot-Verfahren als primärem Sicherheitsmechanismus. Da natives Rollback verfügbar ist, müssen Sie sich bei Upgrades nicht mehr ausschließlich auf etcd-Snapshots oder benutzerdefinierte Rollback-Skripts für die Notfallwiederherstellung verlassen.

Erkenntnisse werden nach bestem Wissen gewonnen und sind zeitnah. Amazon EKS wertet sie aus, wenn Sie ein Rollback auslösen. Änderungen, die nach dieser Prüfung vorgenommen werden (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 der Anwendung. Amazon EKS stellt die Steuerungsebene sicher wieder her, aber es liegt in Ihrer Verantwortung, Ihre Anwendungen, Konfigurationen und Abhängigkeiten anhand der vorherigen Version zu validieren.

Rollback des Clusters auf die vorherige Kubernetes-Version

Führen Sie ein Rollback der Amazon EKS-Cluster im automatischen Modus durch

Bewährte Methoden für Cluster-Upgrades

Cluster-Erkenntnisse

Lebenszyklus der Kubernetes-Version auf EKS