Come funziona l’handover
L’handover è il modo in cui un cluster si sposta tra il control plane hosted di kubehz e l’infrastruttura di tua proprietà: il meccanismo dietro la promessa di no-lock-in. Questa pagina spiega l’idea; la guida passo passo è Migrazione — dentro e fuori.
Un cluster è la sua identità, non i suoi server
Riduci un cluster Kubernetes all’essenziale e ciò che lo rende quel cluster è sorprendentemente poco:
- la certificate authority (CA) di cui si fidano ogni nodo e ogni kubeconfig,
- le chiavi di firma dei service account con cui è firmato 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 sono sostituibili; l’identità no. Sposta identità e dati, e il cluster è 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 deliberatamente meccanismi collaudati invece che 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 viene seminato prima che il nuovo control plane si inizializzi, e lo snapshot viene ripristinato.
- Il bootstrap standard di Kubernetes 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; si riconnettono e proseguono. Nessun trasferimento live tra control plane, nessun protocollo di replicazione su misura: uno snapshot e un restore, verificabili a ogni passo.
Il cancello sei tu
L’handover è deliberatamente non del tutto automatico. Due momenti appartengono a te:
- Cutover: ripuntare il DNS dell’endpoint del cluster al nuovo control plane è un’azione tua, e la piattaforma attende la tua conferma esplicita. Fino ad allora non è successo nulla di distruttivo.
- Decommission: il vecchio control plane viene rimosso solo dopo che la piattaforma ha visto vivo il nuovo (heartbeat) e tu hai confermato una seconda volta. Finché non valgono entrambe, il lato vecchio resta intatto come tua rete di sicurezza.
Un handover che si ferma a metà semplicemente si arresta e mantiene tutto lo stato su entrambi i lati: non c’è alcun passaggio in cui resti senza un control plane funzionante.
Guarda prima che qualcosa si muova
Prima ancora 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: 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, esattamente come descritto sopra.
- Adopt (il tuo cluster → hosted) oggi funziona come recreation: il control plane hosted viene creato da zero, con una nuova identità, e i workload si spostano riapplicandoli. Un adopt che preserva l’identità è pianificato; finché non arriva, la documentazione dice “nuova identità” senza lasciar 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-07-29 |