Skip to content

Add-ons

Deine gehostete Control Plane hat keinen Tarif: du legst ihre Form fest (1 bis 3 API-Server, ein Zustandslimit) und legst Add-ons darauf. Diese Seite ist die praktische Ergänzung zu Preise: was jedes Add-on dir tatsächlich bringt, wie du es nutzt und, wo es passt, ein Befehl zum Einfügen.

Du wählst Add-ons im Dashboard: im Erstellungs-Assistenten und später unter Einstellungen → Tarif 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: App und Version wählen, optional Helm-Values mitgeben, 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 sie geprüft sind.

Inklusive vs. Add-on

Zwei Dinge, die man als Add-on erwartet, sind keine, weil sie eingebaut sind:

  • etcd-Backups: geplante Snapshots sind in jeder gehosteten Control Plane enthalten, standardmäßig aktiv. Siehe etcd-Backups unten, was das bedeutet.
  • Hochverfügbarkeit: HA ist die Zahl der API-Server, die du festlegst (3× API-Server), kein eigener Posten. Stell drei ein, und du hast sie.

Add-ons im Überblick: jedes Add-on unten kostet bis zum 1. November 2026 0 EUR. Danach gelten die folgenden Listenpreise (siehe Preise):

0 EUR bis 1. November 2026

Add-onPreis ab 1. November 2026MonatsdeckelBraucht
Cluster-Web-Dashboard (Headlamp)0,001 €/Std.0,73 €/Monatjede Form
OPA / Gatekeeperkostenloskostenlosjede Form
etcd-Backupsinklusiveinklusivejede Control Plane
Audit-Logging0,001 €/Std.0,73 €/Monatjede Form
Monitoring0,010 €/Std.7,30 €/Monatjede Form
Logging0,008 €/Std.5,84 €/Monat3 API-Server
Dedizierte Nodes0,018 €/Std.13,14 €/Monat3 API-Server

So misst der Zähler. kubehz berechnet jede angefangene Stunde voll. Die Abrechnung beginnt, 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 ist ein Maximum, auch in einem Monat mit 31 Tagen. Add-ons werden getrennt abgerechnet. Ein Add-on, das ein Löschen überlebt, wird berechnet, bis du auch das Add-on löschst. Siehe Preise.

Ein Preis steht außerhalb 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, berechnet 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, von kubehz direkt neben deiner Control-Plane betrieben und unter einer sofort erreichbaren öffentlichen URL veröffentlicht:

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), und 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 keinerlei Admin-Zugangsdaten. Keine kubeconfig, kein Proxy, kein zweites Passwort.

Es kostet 0,001 €/Std., höchstens 0,73 €/Monat, auf jeder Form, und du kannst es überall abwählen. Der Erstellungs-Assistent wählt kein Add-on für dich vor; dieses hakst du selbst an. Headlamp hat das veraltete Upstream-kubernetes-dashboard hinter diesem Add-on abgelöst (2026-07): gleiche Option, gleicher Preis, ein deutlich besserer Zugangsweg.

Lieber eine lokale App? Headlamp Desktop öffnet denselben Cluster mit deiner heruntergeladenen kubeconfig, ganz ohne Add-on. Das ist auch der Dashboard-Weg für self-hosted Cluster.

Fallback: kubectl proxy. Ein Cluster, auf dem noch das alte In-Cluster- kubernetes-dashboard läuft, bleibt über den Service-Proxy des API-Servers erreichbar, authentifiziert mit deiner eigenen kubeconfig:

  1. Lade die kubeconfig des Clusters aus dem kubehz-Dashboard herunter (Detailseite des Clusters).

  2. Starte einen lokalen Proxy zum API-Server:

    bash
    kubectl --kubeconfig ./kubeconfig proxy
  3. Ö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, sodass das Dashboard genau das sieht, was du auch mit kubectl sehen würdest, und nicht mehr.

OPA / Gatekeeper

Was es ermöglicht. OPA Gatekeeper-Policy-Durchsetzung in deinem Cluster: Validierung von Ressourcen zur Admission-Zeit gegen Richtlinien, die du als ConstraintTemplate + Constraint schreibst. Es ist kostenlos und auf jeder Form verfügbar. Der Operator bildet das 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 (definiert eine wiederverwendbare Regel) und danach ein Constraint (wendet sie 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 wird ein Namespace ohne owner-Label bei der Admission abgelehnt:

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 er wird zugelassen:

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). Das ist in jeder gehosteten Control Plane enthalten, 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 * * *), und die letzten 20 Snapshots werden aufbewahrt; ältere werden automatisch bereinigt. Snapshots werden in kubehz-verwalteten Objektspeicher in der EU geschrieben. 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 (POST /api/clusters/{id}/snapshots mit einem name, GET zum Auflisten, DELETE .../snapshots/{name} zum Löschen und die Restore-Aktion an einem Snapshot). Eine Wiederherstellung ist ein KKP-EtcdRestore auf deiner Control Plane: Der API-Server ist für die paar Minuten nicht erreichbar, und jedes seit dem Snapshot geänderte Objekt ist weg. Wenn du lieber ein zweites Paar Augen hättest, frag im Chat, bevor du 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). 0,001 €/Std., höchstens 0,73 €/Monat, auf jeder Form. Der Operator bildet das auf KKPs auditLogging mit einem festen Policy-Preset ab.

Welches Preset angewendet wird. kubehz aktiviert das recommended-Audit-Policy-Preset, eine ausgewogene Stufe, die die sicherheitsrelevanten Operationen erfasst, ohne die Datenmenge eines vollen Request/Response-Stroms. (Das Preset ist fest; es gibt keinen Policy-Editor pro Cluster.)

Wohin die Ereignisse gehen. Audit-Ereignisse werden vom API-Server auf deiner Control Plane erzeugt. 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 sie zu durchsuchen, kombiniere das Add-on mit Logging, das dir einen Ort gibt, um sie in großem Umfang zu lesen.

Monitoring

Was es ermöglicht. Pro-Cluster gesammelte Metriken aus deinem Cluster, die an die kubehz-Plattform geschickt werden. 0,010 €/Std., höchstens 7,30 €/Monat, auf jeder Form. Du schaltest es im kubehz-Dashboard ein: beim Erstellen in den Add-on-Optionen des Assistenten oder später unter Einstellungen → Tarif des Clusters. Ein Prometheus läuft in deinem Cluster und speist die Plattform; du betreibst oder skalierst es nicht.

Was die Gebühr abdeckt. Die Plattform-Seite: mandantenfähige Metrik-Speicherung mit 15 Tagen Aufbewahrung, der Abfragepfad des Dashboards und das Alerting. All das wird von kubehz betrieben und verwaltet. Auf deiner Seite läuft nur ein leichter Collector auf deinen eigenen Workern; die Gebühr bezahlt unser Backend und unseren Speicher, nicht deine Rechenleistung.

Was gesammelt wird. Cluster- und Node-Zustand, Ressourcennutzung von Control Plane und Workloads (die üblichen Kubernetes-/cAdvisor-/kube-state-Signale), sodass du CPU-, Speicher-, Pod- und Node-Metriken über die Zeit bekommst, ohne dein eigenes Prometheus aufzusetzen.

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

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 mit POST /api/clusters/{id}/alerts/subscription oder über den Schalter auf derselben Seite.

Logging

Was es ermöglicht. Pro-Cluster Log-Aggregation, Loki-basiert, über denselben Plattform-Stack. 0,008 €/Std., höchstens 5,84 €/Monat; es braucht die Form mit drei API-Servern. Wie beim Monitoring schaltest du es im kubehz-Dashboard ein: beim Erstellen in den Add-on-Optionen des Assistenten oder später unter Einstellungen → Tarif 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. All das wird von kubehz betrieben und verwaltet. Der Collector auf deinen Nodes gehört dir und fällt kaum ins Gewicht; die Gebühr bezahlt unser Backend und unseren Speicher.

Aufbewahrung. Das Add-on enthält 7 Tage Log-Aufbewahrung: Die letzte Woche an Logs ist abfragbar, und ältere Daten laufen aus.

Wo du es siehst. Logs erscheinen im kubehz-Dashboard neben dem Monitoring. Wie die Monitoring-Ansicht wird der Log-Browser im Dashboard ausgerollt; die Sammlung und die 7-Tage-Aufbewahrung stellt das Add-on heute bereit, und es ist auch der natürliche Begleiter zu Audit-Logging, um 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: stabilere, isolierte Leistung für die Control Plane. 0,018 €/Std., höchstens 13,14 €/Monat; es braucht die Form mit drei API-Servern. Der Operator steuert deine Control Plane auf Metal-Class-Nodes (eine Platzierungsänderung, keine Größenänderung).

Live-Migration beim Umschalten. Dediziert ist umkehrbar: das Einschalten (oder Ausschalten) löst eine Live-Migration der Control Plane auf (oder von) den Metal-Pool aus: Der Operator verschiebt den Workload; du baust den Cluster nicht neu.

Kapazitäts-Gating (die ehrliche Sache). Bare Metal ist ein knapper, bewusst begrenzter Pool. Deshalb ist Dediziert zur Bereitstellungszeit kapazitätsbegrenzt: Ist der Metal-Pool an seiner Untergrenze, kann die Option selbst auf einem pro-Cluster vorübergehend nicht bestellbar sein. Das ist beabsichtigt (Metal wird hinzugefügt, wenn die Nachfrage es rechtfertigt) und nur für pro, damit Wegwerf-Cluster die knappe Kapazität nicht verbrauchen. Ist sie beim Versuch nicht verfügbar, öffnet sie sich, sobald Kapazität hinzukommt.

Nächste Schritte


Doku-Status

AspektDetail
ZustandAdd-ons live; Snapshots, Wiederherstellung, Audit-Zustellung und Alerting als Self-Service; Log-Browser im Dashboard im Rollout
Zuletzt geprüft2026-09-05