Vermeidung von Zombie-Cluster-Mitgliedern beim Upgrade auf etcd v3.6

TL;DR

Beim Upgrade auf etcd v3.6 ist es entscheidend, zunächst auf v3.5.26 oder höher zu aktualisieren. Dadurch wird sichergestellt, dass Cluster automatisch repariert werden und das Auftreten von “Zombie-Mitgliedern” vermieden wird.

Hauptinhalt

Die etcd-Community hat ein Problem identifiziert, das beim Upgrade von etcd v3.5 auf v3.6 auftreten kann. Dieses Problem führt dazu, dass “Zombie-Mitglieder” im Cluster angezeigt werden. Diese Mitglieder sind Knoten, die zuvor aus dem Cluster entfernt wurden, aber nach dem Upgrade wieder erscheinen und versuchen, am Konsens des Clusters teilzunehmen. Dies führt dazu, dass der Cluster inoperabel wird, bis diese Zombie-Mitglieder entfernt werden.

In den Versionen v3.5 und früher war der v2store die maßgebliche Quelle für Mitgliedsdaten, obwohl auch der v3store vorhanden war. Mit der Einführung von v3.6 wird der v3store zur Hauptquelle für die Cluster-Mitgliedschaft, im Rahmen eines Plans zur Abwertung des v2stores. Bei älteren Clustern kann es jedoch zu Inkonsistenzen zwischen v2store und v3store kommen, was nach dem Upgrade zu dem Problem mit den Zombie-Mitgliedern führt.

Um dieses Problem zu beheben, wurde in etcd v3.5.26 ein Mechanismus implementiert, der den v3store automatisch mit dem v2store synchronisiert. Dies stellt sicher, dass betroffene Cluster repariert werden, bevor sie auf v3.6.x aktualisiert werden. Der empfohlene Upgrade-Pfad lautet: Zuerst auf v3.5.26 oder höher aktualisieren, danach den Gesundheitszustand aller Mitglieder überprüfen und schließlich auf v3.6 upgraden. Für Nutzer, die aus verschiedenen Gründen nicht auf v3.5.26 aktualisieren können, wird empfohlen, das Upgrade auf v3.6 zu verschieben, bis diese Version verfügbar ist.

Technische Details/Implikationen

Das Problem tritt insbesondere bei Clustern auf, die in Produktionsumgebungen mit etcd v3.5.25 oder früher betrieben werden. Es ist eine Folge der Hinzufügung und Entfernung von Mitgliedern aus dem Cluster oder der Wiederherstellung des Clusters nach einem Ausfall. Die Wahrscheinlichkeit, dass dieses Problem auftritt, steigt mit dem Alter des Clusters, kann jedoch auch bei neueren Clustern auftreten.

Es wurden mehrere mögliche Auslöser für das Problem identifiziert, darunter:

1. Ein Fehler beim Wiederherstellen von Snapshots mit etcdctl snapshot restore in v3.4 und älteren Versionen, bei dem alte Mitglieder nicht entfernt wurden.
2. Das erzwungene Erstellen eines neuen Clusters mit der Option --force-new-cluster in v3.5 und früher, was ebenfalls zu Zombie-Mitgliedern führen kann.
3. Die Aktivierung von --unsafe-no-sync, die in seltenen Fällen zu Inkonsistenzen zwischen v2store und v3store führen kann.

Es ist wichtig zu beachten, dass die Verwendung von --unsafe-no-sync im Allgemeinen nicht empfohlen wird, da sie die Konsensgarantien des Protokolls gefährden kann. Auch wenn die oben genannten Szenarien nicht auf alle Nutzer zutreffen, sollte niemand davon ausgehen, dass das Cluster automatisch sicher ist, nur weil diese Aktionen nicht durchgeführt wurden.

Nach dem Upgrade auf etcd v3.6 wird der v3store zur alleinigen Quelle für Mitgliedsdaten, wodurch zukünftige Inkonsistenzen ausgeschlossen sind.

Fazit/Ausblick

Die Einhaltung des empfohlenen Upgrade-Pfades ist entscheidend, um die Integrität und Funktionsfähigkeit des etcd-Clusters zu gewährleisten. Die frühzeitige Aktualisierung auf v3.5.26 oder höher ist der Schlüssel zur Vermeidung von Problemen mit Zombie-Mitgliedern.