Platform Storage

Platform Storage

StorageClasses, Volume Expand, IOPS und Backup vs. CSI-Snapshots. Komponenten: SDP Storage.

StorageClasses (Katalog)

Welche Klassen in einem konkreten Cluster sichtbar sind, hängt vom Betriebsmodell und den installierten CSI-Blöcken ab. Typische Namen:

StorageClass (Beispiel) Backend Access Mode Typische Nutzung
hcloud-volumes Hetzner Cloud CSI RWO ayedo Cloud / Hetzner-VMs — Volume pro Node-Attachment
longhorn / Varianten Longhorn CSI RWO (RWX je nach Config) Hyperconverged Block, Snapshots/Backups im Longhorn-Stack
ceph-rbd / Ceph-RBD Rook/Ceph RWO Verteiltes Block-Storage
cephfs / CephFS Rook/Ceph RWX Shared File für mehrere Pods 
kubectl get storageclass
kubectl describe storageclass <name>

Dynamic Provisioning

  1. PVC mit gewünschter Größe und StorageClass anlegen
  2. CSI provisioniert das Volume beim ersten bindenden Pod (oder sofort, je nach Binding-Mode)
  3. Pod mountet das Volume; Resize und Lifecycle laufen über die PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: hcloud-volumes   # oder longhorn / ceph-rbd
  resources:
    requests:
      storage: 20Gi

Volume Expand

  • Die meisten SDP-StorageClasses erlauben nur Vergrößern (allowVolumeExpansion: true), kein Shrink.
  • Ablauf: PVC .spec.resources.requests.storage erhöhen → Controller/CSI expandiert → Dateisystem wächst nach (bei manchen Treibern erst nach Pod-Restart oder File-System-Resize im Node).

Downtime-Erwartung:

Backend Typische Auswirkung beim Expand
Hetzner CSI (hcloud-volumes) oft kurzzeitig I/O-Pause oder Pod-Restart nötig, bis das FS die neue Größe sieht
Longhorn Expand online möglich; kurze I/O-Delle möglich
Ceph RBD Expand meist online; Abhängigkeit von FS-Typ im Pod

Plane kritische Expands außerhalb der Produktivspitze und prüfe danach kubectl get pvc sowie die App-seitige freie Kapazität.

IOPS und Performance

  • Bei Cloud-Volumes (z. B. Hetzner) skaliert die IOPS-/Durchsatzklasse oft mit der Volume-Größe und dem Produkt-SKU — nicht mit der Pod-CPU allein.
  • Bei Longhorn/Ceph bestimmen Replica-Anzahl, Disk-Typ der Nodes und Netz die Latenz; „mehr GiB“ allein garantiert keine höheren IOPS.
  • Für Lasttests: Messwerte im Cluster (z. B. Grafana/VictoriaMetrics) statt Annahmen aus anderen Clouds übernehmen.

Snapshots vs. Backup

Mechanismus Verfügbar? Empfehlung
Kubernetes VolumeSnapshot (CSI) Hetzner CSI: in der Regel nicht für plattformweite Snapshot-CRDs vorgesehen Nicht als Backup-SoT erwarten
Longhorn Snapshots / Recurring Jobs ja (Longhorn-eigen) ergänzend, nicht Ersatz für Cluster-Backup
Velero + PVC/Volume-Backup ja (SDP-Standard) empfohlen für app-/clusterweite Sicherung

Managed-Backup-Defaults (Frequenz, Retention): Leistungsanhang zu den AGB. Velero/Restore: Disaster Recovery · Compliance: Backup & BCDR (Portal).

Quotas und Limits

Cluster- und Namespace-Grenzen steuern, wie viel Storage Tenants anfordern dürfen:

  • ResourceQuota / LimitRange auf Namespace-Ebene
  • Node- und Backend-Kapazität (siehe Kapazitätsplanung)
kubectl describe resourcequota -n <namespace>

Bei „Pending“-PVCs zuerst StorageClass, Quota und freie Backend-Kapazität prüfen — nicht nur die PVC-YAML.

Shared Responsibility (kurz)

ayedo Kunde
CSI-/Storage-Stack betreiben, Default-Klassen bereitstellen passende StorageClass und Größe wählen
Managed Backups im vereinbarten Scope (Velero/DB) Expand planen, App-seitige FS-Checks
eigene Snapshot-/App-Backup-Logik, wenn Partial Restore nötig

Weiterführend