Hoe handover werkt
Handover verhuist een cluster tussen het gehoste control plane van kubehz en infrastructuur die je zelf bezit. Het is het mechanisme achter de geen-lock-in-belofte. Deze pagina legt het idee uit. De stap-voor-stap-gids vind je bij Migratie: erin en eruit.
Een cluster is zijn identiteit, niet zijn servers
Haal een Kubernetes-cluster uit elkaar, en maar een paar dingen maken het tot dat cluster:
- de certificate authority (CA) die elke node en elke kubeconfig vertrouwt,
- de ondertekeningssleutels voor service accounts, die elk workload-token ondertekenen,
- de encryptiesleutel, die Secrets at rest beschermt,
- en de data: elk API-object, in etcd.
De servers waarop het control plane draait, kun je vervangen. De identiteit kun je niet vervangen. Verhuis de identiteit en de data, en het cluster blijft hetzelfde cluster, waar zijn control plane ook draait. Dat is de hele truc: handover verplaatst de identiteit, niet de machines.
Restore-gebaseerd, op saaie fundamenten
Handover gebruikt bewust beproefde mechanismen, geen slimme:
- Het platform stelt een exportbundel samen (de identiteit hierboven) en maakt een verse etcd-snapshot.
- Op je doelmachine zet de bundel de identiteit klaar voordat het nieuwe control plane initialiseert, en een restore laadt de snapshot.
- De standaard Kubernetes-bootstrap hergebruikt daarna die identiteit in plaats van een nieuwe te munten.
Het resultaat komt op als jouw cluster: dezelfde CA, dezelfde sleutels, dezelfde objecten. Je workers vertrouwen het al, dus ze verbinden opnieuw en gaan door. Er is geen live overdracht tussen control planes en geen op maat gemaakt replicatieprotocol: alleen een snapshot en een restore, en je kunt elke stap controleren.
Jij bent de poort
Handover is bewust niet volledig automatisch. Twee momenten zijn van jou:
- Cutover: jij wijst de endpoint-DNS van het cluster naar het nieuwe control plane, en het platform wacht op je expliciete bevestiging. Tot dan gebeurt er niets destructiefs.
- Decommission: het platform verwijdert het oude control plane pas nadat het platform het nieuwe levend ziet (heartbeat) en jij een tweede keer bevestigt. Tot beide waar zijn, blijft de oude kant intact als je vangnet.
Stopt een handover halverwege, dan houdt hij halt en behoudt hij alle state aan beide kanten. Geen enkele stap laat je zonder werkend control plane achter.
Eerst kijken, dan pas bewegen
Voordat een handover kan starten, rapporteert de assessment van het platform (een read-only meting van je cluster) een haalbaarheidspad en een vertaalrapport. Dat rapport is de eerlijke lijst van dingen die een control plane niet over providergrenzen volgen: provider-gebonden storage classes, cloud-load-balancers, Cluster-API-beheer. Je ziet eerst het volledige beeld, via lo kubehz assess of het dashboard.
De eerlijke grens van vandaag
- Eject (gehost → jouw infrastructuur) behoudt de identiteit. Het is vandaag live en werkt precies zoals hierboven beschreven.
- Adopt (jouw cluster → gehost) draait vandaag als recreation: kubehz maakt het gehoste control plane vers aan, met een nieuwe identiteit, en jij verhuist de workloads door ze opnieuw toe te passen. Een identiteitsbehoudende adopt staat op de roadmap. Tot die er is, zeggen de docs “nieuwe identiteit” en suggereren ze niets anders.
Volgende stappen
- Migratie: erin en eruit: de stap-voor-stap-gids voor beide richtingen
- Hoe het werkt: het hosting-×-access-model waar handover in past
- Gehost control plane: het gehoste pad zelf
Documentstatus
| Aspect | Detail |
|---|---|
| Status | actief: beschrijft het live handover-mechanisme |
| Laatst gecontroleerd | 2026-10-30 |