kubehz

Deutsch

English
Slovenscina
Italiano
Nederlands

Deutsch

English
Slovenscina
Italiano
Nederlands

Appearance

Add-ons ​

Deine gehostete Control Plane beginnt mit einem Tarif (dev, starter, pro), auf den du Add-ons legst. 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 auf der Detailseite des Clusters. Der kubehz-Operator übersetzt deine Wahl in die passenden Kubermatic-(KKP-) Einstellungen auf deiner Control Plane; du bearbeitest KKP nie direkt.

Inklusive vs. Add-on

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

  • etcd-Backups — geplante Snapshots sind in jedem bezahlten Tarif enthalten, standardmäßig aktiv. Siehe etcd-Backups unten, was das bedeutet.
  • Hochverfügbarkeit — HA ist der pro-Tarif selbst (3× API-Server), kein eigener Posten. Wähle pro, und du hast sie.

Add-ons im Überblick (Listenpreise — siehe Preise):

Add-onPreisMindesttarif
Cluster-Web-Dashboard (Headlamp)0,50 €/Monatbeliebig (ab starter standardmäßig an)
OPA / Gatekeeperkostenlosdev
etcd-Backupsinklusivejeder bezahlte Tarif
Audit-Logging0,50 €/Monatstarter
Monitoring5 €/Monatstarter (in pro enthalten)
Logging4 €/Monatpro
Dedizierte Nodes9 €/Monatpro

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.

Ab dem starter-Tarif standardmäßig an; auf dev ist es aus (eine echte Ersparnis) und kann für 0,50 €/Monat hinzugefügt werden. 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, und 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 — 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 ab dem dev-Tarif 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":

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"]
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: <du>
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 jedem bezahlten Tarif 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.

Wiederherstellung. Das Wiederherstellen aus einem Snapshot ist eine operator-unterstützte KKP-EtcdRestore-Operation auf deiner Control Plane — noch keine Self-Service-Schaltfläche. Wenn du eine Wiederherstellung brauchst, kontaktiere den Support mit dem Cluster und dem gewünschten Zeitpunkt; die Self-Service-Wiederherstellung ist eine Funktion des Managed-Tarifs, die noch schrittweise ausgerollt wird. (Backups existieren genau dafür, dass dieser Weg verfügbar ist, wenn du ihn brauchst.)

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,50 €/Monat ab dem starter-Tarif. 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. Um sie tatsächlich bequem zu durchsuchen, kombiniere das mit Logging — Audit-Logging erzeugt die Ereignisse; das Logging-Add-on gibt dir einen Ort, um sie in großem Umfang zu lesen. Ohne Logging werden die Ereignisse zwar erzeugt, aber es gibt noch keine aggregierte Oberfläche darüber.

Monitoring ​

Was es ermöglicht. Pro-Cluster gesammelte Metriken aus deinem Cluster, die an die kubehz-Plattform geschickt werden. 5 €/Monat ab dem starter-Tarif und im pro-Tarif ohne Aufpreis enthalten. Du schaltest es im kubehz-Dashboard ein — beim Erstellen in den Add-on-Optionen des Assistenten oder später auf der Add-on-Karte der Cluster-Seite. 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 — 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 — du bekommst also CPU-, Speicher-, Pod- und Node-Metriken über die Zeit, ohne dein eigenes Prometheus aufzusetzen.

Wo du es siehst. Metriken erscheinen im Abschnitt Monitoring des kubehz-Dashboards. Diese Ansicht wird ausgerollt — die Sammlung ist live; die Diagramme im Dashboard werden Cluster für Cluster online genommen. Bis sie deinen Cluster erreicht, stellt das Add-on die Daten im Hintergrund bereit.

Logging ​

Was es ermöglicht. Pro-Cluster Log-Aggregation, Loki-basiert, über denselben Plattform-Stack. 4 €/Monat ab dem pro-Tarif. Wie beim Monitoring schaltest du es im kubehz-Dashboard ein — beim Erstellen in den Add-on-Optionen des Assistenten oder später auf der Add-on-Karte der Cluster-Seite. 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 — 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, ä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. 9 €/Monat, nur pro-Tarif. 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; Monitoring-/Logging-Ansichten im Dashboard werden ausgerollt
Zuletzt geprüft2026-07-11