Aggiornamenti gestiti
Parte del tier gestito — attivo oggi
Gli aggiornamenti gestiti di Kubernetes fanno parte del tier gestito (access: managed), che è attivo e richiede un abbonamento Supporter o superiore (i tenant hosted ed enterprise lo hanno incluso). 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.
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 e il tuo cluster (o un control plane hosted) lo esegue:
- prima il control plane, poi i worker cordonati/drenati/aggiornati uno alla volta,
- regole di version-skew applicate (nessun salto di versioni minori),
- controlli preliminari per API rimosse, prontezza dei nodi e salute di etcd,
- rollback automatico se un aggiornamento fallisce a metà.
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
- Report della versione (quale versione esegue ogni cluster registrato) — attivo tramite l'agent heartbeat; puoi vederlo nella dashboard.
- Il tier gestito stesso — attivo (Supporter+): politiche di self-healing, monitoraggio della capacità e gestione dello stato desiderato dalla dashboard.
- Il flusso di aggiornamento con un click guidato da kubehz — in graduale rilascio 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
Stato del documento
| Aspetto | Dettaglio |
|---|---|
| Stato | attivo |
| Ultima revisione | 2026-07-17 |