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 vi aggiungi degli add-on. Questa pagina è il complemento pratico a Prezzi: cosa ti dà davvero ogni add-on, come consumarlo e, dove applicabile, un comando da incollare.

Scegli gli add-on nella dashboard: nel wizard di creazione e, in seguito, in Impostazioni → Piano 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 man mano che vengono revisionate.

Incluso vs. add-on

Due cose che ci si aspetta come add-on non lo sono, perché sono integrate:

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

Add-on in breve: ogni add-on qui sotto è 0 € fino al 1 novembre 2026. Questi sono i prezzi di listino che partono dopo quella data (vedi Prezzi):

0 € fino al 1 novembre 2026

Add-on	Prezzo dal 1° novembre 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. I componenti aggiuntivi si fatturano a parte. Un componente che sopravvive a un’eliminazione viene fatturato finché non elimini anche quello. Vedi Prezzi.

Un prezzo sta fuori da 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, fatturato 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, eseguita da kubehz accanto al tuo control plane e pubblicata 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), e 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, su ogni forma, e puoi deselezionarla ovunque. Il wizard di creazione non preseleziona alcun add-on; questa la spunti tu. Headlamp ha sostituito la kubernetes-dashboard upstream deprecata dietro questo add-on (2026-07): stessa opzione, stesso prezzo, un percorso di accesso decisamente migliore.

Preferisci un’app locale? Headlamp desktop apre lo stesso cluster con il kubeconfig scaricato, senza alcun add-on richiesto. Ed è anche la via alla dashboard per i cluster self-hosted.

Fallback: kubectl proxy. Un cluster che esegue ancora la vecchia kubernetes-dashboard in-cluster resta raggiungibile tramite il proxy dei servizi dell’API server, autenticato 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, quindi 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: validazione delle risorse in fase di admission rispetto a policy che scrivi come oggetti ConstraintTemplate + Constraint. È gratuito e disponibile dal qualsiasi forma. L’operatore lo mappa su opaIntegration.enabled di KKP; i componenti Gatekeeper girano dentro il tuo cluster.

Come consumarlo. Quando l’add-on è attivo, applica un ConstraintTemplate (definisce una regola riutilizzabile) e poi un Constraint (la applica 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é un namespace senza label owner viene rifiutato in fase di admission:

$ 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 verrà ammesso:

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). È incluso in ogni control plane hosted, attivo 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 * * *) e vengono conservati gli ultimi 20 snapshot; i più vecchi vengono eliminati automaticamente. Gli snapshot sono scritti 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: la sezione Backup della pagina del cluster, oppure l’API (POST /api/clusters/{id}/snapshots con un name, GET per elencarli, DELETE .../snapshots/{name} per eliminarne uno e l’azione di ripristino su uno snapshot). Un ripristino è un EtcdRestore di KKP sul tuo control plane: l’API server non è disponibile per i minuti che servono, e ogni oggetto modificato dopo lo snapshot va perso. Se preferisci 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). 0,001 €/ora, al massimo 0,73 €/mese, su qualsiasi forma. L’operatore lo mappa su auditLogging di KKP con un preset di policy fisso.

Quale preset viene applicato. kubehz abilita il preset di policy di audit recommended, un livello bilanciato che cattura le operazioni rilevanti per la sicurezza senza il volume di un flusso completo richiesta/risposta. (Il preset è fisso; non c’è un editor di policy per cluster.)

Dove vanno gli eventi. Gli eventi di audit sono emessi dall’API server sul tuo control plane. 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, access key), none li tiene solo sul control plane. Per sfogliarli e cercarli, abbina l’add-on a Logging, che ti dà un posto per leggerli su larga scala.

Monitoraggio

Cosa abilita. Metriche per cluster raccolte dal tuo cluster e inviate alla piattaforma kubehz. 0,010 €/ora, al massimo 7,30 €/mese, su qualsiasi forma. Lo attivi nella dashboard kubehz: alla creazione tra le opzioni add-on del wizard, o in seguito in Impostazioni → Piano 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. Tutto gestito e operato da kubehz. Dal tuo lato gira solo un collector leggero sui tuoi worker; il costo paga il nostro backend e il nostro storage, non il tuo compute.

Cosa viene raccolto. Salute di cluster e nodi, uso delle risorse di control plane e workload (i segnali standard Kubernetes/cAdvisor/kube-state), così ottieni metriche di CPU, memoria, pod e nodi nel tempo senza tirare su un tuo Prometheus.

Dove vederle. Le metriche appaiono nella sezione Monitoraggio della dashboard kubehz, nella pagina del cluster.

Alerting. La stessa sezione contiene le tue regole di alert e i receiver. 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 receiver è un URL webhook o un indirizzo email (PUT .../monitoring/receivers/{name}). Iscrivi il tuo account alle mail di alert del cluster con POST /api/clusters/{id}/alerts/subscription, o con l’interruttore nella stessa pagina.

Logging

Cosa abilita. Aggregazione dei log per cluster, basata su Loki, tramite lo stesso stack di piattaforma. 0,008 €/ora, al massimo 5,84 €/mese; richiede la forma con tre API server. Come il monitoraggio, la attivi nella dashboard kubehz: alla creazione tra le opzioni add-on del wizard, o in seguito in Impostazioni → Piano 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. Tutto gestito e operato da kubehz. Il collector sui tuoi nodi è tuo e marginale; il costo paga il nostro backend e il nostro storage.

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

Dove vederli. I log appaiono nella dashboard kubehz accanto al monitoraggio. Come la vista di monitoraggio, il browser dei log nella dashboard è in fase di rilascio; la raccolta e i 7 giorni di conservazione sono ciò che l’add-on fornisce oggi, ed è anche il compagno naturale del Registro di audit per leggere gli eventi di audit.

Nodi dedicati

Cosa abilita. Colloca il tuo control plane su bare-metal dedicato nella flotta kubehz invece che su VM cloud condivise: prestazioni più stabili e isolate per il control plane. 0,018 €/ora, al massimo 13,14 €/mese; richiede la forma con tre API server. L’operatore indirizza il tuo control plane su nodi di classe metal (un cambio di collocazione, non un ridimensionamento).

Migrazione live al toggle. Dedicato è reversibile: attivarlo (o disattivarlo) innesca una migrazione live del control plane sul (o dal) pool metal: l’operatore sposta il workload; non ricostruisci il cluster.

Gating di capacità (la parte onesta). Il bare metal è un pool scarso e volutamente limitato. Per questo il dedicato è soggetto a gating di capacità al momento del provisioning: se il pool metal è al suo minimo, l’opzione può essere temporaneamente non ordinabile anche su un cluster pro. È intenzionale (il metal viene aggiunto quando la domanda lo giustifica) e solo pro, così i cluster usa-e-getta non consumano la capacità scarsa. Se non è disponibile al tentativo, si aprirà man mano che viene aggiunta capacità.

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; snapshot, ripristino, consegna audit e alerting self-service; browser dei log nella dashboard in fase di rilascio
Ultima revisione	2026-09-05