Hoe het werkt

kubehz draait om één vraag: hoeveel wil je uit handen geven, en wat ben je bereid te delen om dat te krijgen? Twee onafhankelijke assen beantwoorden die vraag — en een strikte privacygrens maakt het antwoord veilig.

Twee assen

Je kiest ze afzonderlijk in cluster.lok8s.yaml onder spec.kubehz:

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

Hosting — wie draait het control plane

Waarde	Betekenis	Status
self	Jij rolt het control plane uit en beheert het op je eigen Hetzner-account. De normale lok8s-flow.	Beschikbaar
hosted	kubehz draait het control plane (etcd, apiserver, scheduler) op zijn infrastructuur; jij draait alleen workers.	Early access

Access — hoeveel kubehz ziet en doet

Waarde	kubehz ziet	kubehz doet	Status
none	Niets — helemaal geen contact met het platform.	Niets.	Beschikbaar
registered	Alleen-lezen gezondheid: Kubernetes-versie, nodes & status, gezondheid van control-plane-componenten, certificaatvervaldatum.	Toont het in het dashboard.	Beschikbaar
managed	Beheerdata voor healing-beleid, capaciteitsbewaking, gewenste staat.	Legt de gewenste staat vast; jouw cluster haalt die op en past die toe.	Beschikbaar (Supporter+)

De alledaagse combinatie is hosting: self + access: registered: jouw cluster op jouw account, kubehz als een alleen-lezen dashboard. access: managed is daarbovenop live — het voegt de beheerfuncties van kubehz toe (healing-beleid, capaciteitsbewaking en beheer van de gewenste staat, aangestuurd vanuit het dashboard) en vereist een Supporter-abonnement of hoger. Een managed cluster registreert en wordt geclaimd precies zoals een registered cluster; de abonnementspoort geldt zodra je beheerfuncties aanstuurt.

De vertrouwensgrens — wie je Hetzner-token nodig heeft

Dit is het deel dat ertoe doet, dus het is de moeite waard om het precies te stellen:

• registered (self-hosted): geen Hetzner-token. kubehz krijgt alleen-lezen gezondheid en niets anders. Het kan niets wijzigen op je account of in je cluster.
• managed op je eigen self-hosted cluster: token optioneel. kubehz legt de gewenste staat vast (bijv. "upgrade naar v1.35"); de in-cluster agent haalt die op bij het platform en past die lokaal toe met de credentials die je cluster al heeft — kubehz pusht nooit je cluster in en heeft geen inkomende credential. kubehz heeft geen token nodig voor kernfuncties als self-heal / schalen / upgraden. Een Hetzner-token is alleen ooit nodig om je accountspecifieke prijzen te tonen — nooit om het cluster te draaien.
• hosted control plane: token vereist. Hier delegeer je echt — kubehz rolt infrastructuur voor je uit, dus heeft het toegang nodig om dat te doen.

registered en managed zijn vandaag live en hosted is in early access; de managed-grens hierboven is precies hoe de tier werkt — pull-gebaseerd en alleen uitgaand. De escalatie is bewust: je verleent nooit meer dan wat het onderdeel dat je hebt aangevraagd vereist.

Jouw data — een harde belofte (self-hosted)

Voor self-hosted clusters is dit een garantie, geen extraatje:

• Alleen de data die de functie die je hebt ingeschakeld nodig heeft, verlaat ooit je cluster. registered stuurt gezondheid; managed stuurt beheerdata. Dat is de hele lijst.
• Geen telemetrie. Geen analytics. Niets anders. We verzamelen geen gebruiksdata, workload-inhoud, secrets, logs of metrics waarvoor je je niet hebt aangemeld.
• Alleen uitgaand. De in-cluster heartbeat-agentpusht volgens een schema een statusmomentopname. kubehz maakt nooit verbinding naar je cluster en houdt er geen inkomende credentials voor.
• Uitschakelen is één stap. lo kubehz deregister plus het verwijderen van de kubehz-system-namespace verwijdert alles; je cluster blijft draaien.

Omdat de agent alleen pusht wat een functie nodig heeft, schakelt het uitzetten van een functie ook de bijbehorende data uit.

Eigenaarschap — registreren en claimen

Een cluster wordt van jou op het platform in twee conceptuele stappen:

1. Registreren — bij de provisioning wordt het cluster aangemeld bij kubehz (of voer lo kubehz register uit). Het verschijnt als pending.
2. Claimen — in het dashboard claim je het pending cluster om eigenaarschap te bewijzen en het aan je account te koppelen. Zodra het is geclaimd, is het van jou.

Dat is het hele model: register → claim → owned. (De precieze claim-handshake wordt herzien, dus we houden het hier op dit niveau.)

Principes

• Open source eerst. lok8s, de CLI die alles uitrolt, is open source en werkt zonder kubehz. Je zit nooit vast.
• Eerlijke prijzen. Prijzen komen uit gemeten kosten op onze eigen vloot en we leggen onze prijzen uit.
• EU-datasoevereiniteit. Infrastructuur in Duitsland; geen afhankelijkheden van Amerikaanse cloud.

Volgende stappen

• Registratie — schakel vandaag alleen-lezen zichtbaarheid in
• Dashboard & account — wat je krijgt zodra je hebt geclaimd
• Gehost control plane — het gedelegeerde pad (early access)