So funktioniert Handover
Handover zieht einen Cluster zwischen der gehosteten Control Plane von kubehz und Infrastruktur um, die dir gehört. Es ist der Mechanismus hinter dem No-Lock-in-Versprechen. Diese Seite erklärt die Idee. Die Schritt-für-Schritt-Anleitung findest du unter Migration: rein und raus.
Ein Cluster ist seine Identität, nicht seine Server
Nimm einen Kubernetes-Cluster auseinander, und nur wenige Dinge machen ihn zu diesem Cluster:
- die Zertifizierungsstelle (CA), der jeder Node und jede kubeconfig vertraut,
- die Service-Account-Signaturschlüssel, die jedes Workload-Token signieren,
- der Verschlüsselungsschlüssel, der Secrets im Ruhezustand schützt,
- und die Daten: jedes API-Objekt, in etcd.
Die Server, auf denen die Control Plane läuft, kannst du ersetzen. Die Identität kannst du nicht ersetzen. Zieh Identität und Daten um, und der Cluster bleibt derselbe Cluster, egal, wo seine Control Plane läuft. Genau das ist der Kniff: Handover verschiebt die Identität, nicht die Maschinen.
Restore-basiert, auf langweiligen Fundamenten
Handover setzt bewusst auf erprobte Mechanismen, nicht auf clevere:
- Die Plattform stellt ein Export-Bundle zusammen (die Identität von oben) und erstellt einen frischen etcd-Snapshot.
- Auf deiner Zielmaschine spielt das Bundle die Identität ein, bevor die neue Control Plane initialisiert, und ein Restore lädt den Snapshot.
- Der Standard-Kubernetes-Bootstrap übernimmt dann die eingespielte Identität, statt eine neue zu prägen.
Das Ergebnis startet als dein Cluster: dieselbe CA, dieselben Schlüssel, dieselben Objekte. Deine Worker vertrauen ihm bereits, also verbinden sie sich neu und machen weiter. Es gibt keinen Live-Transfer zwischen Control Planes und kein eigenes Replikationsprotokoll: nur einen Snapshot und einen Restore, und du kannst jeden Schritt nachprüfen.
Du bist das Gate
Handover ist bewusst nicht vollautomatisch. Zwei Momente gehören dir:
- Cutover: Du richtest den Endpoint-DNS des Clusters auf die neue Control Plane, und die Plattform wartet auf deine ausdrückliche Bestätigung. Bis dahin passiert nichts Destruktives.
- Decommission: Die Plattform entfernt die alte Control Plane erst, wenn die Plattform die neue lebendig sieht (Heartbeats) und du ein zweites Mal bestätigst. Bis beides zutrifft, bleibt die alte Seite als dein Fallback intakt.
Stoppt ein Handover mittendrin, hält es an und behält den gesamten Zustand auf beiden Seiten. Kein Schritt lässt dich ohne funktionierende Control Plane zurück.
Erst schauen, dann bewegen
Bevor ein Handover starten kann, liefert das Assessment der Plattform (eine rein lesende Sonde deines Clusters) einen Machbarkeitspfad und einen Übersetzungsbericht. Dieser Bericht ist die ehrliche Liste der Dinge, die einer Control Plane nicht über Provider-Grenzen folgen: provider-gekoppelte Storage-Klassen, Cloud-Load-Balancer, Cluster-API-Verwaltung. Du siehst das vollständige Bild zuerst, per lo kubehz assess oder im Dashboard.
Die ehrliche Grenze heute
- Eject (Hosted → deine Infrastruktur) erhält die Identität. Es ist heute live und funktioniert genau wie oben beschrieben.
- Adopt (dein Cluster → Hosted) läuft heute als Recreation: kubehz legt die gehostete Control Plane frisch an, mit neuer Identität, und du ziehst die Workloads um, indem du sie erneut anwendest. Ein identitätserhaltendes Adopt steht auf der Roadmap. Bis es ausgeliefert ist, steht in den Docs „neue Identität“, und sie deuten nichts anderes an.
Nächste Schritte
- Migration: rein und raus: die Schritt-für-Schritt-Anleitung für beide Richtungen
- So funktioniert es: das Hosting-×-Access-Modell, in das Handover sich einfügt
- Gehostete Control Plane: der Hosted-Weg selbst
Doku-Status
| Aspekt | Detail |
|---|---|
| Zustand | aktiv: beschreibt den live geschalteten Handover-Mechanismus |
| Zuletzt geprüft | 2026-10-30 |