Migratie — erin en eruit

Geen lock-in is alleen een belofte als je haar ook echt kunt inlossen. Deze pagina documenteert de handover (het verplaatsen van een cluster tussen het gehoste control plane van kubehz en je eigen infrastructuur) in beide richtingen, precies zoals het vandaag werkt.

Wat vandaag live is

Gehost → self-hosted (eject) is live. Je kunt je gehoste control plane naar je eigen Hetzner-infrastructuur verplaatsen en daarbij de cryptografische identiteit van het cluster behouden: je workers, kubeconfigs en secrets blijven werken.

Self-hosted → gehost (adopt) is live als recreation. kubehz zet een vers gehost control plane neer en jij verplaatst je workloads ernaartoe. Het cluster krijgt een nieuwe identiteit. Een identiteitsbehoudende adopt is gepland; tot die er is, zegt deze pagina dat gewoon eerlijk in plaats van iets anders voor te wenden.

Voor de concepten hierachter (waarom juist de identiteit verhuist, en waarom er niets wordt verwijderd zonder jouw toestemming), zie Hoe handover werkt.

De twee richtingen

Richting	Wat er gebeurt	Status
Eject: gehost → jouw infrastructuur	Je gehoste control plane wordt hersteld op machines die je zelf bezit, met dezelfde identiteit. Workers blijven.	Live
Adopt: jouw cluster → gehost	kubehz maakt een vers gehost control plane; jij verplaatst workloads ernaartoe. Nieuwe identiteit.	Live (recreation)

Eject is voor het moment dat je volledig eigenaarschap wilt: compliance-eisen, kostenbeheersing op schaal, of gewoon omdat het kan. De uitgang is het bewijs dat gehost een keuze is en geen val.

Adopt is voor het moment dat je klaar bent met zelf een control plane draaien en alleen nog workers op je account wilt houden.

Eerst komt de assessment

Er beweegt niets voordat je het plan hebt gezien. Het platform verzamelt doorlopend een read-only assessment van je cluster (Kubernetes-versie, datastore, storage classes, load balancers, CAPI-beheer) en leidt daaruit een haalbaarheidspad plus een vertaalrapport af, de lijst van dingen die niet automatisch meegaan en jouw aandacht nodig hebben:

• Provider-gebonden storage classes: volumes die door de CSI-driver van de ene provider zijn aangemaakt, volgen het control plane niet naar een andere.
• LoadBalancer-services: cloud-load-balancers zijn gebonden aan de provider die ze heeft aangemaakt.
• CAPI-beheerde clusters: een cluster waarvan de levenscyclus door Cluster API wordt aangestuurd, heeft gepauzeerd beheer nodig voordat een handover zinvol is.

Op elk moment in te zien via de CLI (het leest het register van je tenant en heeft daarom KUBEHZ_TOKEN nodig):

lo kubehz assess

Het dashboard toont dezelfde assessment en haalbaarheid op de clusterpagina. Het haalbaarheidspad is een van:

Pad	Betekenis
restore	Verhuizen via snapshot + identiteits-seed. Wat eject vandaag gebruikt.
recreation	Een vers control plane; workloads verhuizen door ze opnieuw toe te passen. Wat adopt vandaag gebruikt.
graft	Een live overdracht ter plekke. Wordt beoordeeld en gerapporteerd, maar nog niet uitvoerbaar; staat op de roadmap.

Gehost → self-hosted (eject)

Eject verplaatst je gehoste control plane naar infrastructuur die je zelf bezit, met behoud van de identiteit van het cluster: de certificate authority (CA), de ondertekeningssleutels voor service accounts, de encryptiesleutel voor secrets en elk object in het cluster (via een etcd-snapshot). Omdat de identiteit behouden blijft:

• Je workers blijven werken: ze vertrouwen de CA van het cluster al en verbinden na de cutover opnieuw met hetzelfde logische cluster.
• Bestaande kubeconfigs en service-account-tokens blijven geldig.
• Secrets zijn te ontsleutelen: de encryptiesleutel reist met het cluster mee.

De flow

1. Assess: lo kubehz assess (of het dashboard). Bevestig dat het pad restore is en lees het vertaalrapport.

2. Start de handover: via het Handover-tabblad van het cluster in het dashboard (of via de API). Je kiest de doeldriver (kubeadm of kubeone) en of het endpoint behouden blijft of wordt geroteerd.

3. Het platform exporteert: het stelt de exportbundel samen (de PKI van het cluster, de service-account-sleutels en de encryptiesleutel) en maakt een verse etcd-snapshot.

4. Download de bundel: de download vereist opnieuw inloggen, is eenmalig en wordt in de auditlog vastgelegd. De bundel is de root-identiteit van je cluster: behandel haar als een root-credential en verwijder je lokale kopie zodra de handover is afgerond.

5. Bereid het doel voor: een machine (of machines) in je eigen bezit, bereikbaar voor je workers. Concreet:

   • Bereikbaar op 6443 vanaf elke worker: dat is het API-endpoint dat lok8s instelt. Een doel achter NAT zonder inkomende 6443 is de gebruikelijke oorzaak van een restore die lijkt te slagen en je workers daarna laat vastlopen.
   • Dimensioneer bóven de reserveringen, niet erop. Op een control-plane-node reserveert lok8s 400m CPU en 1 GiB geheugen voor systeem en kubelet vóór enige workload, en de kubelet begint pods te verdringen zodra er minder dan 500 MiB beschikbaar is. 2 GB is dus de ondergrens, geen werkbare maat. Onze eigen referentieconfigs gebruiken cx33 voor control planes. Zie de KubeOne-gids.
   • Eén of drie nodes, nooit twee: etcd heeft een oneven aantal nodig voor quorum.
   • Een node draait maximaal 110 pods; daarvoor is de kubelet van de control plane ingesteld.
   • lok8s geïnstalleerd op het doel, met de rechten om het te gebruiken.receive draait op die machine, niet vanaf je werkstation: het schrijft /etc/kubernetes en /var/lib/etcd en roept kubeadm aan.
   • De bundel op het doel. Stap 4 downloadt hem waar je die uitvoerde; verplaats hem via een kanaal dat je vertrouwt en verwijder beide kopieën zodra stap 7 bevestigt. Onderweg is het de root-identiteit van je cluster.
   • Een schone node. receive weigert een machine die al Kubernetes-state draagt; voer op een eerder gebruikte node eerst zelf kubeadm reset uit.

6. Herstel op het doel:

   # kubeadm-driver: draai direct op de doelnode zelf
   lo kubehz handover receive --bundle ./bundle.tar.gz
   
   # kubeone-driver: seed eerst de identiteit, provision daarna zoals gewoonlijk
   lo kubehz handover preseed --bundle ./bundle.tar.gz --node "<node-ip>"
   lo provision

   receive kent --snapshot <bestand> om een apart gedownloade etcd-snapshot te herstellen, --single-node voor een control plane van één node, en --force om een node te overschrijven die al Kubernetes-state draagt (in plaats van de kubeadm reset hierboven). preseed bereikt de node via SSH: --user (standaard root), --port (standaard 22) en --ssh-key bepalen hoe.

   receive seedt de geëxporteerde identiteit, herstelt de etcd-snapshot en start een control plane dat jouw cluster is: dezelfde CA, dezelfde sleutels, dezelfde objecten.

7. Cutover: wijs de endpoint-DNS van het cluster naar je nieuwe control plane. Workers verbinden vanzelf opnieuw; op de workers verandert niets. Bevestig daarna de cutover: het platform wacht op je expliciete bevestiging en doet daarvoor niets destructiefs.

8. Decommission: het oude gehoste control plane wordt pas verwijderd als twee dingen waar zijn. Het platform moet je nieuwe control plane levend hebben gezien (heartbeat), en je moet het decommissionen expliciet hebben bevestigd. Tot die tijd blijft het oude control plane intact als je vangnet.

Wat jij doet bij de cutover

De ene actie die alleen van jou is: de endpoint-DNS van het cluster naar het nieuwe control plane wijzen. Alles daarvoor is omkeerbaar; het platform zet nooit jouw DNS om. Ziet iets er niet goed uit, bevestig dan niet: een gestopte handover behoudt alle state aan beide kanten.

Self-hosted → gehost (adopt)

Adopt draagt het beheer van het control plane over aan kubehz: je houdt alleen workers op je Hetzner-account. Vandaag werkt adopt via recreation, en dat zeggen we gewoon:

• kubehz maakt een vers gehost control plane met een nieuwe identiteit (nieuwe CA, nieuwe sleutels). Op het platform is het een nieuw cluster.
• Je workloads verhuizen door ze opnieuw toe te passen (vanuit je GitOps-repo of manifests) op het nieuwe cluster. Dit is het moment waarop een declaratieve setup zich uitbetaalt.
• Persistente data verhuist niet automatisch. Herstel die uit je eigen back-ups of provision haar opnieuw. Een geautomatiseerde data mover is er nog niet, dus doen we niet alsof.
• Nodes sluiten vers aan: workers starten tegen het nieuwe control plane via worker pools; oude kubeconfigs en tokens gelden niet meer.

De assessment en het vertaalrapport draaien eerst, precies zoals bij eject; je weet dus van provider-gebonden storage, load balancers en CAPI-beheer voordat er iets wordt aangemaakt.

Waarom recreation? De beheerde control-plane-stack munt de identiteit van een cluster bij het aanmaken. Jouw bestaande identiteit daar betrouwbaar in krijgen vereist een stap “gepauzeerd aanmaken, dan seeden” die ontworpen en gepland is. Zodra die er is, behoudt adopt de identiteit zoals eject dat vandaag al doet. Tot die tijd betekent adopt: vers control plane, workloads opnieuw toegepast.

Geen lock-in, met of zonder migratie

Handover is de sterke vorm van de belofte, maar vast zat je toch al nooit:

• lok8s is open source en rolt je cluster uit op jouw Hetzner-account.
• De dashboard-integratie is opt-in en alleen uitgaand; kubehz houdt geen inkomende credentials tot je cluster.
• kubehz verwijderen van een self-hosted cluster is twee commando’s: lo kubehz deregister deregistreert het (het heeft KUBEHZ_TOKEN nodig), en het verwijderen van de kubehz-system-namespace verwijdert de in-cluster agent. De clusterbrede RBAC van de agent (zijn ClusterRole en ClusterRoleBinding, plus een Role in kube-system) overleeft de namespace; verwijder die objecten ook als je een schoon cluster wilt. Je cluster blijft precies zoals voorheen draaien.

Volgende stappen

• Hoe handover werkt: identiteit vs. infrastructuur, en waarom het proces op jou wacht
• Gehost control plane: het gehoste pad
• Worker pools: waar je workers leven in gehoste modus
• KubeOne op Hetzner: het self-hosted doel waar de meeste ejects landen

---

Documentstatus

Aspect	Detail
Status	eject live (restore-gebaseerd); adopt live als recreation; identiteitsbehoudende adopt gepland
Laatst gecontroleerd	2026-09-05