Training Module

Kubernetes Hochverfügbarkeit — Multi-Master Control-Plane

In diesem 120-Minuten-Modul baut ihr die Topologie, die euch das Modul “Kubernetes Administration” bislang nur als Konzept vermittelt hat, zum ersten Mal tatsächlich selbst. Ihr startet mit der Frage, die jede Single-Node-Control-Plane offen lässt: Was passiert mit euren Worker-Nodes, wenn der einzige API-Server oder das einzige etcd ausfällt – laufende Workloads bleiben zunächst am Leben, aber niemand kann mehr etwas Neues anlegen, skalieren oder reparieren, bis die Control-Plane zurück ist. Danach ordnet ihr Stacked gegen External etcd konzeptionell ein: weniger Nodes gegen entkoppelte Ausfälle. Den größten Unterschied zu allen bisherigen Modulen dieses Repos macht das Werkzeug: Statt Minikube baut ihr euren Cluster mit kind (Kubernetes-in-Docker) auf – jeder Node ist ein eigener Docker-Container, keine verschachtelte Virtualisierung nötig, und mit drei control-plane-Rollen in der Cluster-Config bekommt ihr einen echten Multi-Control-Plane-Cluster inklusive eines automatisch erzeugten HAProxy-Loadbalancers vor den drei API-Servern – etwas, das Minikube in keiner Konfiguration leisten kann. Im zweiten Hands-on-Block wird es konkret: Ihr beobachtet das etcd-Raft-Quorum live mit etcdctl member list, stoppt gezielt einen Control-Plane-Container und weist nach, dass der Cluster bei 2 von 3 Membern weiterhin schreibfähig bleibt – stoppt ihr einen zweiten, seht ihr am eigenen Cluster, wie jede Schreiboperation blockiert, sobald das Quorum kippt. Danach ordnet ihr das Load-Balancer-Konzept vor mehreren API-Server-Instanzen allgemein ein, losgelöst von der kind-spezifischen HAProxy-Lösung und ohne Cloud-LB-Spezifika. Zum Abschluss ein bewusster Ausblick ohne eigenes Hands-on: die Verteilung der Worker-Nodes über Failure-Domains. Voraussetzung ist das Modul “Kubernetes Administration” – dessen High-Availability-Block wird hier vorausgesetzt und zum ersten Mal in die Praxis überführt. Die Session läuft weiterhin vollständig lokal, ohne Cloud-Account und ohne Kostenwirkung – mit etwas höherem Ressourcenbedarf als die bisherigen Single-Node-Module, weil drei Control-Plane-Container gleichzeitig laufen.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

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

Teilnehmende

Ops/Admins, die eine Multi-Control-Plane-Topologie einmal selbst aufgebaut und ein Quorum-Verhalten am eigenen Cluster gesehen haben wollen

Voraussetzungen

Abgeschlossenes Modul “Kubernetes Administration” (High-Availability-Konzeptblock) oder gleichwertige Vorkenntnisse, lauffähige lokale Docker-Umgebung für kind – etwas höherer Ressourcenbedarf als bei den Single-Node-Modulen, weil drei Control-Plane-Container parallel laufen

Warum dieses Training für deine Organisation wirkt

Aus dem Konzept wird ein echter Cluster

“Kubernetes Administration” vermittelt Control-Plane-HA und etcd-Raft-Quorum als Frontalteil – ehrlich begründet, weil eine Single-Node-Sandbox keine echte Topologie hergibt. Dieses Modul schließt genau diese Lücke: derselbe Stoff, diesmal als eigener Cluster in euren Händen.

Quorum ist kein Diagramm mehr, sondern ein Befehl

Wer nur gehört hat, dass etcd bei 2 von 3 Membern noch schreibfähig ist, glaubt es. Wer einen Container selbst stoppt und die Schreiboperation live blockieren sieht, sobald das Quorum kippt, versteht es – und trifft im Ernstfall die richtige Entscheidung unter Zeitdruck.

Werkzeugwechsel mit Grund, nicht mit Geschmack

kind statt Minikube ist keine Stilfrage: Nur mit eigenen Node-Containern pro Rolle entsteht ein echter Multi-Control-Plane-Cluster samt automatischem HAProxy-Loadbalancer – etwas, das eine Minikube-Instanz grundsätzlich nicht abbilden kann.

Was Teilnehmende mitnehmen

  • Herleiten, warum eine Ein-Node-Control-Plane ein Single Point of Failure ist – und was für Worker-Nodes im Ausfall konkret noch geht und was nicht.
  • Stacked etcd gegen External etcd als Topologie-Trade-off einordnen: weniger Nodes gegen entkoppelte Control-Plane-/etcd-Ausfälle.
  • Mit kind create cluster aus einer Mehrknoten-Config einen echten Multi-Control-Plane-Cluster (3 Control-Plane-Nodes + Worker) aufbauen, inklusive des automatisch erzeugten HAProxy-Loadbalancers vor den API-Servern.
  • Das etcd-Raft-Quorum mit etcdctl member list live an echten Membern nachvollziehen, statt es nur aus einem Diagramm zu kennen.
  • Einen Control-Plane-Node gezielt stoppen, die fortbestehende Schreibfähigkeit bei 2 von 3 Membern nachweisen und am eigenen Cluster erleben, wie Schreiboperationen bei Verlust des Quorums (1 von 3) blockieren.
  • Das Load-Balancer-Konzept vor mehreren API-Server-Instanzen allgemein einordnen, losgelöst von der kind-eigenen HAProxy-Lösung und ohne Cloud-Anbieter-Spezifika.
  • Die Verteilung von Worker-Nodes über Failure-Domains als Ausblick benennen – bewusst ohne eigenes Hands-on, weil Container auf demselben Docker-Host keine echten physischen Failure-Domains abbilden.

Für wen dieses Modul ideal ist

  • • Ops/Admins mit abgeschlossenem Modul “Kubernetes Administration” oder gleichwertigen Vorkenntnissen
  • • Alle, die eine produktive Multi-Control-Plane-Topologie planen oder betreiben sollen, aber noch nie eine echte selbst aufgebaut haben
  • • Teams, die vor dem nächsten Vorfall wissen wollen, ab wann ein etcd-Quorum tatsächlich kippt – nicht nur, dass es das theoretisch tut

Rahmendaten

  • • Dauer: 120 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, zwei aufeinander aufbauende Hands-on-Übungen (Cluster-Aufbau, Quorum-Verhalten), Load-Balancer-Konzept und Failure-Domain-Ausblick als reine Konzeptteile
  • • Voraussetzungen: abgeschlossenes Modul “Kubernetes Administration”, lauffähige lokale Docker-Umgebung für kind, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Warum HA — Single Point of Failure der Control-Plane (10 min): was ein Ausfall von API-Server oder etcd für Worker-Nodes bedeutet (Workloads laufen weiter) gegenüber der Administration (keine Zustandsänderung mehr möglich).

  2. Stacked vs. External etcd (10 min): die zwei etablierten kubeadm-Topologien als konzeptioneller Trade-off zwischen Node-Zahl und entkoppelten Ausfällen.

  3. Hands-on 1: Multi-Control-Plane-Cluster mit kind aufsetzen (30 min, Hands-on): aus einer Cluster-Config mit drei control-plane-Rollen und einem Worker einen echten Cluster erzeugen, den automatisch erzeugten HAProxy-Loadbalancer vor den API-Servern identifizieren.

  4. Hands-on 2: etcd-Raft-Quorum live beobachten (40 min, Hands-on): mit etcdctl member list alle drei Member sehen, einen Control-Plane-Node stoppen und Schreibfähigkeit bei 2 von 3 Membern nachweisen, einen zweiten Node stoppen und den Schreibblock bei Quorum-Verlust demonstrieren.

  5. Load-Balancer-Konzept vor mehreren API-Servern (10 min): allgemeine Einordnung jenseits der kind-eigenen HAProxy-Lösung, bewusst ohne Cloud-Anbieter-Spezifika.

  6. Failure-Domain-Verteilung der Worker als Ausblick, ohne eigenes Hands-on (10 min): Topology Spread Constraints als Konzept – analog zur Abgrenzungslogik aus “Kubernetes Administration”, weil Container auf demselben Docker-Host keine echten Failure-Domains abbilden.

  7. Puffer/Q&A (10 min): offene Fragen, individuelle Vertiefung je nach Ziel-Topologie der Teilnehmenden.

Dieses Modul setzt das Vertiefungsmodul Kubernetes Administration — RBAC, Node-Betrieb und Cluster-Netzwerk voraus – und zwar konkret dessen High-Availability-Block: Was dort als Konzept eingeführt wurde (Control-Plane-HA, etcd-Raft-Quorum), baut ihr hier zum ersten Mal tatsächlich selbst auf und beobachtet das Quorum-Verhalten live. Wer diesen Hintergrund noch nicht hat, sollte zuerst dieses Modul buchen.

Wer stattdessen den Datenverlust-Fall vertiefen will – ein etcd-Backup per etcdctl snapshot save erstellen und einen gelöschten Namespace daraus wiederherstellen – findet das im Schwestermodul Kubernetes Cluster-Recovery — etcd Backup & Restore. Beide Module behandeln Control-Plane-Resilienz aus unterschiedlichem Blickwinkel: Dieses Modul hier vertieft die Topologie-Verfügbarkeit (mehrere Control-Plane-Nodes, Quorum bei laufendem Cluster), das Schwestermodul die Datenwiederherstellung (Snapshot/Restore nach Datenverlust) – keines setzt das andere voraus.

Wer beide Module – dieses hier UND das Schwestermodul Cluster-Recovery – 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: koordiniertes Restore über mehrere etcd-Member hinweg, mit neuem Cluster-Token und konsistenten –initial-cluster-Flags.

Hands-on Inhalte (Auszug)

Multi-Control-Plane-Cluster aufsetzen

  • Eine kind-Cluster-Config mit drei control-plane-Rollen und einem worker schreiben und mit kind create cluster –config anwenden
  • Mit docker ps die vier Node-Container und den automatisch erzeugten HAProxy-Loadbalancer-Container identifizieren

Quorum live sehen

  • Mit kubectl exec in einen etcd-static-Pod wechseln und mit etcdctl member list -w table alle drei Member bestätigen
  • Die Erwartung vorher laut aussprechen, bevor der erste Node gestoppt wird

2 von 3: noch schreibfähig

  • Einen Control-Plane-Container mit docker stop anhalten
  • Mit kubectl create configmap live nachweisen, dass der Cluster bei 2 von 3 Membern weiterhin schreibfähig bleibt

1 von 3: Quorum verloren

  • Einen zweiten Control-Plane-Container stoppen und den nächsten Schreibversuch live blockieren sehen
  • Beide Container mit docker start zurückholen und das Quorum wiederhergestellt verifizieren

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit vom Node-Stopp bis zum beobachteten Schreibblock) 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