Come funziona l’handover
L’handover sposta un cluster tra il control plane hosted di kubehz e un’infrastruttura di tua proprietà. È il meccanismo dietro la promessa di no-lock-in. Questa pagina spiega l’idea. La guida passo passo è in Migrazione: dentro e fuori.
Un cluster è la sua identità, non i suoi server
Smonta un cluster Kubernetes e solo poche cose lo rendono quel cluster:
- la certificate authority (CA) di cui si fidano ogni nodo e ogni kubeconfig,
- le chiavi di firma dei service account, che firmano ogni token dei workload,
- la chiave di cifratura, che protegge i Secret a riposo,
- e i dati: ogni oggetto API, in etcd.
I server su cui gira il control plane li puoi sostituire. L’identità non la puoi sostituire. Sposta identità e dati, e il cluster resta lo stesso cluster, ovunque giri il suo control plane. Tutto il trucco è qui: l’handover sposta l’identità, non le macchine.
Basato su restore, su fondamenta noiose
L’handover usa di proposito meccanismi collaudati, non ingegnosi:
- La piattaforma assembla un export bundle (l’identità di cui sopra) e crea uno snapshot di etcd fresco.
- Sulla tua macchina di destinazione il bundle semina l’identità prima che il nuovo control plane si inizializzi, e un restore carica lo snapshot.
- Il bootstrap standard di Kubernetes poi riusa l’identità seminata invece di coniarne una nuova.
Il risultato si avvia come il tuo cluster: stessa CA, stesse chiavi, stessi oggetti. I tuoi worker si fidano già di lui, quindi si riconnettono e proseguono. Non c’è alcun trasferimento live tra control plane e nessun protocollo di replicazione su misura: solo uno snapshot e un restore, e puoi verificare ogni passo.
Il cancello sei tu
L’handover di proposito non è del tutto automatico. Due momenti appartengono a te:
- Cutover: punti tu il DNS dell’endpoint del cluster al nuovo control plane, e la piattaforma attende la tua conferma esplicita. Fino ad allora non succede nulla di distruttivo.
- Decommission: la piattaforma rimuove il vecchio control plane solo dopo che la piattaforma vede vivo il nuovo (heartbeat) e tu confermi una seconda volta. Finché non valgono entrambe, il lato vecchio resta intatto come tua rete di sicurezza.
Se un handover si ferma a metà, si arresta e mantiene tutto lo stato su entrambi i lati. Nessun passaggio ti lascia senza un control plane funzionante.
Guarda prima che qualcosa si muova
Prima che un handover possa partire, l’assessment della piattaforma (una sonda in sola lettura del tuo cluster) riporta un percorso di fattibilità e un report di traduzione. Quel report è l’elenco onesto delle cose che non seguono un control plane attraverso i provider: storage class legate al provider, load balancer cloud, gestione Cluster API. Vedi il quadro completo per primo, da lo kubehz assess o dalla dashboard.
Il confine onesto di oggi
- Eject (hosted → la tua infrastruttura) preserva l’identità. È attivo oggi e funziona esattamente come descritto sopra.
- Adopt (il tuo cluster → hosted) oggi funziona come recreation: kubehz crea da zero il control plane hosted, con una nuova identità, e tu sposti i workload applicandoli di nuovo. Un adopt che preserva l’identità è nella roadmap. Finché non arriva, la documentazione dice “nuova identità” e non lascia intendere altro.
Prossimi passi
- Migrazione: dentro e fuori: la guida passo passo per entrambe le direzioni
- Come funziona: il modello hosting × access in cui l’handover si inserisce
- Control plane hosted: il percorso hosted stesso
Stato del documento
| Aspetto | Dettaglio |
|---|---|
| Stato | attivo: descrive il meccanismo di handover in produzione |
| Ultima revisione | 2026-10-30 |