Pool di worker (hosted)
Per un cluster hosted, kubehz gestisce il control plane ed esegue il provisioning dei tuoi pool di worker sul tuo account Hetzner, con il token API Hetzner che hai collegato. I server worker compaiono nel tuo progetto Hetzner come qualsiasi altro server: li paghi direttamente a Hetzner, ai prezzi di Hetzner; kubehz fattura solo il control plane. Sui worker non c’è alcun ricarico kubehz.
Gestisci i pool nella dashboard: alla creazione del cluster o in seguito nella pagina di dettaglio del cluster.
Self-hosted?
Su un cluster self-hosted, lok8s esegue il provisioning dei worker sul tuo account senza coinvolgere kubehz; vedi KubeOne su Hetzner.
Requisiti
- Un token API Hetzner collegato con permesso Read & Write. I pool di worker sono esattamente il passo di delega del confine di fiducia: kubehz crea server sul tuo account, quindi serve un token che possa farlo. Vedi Il token Hetzner.
- Un cluster hosted creato con il token già collegato. La modalità di provisioning è fissata alla creazione: un cluster hosted creato senza token collegato non può ottenere pool di worker in seguito. Collega un token e ricrea il cluster.
Tipi di server
Un worker hosted richiede almeno 2 vCPU. Su un tipo con 1 vCPU come cpx12, i pod di sistema che girano su ogni worker (rete, DNS, metriche) riempiono il nodo e non resta spazio per altro. kubehz rifiuta un tipo simile con MACHINE_TYPE_TOO_SMALL. Il testo di aiuto indica i tipi più piccoli che puoi usare nella regione del cluster. I pool statici (vedi sotto) non vengono controllati.
Il tipo deve anche essere disponibile nella regione del cluster. Se non lo è, kubehz risponde con MACHINE_TYPE_UNAVAILABLE ed elenca i tipi disponibili. La disponibilità di Hetzner cambia, quindi nessun tipo è sempre disponibile: usa qualsiasi tipo con 2 o più vCPU che il tuo account offre nella regione. Il 30 ottobre 2026, per esempio, i tipi più piccoli che l’account di kubehz vedeva in fsn1 erano cpx22 (x86) e cax11 (Arm), entrambi con 2 vCPU e 4 GB di RAM.
Anche gli add-on hanno bisogno di spazio sui worker. Prima di attivare monitoraggio, logging, OPA/Gatekeeper o un’app del catalogo, kubehz controlla che i pool possano ospitarli. Se non possono, kubehz risponde con ADDON_NEEDS_CAPACITY. Il testo di aiuto indica la capacità che serve agli add-on, quella che danno i pool e un pool sufficiente (per esempio 2 × cax11). Scegli un tipo più grande, aggiungi worker o rimuovi un add-on. I numeri sono in Capacità dei worker.
Cosa puoi fare
- Aggiungere e rimuovere pool: alla creazione del cluster o in qualsiasi momento dopo. Fino a 4 pool per cluster, ciascuno con 0–20 nodi.
- Scalare il numero di nodi di un pool, in su o in giù.
- Autoscalare un pool: imposta un minimo e un massimo invece di un numero fisso; il cluster-autoscaler adatta il pool al carico. Finché l’autoscaling è attivo, il numero di nodi appartiene all’autoscaler; lo scaling manuale viene rifiutato. Richiede l’addon cluster-autoscaler in esecuzione nel cluster; senza, i limiti non hanno effetto.
- Label e taint per pool, per indirizzare i workload sul pool giusto (i prefissi label riservati
kubernetes.io//k8s.io/non sono ammessi). - Cambiare il tipo di macchina di un pool. Sii consapevole di cosa significa: ogni nodo del pool viene sostituito, in modo progressivo con server nuovi, e i tuoi workload vengono rischedulati. La dashboard ti chiede di confermare esattamente questo prima di iniziare.
Cosa non puoi fare
- Regione per pool: ogni pool gira nella regione del cluster. Se ti serve un’altra regione, quello è un altro cluster.
- Dimensione del disco per pool: il disco segue il tipo di server Hetzner che scegli, come su qualsiasi server Hetzner.
Preferiamo elencarlo qui piuttosto che fartelo scoprire in un messaggio di errore.
Nodi statici
Un pool statico contiene nodi worker che porti tu: bare metal, un altro cloud o una VM che esiste già. kubehz non crea, non sostituisce e non ruota questi server. Il join lo fa la CLI per te, direttamente sulla macchina:
# sulla macchina che stai aggiungendo (richiede KUBEHZ_TOKEN)
lo kubehz node join --pool static
# dietro NAT, o con un nome scelto da te
lo kubehz node join --pool static --name edge-1 --node-ip 203.0.113.7
# mostra la riga kubeadm join senza eseguire nulla
lo kubehz node join --pool static --print-only--pool indica il pool statico (si può omettere se il cluster ne ha uno solo), --name per default è lo short hostname della macchina, --node-ip è l’indirizzo con cui la raggiungono gli altri nodi, --kubelet-version sovrascrive quello che la CLI legge dalla macchina e --cluster-id punta a un cluster diverso da quello del dominio attivo. lo kubehz node status elenca i nodi che hai portato; lo kubehz node remove --name <node> ne toglie uno e libera il suo slot.
Un nodo statico costa 0,001 €/ora per nodo, al massimo 0,73 € al mese, IVA esclusa. kubehz fattura per intero ogni ora iniziata, finché il nodo è registrato. Gli importi orari non superano mai 0,73 € in un mese, anche in un mese di 31 giorni, perché il prezzo mensile è un tetto. Un nodo NotReady è l’unica eccezione: kubehz non lo fattura mai, quindi un nodo morto non costa nulla. Rimuovi il nodo per fermare il costo.
Le stesse regole valgono per il control plane e per ogni componente aggiuntivo. Vedi Prezzi.
La regola di sopra resta valida: kubehz non aggiunge nulla al prezzo di un server che compri da Hetzner. Il prezzo del nodo statico copre il carico che ogni nodo in più mette sul tuo control plane hosted.
I pool statici si aprono account per account durante il rollout. Se il tuo cluster non offre l’opzione, chiedi in chat.
Prossimi passi
- Control plane hosted: il percorso hosted nel complesso
- Come funziona: il confine di fiducia e per cosa viene usato il tuo token
- Prezzi: cosa fattura kubehz e perché
Stato del documento
| Aspetto | Dettaglio |
|---|---|
| Stato | disponibile: cluster hosted con un token Hetzner collegato |
| Ultima revisione | 2026-10-30 |