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 sind drei Zahlen, und alle drei setzt du selbst mit einem Schieberegler auf der Seite des Space im Dashboard. Es gibt keine Pläne und keine Größen:

Zahl	Bereich	Was sie setzt
Nodes	1 bis 5	wie viele Maschinen du registrieren darfst
Namespaces	1 bis 3	wie viele Namespaces der Space hält
Objektgrößen-Limit	64 bis 512 KiB, mit hinterlegter Zahlungsmethode	das größte Secret und die größte ConfigMap, die deine Namespaces annehmen

Das Objektgrößen-Limit startet bei 256 KiB. Es hält einen Kunden davon ab, den Datenspeicher der geteilten Control Plane mit ein paar großen Objekten zu füllen, und es ist die einzige Zahl ohne Preis: Mit einer hinterlegten Zahlungsmethode schiebst du sie überall im Bereich hin, ohne eine bleibt sie auf dem Standard, egal in welchem Kontomodus du bist. Helm ist die Ausnahme: Ein Helm-Release-Secret behält das 1-MiB-Limit von Kubernetes selbst, egal was das Limit sagt.

Was das kostet. Ein Konto bekommt ein Space umsonst, und jeder Space enthält 2 Nodes, seinen ersten Namespace und das Limit von 256 KiB. Ohne hinterlegte Zahlungsmethode bleibt ein Konto bei diesen Zahlen, egal in welchem Modus. Hinterlege eine, dann schiebst du jeden Regler bis ans Maximum, und der Zähler berechnet jeden Node und jeden Namespace über dem, was der Space enthält, stündlich und monatlich gedeckelt; siehe Preise.

Über dem Maximum? Mehr als 5 Nodes oder mehr als 3 Namespaces sind ein eigener Cluster, kein größerer Space: Nimm die gehostete Control Plane, bei der du die Form setzt und die Worker auf deinem Hetzner-Konto bleiben.

Das Dashboard ist maßgeblich

Das Dashboard zeigt immer die Zahlen, 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: ein Space je Konto ist gratis, mit 2 Nodes und dem ersten Namespace inklusive.

Doku-Status

Aspekt	Detail
Zustand	Live: Spaces live; Nodes, Namespaces und Objektgrößen-Limit je Space gesetzt; Preise veröffentlicht
Zuletzt geprüft	2026-09-18