Add-on

Il tuo control plane hosted parte da un piano (dev, starter, pro) su cui 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, nella pagina di dettaglio del cluster. L'operatore kubehz traduce la tua scelta nelle impostazioni Kubermatic (KKP) corrispondenti sul tuo control plane; non modifichi mai KKP direttamente.

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 piano a pagamento, attivi di default. Vedi Backup di etcd qui sotto per cosa significa.
Alta disponibilità — l'HA è il piano pro stesso (3× API server), non una voce separata. Scegli pro e ce l'hai.

Add-on in breve (prezzi di listino — vedi Prezzi):

Add-on	Prezzo	Piano minimo
Dashboard web del cluster (Headlamp)	0,50 €/mese	qualsiasi (attiva di default da starter)
OPA / Gatekeeper	gratuito	dev
Backup di etcd	incluso	ogni piano a pagamento
Registro di audit	0,50 €/mese	starter
Monitoraggio	5 €/mese	starter (incluso in pro)
Logging	4 €/mese	pro
Nodi dedicati	9 €/mese	pro

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:

text

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.

È attiva di default dal piano starter in su; su dev è disattivata (un risparmio reale) e può essere aggiunta a 0,50 €/mese. 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 — nessun 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:

Scarica il kubeconfig del cluster dalla dashboard kubehz (pagina di dettaglio del cluster).
Avvia un proxy locale verso l'API server:
bash
```
kubectl --kubeconfig ./kubeconfig proxy
```

Apri l'URL del proxy di servizio della dashboard nel browser:

text

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 piano dev in su. 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":

yaml

# 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"]

bash

kubectl apply -f required-labels.yaml

Come appare l'enforcement. Dopodiché un namespace senza label owner viene rifiutato in fase di admission:

console

$ 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:

bash

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
  labels:
    owner: <tu>
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 piano a pagamento, 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.

Ripristino. Ripristinare da uno snapshot è un'operazione EtcdRestore di KKP sul tuo control plane, assistita dall'operatore — non ancora un pulsante self-service. Se ti serve un ripristino, contatta il supporto indicando il cluster e il punto nel tempo desiderato; il ripristino self-service è una funzionalità del tier managed ancora in graduale rilascio. (I backup esistono proprio perché questo percorso sia disponibile quando ti serve.)

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,50 €/mese dal piano starter in su. 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. Per sfogliarli e cercarli comodamente, abbinalo a Logging — l'audit logging produce gli eventi; l'add-on di logging ti dà un posto per leggerli su larga scala. Senza logging gli eventi vengono comunque prodotti, ma non c'è ancora una UI aggregata su di essi.

Monitoraggio

Cosa abilita. Metriche per cluster raccolte dal tuo cluster e inviate alla piattaforma kubehz. 5 €/mese dal piano starter in su, e incluso nel piano pro senza costi aggiuntivi. Lo attivi nella dashboard kubehz — alla creazione tra le opzioni add-on del wizard, o in seguito dalla card degli add-on nella pagina 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 — gestiti e operati 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. Questa vista è in fase di rilascio — la raccolta è attiva; i grafici nella dashboard vengono attivati cluster per cluster. Finché non raggiunge il tuo cluster, l'add-on prepara i dati in background.

Logging

Cosa abilita. Aggregazione dei log per cluster, basata su Loki, tramite lo stesso stack di piattaforma. 4 €/mese dal piano pro in su. Come il monitoraggio, la attivi nella dashboard kubehz — alla creazione tra le opzioni add-on del wizard, o in seguito dalla card degli add-on nella pagina 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 — gestiti e operati 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, 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. 9 €/mese, solo piano pro. 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 — i piani 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; viste di monitoraggio/logging nella dashboard in fase di rilascio
Ultima revisione	2026-07-11

Add-on ​

Dashboard web del cluster (Headlamp) ​

OPA / Gatekeeper ​

Backup di etcd ​

Registro di audit ​

Monitoraggio ​

Logging ​

Nodi dedicati ​

Prossimi passi ​

Stato del documento ​