Training Module

Kubernetes Cluster-Recovery — etcd Backup & Restore

In diesem 90-Minuten-Modul beantwortet ihr die Frage, die sich niemand stellen will, bevor sie zum Vorfall wird: Was passiert, wenn der Clusterzustand selbst weg ist? etcd ist die Single Source of Truth jedes Kubernetes-Clusters – jedes Deployment, jedes Secret, jede RBAC-Regel existiert nur, weil sie als Eintrag in diesem verteilten Key-Value-Store steht. Ohne funktionierendes Backup dieses einen Speichers ist der gesamte Cluster ein Totalausfall, kein Wiederherstellungsfall. Ihr startet damit, Zugriff auf etcdctl im laufenden Cluster herzustellen: etcd läuft bei einem kubeadm-basierten Cluster – und damit auch bei Minikube – als static Pod im Namespace kube-system, seine TLS-Zertifikate liegen unter /etc/kubernetes/pki/etcd/. Danach erstellt ihr einen echten Snapshot per etcdctl snapshot save und prüft dessen Status, bevor ihr euch auf ihn verlasst. Den größten Block bildet die Restore-Übung: Ihr löscht gezielt einen Namespace, stellt den Cluster aus dem zuvor erstellten Snapshot in ein neues Datenverzeichnis wieder her, beobachtet den nötigen Control-Plane-Neustart und verifiziert das Ergebnis mit kubectl get. Zum Abschluss ordnet ihr das Gelernte konzeptionell gegen Velero ein – ein Objekt-Backup auf Kubernetes-API-Ebene mit selektiver, namespace-genauer Wiederherstellung, im Unterschied zum etcd-Snapshot, der immer den gesamten Clusterzustand auf einen einzigen Zeitpunkt zurücksetzt. Bewusst ohne eigenes Hands-on, weil ein Velero-Aufbau mit Objekt-Storage-Anbindung den Rahmen dieses Moduls sprengen würde. Voraussetzung ist das Modul “Kubernetes Administration” – dessen High-Availability-Block hat euch Control-Plane-HA und das etcd-Raft-Quorum bereits als Konzept vermittelt, hier wird das vorausgesetzt und nicht erneut eingeführt. Die Session läuft weiterhin vollständig lokal über Minikube, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

90 Minuten, live (remote oder vor Ort), Input & Hands-on

Teilnehmende

Ops/Admins, die im Ernstfall einen Kubernetes-Cluster aus einem etcd-Snapshot verlässlich wiederherstellen können wollen

Voraussetzungen

Abgeschlossenes Modul “Kubernetes Administration” oder gleichwertige Vorkenntnisse (RBAC, Node-Betrieb, HA-Konzept inkl. etcd-Raft-Quorum), lauffähige lokale Docker-Umgebung für Minikube

Warum dieses Training für deine Organisation wirkt

Ohne etcd-Backup gibt es keine Wiederherstellung

Jedes YAML-Manifest, jedes Secret und jede RBAC-Regel ist nur ein Eintrag in etcd. Wer diesen einen Speicher nicht sichert, hat im Ernstfall keinen Cluster zum Wiederherstellen – nur einen, den er von Grund auf neu bauen muss.

Ein Restore ist kein Klick, sondern eine Prozedur

Zugriff auf etcdctl, ein neues Datenverzeichnis, ein kontrollierter Control-Plane-Neustart – wer diese Schritte nicht vorher einmal selbst durchgespielt hat, verliert im echten Vorfall wertvolle Zeit mit Nachschlagen statt Handeln.

Restore ist Alles-oder-nichts, nicht selektiv

Ein etcd-Snapshot-Restore setzt den gesamten Cluster auf den Zeitpunkt des Snapshots zurück – nicht nur den gelöschten Namespace. Wer diese Grenze nicht kennt, verspricht im Vorfall eine Präzision, die das Werkzeug nicht liefert.

Was Teilnehmende mitnehmen

  • Herleiten, warum etcd die Single Source of Truth eines Kubernetes-Clusters ist und was ein Ausfall ohne Backup bedeutet.
  • Den etcd-static Pod im Namespace kube-system finden, seine TLS-Zertifikate unter /etc/kubernetes/pki/etcd/ lokalisieren und mit etcdctl member list den eigenen Zugriff verifizieren.
  • Einen konsistenten Snapshot per etcdctl snapshot save erstellen und dessen Integrität mit etcdctl snapshot status vor dem Ernstfall prüfen.
  • Einen absichtlich gelöschten Namespace aus einem Snapshot in ein neues Datenverzeichnis wiederherstellen, den nötigen Control-Plane-Neustart einordnen und das Ergebnis mit kubectl get verifizieren.
  • Den entscheidenden Unterschied zu einem selektiven Namespace-Restore benennen: ein etcd-Restore rollt den gesamten Cluster auf den Snapshot-Zeitpunkt zurück, auch danach angelegte Objekte gehen dabei verloren.
  • Velero konzeptionell einordnen: API-Objekt-Backup mit selektiver, namespace-/label-genauer Wiederherstellung über Objekt-Storage, als Ergänzung statt Ersatz für das etcd-Snapshot-Verfahren.

Für wen dieses Modul ideal ist

  • • Ops/Admins mit abgeschlossenem Modul “Kubernetes Administration” oder gleichwertigen Vorkenntnissen
  • • Alle, die einen Cluster im Ernstfall wiederherstellen sollen, es aber noch nie unter Zeitdruck geübt haben
  • • Teams, die vor dem ersten produktiven Backup-Konzept wissen wollen, was ein etcd-Restore tatsächlich leistet – und was nicht

Rahmendaten

  • • Dauer: 90 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, durchgehende Hands-on-Übung von Snapshot bis Restore, Velero-Abgrenzung als reiner Konzeptteil
  • • Voraussetzungen: abgeschlossenes Modul “Kubernetes Administration”, lauffähige lokale Docker-Umgebung, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Warum Backup — etcd als Single Source of Truth (10 min): herleiten, warum jedes Cluster-Objekt nur ein Eintrag in etcd ist, und was ein Datenverlust dort für den gesamten Cluster bedeutet.

  2. Zugriff auf etcdctl im laufenden Cluster (15 min, Hands-on): den etcd-static-Pod in kube-system finden, die TLS-Zertifikate unter /etc/kubernetes/pki/etcd/ lokalisieren, Zugriff mit etcdctl member list verifizieren.

  3. Snapshot erstellen und Status prüfen (15 min, Hands-on): etcdctl snapshot save auf ein lokales Volume, anschließend etcdctl snapshot status gegen die erzeugte Datei.

  4. Restore-Übung: Namespace löschen, aus Snapshot wiederherstellen, verifizieren (35 min, Hands-on): einen Namespace gezielt löschen, per etcdctl snapshot restore in ein neues Datenverzeichnis wiederherstellen, den nötigen Control-Plane-Neustart durchführen und mit kubectl get verifizieren.

  5. Kurze Abgrenzung zu Velero, ohne eigenes Hands-on (10 min): API-Objekt-Backup mit selektiver Wiederherstellung über Objekt-Storage, im Unterschied zum Alles-oder-nichts-Restore eines etcd-Snapshots.

  6. Puffer/Q&A (5 min): offene Fragen, individuelle Vertiefung je nach Backup-Anforderung der Teilnehmenden.

Dieses Modul setzt das Vertiefungsmodul Kubernetes Administration — RBAC, Node-Betrieb und Cluster-Netzwerk voraus – und zwar konkret dessen High-Availability-Block: Control-Plane-HA und das etcd-Raft-Quorum werden dort bereits als Konzept eingeführt und hier als bekannt vorausgesetzt, nicht erneut erklärt. Wer diesen Hintergrund noch nicht hat, sollte zuerst dieses Modul buchen.

Wer stattdessen wissen will, wie sich eine bereits laufende Anwendung diagnostizieren lässt – Prometheus-Scrape-Annotationen, Ephemeral Containers per kubectl debug und die dreistufige Service-Troubleshooting-Kette – findet das im Schwestermodul Kubernetes: Monitoring & Troubleshooting. Dieses Modul behandelt ausschließlich die Wiederherstellung des Clusterzustands selbst (etcd) – die Wiederherstellung von Anwendungsdaten auf einer PersistentVolumeClaim ist ein eigenes Thema und bereits Teil des Moduls Kubernetes Storage — Volumes, PersistentVolumes & Claims, hier nicht erneut behandelt.

Wer stattdessen den Topologie-Fall vertiefen will – einen echten Multi-Control-Plane-Cluster mit drei Control-Plane-Nodes über kind selbst aufbauen und das etcd-Raft-Quorum live an einem simulierten Node-Ausfall beobachten – findet das im Schwestermodul Kubernetes Hochverfügbarkeit — Multi-Master Control-Plane. Beide Module behandeln Control-Plane-Resilienz aus unterschiedlichem Blickwinkel: Dieses Modul hier vertieft die Datenwiederherstellung (Snapshot/Restore nach Datenverlust), das Schwestermodul die Topologie-Verfügbarkeit (mehrere Control-Plane-Nodes, Quorum bei laufendem Cluster) – keines setzt das andere voraus.

Wer beide Module – dieses hier UND das Schwestermodul Hochverfügbarkeit – bereits abgeschlossen hat und wissen will, wie sich ein produktiver Cluster mit mehreren etcd-Membern koordiniert wiederherstellen lässt, findet das im Aufbaumodul Kubernetes Multi-Master Disaster Recovery — Koordinierte etcd-Wiederherstellung. Es setzt beide Module gleichzeitig voraus und schließt genau die Lücke, die dieses Modul hier bewusst offen lässt: Restore über mehrere etcd-Member hinweg, mit neuem Cluster-Token und konsistenten –initial-cluster-Flags.

Hands-on Inhalte (Auszug)

Zugriff auf etcdctl verifizieren

  • Den etcd-static-Pod in kube-system identifizieren und per kubectl exec hineinwechseln
  • Mit den TLS-Zertifikaten aus /etc/kubernetes/pki/etcd/ und etcdctl member list live bestätigen, dass der eigene Zugriff funktioniert, bevor überhaupt gesichert wird

Snapshot erstellen und prüfen

  • etcdctl snapshot save auf ein lokales, dauerhaftes Volume ausführen
  • Mit etcdctl snapshot status die erzeugte Datei gegenprüfen, statt ihr blind zu vertrauen

Absichtlicher Datenverlust

  • Einen eigens angelegten Namespace samt Inhalt gezielt mit kubectl delete namespace entfernen
  • Mit kubectl get namespace den Verlust bestätigen, bevor die Wiederherstellung beginnt

Restore & Verifikation

  • Mit etcdctl snapshot restore in ein neues Datenverzeichnis wiederherstellen und den Control-Plane-Neustart begleiten
  • Mit kubectl get namespace und kubectl get all -n verifizieren, dass der gelöschte Namespace wieder da ist

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit vom Snapshot bis zum verifizierten Restore) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übung auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen