Add-on

Il tuo control plane hosted non ha piani. Imposti la sua forma (da 1 a 3 API server, un limite di stato) e aggiungi degli add-on sopra.

Questa pagina è il complemento pratico a Prezzi. Per ogni add-on ti dice cosa ottieni, come usarlo e, dove applicabile, quale comando puoi incollare. Il riferimento API descrive ogni route API che questa pagina nomina.

Scegli gli add-on nella dashboard: nel wizard di creazione e, in seguito, in Impostazioni → Dimensionamento del cluster. La card Add-on nella pagina del cluster mostra solo cosa è installato.

L’operatore kubehz traduce la tua scelta nelle impostazioni Kubermatic (KKP) corrispondenti sul tuo control plane. Non modifichi mai KKP direttamente.

Le app non sono add-on

Gli add-on sono opzioni del control plane. Il software che gira nel tuo cluster arriva dal catalogo app nella scheda Applicazioni del cluster.

Scegli un’app e una versione, passa facoltativamente dei valori Helm e l’operatore la installa (GET /api/catalog/apps, PUT /api/clusters/{id}/apps/{name}). Oggi il catalogo contiene cert-manager. Altre app seguiranno dopo la nostra revisione.

Inclusi, non add-on

Due cose che ci si aspetta come add-on non sono add-on, perché ogni control plane hosted le ha:

• Backup di etcd: ogni control plane hosted include gli snapshot pianificati, attivi di default. I dettagli sono qui sotto in Backup di etcd.
• Alta disponibilità: l’HA è il numero di API server che imposti (3 API server), non una voce separata. Impostane tre e hai l’HA.

Add-on in breve: ogni add-on qui sotto è 0 € fino al 1 dicembre 2026. La tabella mostra i prezzi di listino che partono dopo quella data, IVA esclusa. I consumatori pagano l’IVA in aggiunta: il 22% in Slovenia o l’aliquota del proprio Paese. La pagina Prezzi mostra i prezzi con IVA inclusa.

0 € fino al 1 dicembre 2026

Add-on	Prezzo dal 1° dicembre 2026	Tetto mensile	Richiede
Dashboard web del cluster (Headlamp)	0,001 €/ora	0,73 €/mese	qualsiasi forma
OPA / Gatekeeper	gratuito	gratuito	qualsiasi forma
Backup di etcd	incluso	incluso	ogni control plane
Registro di audit	0,001 €/ora	0,73 €/mese	qualsiasi forma
Monitoraggio	0,010 €/ora	7,30 €/mese	qualsiasi forma
Logging	0,008 €/ora	5,84 €/mese	3 API server
Nodi dedicati	0,018 €/ora	13,14 €/mese	3 API server

Come funziona il contatore. kubehz fattura per intero ogni ora iniziata. La fatturazione parte quando crei la risorsa. kubehz fattura la risorsa finché esiste, in qualunque stato. Solo l’eliminazione ferma il costo.

Gli importi orari di una unità non superano mai il suo prezzo mensile. La cifra €/mese è la tariffa oraria moltiplicata per 730 ore, ed è un massimo, anche in un mese di 31 giorni.

kubehz fattura gli add-on a parte. Se un add-on resta dopo che hai eliminato qualcos’altro, kubehz lo fattura finché non elimini anche l’add-on. Vedi Prezzi.

Un prezzo non è in questa lista, perché non è un add-on. Un nodo statico (un nodo worker che porti tu) costa 0,001 €/ora per nodo, al massimo 0,73 €/mese IVA esclusa. kubehz lo fattura per ogni ora in cui risulta Ready.

Un nodo NotReady è l’unica eccezione alle regole sopra: kubehz non lo fattura mai. Vedi Nodi statici.

Dashboard web del cluster (Headlamp)

Cosa abilita. Una dashboard web Headlamp gestita per il tuo cluster. kubehz la esegue accanto al tuo control plane e la pubblica su un URL pubblico immediato:

https://dash-<cluster-id>.kubehz.cloud

Aprila dalla pagina di dettaglio del cluster nella dashboard kubehz (pulsante Apri la dashboard). Accedi con il tuo account kubehz (lo stesso login SSO della piattaforma).

Ciò che puoi vedere e fare segue la tua RBAC Kubernetes. Headlamp inoltra il tuo token di identità all’API server e non detiene credenziali admin proprie. Niente kubeconfig, niente proxy, nessuna seconda password.

Costa 0,001 €/ora, al massimo 0,73 €/mese IVA esclusa, su ogni forma. Puoi deselezionarla nel wizard e in Impostazioni → Dimensionamento. Il wizard di creazione non preseleziona alcun add-on: questa la spunti tu.

A luglio 2026 Headlamp ha sostituito la kubernetes-dashboard upstream deprecata dietro questo add-on: stessa opzione, stesso prezzo, un percorso di accesso migliore.

Preferisci un’app locale? Headlamp desktop apre lo stesso cluster con il kubeconfig scaricato, senza add-on. È anche il modo per avere una dashboard sui cluster self-hosted.

Fallback: kubectl proxy. Se il tuo cluster esegue ancora la vecchia kubernetes-dashboard in-cluster, puoi ancora raggiungerla tramite il proxy dei servizi dell’API server. Il proxy si autentica con il tuo kubeconfig:

1. Scarica il kubeconfig del cluster dalla dashboard kubehz (pagina di dettaglio del cluster).

2. Avvia un proxy locale verso l’API server:

   kubectl --kubeconfig ./kubeconfig proxy

3. Apri l’URL del proxy di servizio della dashboard nel browser:

   http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Il proxy eredita il tuo kubeconfig. La dashboard vede esattamente ciò che vedresti con kubectl, niente di più.

OPA / Gatekeeper

Cosa abilita. L’applicazione delle policy di OPA Gatekeeper nel tuo cluster. Gatekeeper valida le risorse in fase di admission rispetto a policy che scrivi come oggetti ConstraintTemplate + Constraint.

È gratuito e disponibile su qualsiasi forma. L’operatore mappa questo add-on su opaIntegration.enabled di KKP. I componenti Gatekeeper girano dentro il tuo cluster.

Come usarlo. Quando l’add-on è attivo, applica un ConstraintTemplate (definisce una regola riutilizzabile) e poi un Constraint (applica la regola a kind specifici). Il classico per iniziare è “ogni namespace deve avere una label owner”:

Mostra lo YAML completo di ConstraintTemplate + Constraint

# 1. Il template: una regola "required labels" riutilizzabile.
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }
---
# 2. Il constraint: richiedi una label `owner` su ogni Namespace.
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-owner
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["owner"]

Salva entrambi i documenti come required-labels.yaml, poi applicali:

kubectl apply -f required-labels.yaml

Come appare l’enforcement. Dopodiché il webhook di admission rifiuta un namespace senza label owner:

$ kubectl create namespace demo
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied
the request: [ns-must-have-owner] you must provide labels: {"owner"}

Crea invece il namespace direttamente con la label, e Gatekeeper lo ammette:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
  labels:
    owner: platform-team  # qualsiasi valore — la policy richiede solo la chiave
EOF

Backup di etcd

Cosa abilita. Snapshot pianificati dell’etcd del tuo control plane, il datastore dietro ogni oggetto del tuo cluster (Deployment, Secret, CRD, tutto).

Ogni control plane hosted li include, attivi di default. Non c’è niente da comprare o attivare. L’operatore fornisce un EtcdBackupConfig di KKP per il tuo cluster.

Pianificazione e conservazione. I backup girano ogni 6 ore (cron 0 */6 * * *). kubehz conserva gli ultimi 20 snapshot ed elimina automaticamente quelli più vecchi. Scrive gli snapshot su storage a oggetti gestito da kubehz nell’UE. Non gestisci alcun bucket.

Snapshot una tantum e ripristino. Accanto alla pianificazione puoi fare uno snapshot tu stesso, prima di una modifica rischiosa, e ripristinare da qualsiasi snapshot che possiedi. Entrambi sono self-service: usa la sezione Backup della pagina del cluster, oppure l’API.

Nell’API, POST /api/clusters/{id}/snapshots con un name crea uno snapshot, GET li elenca, DELETE .../snapshots/{name} ne elimina uno e l’azione di ripristino su uno snapshot lo ripristina.

Un ripristino è un EtcdRestore di KKP sul tuo control plane. L’API server non è disponibile per i minuti che servono al ripristino, e ogni oggetto modificato dopo lo snapshot va perso. Se vuoi un secondo parere, chiedi in chat prima di premere il pulsante.

Registro di audit

Cosa abilita. L’audit logging dell’API di Kubernetes sul tuo control plane: un registro di chi ha fatto cosa contro l’API server (richieste, soggetti, verbi, risorse).

Costa 0,001 €/ora, al massimo 0,73 €/mese IVA esclusa, su qualsiasi forma. L’operatore mappa questo add-on su auditLogging di KKP con un preset di policy fisso.

Quale preset si applica. kubehz abilita il preset di policy di audit recommended. Questo livello bilanciato cattura le operazioni rilevanti per la sicurezza senza il volume di un flusso completo di richieste/risposte. Non puoi cambiare il preset: non esiste un editor di policy per cluster.

Dove vanno gli eventi. L’API server sul tuo control plane emette gli eventi di audit. Scegli una consegna per loro nella pagina del cluster, o con PUT /api/clusters/{id}/audit-delivery:

• webhook invia ogni batch a un tuo endpoint HTTPS (con un bundle CA facoltativo).
• s3 li scrive in un bucket compatibile S3 di tua proprietà (endpoint, bucket, prefisso, chiave di accesso).
• none li tiene solo sul control plane.

Per sfogliarli e cercarli, abbina questo add-on a Logging. Logging ti dà un posto dove leggerli su larga scala.

Monitoraggio

Cosa abilita. Metriche per cluster: kubehz le raccoglie dal tuo cluster e le invia alla piattaforma kubehz. Costa 0,010 €/ora, al massimo 7,30 €/mese IVA esclusa, su qualsiasi forma.

Lo attivi nella dashboard kubehz: tra le opzioni add-on del wizard quando crei il cluster, o in seguito in Impostazioni → Dimensionamento del cluster. Un Prometheus gira nel tuo cluster e alimenta la piattaforma. Non lo esegui né lo scali tu.

Cosa copre il costo. Il lato piattaforma: storage delle metriche multi-tenant con 15 giorni di conservazione, il percorso di query della dashboard e l’alerting. kubehz gestisce e opera tutto questo.

Dal tuo lato gira un agent di monitoraggio sui tuoi worker: 2 repliche che insieme richiedono 220m di CPU e 532 MiB di memoria (vedi Capacità dei worker). Il costo paga il nostro backend e il nostro storage, non il tuo compute.

Cosa raccoglie kubehz. Salute di cluster e nodi, e uso delle risorse di control plane e workload (i segnali standard Kubernetes/cAdvisor/kube-state). Ottieni metriche di CPU, memoria, pod e nodi nel tempo senza un Prometheus tuo.

Dove vederlo. Le metriche compaiono nella sezione Monitoraggio della pagina del cluster nella dashboard kubehz.

Alerting. La stessa sezione contiene le tue regole di alert e i tuoi destinatari:

• Un gruppo di regole è un file di regole Prometheus per metrics o logs (PUT /api/clusters/{id}/monitoring/rules/{name} con lo YAML in data).
• Un destinatario è un URL webhook o un indirizzo email (PUT .../monitoring/receivers/{name}).

Iscrivi il tuo account alle mail di alert del cluster con l’interruttore nella stessa pagina, o con POST /api/clusters/{id}/alerts/subscription.

Logging

Cosa abilita. Aggregazione dei log per cluster, basata su Loki, tramite lo stesso stack di piattaforma. Costa 0,008 €/ora, al massimo 5,84 €/mese IVA esclusa, e richiede la forma con tre API server.

Come il monitoraggio, lo attivi nella dashboard kubehz: tra le opzioni add-on del wizard quando crei il cluster, o in seguito in Impostazioni → Dimensionamento del cluster. Un collector in stile promtail gira nel tuo cluster e invia i log dei pod al Loki della piattaforma. Loki non lo esegui tu.

Cosa copre il costo. L’ingest lato piattaforma, i 7 giorni di archiviazione dei log e il percorso di query dietro il browser dei log della dashboard. kubehz gestisce e opera tutto questo.

Il collector sui tuoi nodi è tuo: su ogni nodo worker richiede 60m di CPU e 74 MiB di memoria. Il costo paga il nostro backend e il nostro storage.

Conservazione. L’add-on include 7 giorni di conservazione dei log: puoi interrogare i log dell’ultima settimana, e i dati più vecchi scadono.

Dove vederlo. I log compaiono nella dashboard kubehz accanto al monitoraggio. Il rilascio del browser dei log nella dashboard è in corso. Oggi l’add-on ti dà la raccolta e la conservazione di 7 giorni.

Logging è anche il compagno naturale del Registro di audit: ti dà un posto dove leggere gli eventi di audit.

Nodi dedicati

Cosa abilita. Colloca il tuo control plane su capacità bare-metal dedicata nella flotta kubehz invece che su VM cloud condivise. Il control plane ottiene prestazioni più stabili e isolate.

Costa 0,018 €/ora, al massimo 13,14 €/mese IVA esclusa, e richiede la forma con tre API server. L’operatore sposta il tuo control plane su nodi di classe metal (un cambio di posizionamento, non un ridimensionamento).

Migrazione live al toggle. Dedicato è reversibile. Quando lo attivi (o disattivi), l’operatore avvia una migrazione live del control plane sul pool metal (o fuori da esso). L’operatore sposta il carico: non ricostruisci il cluster.

Gating di capacità (la parte onesta). Il bare metal è un pool scarso, e lo limitiamo di proposito. Per questo il dedicato è soggetto a gating di capacità al momento del provisioning. Se il pool metal è al suo minimo, potresti non poter ordinare l’opzione per un po’, anche su un cluster con tre API server.

È intenzionale: aggiungiamo metal quando la domanda lo giustifica. L’opzione richiede la forma con tre API server, così i cluster usa-e-getta non consumano la capacità scarsa. Se l’opzione non è disponibile quando ci provi, si riapre quando aggiungiamo capacità.

Capacità dei worker

Alcuni add-on eseguono pod sui tuoi worker hosted, e quei pod richiedono CPU e memoria. Prima di attivare un add-on di questo tipo, kubehz controlla che i pool di worker possano ospitare i pod di sistema e tutti gli add-on che hai scelto. Il controllo conta queste richieste (requests):

Sui tuoi worker	CPU	Memoria	Conteggio
Pod di sistema su ogni nodo	175m	114 MiB	per nodo worker
Pod di sistema per il cluster	320m	484 MiB	una volta per cluster
Monitoraggio (2 repliche dell’agent)	220m	532 MiB	una volta per cluster
Logging (collector)	60m	74 MiB	per nodo worker
OPA / Gatekeeper	200m	1024 MiB	una volta per cluster
cert-manager (catalogo app)	60m	160 MiB	una volta per cluster

La dashboard web del cluster, il registro di audit, i backup di etcd e i nodi dedicati girano accanto al control plane. Sui tuoi worker non richiedono nulla.

La regola. I pool devono offrire almeno 1,5 volte la somma di queste richieste, per la CPU e per la memoria. Il margine del 50% copre l’uso oltre le richieste, il pod in più durante un rolling update e l’errore della stima.

kubehz stima quanto offre un nodo dal suo tipo di server: vCPU × 1000m meno 400m di CPU, e il 93% della sua memoria meno 500 MiB. Un pool con autoscaling conta con il suo numero minimo di nodi.

Esempio. Un worker con 2 vCPU e 4 GB (cpx22 o cax11) offre 1600m di CPU e 3309 MiB. I pod di sistema più il monitoraggio richiedono (175 + 320 + 220) × 1,5 = 1073m di CPU e (114 + 484 + 532) × 1,5 = 1695 MiB. Un solo worker di questo tipo basta.

Quando kubehz controlla. Quando crei un cluster con worker e add-on, aggiungi un add-on, installi un’app del catalogo o dai i primi worker a un cluster che non ne ha. Su un cluster che ha già worker, questo controllo non rifiuta mai una modifica a un pool (riduzione, nuovo tipo, rimozione).

kubehz non valuta i pool statici (non ne conosce la dimensione). Lascia passare la modifica anche quando il catalogo Hetzner non è disponibile.

Quando non basta. kubehz rifiuta la modifica con ADDON_NEEDS_CAPACITY. Il testo di aiuto indica cosa richiedono gli add-on e i pod di sistema, cosa offrono i pool e un pool di esempio sufficiente (per esempio 2 × cax11).

Scegli un tipo di server più grande, aggiungi worker o rimuovi un add-on. Ogni worker hosted richiede inoltre almeno 2 vCPU: vedi Tipi di server.

Prossimi passi

• Prezzi: il listino completo degli add-on.
• Control plane hosted: la forma e il percorso hosted nel complesso.
• Pool di worker: pool, scaling e autoscaling sul tuo cluster.
• Dashboard e account: dove attivi gli add-on e scarichi il kubeconfig.

---

Stato del documento

Aspetto	Dettaglio
Stato	add-on attivi, con snapshot, ripristino, consegna audit e alerting self-service. Browser dei log nella dashboard: rilascio in corso
Ultima revisione	2026-10-30