Archiviazione in uno Spazio
L’archiviazione è la parte di uno Spazio su cui conviene decidere prima di fare il deploy di qualcosa con stato, perché la risposta onesta è un menù e non un unico default.
In breve: i dischi dei tuoi nodi sono tuoi e non costano nulla in più. Tutto il resto è un compromesso tra comodità, durabilità e prezzo.
Il menù
1. Dischi locali — gratis, e tuoi
I tuoi nodi hanno dischi. Un pod può usarli, e in questo non c’è kubehz né un costo oltre la macchina che già paghi.
Buono per: cache, spazio scratch, artefatti di build, tutto ciò la cui perdita non ti dispiace, e database su singolo nodo, se hai accettato il compromesso.
Il compromesso: un volume locale è legato alla macchina su cui vive. Se quel nodo muore, i dati sono su una macchina morta, e un pod che ne ha bisogno non parte altrove. Non c’è replica, a meno che non la faccia la tua applicazione. Kubernetes non lo risolve per te, e nemmeno noi.
Fai tu il backup. Nessun altro sta salvando il disco del tuo nodo.
2. Volumi a blocchi collegati — durevoli, sempre tuoi
Se le tue macchine sono VM Hetzner Cloud, puoi collegare un Hetzner Cloud Volume a un nodo, montarlo e usarlo esattamente come un disco locale che sopravvive alla macchina. Il volume lo compri e lo gestisci tu; kubehz non è coinvolto e non lo fattura.
Buono per: database e tutto ciò dove perdere il nodo non deve significare perdere i dati.
Il compromesso: il volume si collega a un nodo alla volta. Spostarlo su un altro è oggi un passo manuale: collega, monta, lascia ripianificare il pod. Per un database che sposteresti comunque di proposito va bene; un failover trasparente non è.
Automatizzarlo per bene richiede un driver di storage che possa agire sul tuo account cloud per tuo conto: un lavoro più grande di quel che sembra. È nella roadmap; la ricetta manuale funziona adesso.
3. Object storage: quello che viaggia con te
All’object storage compatibile S3 non importa su quale nodo giri il tuo pod, il che lo rende la scelta naturale in un modello dove i nodi vanno e vengono. Oggi porti il tuo bucket (Hetzner Object Storage o qualsiasi endpoint S3); un bucket emesso da kubehz con credenziali limitate al tuo Spazio è pianificato, non rilasciato.
Buono per: upload, backup, artefatti, asset statici: tutto ciò che la tua applicazione può indirizzare via HTTP.
Il compromesso: è object storage, non un filesystem. La tua applicazione deve parlare S3.
Pianificato
Pacchetti e prezzi dell’object storage fornito da kubehz non sono definitivi. Nulla qui è un impegno di prezzo; finché non arrivano, usa un bucket tuo.
4. Storage a blocchi di rete — più avanti
Storage a blocchi replicato servito dai nodi della piattaforma, con un volume per tenant e credenziali che raggiungono solo i tuoi dati. Latenza nella stessa regione, quindi adatto a IO moderati.
È pianificato, non consegnato. Quando arriverà sarà la cosa più vicina a “funziona e basta” per i carichi con stato in uno Spazio.
Scegliere
| Stai eseguendo | Parti da |
|---|---|
| Un servizio stateless | Niente: non ti serve archiviazione |
| Cache, scratch, stato di build | Disco locale |
| Un database che sposteresti comunque a mano | Volume a blocchi collegato |
| Upload, backup, artefatti | Object storage |
| Qualcosa che deve sopravvivere in modo trasparente a qualsiasi singolo nodo | Aspetta lo storage a blocchi di rete, o prendi un cluster tuo |
Cosa non facciamo
Non facciamo il backup dei tuoi dati. Né dischi locali né volumi collegati. Noi gestiamo il control plane (gli oggetti Kubernetes che descrivono i tuoi carichi), ed è quello che proteggiamo. I byte dentro i tuoi PersistentVolume sono tuoi, sulle tue macchine, sotto la tua politica di backup.
Se questo è scomodo per quello che stai costruendo, è un segnale vero: valuta un cluster hosted, dove la storia dello storage è nostra, oppure tieni la parte con stato altrove gestita ed esegui qui quella stateless.
Stato del documento
| Aspetto | Dettaglio |
|---|---|
| Stato | live: dischi locali e volumi collegati come descritto; object storage fornito da kubehz e block storage di rete pianificati, non rilasciati |
| Ultima revisione | 2026-09-05 |