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 |