Spaces

Ein Space ist ein Ausschnitt eines Kubernetes-Clusters, den kubehz betreibt und absichert, mit Namespaces, die dir gehören, und Nodes, die dir gehören. Du bringst die Maschinen mit; wir betreiben die Control Plane.

Bring eine 4-€-VM mit und bekomme einen verwalteten Kubernetes-Namespace.

Welcher Weg ist das?

kubehz gibt es in drei Formen. Self-hosted: dein Cluster auf deinem Konto, kubehz schaut zu. Hosted: Wir betreiben die Control Plane, die Worker laufen auf deinem Hetzner-Konto. Spaces: Wir betreiben eine Control Plane, die sich viele Kundinnen und Kunden teilen, und du registrierst deine eigenen Maschinen darin. Spaces sind die günstigste der drei Varianten, weil der teure Teil (die Control Plane) geteilt wird.

Was du bekommst

• Einen oder mehrere Namespaces auf einer Control Plane, die wir betreiben, patchen und sichern.
• Deine eigenen Nodes. Du kaufst sie, sie gehören dir, und du bezahlst sie bei wem auch immer: Hetzner, einem anderen Anbieter oder der Maschine unter deinem Schreibtisch. kubehz stellt sie nie bereit und berechnet sie nie.
• kubectl-Zugriff auf deine Namespaces über deinen kubehz-Login.
• Ein stabiler API-Endpunkt für die gesamte Lebensdauer deines Space: https://<dein-space>.k8s.kubehz.cloud. Er nutzt ein öffentlich vertrauenswürdiges Zertifikat (kein CA-Download) und bleibt über jede Migration hinweg gleich, die die Plattform durchführt. Einmal in kubeconfig und CI eintragen, dann vergessen.
• Die Plattform-Basis läuft bereits: CNI, Ingress, Zertifikate, DNS.

Was du bewusst nicht bekommst

Keinen Zugriff auf die geteilte Control Plane. Für die Plane, auf der ein Space startet, gibt es keine Admin-Kubeconfig. Sie wird mit anderen Kundinnen und Kunden geteilt: Cluster-Admin herauszugeben hieße, auch deren Daten herauszugeben. Genau dieser Handel macht den Preis möglich. Wenn dir das zu eng wird, füge deine eigene Control Plane hinzu: dediziert, auf deinen eigenen Nodes, Cluster-Admin inklusive.

Konkret bedeutet das:

• Kein kubectl get nodes -A über den Cluster, keine eigenen cluster-weiten Objekte (keine CRDs, keine ClusterRoles, keine Admission-Webhooks).
• Kein eigenes CNI und keine Änderungen am Netzwerk des Clusters.
• Du siehst deine Namespaces und deine Nodes. Die Workloads anderer sind für dich unsichtbar, und deine für sie.

Wenn du etwas davon brauchst, brauchst du einen eigenen Cluster: nimm den Weg Hosted oder Self-hosted. Der Wechsel nach oben ist eine unterstützte Migration, kein Neuaufbau.

Wie die Isolation funktioniert

Vier Grenzen, jede für sich durchgesetzt:

1. Deine Pods laufen nur auf deinen Nodes. Jeder Namespace trägt einen Node-Selector für deinen Mandanten, und deine Nodes tragen ein passendes Label plus einen Taint, der alle anderen fernhält. Ein Pod von dir kann nicht auf der Maschine einer anderen Kundin landen, und umgekehrt.
2. Dein Netzwerk ist standardmäßig geschlossen. Jeder Namespace startet mit einer Default-Deny-Regel. Verkehr zwischen deinen eigenen Namespaces, DNS und das Internet werden für dich geöffnet; die Namespaces anderer sind in keiner Richtung und über kein Protokoll erreichbar.
3. Deine Zugangsdaten wirken nur auf deine Dinge. Der Zugriff ist auf deine Namespaces beschränkt. Eine Anfrage nach einem fremden Space antwortet nicht gefunden (nicht verboten), damit sich die Liste der anderen im Cluster nicht abfragen lässt.
4. Der Speicher und der Steuerverkehr der Plattform sind unerreichbar von jeder Kunden-Node aus.

Die Nodes gehören dir — in beide Richtungen

kubehz plant Workloads auf deine Maschinen ein. Es stellt sie nicht bereit, meldet sich nicht darauf an, patcht sie nicht und überwacht ihre Festplatten nicht. Fällt eine Node um 3 Uhr nachts aus, verteilen sich deine Workloads auf deine anderen Nodes – sofern du andere Nodes hast.

Das ist die ehrliche Fassung des Handels, und man plant sie am besten ein:

• Betreibe mindestens zwei Nodes für alles, was verfügbar bleiben soll.
• Dir gehört das Betriebssystem: Kernel-Updates, Plattenplatz, die Firewall der Maschine. Wir veröffentlichen eine empfohlene Firewall: Sie ist ein Dienst an dir, keine Kontrolle über dich; du hast root und kannst sie ändern.
• Eine Node im Dashboard abzumelden stoppt die Maschine nicht. Es entzieht ihr die Zugangsdaten und entfernt sie aus dem Cluster. Die Kiste herunterzufahren (und ihre Rechnung zu beenden) ist deine Sache.

Grenzen

Ein Space hat zwei Budgets: wie viele Nodes du registrieren darfst und wie viele Namespaces du haben darfst. Beide stehen live gezählt auf der Seite des Space im Dashboard. Die Obergrenzen folgen deinem Kontomodus:

Kontomodus	Nodes pro Space	Namespaces pro Space
Free	2	1
Supporter	5	3
Enterprise	10	5

Brauchst du mehr? Beantrage eine höhere Grenze auf der Seite des Space im Dashboard oder mit POST /api/spaces/{id}/limit-requests (die Ressource, der gewünschte Wert und eine kurze Begründung). Wir prüfen jeden Antrag von Hand und heben die Obergrenze am Space selbst an; dein Kontomodus ändert sich dadurch nicht.

Das Dashboard ist maßgeblich

Die Tabelle zeigt die heutigen Standardwerte. Das Dashboard zeigt immer die Grenzen, unter denen dein Space tatsächlich läuft; verlass dich darauf und nicht auf eine Zahl in einer Doku.

Erste Schritte

1. Lege einen Space mit der CLI an: Schreibe eine cluster.lok8s.yaml mit kind: Kubehz und spec.kubehz.hosting: shared, exportiere KUBEHZ_TOKEN (ein API-Token aus dem Dashboard, Zugriff → API-Tokens) und führe dann lo provision aus. Das Dashboard listet und verwaltet Spaces; ein Formular zum Anlegen hat es noch nicht.
2. Verbinde deine erste Node.
3. Deploye in deinen Namespace mit kubectl, genau wie überall sonst.

Vor etwas Statefulem lohnt sich ein Blick auf Speicher in einem Space. Was ein Space kostet, steht auf der Preisseite: Der erste Space, sein erster Namespace und zwei Nodes sind gratis.

Doku-Status

Aspekt	Detail
Zustand	Live: Spaces live; Obergrenzen je Kontomodus mit Limit-Anträgen; Preise veröffentlicht
Zuletzt geprüft	2026-09-05