Hoe handover werkt
Handover is hoe een cluster verhuist tussen het gehoste control plane van kubehz en infrastructuur die je zelf bezit — het mechanisme achter de geen-lock-in-belofte. Deze pagina legt het idee uit; de stap-voor-stap-gids is Migratie — erin en eruit.
Een cluster is zijn identiteit, niet zijn servers
Strip een Kubernetes-cluster tot de kern en wat het dat cluster maakt, is verrassend klein:
- de certificate authority (CA) die elke node en elke kubeconfig vertrouwt,
- de ondertekeningssleutels voor service accounts waarmee elk workload-token is ondertekend,
- de encryptiesleutel die secrets at rest beschermt,
- en de data — elk API-object, in etcd.
De servers waarop het control plane draait zijn vervangbaar; de identiteit niet. Verhuis de identiteit en de data, en het cluster is 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 in plaats van slimme mechanismen:
- Het platform stelt een exportbundel samen — de identiteit hierboven — en maakt een verse etcd-snapshot.
- Op je doelmachine wordt de bundel geseed voordat het nieuwe control plane initialiseert, en wordt de snapshot hersteld.
- De standaard Kubernetes-bootstrap hergebruikt vervolgens de geseede identiteit in plaats van een verse te munten.
Het resultaat komt op als jouw cluster — dezelfde CA, dezelfde sleutels, dezelfde objecten. Je workers vertrouwen het al; ze verbinden opnieuw en gaan door. Geen live overdracht tussen control planes, geen op maat gemaakt replicatieprotocol — een snapshot en een restore, bij elke stap controleerbaar.
Jij bent de poort
Handover is bewust niet volledig automatisch. Twee momenten zijn van jou:
- Cutover — de endpoint-DNS van het cluster naar het nieuwe control plane wijzen is jouw actie, en het platform wacht op je expliciete bevestiging. Tot dan is er niets destructiefs gebeurd.
- Decommission — het oude control plane wordt pas verwijderd nadat het platform het nieuwe levend heeft gezien (heartbeat) en jij een tweede keer hebt bevestigd. Tot beide waar zijn, blijft de oude kant intact als je vangnet.
Een handover die halverwege stopt, houdt simpelweg halt en behoudt alle state aan beide kanten — er is geen stap waarop je zonder werkend control plane komt te zitten.
Eerst kijken, dan pas bewegen
Voordat een handover überhaupt kan starten, rapporteert de assessment van het platform — een read-only meting van je cluster — een haalbaarheidspad en een vertaalrapport: 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 — vandaag live, precies zoals hierboven beschreven.
- Adopt (jouw cluster → gehost) draait vandaag als recreation: het gehoste control plane wordt vers aangemaakt, met een nieuwe identiteit, en workloads verhuizen door ze opnieuw toe te passen. Een identiteitsbehoudende adopt is gepland; tot die er is, zeggen de docs “nieuwe identiteit” — zonder iets anders te suggereren.
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-07-29 |