Wer einen Kubernetes-Cluster betreibt, beschäftigt sich früher oder später mit der Frage, wie sich die Infrastruktur nach einem schwerwiegenden Fehler wiederherstellen lässt. Dabei spielt eine Komponente eine besonders wichtige Rolle: etcd. Fällt diese Datenbank aus, kann das erhebliche Auswirkungen auf die gesamte Kubernetes Control Plane haben.
Während sich ausgefallene Pods häufig automatisch ersetzen lassen, sieht die Situation bei etcd deutlich komplizierter aus. Schließlich werden hier die zentralen Zustandsinformationen des Kubernetes-Clusters gespeichert. Gehen diese Daten verloren, können wichtige Informationen über Deployments, Services, Secrets und zahlreiche weitere Kubernetes-Ressourcen fehlen.
Deshalb gehört die Fähigkeit, etcd in Kubernetes wiederherzustellen, zu den wichtigsten Grundlagen eines zuverlässigen Clusterbetriebs. Allerdings ist nicht jeder Ausfall gleich. Ein defektes etcd-Mitglied lässt sich unter Umständen relativ einfach ersetzen, während der vollständige Verlust des Quorums einen deutlich aufwendigeren Wiederherstellungsprozess erforderlich macht.
In diesem Artikel schauen wir uns die verschiedenen Möglichkeiten der etcd-Wiederherstellung an. Dabei geht es um Snapshots, den Austausch einzelner Mitglieder, den Wiederaufbau nach einem Cluster-Ausfall und typische Fehler, die du unbedingt vermeiden solltest.
Warum ist etcd für Kubernetes so wichtig?
etcd ist ein verteilter Key-Value-Store, der von Kubernetes als zentrale Datenhaltung für den Clusterzustand verwendet wird. Vereinfacht gesagt speichert etcd die Informationen, die Kubernetes benötigt, um den gewünschten und den tatsächlich bekannten Zustand seiner Ressourcen zu verwalten.
Wenn du beispielsweise ein Deployment erstellst, wird die entsprechende Konfiguration über den Kubernetes API Server verarbeitet und in etcd gespeichert. Auch Informationen über Namespaces, ConfigMaps, Secrets, Services und viele weitere Ressourcen befinden sich dort.
Der Kubernetes API Server ist dabei die zentrale Schnittstelle zwischen den Kubernetes-Komponenten und etcd. Andere Komponenten greifen normalerweise nicht direkt auf die Datenbank zu, sondern kommunizieren über die Kubernetes-API.
Fällt etcd vollständig aus, kann der API Server wichtige Anfragen nicht mehr ordnungsgemäß bearbeiten. Bereits laufende Container müssen dadurch nicht zwangsläufig sofort beendet werden. Allerdings können neue Deployments, Änderungen an Ressourcen und verschiedene Verwaltungsfunktionen beeinträchtigt sein.
Deshalb ist etcd nicht einfach irgendeine Datenbank innerhalb des Clusters, sondern eine zentrale Voraussetzung für den zuverlässigen Betrieb der Control Plane.
Welche Möglichkeiten gibt es, etcd wiederherzustellen?
Bevor du eine Wiederherstellung startest, solltest du zunächst herausfinden, welche Art von Fehler überhaupt vorliegt. Denn nicht bei jedem Problem ist ein vollständiger Snapshot-Restore notwendig.
Grundsätzlich lassen sich drei typische Szenarien unterscheiden:
- Ein einzelnes etcd-Mitglied ist ausgefallen: Der verbleibende Cluster besitzt noch ein funktionierendes Quorum und kann das Mitglied ersetzen.
- Der etcd-Cluster hat sein Quorum verloren: Es stehen nicht mehr genügend Mitglieder zur Verfügung, um neue Änderungen zu bestätigen.
- Der Datenbestand muss auf einen früheren Zustand zurückgesetzt werden: Beispielsweise nach einem schwerwiegenden Fehler oder Datenverlust.
Je nach Situation kommen unterschiedliche Wiederherstellungsverfahren infrage. Deshalb wäre es ein Fehler, bei jedem etcd-Problem sofort ein altes Backup einzuspielen.
Solange der Cluster noch funktionsfähig ist, sollte zunächst geprüft werden, ob sich das Problem ohne Zurücksetzen der gesamten Datenbank beheben lässt.
Das etcd-Quorum verstehen
Um die Wiederherstellung richtig einzuordnen, müssen wir zunächst das Quorum verstehen.
etcd verwendet das Raft-Konsensverfahren. Dabei müssen Änderungen von einer Mehrheit der stimmberechtigten Mitglieder bestätigt werden, bevor sie als erfolgreich committed gelten.
Bei einem etcd-Cluster mit drei Mitgliedern werden deshalb mindestens zwei funktionierende Mitglieder benötigt. Ein Cluster mit fünf Mitgliedern benötigt dagegen mindestens drei Mitglieder.
Das bedeutet, dass ein Cluster mit drei Mitgliedern den Ausfall eines einzelnen Mitglieds normalerweise tolerieren kann.
Fallen jedoch zwei Mitglieder dauerhaft aus, ist keine Mehrheit mehr vorhanden. Der Cluster verliert sein Quorum und kann keine regulären Schreiboperationen mehr bestätigen.
Genau deshalb werden etcd-Cluster häufig mit einer ungeraden Anzahl an Mitgliedern betrieben.
Allerdings bietet ein Cluster mit vier Mitgliedern keine höhere Ausfalltoleranz als einer mit drei Mitgliedern, da bei vier Mitgliedern bereits drei für eine Mehrheit erforderlich sind.
Bevor du also Maßnahmen zur Wiederherstellung einleitest, solltest du immer prüfen, ob das Quorum noch vorhanden ist.
Den Zustand von etcd überprüfen
Für die Administration von etcd steht das Kommandozeilenwerkzeug etcdctl zur Verfügung.
In einem typischen, mit kubeadm erstellten Kubernetes-Cluster wird etcd häufig als Static Pod auf einem Control-Plane-Node ausgeführt. Die benötigten Zertifikate befinden sich in solchen Umgebungen normalerweise unter /etc/kubernetes/pki/etcd/.
Die folgenden Beispiele beziehen sich auf eine solche kubeadm-Installation mit lokalem etcd. Bei extern betriebenen etcd-Clustern oder Managed-Kubernetes-Diensten können die Pfade und Verwaltungsverfahren abweichen.
Mit folgendem Befehl kannst du den Zustand eines erreichbaren etcd-Endpunkts überprüfen:
sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
endpoint healthZusätzlich kannst du mit endpoint status weitere Informationen abrufen:
sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
endpoint status --write-out=tableDamit erhältst du unter anderem Informationen über den aktuellen Raft-Zustand, die Revision und den Leader-Status des abgefragten Mitglieds.
Bei einem Cluster mit mehreren Mitgliedern solltest du zusätzlich alle bekannten Endpunkte untersuchen. Nur so lässt sich zuverlässig beurteilen, ob lediglich ein einzelnes Mitglied betroffen ist oder der gesamte Cluster Probleme hat.
Möglichkeit 1: Ein ausgefallenes etcd-Mitglied ersetzen
Wenn ein etcd-Cluster weiterhin über ein funktionierendes Quorum verfügt, ist normalerweise kein vollständiger Restore erforderlich.
Angenommen, du betreibst drei Control-Plane-Nodes mit jeweils einem etcd-Mitglied. Einer dieser Server fällt aufgrund eines Hardwaredefekts dauerhaft aus, während die beiden anderen weiterhin erreichbar sind.
In diesem Fall kann der etcd-Cluster normalerweise weiterarbeiten, weil noch zwei von drei Mitgliedern verfügbar sind.
Das ausgefallene Mitglied sollte jedoch ersetzt werden, damit die ursprüngliche Fehlertoleranz wiederhergestellt wird.
Der grundlegende Ablauf besteht darin, das ausgefallene Mitglied aus der Cluster-Konfiguration zu entfernen und anschließend ein neues Mitglied hinzuzufügen.
Mit folgendem Befehl kannst du die aktuellen Mitglieder anzeigen:
etcdctl member list --write-out=tableFür diesen Befehl müssen ebenfalls der richtige Endpunkt und gegebenenfalls die zuvor gezeigten TLS-Zertifikatsoptionen angegeben werden.
Nachdem das betroffene Mitglied eindeutig identifiziert wurde, kann es aus einem funktionsfähigen etcd-Cluster entfernt werden:
etcdctl member remove MEMBER_IDAnschließend lässt sich ein neues Mitglied registrieren. Bei einem direkt verwalteten etcd-Cluster kann dafür beispielsweise etcdctl member add verwendet werden.
Wichtig ist, dass die Startkonfiguration des neuen Mitglieds zur aktuellen Cluster-Mitgliedschaft passt. Außerdem darf ein entferntes Mitglied nicht versehentlich mit seinem alten Datenverzeichnis erneut gestartet werden.
Bei kubeadm-Clustern solltest du darüber hinaus den von kubeadm vorgesehenen Ablauf zum Wiederherstellen oder Hinzufügen eines Control-Plane-Nodes verwenden. Eine manuelle Änderung der etcd-Mitgliedschaft und ein gleichzeitiger kubeadm-Join ohne abgestimmten Plan können zusätzliche Probleme verursachen.
Entscheidend ist: Solange das Quorum vorhanden ist, kann ein einzelnes Mitglied normalerweise ersetzt werden, ohne den gesamten etcd-Datenbestand aus einem Snapshot zurückzusetzen.
Möglichkeit 2: etcd aus einem Snapshot wiederherstellen
Eine andere Situation entsteht, wenn der gesamte etcd-Cluster seinen Zustand verloren hat oder der Datenbestand auf einen früheren Zeitpunkt zurückgesetzt werden muss.
Hier kommen etcd-Snapshots ins Spiel.
Ein Snapshot enthält den gespeicherten Zustand der etcd-Datenbank zu einem bestimmten Zeitpunkt. Damit lässt sich ein neuer logischer etcd-Cluster auf Grundlage dieses Datenbestands aufbauen.
Allerdings solltest du bedenken, dass Änderungen nach dem Zeitpunkt der Sicherung bei einer Wiederherstellung nicht automatisch wieder vorhanden sind.
Einen etcd-Snapshot erstellen
Für die Erstellung eines Snapshots wird etcdctl snapshot save verwendet.
Ein Beispiel für eine kubeadm-Installation sieht folgendermaßen aus:
sudo etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
snapshot save /backup/etcd-snapshot.dbDas Verzeichnis /backup muss bereits existieren und beschreibbar sein.
Der Befehl erstellt eine konsistente Sicherung des etcd-Datenbestands. Allerdings solltest du die Snapshot-Datei anschließend auf ein unabhängiges und ausreichend geschütztes Backup-System übertragen.
Schließlich hilft ein Backup wenig, wenn es ausschließlich auf demselben Server gespeichert wird, der später ausfällt.
Snapshot überprüfen
Bevor ein Snapshot zur Wiederherstellung verwendet wird, sollte er überprüft werden.
Für aktuelle etcd-Versionen steht dafür das Werkzeug etcdutl zur Verfügung:
etcdutl snapshot status \
/backup/etcd-snapshot.db \
--write-out=tableDie Ausgabe enthält unter anderem die Revision, die Anzahl der Schlüssel und die Größe der Datenbank.
Dadurch lässt sich zumindest überprüfen, ob der Snapshot grundsätzlich lesbar ist und welchen Datenstand er enthält.
Allerdings ersetzt diese Prüfung keinen vollständigen Wiederherstellungstest.
Einen Snapshot mit etcdutl wiederherstellen
Für die Wiederherstellung einer gesicherten etcd-Datenbank wird bei aktuellen etcd-Versionen etcdutl snapshot restore eingesetzt.
Ein grundlegendes Beispiel lautet:
etcdutl snapshot restore \
/backup/etcd-snapshot.db \
--data-dir=/var/lib/etcd-restoredDieser Befehl erstellt aus dem Snapshot ein neues etcd-Datenverzeichnis.
Wichtig ist dabei, dass eine Wiederherstellung aus einem Snapshot nicht einfach das alte Cluster-Mitglied fortsetzt. Stattdessen werden neue Identitätsinformationen für den wiederhergestellten etcd-Cluster erzeugt.
Für einen Cluster mit mehreren etcd-Mitgliedern müssen deshalb alle Mitglieder auf Grundlage desselben Snapshots und mit einer zueinander passenden Cluster-Konfiguration wiederhergestellt werden.
Bei einem einzelnen kubeadm-Control-Plane-Node ist der Ablauf vergleichsweise übersichtlich. Allerdings muss der wiederhergestellte Datenbestand anschließend auch tatsächlich von der etcd-Instanz verwendet werden.
Bei einer Static-Pod-Installation wird diese Konfiguration normalerweise über das Manifest unter /etc/kubernetes/manifests/etcd.yaml gesteuert.
Bevor du dort Änderungen vornimmst, solltest du das Manifest sichern und überprüfen, welches Host-Verzeichnis tatsächlich als etcd-Datenverzeichnis eingebunden wird.
Außerdem muss sichergestellt sein, dass keine alte etcd-Instanz gleichzeitig denselben Datenbestand verwendet. Für die Wiederherstellung ist deshalb ein geplanter Stillstand beziehungsweise eine koordinierte Wiederanlaufphase erforderlich.
Wichtig: Die gezeigten Restore-Befehle veranschaulichen das Verfahren. Sie sind keine vollständige, universell anwendbare Wiederherstellungsanleitung für beliebige produktive Kubernetes-Cluster.
Warum –bump-revision und –mark-compacted wichtig sind
Bei der Wiederherstellung von etcd in Kubernetes gibt es eine Besonderheit, die leicht übersehen wird.
Kubernetes-Controller verwenden Watches und lokale Caches, um Änderungen an Kubernetes-Ressourcen effizient zu verfolgen.
Wird ein älterer Snapshot eingespielt, kann die etcd-Revision gegenüber dem zuletzt bekannten Zustand zurückspringen.
Das kann zu Problemen führen, weil Clients unter Umständen noch Informationen aus einem neueren, nicht mehr vorhandenen Zustand zwischengespeichert haben.
Deshalb empfiehlt die etcd-Dokumentation für Kubernetes die Verwendung eines sogenannten Revision Bumps in Kombination mit dem Markieren der Revisionen als kompaktierte Historie.
Ein entsprechender Restore-Befehl könnte so aussehen:
etcdutl snapshot restore \
/backup/etcd-snapshot.db \
--data-dir=/var/lib/etcd-restored \
--bump-revision=1000000000 \
--mark-compactedMit --bump-revision wird die Revision entsprechend erhöht. Der gewählte Wert muss ausreichend groß sein, um die seit dem Snapshot erfolgten Änderungen abzudecken.
Durch --mark-compacted werden entsprechende Watches ungültig, sodass Clients ihre zwischengespeicherten Informationen neu aufbauen können.
Gerade bei Kubernetes ist das ein wichtiger Bestandteil einer durchdachten Disaster-Recovery-Strategie.
Möglichkeit 3: Vollständige Wiederherstellung nach Quorum-Verlust
Die schwierigste Situation entsteht, wenn ein etcd-Cluster die Mehrheit seiner Mitglieder dauerhaft verliert.
Bei einem Cluster mit drei Mitgliedern reicht bereits der dauerhafte Ausfall von zwei Mitgliedern aus, um das Quorum zu verlieren.
In diesem Zustand können reguläre Änderungen an der Cluster-Mitgliedschaft nicht mehr zuverlässig durchgeführt werden.
Deshalb lässt sich das Problem nicht einfach dadurch lösen, dass man mit etcdctl member remove die ausgefallenen Mitglieder entfernt. Schließlich benötigt auch diese Änderung normalerweise ein funktionierendes Quorum.
Wenn die ausgefallenen Mitglieder nicht wiederhergestellt werden können, muss ein neuer logischer etcd-Cluster aufgebaut werden.
Dafür kann ein vorhandener Snapshot verwendet werden. Bei einem mehrgliedrigen Cluster müssen die Datenverzeichnisse und Startparameter der neuen Mitglieder jedoch sorgfältig aufeinander abgestimmt werden.
Ein besonders wichtiger Punkt ist, dass alte und neu wiederhergestellte etcd-Mitglieder nicht versehentlich miteinander vermischt werden.
Andernfalls können widersprüchliche Cluster-Zustände entstehen, die eine Wiederherstellung zusätzlich erschweren.
Deshalb sollte ein vollständiger Restore niemals unkoordiniert auf einzelnen Control-Plane-Nodes durchgeführt werden.
Was ist nach der Wiederherstellung zu prüfen?
Wenn etcd wieder erreichbar ist, bedeutet das noch nicht automatisch, dass der gesamte Kubernetes-Cluster vollständig wiederhergestellt wurde.
Zunächst sollte überprüft werden, ob der API Server wieder erfolgreich auf etcd zugreifen kann.
Anschließend kannst du beispielsweise folgende Befehle verwenden:
kubectl get nodes
kubectl get pods -A
kubectl get deployments -ADarüber hinaus solltest du die Logs der Control-Plane-Komponenten kontrollieren und sicherstellen, dass Controller und Scheduler wieder ordnungsgemäß arbeiten.
Besonders wichtig ist außerdem die Frage, welche Änderungen seit dem letzten Snapshot erfolgt sind.
Wurden zwischenzeitlich Deployments geändert, Secrets aktualisiert oder neue Ressourcen erstellt, können diese Informationen nach der Wiederherstellung fehlen.
Gleichzeitig können auf Worker Nodes noch Container laufen, deren Konfiguration nicht mehr vollständig zum wiederhergestellten Kubernetes-Zustand passt.
Deshalb ist nach einem vollständigen etcd-Restore eine sorgfältige Prüfung der Workloads erforderlich.
Was gehört zu einer zuverlässigen etcd-Backup-Strategie?
Eine gute Wiederherstellungsstrategie beginnt nicht erst beim Ausfall, sondern bereits bei der Planung der Backups.
Für produktive Kubernetes-Cluster würde ich insbesondere folgende Punkte berücksichtigen:
- Regelmäßige automatische etcd-Snapshots erstellen.
- Backups unabhängig vom Kubernetes-Cluster speichern.
- Die Zugriffsrechte auf Snapshot-Dateien einschränken.
- Notwendige Zertifikate und Kubernetes-Konfigurationen separat sichern.
- Die Integrität der Sicherungen regelmäßig prüfen.
- Den vollständigen Wiederherstellungsprozess in einer Testumgebung durchführen.
- Wiederherstellungszeiten und möglichen Datenverlust dokumentieren.
Gerade die Sicherung der Zertifikate wird häufig unterschätzt.
Ein etcd-Snapshot enthält zwar den Datenbestand, aber nicht automatisch sämtliche Dateien und Zugangsdaten, die für die Wiederherstellung der Control Plane benötigt werden.
Auch externe Ressourcen wie Persistent Volumes müssen separat berücksichtigt werden. Ein etcd-Backup ersetzt schließlich keine Sicherung der eigentlichen Anwendungsdaten.
Darüber hinaus sollten die Anforderungen an die maximale Wiederherstellungszeit und den akzeptablen Datenverlust bekannt sein.
Wenn beispielsweise nur einmal täglich ein Snapshot erstellt wird, kann bei einem vollständigen Datenverlust ein erheblicher Teil der zwischenzeitlichen Änderungen fehlen.
Häufige Fehler bei der Wiederherstellung von etcd
Ein häufiger Fehler besteht darin, einen Snapshot einzuspielen, obwohl lediglich ein einzelnes etcd-Mitglied ausgefallen ist und der Cluster weiterhin ein funktionierendes Quorum besitzt.
In solchen Fällen ist der Austausch des betroffenen Mitglieds normalerweise die sinnvollere Lösung.
Problematisch ist außerdem das Wiederherstellen eines Snapshots in ein bereits verwendetes Datenverzeichnis, ohne den bestehenden Zustand vorher zu sichern und die laufenden Prozesse zu stoppen.
Auch eine fehlerhafte Cluster-Mitgliedschaft kann schwerwiegende Auswirkungen haben. Deshalb sollten insbesondere die Member-Namen, Peer-Adressen und Startparameter genau überprüft werden.
Ein weiterer Fehler ist die Annahme, dass eine erfolgreich gestartete etcd-Instanz bereits eine erfolgreiche Kubernetes-Wiederherstellung bedeutet.
Erst wenn API Server, Controller und die relevanten Workloads wieder korrekt funktionieren, ist der Wiederherstellungsprozess tatsächlich abgeschlossen.
Fazit: Eine etcd-Wiederherstellung muss vorbereitet sein
etcd ist eine der wichtigsten Komponenten eines Kubernetes-Clusters. Ohne eine funktionierende etcd-Datenhaltung kann die Control Plane zentrale Verwaltungsaufgaben nicht zuverlässig erfüllen.
Allerdings bedeutet nicht jeder Ausfall, dass sofort ein vollständiges Backup eingespielt werden muss.
Solange ein funktionierendes Quorum vorhanden ist, lassen sich ausgefallene Mitglieder häufig gezielt ersetzen. Geht dagegen die Mehrheit dauerhaft verloren, kann der Aufbau eines neuen etcd-Clusters aus einem Snapshot erforderlich werden.
Besonders wichtig ist dabei, die Unterschiede zwischen einem einzelnen Mitgliedsausfall, dem Verlust des Quorums und der vollständigen Wiederherstellung eines früheren Datenbestands zu verstehen.
Mein Tipp wäre deshalb, die etcd-Wiederherstellung nicht erst während eines echten Produktionsausfalls auszuprobieren.
Baue stattdessen eine Kubernetes-Testumgebung auf, erstelle einen Snapshot und führe dort einen vollständigen Restore durch. Beobachte anschließend, wie die Kubernetes Control Plane reagiert und welche Komponenten nach der Wiederherstellung überprüft werden müssen.
Gerade bei einem hochverfügbaren Cluster mit mehreren Control-Plane-Nodes lohnt es sich, auch den Ausfall einzelner Mitglieder und den vollständigen Quorum-Verlust gezielt zu simulieren.
Mein Fazit: Ein etcd-Backup ist wichtig. Entscheidend ist aber, dass du auch weißt, wie du den Cluster damit zuverlässig wiederherstellen kannst.
Denn erst ein regelmäßig getesteter Wiederherstellungsprozess macht aus einer vorhandenen Snapshot-Datei eine brauchbare Disaster-Recovery-Strategie.
Weiterführende Informationen
Die offizielle etcd-Dokumentation zum Disaster Recovery beschreibt die grundlegenden Verfahren zur Wiederherstellung eines etcd-Clusters.
Zusätzlich findest du in der Kubernetes-Dokumentation zur etcd-Administration wichtige Informationen zur Integration von etcd in Kubernetes.
Für den Austausch einzelner Mitglieder lohnt sich außerdem ein Blick auf die etcd-Dokumentation zur Runtime Reconfiguration.