Ein Service bekommt Volumes mit Mount-Pfad, Größe und Storage-Klasse. Clusterward legt die Claims an, plant Snapshots mit Aufbewahrung und löscht Daten nur nach einem bestätigten Snapshot.
Ein Volume in Clusterward ist ein persistenter Datenträger eines Services: ein PersistentVolumeClaim auf Scaleway Block Storage mit Name, Mount-Pfad, Größe und Storage-Klasse, der vor dem Deployment angelegt und in den Container eingehängt wird. Snapshots sind Scaleway-Block-Storage-Snapshots des Datenträgers hinter dem Claim, nach Zeitplan mit Aufbewahrung in Tagen oder einmalig vor dem Löschen. Undeploy lässt Volumes unberührt, ein Service mit Volumes kann nicht gelöscht werden, und der einzige Weg, Daten loszuwerden, führt über einen bestätigten Snapshot.
Name, Mount-Pfad, Größe, Storage-Klasse und optional der Snapshot-Plan.
Beim Deployment entsteht der Claim vor dem Deployment und wird eingehängt.
Ein stündlicher Lauf erstellt fällige Snapshots ausgerollter Services.
Abgelaufene Snapshots werden nur aus Clusterwards eigener Liste gelöscht.
Erst ein Snapshot, der bereit sein muss, dann der Claim, dann das Volume.
Die Regeln, die man bei Block Storage auf Kubernetes einmal schmerzhaft lernt, sind hier eingebaut.
Jedes Volume wird ein eigener Claim mit Namen aus Release und Volume, vor dem Deployment angelegt. Mount-Pfade dürfen sich nicht überlappen, Namen sind eindeutig.
Ein Deployment mit Volumes nutzt die Strategie Recreate, weil ein Rolling Update auf einem Single-Attach-Datenträger stehen bleibt. Die Skalierung ist auf eine Instanz gepinnt.
Pro Volume ein Zeitplan und eine Aufbewahrung in Tagen. Snapshots entstehen als Scaleway-Block-Storage-Snapshots, erscheinen in der Konsole und lassen sich im Cockpit per Klick wiederherstellen.
Die Größe eines Volumes kann steigen, nie sinken, und die Storage-Klasse bleibt fest. Ein Volume aus der Liste zu entfernen wird verweigert.
Undeploy rührt keinen Claim an. Ein Service mit Volumes lässt sich nicht löschen, bis seine Daten ausdrücklich entfernt wurden.
Der einzige Weg: Volume-Daten löschen, mit Eintippen bestätigt, bei nicht ausgerolltem Service. Ein Snapshot muss bereit sein, bevor der Claim geht.
Die Claims, die ein Chart selbst anlegt – auch die einer Datenbank im StatefulSet –, erscheinen auf der Volumes-Karte des Helm-Services, markiert als „from the chart“, mit Mount-Pfad und Größe. Snapshots sofort oder nach Zeitplan.
Beim Zurückspielen stoppt Clusterward jedes Deployment und StatefulSet, das die Festplatte nutzt, sichert den aktuellen Stand und legt den Claim mit den Metadaten von Helm neu an. Das nächste Upgrade kennt ihn weiter als seinen.
Eine Festplatte, die das Chart beim Deinstallieren zurücklässt, bleibt sichtbar und lässt sich löschen – mit einem letzten Snapshot vorher.
Datenträger und Snapshots über die Scaleway-API, zonenbezogen.
Der Datenträger wird über PVC, PV und CSI-Handle aufgelöst.
Das Löschen des Claims überlässt den Datenträger der Klasse.
Optional pro Volume, damit Nicht-Root-Container schreiben dürfen.
Jede Regel entspricht einem Fehler, der auf Block Storage sonst Daten kostet.
| Regel | Verhalten |
|---|---|
| Skalierung | Fest, genau eine Instanz, kein Autoscaler |
| Strategie | Recreate statt RollingUpdate |
| Größe | Nur vergrößern |
| Storage-Klasse | Nach der Erstellung unveränderlich |
| Volume entfernen | Nur über „Volume-Daten löschen“ mit Snapshot |
| Undeploy | Claims bleiben bestehen |
| Snapshot-Löschung | Nur Einträge aus Clusterwards Liste |
| Helm-Chart-Festplatten | Snapshots und Wiederherstellung wie bei eigenen Volumes; die Größe bestimmt das Chart |
| Snapshot-Status | Etwa eine Minute nach Fertigstellung bei Scaleway als bereit angezeigt |
Volumes gehören zum Service und werden mit jedem Deployment angelegt oder vergrößert. Snapshots brauchen den Block-Storage-Berechtigungssatz im Provisioning-Profil des Clusters, siehe Cluster-Provisioning.
Umgebungs-Bausteine einer Pipeline tragen ebenfalls Volumes, im Designer unter „Volumes (optional)“; ihr Rollback sichert jede Platte per Snapshot, bevor er abbaut, beschrieben unter Tenant-Pipelines.
Welche Festplatten ein Helm-Chart anlegt und was helm uninstall mit ihnen macht, erklärt der Beitrag Helm-Charts und ihre Festplatten.
Git, Container-Image oder Helm-Chart – mit Health-Check ausgerollt.
Zu DeploymentsPostgres und MySQL privat angebunden, eine Datenbank pro Service.
Zu Managed DatenbankenKunden-Onboarding als Bausteine, in unter einer Minute live.
Zu Tenant-PipelinesAlles, was Dateien auf einer Festplatte erwartet: Upload-Ordner eines CMS, Suchindizes, Caches, kleine Datenbanken in Containern. Für relationale Daten empfiehlt sich eine Managed Datenbank; Volumes decken den Rest ab.
Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir hängen einem Service ein Volume an, planen Snapshots und zeigen den geschützten Löschweg.
