Aggiornamenti gestiti
Tier gestito attivo, gli aggiornamenti in un clic sono in rollout
Gli aggiornamenti gestiti di Kubernetes fanno parte del tier gestito (access: managed), che è attivo e richiede un abbonamento Supporter o superiore. Gli account Enterprise lo includono, così come ogni control plane hosted. Il tier aggiunge le funzionalità di gestione di kubehz sopra registered: politiche di self-healing, monitoraggio della capacità e gestione dello stato desiderato guidate dalla dashboard. Le funzionalità che agiscono vengono rilasciate deliberatamente dietro interruttori per-funzionalità, quindi una funzionalità può essere visibile nella dashboard prima che la sua metà attiva sia abilitata per un deployment. Il flusso di aggiornamento con un click è in graduale rilascio.
Ti serve aggiornare oggi un cluster hosted? Dillo a noi e lo facciamo: in #support su chat.kubehz.cloud o via e-mail a contact@kubehz.io indicando cluster e versione desiderata. Il flusso in un clic lo sostituisce quando l’interruttore è attivo per il tuo ambiente.
Vuoi aggiornare un cluster self-hosted da solo? Funziona come sempre con il provisioner lok8s (KubeOne/CAPI): aumenta la versione nel tuo spec e riesegui il provisioner. È un’operazione lok8s sul tuo cluster, indipendente da kubehz. Vedi la documentazione lok8s.
Il modello
Il tier gestito è l’asse access: managed del modello a due assi. Su un cluster per cui lo hai attivato, le funzionalità di gestione di kubehz vengono guidate dalla dashboard: politiche di self-healing, monitoraggio della capacità e gestione dello stato desiderato. I flussi di aggiornamento e di scaling passano per quel canale dello stato desiderato. Per un aggiornamento, kubehz registra la versione Kubernetes desiderata. Dove l’interruttore di upgrade è attivo, l’agent del tuo cluster porta i worker verso quella versione:
- La versione viene controllata prima di essere registrata. Nessun downgrade, nessun target a fine vita e nessun salto di una versione minore.
- Il control plane va per primo, e su un cluster self-hosted quella parte è tua. Lo aggiorni con il tuo provisioner (
lo provision/kubeone apply). L’agent poi si rifiuta di muovere i worker finché la versione osservata del control plane è ancora indietro rispetto al target, o finché non riesce proprio a leggerla. Il control plane non lo tocca mai. (Su un control plane hosted è nostro; vedi la nota in cima a questa pagina per come funzionano oggi quegli aggiornamenti.) - Poi un pool di worker alla volta. L’agent imposta la versione kubelet di destinazione sul MachineDeployment di un pool e aspetta che quel giro finisca prima di iniziare il successivo. I worker non superano mai il control plane.
- Il lavoro sui nodi lo fa il tuo machine-controller. kubehz cambia un campo su una risorsa. Da lì il machine-controller del tuo cluster sostituisce le macchine: drena ogni nodo e crea il server sostitutivo nel tuo account Hetzner, con credenziali che kubehz non possiede mai.
- L’avanzamento è osservato, non presunto. Ogni pool riporta
v1.34.3 → v1.35.1 (2/5), letto dagli oggetti Machine nel tuo cluster.
Cosa un aggiornamento non fa
Vale la pena dirlo chiaramente, perché le offerte gestite spesso lasciano intendere il contrario:
- Nessun rollback automatico. Se un pool non riesce a completare il giro, l’aggiornamento si ferma: quel pool viene riportato come fallito, i pool successivi restano in coda e l’agent riprova al poll seguente. Nulla viene ripristinato per te: un nodo sostituito è sostituito. La mossa successiva la decidi tu (e ti aiutiamo se ce lo chiedi).
- Nessuna scansione delle API rimosse. kubehz non legge i tuoi workload, quindi non può avvisarti che qualcosa chiama ancora un’API che la release di destinazione elimina. Quel controllo fallo tu prima dell’aggiornamento.
- Nessun gate su etcd o sulla prontezza dei nodi. Il confronto di versione del control plane descritto sopra è l’unico controllo preliminare.
- Nessun SSH e nessun accesso ai nodi. L’agent applica patch a oggetti Kubernetes nel tuo cluster e nient’altro: non detiene credenziali cloud, né chiavi SSH, né alcuna tua kubeconfig.
Il meccanismo — pull, non push
L’azione è pull-based. L’agent nel cluster recupera lo stato desiderato dalla piattaforma (GET /clusters/{id}/desired) e lo applica localmente con le credenziali proprie del cluster. La piattaforma non detiene mai una credenziale in ingresso e non fa mai push dentro il tuo cluster.
Per un cluster gestito self-hosted questo significa che kubehz non ha bisogno di alcun token Hetzner: kubehz registra lo stato desiderato e il machine-controller del tuo cluster fa il lavoro con le credenziali che già possiede.
Interruttori di esecuzione per-funzionalità controllano la metà attiva di ogni funzionalità gestita, così le funzionalità che agiscono vengono rilasciate deliberatamente: prima la visibilità, poi l’azione quando l’interruttore è abilitato per un deployment.
Cosa è attivo oggi
- ATTIVO Report della versione (quale versione esegue ogni cluster registrato), tramite l’agent heartbeat; puoi vederlo nella dashboard.
- ATTIVO Il tier gestito stesso (Supporter+): politiche di self-healing, monitoraggio della capacità e gestione dello stato desiderato dalla dashboard.
- IN ROLLOUT Il flusso di aggiornamento con un click guidato da kubehz, dietro gli interruttori di esecuzione per-funzionalità descritti sopra.
Il gate è un abbonamento, non un cambiamento nella registrazione: un cluster managed viene registrato e rivendicato esattamente come uno registered. Il gate del tier si applica quando un tenant usa le funzionalità di gestione: la piattaforma rifiuta il passaggio a managed di un tenant gratuito.
Prossimi passi
- Come funziona: il tier gestito e il confine di fiducia
- Registrazione: ottieni oggi la visibilità di versione e salute
- Prezzi: il tier Supporter che sblocca le funzionalità di gestione
Stato del documento
| Aspetto | Dettaglio |
|---|---|
| Stato | Report della versione e il tier gestito attivi; aggiornamenti con un click guidati da kubehz in rollout |
| Ultima revisione | 2026-07-17 |