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.	Early Access

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 wendet ihn an.	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. kubehz benötigt kein Token für Kern-Selbstheilung / -Skalierung / -Upgrade. 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 und managed sind heute live und hosted ist im Early Access; 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 nie mehr, als das erfordert, worum du gebeten hast.

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. (Der genaue Beanspruchungs-Handshake wird gerade überarbeitet, daher belassen wir es hier auf dieser Ebene.)

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 (Early Access)