Speicher in einem Space
Speicher ist der eine Teil eines Space, über den man vor dem ersten statefulen Deployment entscheiden sollte, denn die ehrliche Antwort ist eine Auswahl und kein einzelner Standard.
Kurz gefasst: die Platten deiner Nodes gehören dir und kosten nichts extra. Alles andere ist ein Abwägen zwischen Komfort, Haltbarkeit und Preis.
Die Auswahl
1. Lokale Platten — kostenlos und deine
Deine Nodes haben Festplatten. Ein Pod kann sie nutzen, und daran ist weder kubehz beteiligt noch kostet es etwas über die Maschine hinaus, die du ohnehin bezahlst.
Gut für: Caches, Scratch-Space, Build-Artefakte, alles, dessen Verlust egal ist, und Single-Node-Datenbanken, wenn du den Handel akzeptiert hast.
Der Handel: ein lokales Volume hängt an der Maschine, auf der es liegt. Stirbt diese Node, liegen die Daten auf einer toten Maschine, und ein Pod, der sie braucht, startet anderswo nicht. Es gibt keine Replikation, außer deine Anwendung macht sie selbst. Kubernetes löst das nicht für dich, und wir auch nicht.
Sichere sie selbst. Niemand sonst sichert die Platte deiner Node.
2. Angehängte Block-Volumes — haltbar, weiterhin deine
Sind deine Maschinen Hetzner-Cloud-VMs, kannst du ein Hetzner Cloud Volume an eine Node hängen, mounten und wie eine lokale Platte nutzen, die die Maschine überlebt. Du kaufst und verwaltest das Volume; kubehz ist nicht beteiligt und berechnet es nicht.
Gut für: Datenbanken und alles, wo der Verlust der Node nicht den Verlust der Daten bedeuten darf.
Der Handel: das Volume hängt an einer Node zur Zeit. Es auf eine andere zu verschieben, ist heute ein manueller Schritt: anhängen, mounten, den Pod neu einplanen lassen. Für eine Datenbank, die du ohnehin bewusst verschieben würdest, ist das in Ordnung; ein transparentes Failover ist es nicht.
Das sauber zu automatisieren braucht einen Storage-Treiber, der in deinem Namen auf deinem Cloud-Konto handeln kann, ein größeres Stück Arbeit, als es aussieht. Es steht auf der Roadmap; das manuelle Rezept funktioniert jetzt.
3. Objektspeicher: der, der mitreist
S3-kompatiblem Objektspeicher ist egal, auf welcher Node dein Pod läuft, was ihn zur natürlichen Wahl in einem Modell macht, in dem Nodes kommen und gehen. Heute bringst du deinen eigenen Bucket mit (Hetzner Object Storage oder ein beliebiger S3-Endpunkt); ein von kubehz ausgestellter Bucket mit Zugangsdaten nur für deinen Space ist geplant, nicht ausgeliefert.
Gut für: Uploads, Backups, Artefakte, statische Assets: alles, was deine Anwendung über HTTP ansprechen kann.
Der Handel: es ist Objektspeicher, kein Dateisystem. Deine Anwendung muss S3 sprechen.
Geplant
Die von kubehz bereitgestellten Objektspeicher-Pakete und ihre Preise sind nicht final. Nichts hier ist eine Preiszusage; bis sie ausgeliefert sind, nimm einen eigenen Bucket.
4. Netzwerk-Blockspeicher — später
Replizierter Blockspeicher von den Nodes der Plattform, mit einem Volume je Mandant und Zugangsdaten, die nur an deine Daten kommen. Latenz innerhalb der Region, also passend für moderate IO.
Das ist geplant, nicht ausgeliefert. Wenn es kommt, wird es dem „funktioniert einfach" für stateful Workloads in einem Space am nächsten kommen.
Auswählen
| Du betreibst | Beginne mit |
|---|---|
| Einen zustandslosen Dienst | Nichts: Du brauchst keinen Speicher |
| Caches, Scratch, Build-Zustand | Lokale Platte |
| Eine Datenbank, die du ohnehin von Hand verschieben würdest | Angehängtes Block-Volume |
| Uploads, Backups, Artefakte | Objektspeicher |
| Etwas, das jede einzelne Node transparent überleben muss | Auf Netzwerk-Blockspeicher warten oder einen eigenen Cluster nehmen |
Was wir nicht tun
Wir sichern deine Daten nicht. Weder lokale Platten noch angehängte Volumes. Wir betreiben die Control Plane (die Kubernetes-Objekte, die deine Workloads beschreiben), und genau die schützen wir. Die Bytes in deinen PersistentVolumes gehören dir, liegen auf deinen Maschinen und unterliegen deiner Backup-Politik.
Wenn sich das für dein Vorhaben unangenehm anfühlt, ist das ein echtes Signal: erwäge einen gehosteten Cluster, wo die Speichergeschichte unsere ist, oder halte den statefulen Teil woanders verwaltet und betreibe den zustandslosen hier.
Doku-Status
| Aspekt | Detail |
|---|---|
| Zustand | Live: lokale Platten und angehängte Volumes wie beschrieben; von kubehz bereitgestellter Objektspeicher und Netzwerk-Blockspeicher geplant, nicht ausgeliefert |
| Zuletzt geprüft | 2026-09-05 |