Kubernetes Multi-Master Disaster Recovery — Koordinierte etcd-Wiederherstellung

Dieses 120-Minuten-Modul schließt eine Lücke, die zwei Vorgängermodule dieses Repos jeweils ausdrücklich offen gelassen haben: “Kubernetes Cluster-Recovery” hat euch Snapshot und Restore an einem einzelnen etcd-Member beigebracht, “Kubernetes Hochverfügbarkeit” hat euch einen echten Drei-Control-Plane-Cluster bauen und das Raft-Quorum bei einem simulierten Node-Ausfall live beobachten lassen – beide Module benennen an ihrem Ende wörtlich dieselbe offene Frage: Was tut ihr, wenn beides gleichzeitig zutrifft – ein produktiver Cluster mit mehreren etcd-Membern, bei dem tatsächlich etwas kaputtgeht? Ihr startet mit der entscheidenden Unterscheidung, die im Ernstfall über eure erste Reaktion entscheidet: Verliert ihr einen Control-Plane-Node, während die übrigen Member weiterhin eine Raft-Mehrheit bilden, ist das ein Ersatz-Fall – der tote Member wird sauber aus dem laufenden Cluster entfernt, ein neuer tritt bei, ohne dass irgendwo ein Snapshot ins Spiel kommt. Verliert ihr dagegen die Mehrheit der Member gleichzeitig, ist der Cluster für jede Zustandsänderung eingefroren, und es bleibt nur die koordinierte Wiederherstellung aus einem Snapshot – auf allen betroffenen Membern gleichzeitig, mit identischem neuen Cluster-Token und exakt übereinstimmenden –initial-cluster-Flags, sonst entstehen mehrere unabhängige Ein-Member-Cluster statt eines wiederhergestellten Mehr-Member-Clusters. Im ersten Hands-on übt ihr den Ersatz-Fall an eurem eigenen Drei-Control-Plane-kind-Cluster: einen Node stoppen, den toten Member mit etcdctl member remove sauber austragen, einen frischen Node per kubeadm join –control-plane beitreten lassen und verifizieren, dass die Cluster-ID dabei unverändert bleibt – kein neuer Cluster, sondern derselbe, wieder auf drei Membern. Im zweiten, größeren Hands-on kippt ihr bewusst das Quorum, erlebt den eingefrorenen Cluster am eigenen kubectl, und übt die koordinierte Wiederherstellung aus einem zuvor gezogenen Snapshot auf mehreren Membern gleichzeitig – inklusive der Fallstricke, die entstehen, wenn ihr das nacheinander statt koordiniert tut. Bewusst nicht Teil dieses Moduls: keine erneute Snapshot-Grundlage (kennt ihr aus Cluster-Recovery), kein Raft-Quorum-Grundlagenteil (kennt ihr aus Hochverfügbarkeit), kein Velero/PVC-Restore und keine automatisierte Backup-Pipeline – siehe Modulaufbau. Voraussetzung sind beide Vorgängermodule gleichzeitig. Die Session läuft weiterhin vollständig lokal über kind, ohne Cloud-Account und ohne Kostenwirkung – mit demselben höheren Ressourcenbedarf wie im Modul Hochverfügbarkeit, weil wieder drei Control-Plane-Container gleichzeitig laufen.