Add-ons

Deine gehostete Control Plane hat keinen Tarif. Du legst ihre Form fest (1 bis 3 API-Server, ein Zustandslimit) und setzt Add-ons darauf.

Diese Seite ist die praktische Ergänzung zu Preise. Für jedes Add-on sagt sie dir, was du bekommst, wie du es nutzt und, wo es passt, welchen Befehl du einfügen kannst. Die API-Referenz beschreibt jede API-Route, die diese Seite nennt.

Du wählst Add-ons im Dashboard: im Erstellungs-Assistenten und später unter Einstellungen → Zuschnitt des Clusters. Die Karte Add-ons auf der Cluster-Seite zeigt nur, was installiert ist.

Der kubehz-Operator übersetzt deine Wahl in die passenden Kubermatic-(KKP-)Einstellungen auf deiner Control Plane. Du bearbeitest KKP nie direkt.

Apps sind keine Add-ons

Add-ons sind Control-Plane-Optionen. Software, die in deinem Cluster läuft, kommt aus dem App-Katalog im Tab Anwendungen des Clusters.

Wähle eine App und eine Version, gib optional Helm-Values mit, und der Operator installiert sie (GET /api/catalog/apps, PUT /api/clusters/{id}/apps/{name}). Heute enthält der Katalog cert-manager. Weitere Apps folgen, sobald wir sie geprüft haben.

Inklusive, keine Add-ons

Zwei Dinge, die man als Add-on erwartet, sind keine Add-ons, weil jede gehostete Control Plane sie hat:

etcd-Backups: Jede gehostete Control Plane enthält geplante Snapshots, standardmäßig aktiv. Die Details stehen unten unter etcd-Backups.
Hochverfügbarkeit: HA ist die Zahl der API-Server, die du festlegst (3 API-Server), kein eigener Posten. Stell drei ein, und du hast HA.

Add-ons im Überblick: jedes Add-on unten kostet bis zum 1. Dezember 2026 0 EUR. Die Tabelle zeigt die Listenpreise, die nach diesem Datum gelten, exkl. MwSt. Verbraucher zahlen die MwSt. zusätzlich: 22 % in Slowenien oder den Satz ihres Landes. Die Seite Preise zeigt die Preise inkl. MwSt.

0 EUR bis 1. Dezember 2026

Add-on	Preis ab 1. Dezember 2026	Monatsdeckel	Braucht
Cluster-Web-Dashboard (Headlamp)	0,001 €/Std.	0,73 €/Monat	jede Form
OPA / Gatekeeper	kostenlos	kostenlos	jede Form
etcd-Backups	inklusive	inklusive	jede Control Plane
Audit-Logging	0,001 €/Std.	0,73 €/Monat	jede Form
Monitoring	0,010 €/Std.	7,30 €/Monat	jede Form
Logging	0,008 €/Std.	5,84 €/Monat	3 API-Server
Dedizierte Nodes	0,018 €/Std.	13,14 €/Monat	3 API-Server

So misst der Zähler. kubehz berechnet jede angefangene Stunde voll. Die Abrechnung startet, sobald du die Ressource anlegst. kubehz berechnet die Ressource, solange sie existiert, in jedem Zustand. Nur das Löschen beendet die Kosten.

Die Stundenbeträge einer Einheit gehen nie über ihren Monatspreis hinaus. Die €/Monat-Zahl ist der Stundensatz multipliziert mit 730 Stunden, und sie ist ein Maximum, auch in einem Monat mit 31 Tagen.

kubehz rechnet Add-ons getrennt ab. Bleibt ein Add-on bestehen, nachdem du etwas anderes gelöscht hast, berechnet kubehz es, bis du auch das Add-on löschst. Siehe Preise.

Ein Preis steht nicht in dieser Liste, weil er kein Add-on ist. Ein statischer Node (ein Worker-Node, den du selbst mitbringst) kostet 0,001 €/Std. pro Node, höchstens 0,73 €/Monat exkl. MwSt. kubehz berechnet ihn pro Stunde, in der er Ready meldet.

Ein NotReady-Node ist die einzige Ausnahme von den Regeln oben: kubehz berechnet ihn nie. Siehe Statische Nodes.

Cluster-Web-Dashboard (Headlamp)

Was es ermöglicht. Ein gehostetes Headlamp-Web-Dashboard für deinen Cluster. kubehz betreibt es neben deiner Control Plane und veröffentlicht es unter einer sofort erreichbaren öffentlichen URL:

text

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

Öffne es von der Detailseite des Clusters im kubehz-Dashboard (Button Dashboard öffnen). Du meldest dich mit deinem kubehz-Konto an (derselbe SSO-Login wie für die Plattform).

Was du sehen und tun kannst, folgt deiner Kubernetes-RBAC. Headlamp reicht dein eigenes Identitäts-Token an den API-Server weiter und hält selbst keine Admin-Zugangsdaten. Keine kubeconfig, kein Proxy, kein zweites Passwort.

Es kostet 0,001 €/Std., höchstens 0,73 €/Monat exkl. MwSt., auf jeder Form. Du kannst es im Assistenten und unter Einstellungen → Zuschnitt abwählen. Der Erstellungs-Assistent wählt kein Add-on für dich vor: Dieses hakst du selbst an.

Headlamp hat im Juli 2026 das veraltete Upstream-kubernetes-dashboard hinter diesem Add-on abgelöst: gleiche Option, gleicher Preis, ein besserer Zugangsweg.

Lieber eine lokale App? Headlamp Desktop öffnet denselben Cluster mit deiner heruntergeladenen kubeconfig, ganz ohne Add-on. So bekommst du auch auf self-hosted Clustern ein Dashboard.

Fallback: kubectl proxy. Läuft auf deinem Cluster noch das alte In-Cluster-kubernetes-dashboard, erreichst du es weiter über den Service-Proxy des API-Servers. Der Proxy authentifiziert sich mit deiner eigenen kubeconfig:

Lade die kubeconfig des Clusters aus dem kubehz-Dashboard herunter (Detailseite des Clusters).
Starte einen lokalen Proxy zum API-Server:
bash
```
kubectl --kubeconfig ./kubeconfig proxy
```

Öffne die Service-Proxy-URL des Dashboards im Browser:

text

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

Der Proxy übernimmt deine kubeconfig. Das Dashboard sieht genau das, was du auch mit kubectl sehen würdest, und nicht mehr.

OPA / Gatekeeper

Was es ermöglicht. OPA Gatekeeper setzt Policies in deinem Cluster durch. Gatekeeper prüft Ressourcen bei der Admission gegen Richtlinien, die du als ConstraintTemplate + Constraint schreibst.

Es ist kostenlos und auf jeder Form verfügbar. Der Operator bildet dieses Add-on auf KKPs opaIntegration.enabled ab. Die Gatekeeper-Komponenten laufen in deinem Cluster.

Wie du es nutzt. Sobald das Add-on an ist, wende ein ConstraintTemplate an (es definiert eine wiederverwendbare Regel) und danach ein Constraint (es wendet die Regel auf bestimmte Kinds an). Der Klassiker zum Einstieg ist „jeder Namespace muss ein owner-Label tragen“:

Vollständiges ConstraintTemplate + Constraint YAML anzeigen

yaml

# 1. Das Template: eine wiederverwendbare „required labels"-Regel.
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. Das Constraint: verlange ein `owner`-Label auf jedem Namespace.
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-owner
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["owner"]

Speichere beide Dokumente als required-labels.yaml und wende sie dann an:

bash

kubectl apply -f required-labels.yaml

Wie die Durchsetzung aussieht. Danach lehnt der Admission-Webhook einen Namespace ohne owner-Label ab:

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"}

Erstelle den Namespace stattdessen gleich mit dem Label, und Gatekeeper lässt ihn zu:

bash

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
  labels:
    owner: platform-team  # beliebiger Wert — die Policy verlangt nur den Schlüssel
EOF

etcd-Backups

Was es ermöglicht. Geplante Snapshots des etcd deiner Control Plane, des Datenspeichers hinter jedem Objekt in deinem Cluster (Deployments, Secrets, CRDs, alles).

Jede gehostete Control Plane enthält sie, standardmäßig aktiv. Es gibt nichts zu kaufen oder einzuschalten. Der Operator stellt eine KKP- EtcdBackupConfig für deinen Cluster bereit.

Zeitplan und Aufbewahrung. Backups laufen alle 6 Stunden (Cron 0 */6 * * *). kubehz behält die letzten 20 Snapshots und bereinigt ältere automatisch. Es schreibt die Snapshots in kubehz-verwalteten Objektspeicher in der EU. Du verwaltest keinen Bucket.

Einzelne Snapshots und Wiederherstellung. Neben dem Zeitplan kannst du selbst einen Snapshot anlegen, etwa vor einer riskanten Änderung, und aus jedem Snapshot wiederherstellen, den du hast. Beides ist Self-Service: im Abschnitt Backups der Cluster-Seite oder über die API.

In der API legt POST /api/clusters/{id}/snapshots mit einem name einen Snapshot an, GET listet sie auf, DELETE .../snapshots/{name} löscht einen, und die Restore-Aktion an einem Snapshot stellt ihn wieder her.

Eine Wiederherstellung ist ein KKP-EtcdRestore auf deiner Control Plane. Der API-Server ist für die Minuten der Wiederherstellung nicht erreichbar, und jedes seit dem Snapshot geänderte Objekt ist weg. Wenn du ein zweites Paar Augen möchtest, frag im Chat, bevor du den Knopf drückst.

Audit-Logging

Was es ermöglicht. Kubernetes-API-Audit-Logging auf deiner Control Plane: eine Aufzeichnung, wer was gegen den API-Server gemacht hat (Requests, Subjekte, Verben, Ressourcen).

Es kostet 0,001 €/Std., höchstens 0,73 €/Monat exkl. MwSt., auf jeder Form. Der Operator bildet dieses Add-on auf KKPs auditLogging mit einem festen Policy-Preset ab.

Welches Preset gilt. kubehz aktiviert das recommended-Audit-Policy-Preset. Diese ausgewogene Stufe erfasst die sicherheitsrelevanten Operationen ohne die Datenmenge eines vollen Request/Response-Stroms. Du kannst das Preset nicht ändern: Es gibt keinen Policy-Editor pro Cluster.

Wohin die Ereignisse gehen. Der API-Server auf deiner Control Plane erzeugt die Audit-Ereignisse. Wähle auf der Cluster-Seite oder mit PUT /api/clusters/{id}/audit-delivery eine Zustellung dafür:

webhook sendet jeden Batch an einen HTTPS-Endpunkt von dir (optional mit CA-Bundle).
s3 schreibt sie in einen S3-kompatiblen Bucket, der dir gehört (Endpunkt, Bucket, Präfix, Access-Key).
none behält sie nur auf der Control Plane.

Um die Ereignisse zu durchsuchen, kombiniere dieses Add-on mit Logging. Logging gibt dir einen Ort, um sie in großem Umfang zu lesen.

Monitoring

Was es ermöglicht. Metriken pro Cluster: kubehz sammelt sie in deinem Cluster und schickt sie an die kubehz-Plattform. Es kostet 0,010 €/Std., höchstens 7,30 €/Monat exkl. MwSt., auf jeder Form.

Du schaltest es im kubehz-Dashboard ein: beim Erstellen des Clusters in den Add-on-Optionen des Assistenten oder später unter Einstellungen → Zuschnitt des Clusters. Ein Prometheus läuft in deinem Cluster und speist die Plattform. Du betreibst oder skalierst ihn nicht.

Was die Gebühr abdeckt. Die Plattform-Seite: mandantenfähige Metrik-Speicherung mit 15 Tagen Aufbewahrung, der Abfragepfad des Dashboards und das Alerting. kubehz betreibt und verwaltet all das.

Auf deiner Seite läuft ein Monitoring-Agent auf deinen eigenen Workern: 2 Replikas, die zusammen 220m CPU und 532 MiB Speicher anfordern (siehe Worker-Kapazität). Die Gebühr bezahlt unser Backend und unseren Speicher, nicht deine Rechenleistung.

Was kubehz sammelt. Cluster- und Node-Zustand sowie die Ressourcennutzung von Control Plane und Workloads (die üblichen Kubernetes-/cAdvisor-/kube-state-Signale). Du bekommst CPU-, Speicher-, Pod- und Node-Metriken über die Zeit, ohne eigenen Prometheus.

Wo du es siehst. Die Metriken erscheinen im Abschnitt Monitoring auf der Cluster-Seite im kubehz-Dashboard.

Alerting. Derselbe Abschnitt enthält deine Alert-Regeln und Empfänger:

Eine Regelgruppe ist eine Prometheus-Regeldatei für metrics oder logs (PUT /api/clusters/{id}/monitoring/rules/{name} mit dem YAML in data).
Ein Empfänger ist eine webhook-URL oder eine email-Adresse (PUT .../monitoring/receivers/{name}).

Abonniere die Alert-Mails des Clusters für dein eigenes Konto über den Schalter auf derselben Seite oder mit POST /api/clusters/{id}/alerts/subscription.

Logging

Was es ermöglicht. Log-Aggregation pro Cluster, Loki-basiert, über denselben Plattform-Stack. Es kostet 0,008 €/Std., höchstens 5,84 €/Monat exkl. MwSt., und es braucht die Form mit drei API-Servern.

Wie beim Monitoring schaltest du es im kubehz-Dashboard ein: beim Erstellen des Clusters in den Add-on-Optionen des Assistenten oder später unter Einstellungen → Zuschnitt des Clusters. Ein promtail-artiger Collector läuft in deinem Cluster und schickt Pod-Logs an das Loki der Plattform. Du betreibst Loki nicht selbst.

Was die Gebühr abdeckt. Die plattformseitige Aufnahme, die 7-tägige Log-Speicherung und der Abfragepfad hinter dem Log-Browser des Dashboards. kubehz betreibt und verwaltet all das.

Der Collector auf deinen Nodes gehört dir: Er fordert auf jedem Worker-Node 60m CPU und 74 MiB Speicher an. Die Gebühr bezahlt unser Backend und unseren Speicher.

Aufbewahrung. Das Add-on enthält 7 Tage Log-Aufbewahrung: Du kannst die Logs der letzten Woche abfragen, ältere Daten laufen aus.

Wo du es siehst. Logs erscheinen im kubehz-Dashboard neben dem Monitoring. Der Rollout des Log-Browsers im Dashboard läuft noch. Heute gibt dir das Add-on die Sammlung und die 7-Tage-Aufbewahrung.

Logging ist auch der natürliche Begleiter zu Audit-Logging: Es gibt dir einen Ort, um die Audit-Ereignisse zu lesen.

Dedizierte Nodes

Was es ermöglicht. Platziert deine Control Plane auf dediziertem Bare-Metal in der kubehz-Flotte statt auf geteilten Cloud-VMs. Die Control Plane bekommt stabilere, isolierte Leistung.

Es kostet 0,018 €/Std., höchstens 13,14 €/Monat exkl. MwSt., und es braucht die Form mit drei API-Servern. Der Operator verschiebt deine Control Plane auf Metal-Class-Nodes (eine Platzierungsänderung, keine Größenänderung).

Live-Migration beim Umschalten. Dediziert ist umkehrbar. Wenn du es einschaltest (oder ausschaltest), startet der Operator eine Live-Migration der Control Plane auf den Metal-Pool (oder von ihm weg). Der Operator verschiebt den Workload: Du baust den Cluster nicht neu.

Kapazitäts-Gating (die ehrliche Sache). Bare Metal ist ein knapper Pool, und wir begrenzen ihn bewusst. Deshalb ist Dediziert zur Bereitstellungszeit kapazitätsbegrenzt. Ist der Metal-Pool an seiner Untergrenze, kannst du die Option eine Zeit lang nicht bestellen, auch auf einem Cluster mit drei API-Servern.

Das ist beabsichtigt: Wir fügen Metal hinzu, wenn die Nachfrage es rechtfertigt. Die Option braucht die Form mit drei API-Servern, damit Wegwerf-Cluster die knappe Kapazität nicht verbrauchen. Ist die Option beim Versuch nicht verfügbar, öffnet sie sich wieder, sobald wir Kapazität hinzufügen.

Worker-Kapazität

Manche Add-ons betreiben Pods auf deinen gehosteten Workern, und diese Pods fordern CPU und Speicher an. Bevor kubehz ein solches Add-on einschaltet, prüft es, ob die Worker-Pools die System-Pods und alle gewählten Add-ons aufnehmen können. Die Prüfung zählt diese Anforderungen (Requests):

Auf deinen Workern	CPU	Speicher	Gezählt
System-Pods auf jedem Node	175m	114 MiB	pro Worker-Node
System-Pods für den Cluster	320m	484 MiB	einmal pro Cluster
Monitoring (2 Agent-Replikas)	220m	532 MiB	einmal pro Cluster
Logging (Collector)	60m	74 MiB	pro Worker-Node
OPA / Gatekeeper	200m	1024 MiB	einmal pro Cluster
cert-manager (App-Katalog)	60m	160 MiB	einmal pro Cluster

Das Cluster-Web-Dashboard, Audit-Logging, etcd-Backups und dedizierte Nodes laufen neben der Control Plane. Auf deinen Workern brauchen sie nichts.

Die Regel. Die Pools müssen mindestens das 1,5-Fache der Summe dieser Requests bieten, bei CPU und bei Speicher. Die 50 % Reserve decken Verbrauch über den Requests, den zusätzlichen Pod bei einem Rolling Update und die Ungenauigkeit der Schätzung.

kubehz schätzt, was ein Node bietet, aus seinem Servertyp: vCPUs × 1000m minus 400m CPU und 93 % seines Speichers minus 500 MiB. Ein automatisch skalierter Pool zählt mit seiner minimalen Node-Anzahl.

Beispiel. Ein Worker mit 2 vCPUs und 4 GB (cpx22 oder cax11) bietet 1600m CPU und 3309 MiB. Die System-Pods und Monitoring brauchen (175 + 320 + 220) × 1,5 = 1073m CPU und (114 + 484 + 532) × 1,5 = 1695 MiB. Ein solcher Worker reicht.

Wann kubehz prüft. Wenn du einen Cluster mit Workern und Add-ons anlegst, ein Add-on hinzufügst, eine Katalog-App installierst oder einem Cluster ohne Worker seine ersten Worker gibst. Hat ein Cluster schon Worker, lehnt diese Prüfung nie eine Pool-Änderung ab (herunterskalieren, neuer Typ, entfernen).

Statische Pools prüft kubehz nicht (ihre Größe ist unbekannt). Ist der Hetzner-Katalog nicht erreichbar, lässt kubehz die Änderung ebenfalls durch.

Wenn es nicht passt. kubehz lehnt die Änderung mit ADDON_NEEDS_CAPACITY ab. Der Hilfetext nennt, was die Add-ons und die System-Pods brauchen, was die Pools bieten, und einen Pool, der reicht (zum Beispiel 2 × cax11).

Wähle einen größeren Servertyp, füge Worker hinzu oder entferne ein Add-on. Jeder gehostete Worker braucht außerdem mindestens 2 vCPUs: siehe Servertypen.

Nächste Schritte

Preise: die vollständige Add-on-Preisliste.
Gehostete Control Plane: die Form und der gehostete Weg insgesamt.
Worker-Pools: Pools, Skalierung und Autoscaling auf deinem Cluster.
Dashboard & Konto: wo du Add-ons umschaltest und die kubeconfig herunterlädst.

Doku-Status

Aspekt	Detail
Zustand	Add-ons live, mit Snapshots, Wiederherstellung, Audit-Zustellung und Alerting als Self-Service. Log-Browser im Dashboard: Rollout läuft
Zuletzt geprüft	2026-10-30

Add-ons ​

Cluster-Web-Dashboard (Headlamp) ​

OPA / Gatekeeper ​

etcd-Backups ​

Audit-Logging ​

Monitoring ​

Logging ​

Dedizierte Nodes ​

Worker-Kapazität ​

Nächste Schritte ​

Doku-Status ​