Upgrade von etcd v3.5 auf v3.6
Im Allgemeinen kann das Upgrade von etcd v3.5 auf v3.6 als Rolling Upgrade ohne Ausfallzeit erfolgen:
- Die etcd-v3.5-Prozesse nacheinander stoppen und durch etcd-v3.6-Prozesse ersetzen.
- Sobald alle v3.6-Prozesse laufen, stehen dem Cluster die neuen Funktionen von v3.6 zur Verfügung.
Lesen Sie zur Vorbereitung den Rest dieses Leitfadens, bevor Sie mit dem Upgrade beginnen .
Checklisten für das Upgrade
3.5 aktualisieren
Stellen Sie vor dem Upgrade auf 3.6 sicher, dass alle Ihre 3.5-Mitglieder auf 3.5.32 oder höher aktualisiert sind
. Die Patch-Releases 3.5.24 bis 3.5.26 beheben mehrere mögliche Upgrade-Hindernisse; 3.5.32
ergänzt --v2-deprecation=write-only-skip-check und erweitert etcdutl check v2store um die Prüfung von WAL-Einträgen zusätzlich zum v2-Snapshot.
V2-Speicher
Wenn das Flag --enable-v2 nicht konfiguriert oder auf false gesetzt ist, sind keine weiteren Maßnahmen erforderlich.
Wenn --enable-v2 konfiguriert ist, führen Sie den Befehl etcdutl check v2store aus, um zu prüfen, ob der v2store Daten enthält, die nicht zur Mitgliedschaft gehören (benutzerdefinierte Daten). Sind keine benutzerdefinierten Daten vorhanden, kann das Flag gefahrlos entfernt werden. Andernfalls finden Sie weitere Einzelheiten im v2-Migrationsleitfaden
.
Hinzugefügte Flags
Entfernte Flags
Veraltete Flags
Das Flag etcd --experimental-bootstrap-defrag-threshold-megabytes ist veraltet.
Das Flag etcd --experimental-compaction-batch-limit ist veraltet.
Das Flag etcd --experimental-compact-hash-check-time ist veraltet.
Das Flag etcd --experimental-compaction-sleep-interval ist veraltet.
Das Flag etcd --experimental-corrupt-check-time ist veraltet.
Das Flag etcd --experimental-enable-distributed-tracing ist veraltet.
Das Flag etcd --experimental-distributed-tracing-address ist veraltet.
Das Flag etcd --experimental-distributed-tracing-instance-id ist veraltet.
Das Flag etcd --experimental-distributed-tracing-sampling-rate ist veraltet.
Das Flag etcd --experimental-distributed-tracing-service-name ist veraltet.
Das Flag etcd --experimental-downgrade-check-time ist veraltet.
Das Flag etcd --experimental-max-learners ist veraltet.
Das Flag etcd --experimental-memory-mlock ist veraltet.
Das Flag etcd --experimental-peer-skip-client-san-verification ist veraltet.
Das Flag etcd --experimental-snapshot-catchup-entries ist veraltet.
Das Flag etcd --experimental-warning-apply-duration ist veraltet.
Das Flag etcd --experimental-warning-unary-request-duration ist veraltet.
Das Flag etcd --experimental-watch-progress-notify-interval ist veraltet.
Experimentelle v3.5-Flags durch Funktionsschalter ersetzen
Entsprechender Funktionsschalter für etcd --experimental-compact-hash-check-enabled=true
Entsprechender Funktionsschalter für etcd --experimental-initial-corrupt-check=true
Entsprechender Funktionsschalter für etcd --experimental-enable-lease-checkpoint=true
Entsprechender Funktionsschalter für etcd --experimental-enable-lease-checkpoint-persist=true
Entsprechender Funktionsschalter für etcd --experimental-stop-grpc-service-on-defrag=true
Entsprechender Funktionsschalter für etcd --experimental-txn-mode-write-with-shared-buffer=false
Flags mit neuen Standardwerten
Ursprüngliches Standard-Flag etcd --snapshot-count=100000
Ursprüngliches Standard-Flag etcd --v2-deprecation='not-yet'
Ursprüngliches Standard-Flag etcd --discovery-fallback='proxy'
Unterschiede bei Prometheus-Metriken
Checklisten für das Server-Upgrade
Upgrade-Voraussetzungen
Um eine bestehende etcd-Installation auf v3.6 zu aktualisieren, muss der laufende Cluster Version v3.5 oder höher verwenden. Falls er eine ältere Version als v3.5 verwendet, führen Sie vor dem Upgrade auf v3.6 zunächst ein Upgrade auf v3.5 durch.
Außerdem muss der laufende Cluster fehlerfrei sein, damit das Rolling Upgrade reibungslos verläuft. Prüfen Sie den Zustand des Clusters mit dem Befehl etcdctl endpoint health, bevor Sie fortfahren.
Vorbereitung
Testen Sie vor einem etcd-Upgrade immer die von etcd abhängigen Dienste in einer Staging-Umgebung, bevor Sie das Upgrade in der Produktionsumgebung durchführen.
Laden Sie vor Beginn das Snapshot-Backup herunter
. Falls beim Upgrade etwas schiefgeht, können Sie mit diesem Backup ein Rollback
auf die bestehende etcd-Version durchführen. Beachten Sie, dass der Befehl snapshot nur die v3-Daten sichert.
Gemischte Versionen
Während des Upgrades unterstützt ein etcd-Cluster Mitglieder mit gemischten etcd-Versionen und verwendet das Protokoll der niedrigsten gemeinsamen Version. Der Cluster gilt erst als aktualisiert, wenn alle Mitglieder auf Version v3.6 aktualisiert wurden. Intern handeln die etcd-Mitglieder untereinander die Gesamtversion des Clusters aus, die die gemeldete Version und die unterstützten Funktionen bestimmt.
Rollback
Erstellen Sie vor dem Upgrade Ihres etcd-Clusters ein Snapshot-Backup des Clusters und laden Sie es herunter . Mit diesem Snapshot lässt sich der Cluster bei Bedarf in seinen Zustand vor dem Upgrade zurückversetzen. Falls während des Upgrades Probleme auftreten, sollten Benutzer zunächst deren Ursache ermitteln und beheben. Solange sich der Cluster noch in einem Zustand mit gemischten Versionen befindet, also mindestens ein Mitglied weiterhin v3.5 verwendet, können sie entweder die Binärdatei oder das Image durch die alte Version v3.5 ersetzen oder den Cluster direkt aus dem Snapshot wiederherstellen. In diesem gemischten Zustand arbeitet der Cluster weiterhin als v3.5-Cluster, sodass ein Rollback ohne formelles Downgrade-Verfahren möglich ist.
Sobald jedoch alle Mitglieder auf v3.6 aktualisiert wurden, gilt der Cluster als vollständig aktualisiert. Der bloße Austausch der Binärdateien ist dann kein gültiges Rollback-Verfahren mehr. Für die Recovery kann entweder der vor dem Upgrade erstellte Snapshot wiederhergestellt oder der offizielle Downgrade-Leitfaden befolgt werden, um zur ursprünglichen Version zurückzukehren und dabei Konsistenz zu gewährleisten sowie Datenbeschädigungen zu vermeiden.
Upgrade-Verfahren
Dieses Beispiel zeigt das Upgrade eines etcd-v3.5-Clusters mit 3 Mitgliedern, der auf einem lokalen Rechner läuft.
Schritt 1: Upgrade-Voraussetzungen prüfen
Ist der Cluster fehlerfrei und läuft er mit v3.5.x?
Schritt 2: Snapshot-Backup vom Leader herunterladen
Laden Sie das Snapshot-Backup herunter , um bei Problemen ein Downgrade durchführen zu können.
Der etcd-Leader enthält garantiert die neuesten Anwendungsdaten. Rufen Sie den Snapshot daher vom Leader ab:
Schritt 3: Einen bestehenden etcd-Server stoppen
Wenn ein etcd-Prozess gestoppt wird, protokollieren die anderen Cluster-Mitglieder erwartete Fehler. Dies ist normal, da die Verbindung zu einem Cluster-Mitglied (vorübergehend) unterbrochen wurde:
Schritt 4: Den etcd-Server mit derselben Konfiguration neu starten
Starten Sie den etcd-Server mit derselben Konfiguration, aber mit der neuen etcd-Binärdatei neu.
Das neue etcd v3.6 veröffentlicht seine Informationen im Cluster. Zu diesem Zeitpunkt verwendet der Cluster weiterhin das Protokoll von v3.5, der niedrigsten gemeinsamen Version.
{"level":"info","ts":"2025-03-01T04:40:36.828+0530","caller":"api/capability.go:76","msg":"enabled capabilities for version","cluster-version":"3.5"}
{"level":"info","ts":"2025-03-01T04:40:36.889+0530","caller":"membership/cluster.go:539","msg":"updated cluster version","cluster-id":"59a05384c9b79ee","local-member-id":"bf9071f4639c75cc","from":"3.0","to":"3.5"}
{"level":"info","ts":"2025-03-01T04:40:36.828+0530","caller":"api/capability.go:76","msg":"enabled capabilities for version","cluster-version":"3.5"}
{"level":"info","ts":"2025-03-01T04:40:36.894+0530","caller":"etcdserver/server.go:1686","msg":"published local member to cluster through raft","local-member-id":"bf9071f4639c75cc","local-member-attributes":"{Name:node1 ClientURLs:[http://127.0.0.1:2379]}","cluster-id":"59a05384c9b79ee","publish-timeout":"7s"}
Prüfen Sie, ob jedes Mitglied und anschließend der gesamte Cluster mit der neuen etcd-v3.6-Binärdatei wieder fehlerfrei ist:
Noch nicht aktualisierte Mitglieder protokollieren Warnungen wie die folgenden, bis der gesamte Cluster aktualisiert wurde.
Dies ist zu erwarten und endet, sobald alle etcd-Cluster-Mitglieder auf v3.6 aktualisiert wurden:
Schritt 5: Schritt 3 und Schritt 4 für die übrigen Mitglieder wiederholen
Sobald alle Mitglieder aktualisiert wurden, meldet der Cluster den erfolgreichen Abschluss des Upgrades auf v3.6:
Mitglied 1:
{"level":"info","ts":"2025-03-01T04:58:32.375+0530","caller":"etcdserver/server.go:2149","msg":"updating cluster version using v3 API","from":"3.5","to":"3.6"}{"level":"info","ts":"2025-03-01T04:58:32.377+0530","caller":"etcdserver/server.go:2164","msg":"cluster version is updated","cluster-version":"3.6"}
Mitglied 2:
{"level":"info","ts":"2025-03-01T04:58:32.377+0530","caller":"membership/cluster.go:539","msg":"updated cluster version","cluster-id":"59a05384c9b79ee","local-member-id":"91bc3c398fb3c146","from":"3.5","to":"3.6"}
Mitglied 3:
{"level":"info","ts":"2025-03-01T04:58:32.377+0530","caller":"membership/cluster.go:539","msg":"updated cluster version","cluster-id":"59a05384c9b79ee","local-member-id":"fd422379fda50e48","from":"3.5","to":"3.6"}