Come funziona

kubehz nasce attorno a una sola domanda: quanto vuoi delegare e cosa sei disposto a condividere per ottenerlo? Due assi indipendenti rispondono a questa domanda — e un confine netto sulla privacy rende sicura la risposta.

Due assi

Li scegli separatamente in cluster.lok8s.yaml sotto spec.kubehz:

spec:
  kubehz:
    hosting: self          # self | hosted
    access: registered     # none | registered | managed
    apiUrl: https://api.kubehz.cloud

Hosting — chi gestisce il control plane

Valore	Significato	Stato
self	Esegui il provisioning e possiedi il control plane sul tuo account Hetzner. Il normale flusso lok8s.	Disponibile
hosted	kubehz gestisce il control plane (etcd, apiserver, scheduler) sulla propria infrastruttura; tu esegui solo i worker.	Early access

Access — quanto kubehz vede e fa

Valore	kubehz vede	kubehz fa	Stato
none	Niente — nessun contatto con la piattaforma.	Niente.	Disponibile
registered	Salute in sola lettura: versione Kubernetes, nodi e stato, salute dei componenti del control plane, scadenza dei certificati.	La mostra nella dashboard.	Disponibile
managed	Dati di gestione per politiche di self-healing, monitoraggio della capacità, stato desiderato.	Registra lo stato desiderato; il tuo cluster lo recupera e lo applica.	Disponibile (Supporter+)

La combinazione di tutti i giorni è hosting: self + access: registered: il tuo cluster sul tuo account, kubehz come dashboard in sola lettura. access: managed è attivo sopra di essa — aggiunge le funzionalità di gestione di kubehz (politiche di self-healing, monitoraggio della capacità, gestione dello stato desiderato guidate dalla dashboard) e richiede un abbonamento Supporter o superiore. Un cluster managed viene registrato e rivendicato esattamente come uno registered; il gate dell'abbonamento si applica quando usi le funzionalità di gestione.

Il confine di fiducia — chi ha bisogno del tuo token Hetzner

Questa è la parte che conta, quindi vale la pena dirla con precisione:

• registered (self-hosted): nessun token Hetzner. kubehz ottiene solo la salute in sola lettura e nient'altro. Non può modificare nulla sul tuo account o nel tuo cluster.
• managed sul tuo cluster self-hosted: token opzionale. kubehz registra lo stato desiderato (es. "aggiorna a v1.35"); l'agent nel cluster lo recupera dalla piattaforma e lo applica localmente con le credenziali che il tuo cluster già possiede — kubehz non fa mai push verso l'interno e non detiene alcuna credenziale in ingresso. kubehz non ha bisogno di alcun token per il core self-heal / scale / upgrade. Un token Hetzner serve solo a mostrarti i prezzi specifici del tuo account — mai per far girare il cluster.
• Control plane hosted: token richiesto. Qui stai davvero delegando — kubehz esegue il provisioning dell'infrastruttura per te, quindi ha bisogno dell'accesso per farlo.

registered e managed sono disponibili oggi e hosted è in early access; il confine managed descritto sopra è esattamente come quel tier funziona — pull-based e solo in uscita. L'escalation è deliberata: non concedi mai più di quanto richiede ciò che hai chiesto.

I tuoi dati — una promessa netta (self-hosted)

Per i cluster self-hosted questa è una garanzia, non una gentilezza:

• Solo i dati di cui ha bisogno la funzionalità che hai attivato lasciano il tuo cluster. registered invia la salute; managed invia dati di gestione. Questa è l'intera lista.
• Nessuna telemetria. Nessuna analisi. Nient'altro. Non raccogliamo dati di utilizzo, contenuti dei workload, segreti, log o metriche a cui non hai aderito.
• Solo in uscita. L'agent heartbeat nel cluster invia uno snapshot di stato secondo una pianificazione. kubehz non si connette mai dentro il tuo cluster e non detiene alcuna credenziale in ingresso verso di esso.
• Disattivare è un solo passo. lo kubehz deregister più l'eliminazione del namespace kubehz-system rimuove tutto; il tuo cluster continua a funzionare.

Poiché l'agent invia solo ciò di cui una funzionalità ha bisogno, disattivare una funzionalità disattiva i suoi dati.

Proprietà — registrazione e claim

Un cluster diventa tuo sulla piattaforma in due mosse concettuali:

1. Registrazione — il provisioning annuncia il cluster a kubehz (oppure esegui lo kubehz register). Compare come in attesa (pending).
2. Claim — nella dashboard rivendichi il cluster in attesa per dimostrare la proprietà e collegarlo al tuo account. Una volta rivendicato, è di tua proprietà.

Questo è l'intero modello: register → claim → owned. (L'esatto handshake di claim è in fase di revisione, quindi qui lo manteniamo a questo livello.)

Principi

• Open source prima di tutto. lok8s, la CLI che esegue il provisioning di tutto, è open source e funziona senza kubehz. Non sei mai vincolato.
• Prezzi onesti. I prezzi derivano dai costi misurati sulla nostra flotta e spieghiamo i nostri prezzi.
• Sovranità dei dati UE. Infrastruttura in Germania; nessuna dipendenza da cloud statunitensi.

Prossimi passi

• Registrazione — attiva oggi la visibilità in sola lettura
• Dashboard e account — cosa ottieni una volta rivendicato
• Control plane hosted — il percorso delegato (early access)