So funktioniert Handover
Handover ist der Mechanismus, mit dem ein Cluster zwischen der gehosteten Control Plane von kubehz und deiner eigenen Infrastruktur umzieht — die Technik hinter dem No-Lock-in-Versprechen. Diese Seite erklärt die Idee; die Schritt-für-Schritt-Anleitung ist Migration — rein und raus.
Ein Cluster ist seine Identität, nicht seine Server
Reduziert man einen Kubernetes-Cluster auf das Wesentliche, ist das, was ihn zu diesem Cluster macht, überraschend klein:
- die Zertifizierungsstelle (CA), der jeder Node und jede Kubeconfig vertraut,
- die Service-Account-Signaturschlüssel, mit denen jedes Workload-Token signiert ist,
- 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, sind austauschbar; die Identität ist es nicht. Zieht man Identität und Daten um, ist der Cluster derselbe Cluster — egal, wo seine Control Plane gerade 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 statt auf clevere Mechanismen:
- Die Plattform stellt ein Export-Bundle zusammen — die Identität von oben — und erstellt einen frischen etcd-Snapshot.
- Auf deiner Zielmaschine wird das Bundle eingespielt, bevor die neue Control Plane initialisiert, und der Snapshot wiederhergestellt.
- Der Standard-Kubernetes-Bootstrap übernimmt die eingespielte Identität, statt eine frische zu prägen.
Das Ergebnis startet als dein Cluster — dieselbe CA, dieselben Schlüssel, dieselben Objekte. Deine Worker vertrauen ihm bereits; sie verbinden sich neu und machen weiter. Kein Live-Transfer zwischen Control Planes, kein eigenes Replikationsprotokoll — ein Snapshot und ein Restore, in jedem Schritt nachvollziehbar.
Du bist das Gate
Handover ist bewusst nicht vollautomatisch. Zwei Momente gehören dir:
- Cutover — den Endpoint-DNS des Clusters auf die neue Control Plane zu richten ist deine Aktion, und die Plattform wartet auf deine ausdrückliche Bestätigung. Bis dahin ist nichts Destruktives passiert.
- Decommission — die alte Control Plane wird erst entfernt, nachdem die Plattform die neue lebendig gesehen hat (Heartbeats) und du ein zweites Mal bestätigt hast. Bis beides zutrifft, bleibt die alte Seite als dein Fallback intakt.
Ein Handover, das mittendrin stoppt, hält einfach an und behält den gesamten Zustand auf beiden Seiten — es gibt keinen Schritt, an dem du ohne funktionierende Control Plane dastehst.
Erst schauen, dann bewegen
Bevor ein Handover überhaupt starten kann, liefert das Assessment der Plattform — eine rein lesende Sonde deines Clusters — einen Machbarkeitspfad und einen Übersetzungsbericht: 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 — heute live, genau wie oben beschrieben.
- Adopt (dein Cluster → Hosted) läuft heute als Recreation: Die gehostete Control Plane wird frisch erstellt, mit neuer Identität, und Workloads ziehen per Re-Apply um. Ein identitätserhaltendes Adopt ist geplant; bis es ausgeliefert ist, steht in den Docs „neue Identität“ — ohne etwas anderes anzudeuten.
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-07-29 |