Wie es funktioniert

kubehz dreht sich um eine Frage: Wie viel möchtest du abgeben, und was bist du bereit zu teilen, um es zu bekommen? Zwei unabhängige Achsen beantworten das, und eine feste Datenschutzgrenze macht die Antwort sicher.

Zwei Achsen

Du wählst diese getrennt in cluster.lok8s.yaml unter spec.kubehz:

spec:
  kubehz:
    hosting: self          # self | hosted
    access: registered     # none | registered | managed
    apiUrl: https://api.kubehz.cloud

Hosting — wer die Control Plane betreibt

Wert	Bedeutung	Status
self	Du stellst die Control Plane auf deinem eigenen Hetzner-Konto bereit und besitzt sie. Der normale lok8s-Ablauf.	Verfügbar
hosted	kubehz betreibt die Control Plane (etcd, apiserver, scheduler) auf seiner Infrastruktur; du betreibst nur Worker.	Verfügbar

Access — wie viel kubehz sieht und tut

Wert	kubehz sieht	kubehz tut	Status
none	Nichts: überhaupt kein Plattformkontakt.	Nichts.	Verfügbar
registered	Schreibgeschützter Zustand: Kubernetes-Version, Nodes & Status, Zustand der Control-Plane-Komponenten, Zertifikatsablauf.	Zeigt ihn im Dashboard an.	Verfügbar
managed	Verwaltungsdaten für Healing-Richtlinien, Kapazitäts-Überwachung, gewünschten Zustand.	Hält den gewünschten Zustand fest; dein Cluster holt ihn ab und führt die freigeschalteten Aktionen aus.	Verfügbar (Supporter+)

Die alltägliche Kombination ist hosting: self + access: registered: dein Cluster auf deinem Konto, kubehz als schreibgeschütztes Dashboard. access: managed ist darauf aufbauend live: Es fügt kubehz’ Verwaltungsfunktionen hinzu (Healing-Richtlinien, Kapazitäts-Überwachung, die Verwaltung des gewünschten Zustands, gesteuert aus dem Dashboard) und erfordert ein Supporter-Abo oder höher. Ein managed-Cluster registriert sich und wird genauso beansprucht wie ein registered-Cluster; das Abo-Gate greift, wenn du Verwaltungsfunktionen steuerst.

Die Vertrauensgrenze — wer dein Hetzner-Token braucht

Das ist der entscheidende Teil, deshalb lohnt es sich, ihn genau zu benennen:

• registered (Self-Hosted): kein Hetzner-Token. kubehz erhält schreibgeschützten Zustand und sonst nichts. Es kann nichts an deinem Konto oder in deinem Cluster ändern.
• managed auf deinem eigenen Self-Hosted-Cluster: Token optional. kubehz hält den gewünschten Zustand fest (z. B. “Upgrade auf v1.35”); der clusterinterne Agent holt ihn von der Plattform ab und wendet ihn lokal mit den Zugangsdaten an, die dein Cluster bereits besitzt. kubehz pusht niemals hinein und hält keine eingehenden Zugangsdaten. Selbstheilung, Skalierung und Upgrade benötigen deshalb kein Token: sie laufen in deinem Cluster, jeweils hinter einem eigenen Ausführungs-Schalter. Ein Hetzner-Token wird nur jemals benötigt, um dir kontospezifische Preise anzuzeigen, niemals, um den Cluster zu betreiben.
• hosted Control Plane: Token erforderlich. Hier delegierst du wirklich: kubehz stellt Infrastruktur für dich bereit und benötigt dafür entsprechenden Zugriff.

registered, managed und hosted sind heute alle live; die obige managed-Grenze ist genau so, wie der Tarif funktioniert: Pull-basiert und nur ausgehend. Die Eskalation ist bewusst gewählt: Du gewährst jeder Funktion nur den Zugriff, den sie braucht, mehr nicht.

Deine Daten — ein festes Versprechen (Self-Hosted)

Für Self-Hosted-Cluster ist dies eine Garantie, keine Nettigkeit:

• Nur die Daten, die die von dir aktivierte Funktion benötigt, verlassen jemals deinen Cluster. registered sendet Zustandsdaten; managed sendet Verwaltungsdaten. Das ist die gesamte Liste.
• Keine Telemetrie. Keine Analytik. Nichts weiter. Wir sammeln keine Nutzungsdaten, Workload-Inhalte, Secrets, Logs oder Metriken, die du nicht ausdrücklich aktiviert hast.
• Nur ausgehend. Der clusterinterne Heartbeat-Agentsendet einen Statusschnappschuss nach Zeitplan. kubehz verbindet sich niemals in deinen Cluster hinein und hält keine eingehenden Zugangsdaten dafür.
• Deaktivieren ist ein Schritt. lo kubehz deregister plus Löschen des kubehz-system-Namespace entfernt alles; dein Cluster läuft weiter.

Da der Agent nur sendet, was eine Funktion benötigt, schaltet das Deaktivieren einer Funktion auch deren Daten ab.

Besitz — registrieren und beanspruchen

Ein Cluster wird auf der Plattform in zwei konzeptionellen Schritten deiner:

1. Registrieren: Die Bereitstellung meldet den Cluster bei kubehz an (oder führe lo kubehz register aus). Er erscheint als pending.
2. Beanspruchen: Im Dashboard beanspruchst du den ausstehenden Cluster, um den Besitz nachzuweisen und ihn mit deinem Konto zu verknüpfen. Nach dem Beanspruchen gehört er dir.

Das ist das ganze Modell: registrieren → beanspruchen → besitzen. Claiming beschreibt beide Handshakes vollständig: einen einmaligen Claim-Code oder einen SSH-Fingerprint, der gegen dein Hetzner-Konto geprüft wird.

Prinzipien

• Open Source zuerst. lok8s, das CLI, das alles bereitstellt, ist Open Source und funktioniert ohne kubehz. Du bist nie gebunden.
• Ehrliche Preise. Die Preise basieren auf gemessenen Kosten unserer eigenen Flotte, und wir erklären unsere Preise.
• EU-Datensouveränität. Infrastruktur in Deutschland; keine Abhängigkeiten von US-Clouds.

Nächste Schritte

• Registrierung: schreibgeschützte Sichtbarkeit noch heute aktivieren
• Dashboard & Konto: was du nach dem Beanspruchen erhältst
• Gehostete Control Plane: der delegierte Weg

Doku-Status

Aspekt	Detail
Zustand	Live: Self-Hosted, Managed und Hosted verfügbar; Abrechnung startet am 1. November 2026
Zuletzt geprüft	2026-08-14