Zum Inhalt

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>

Default StorageClass

Pro Cluster gibt es höchstens eine Default-Klasse (storageclass.kubernetes.io/is-default-class: "true"). Ohne explizites storageClassName landet die PVC dort.

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