StorageClass (K8s)

YAML:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: ebs.csi.aws.com # Der "Koch" (Treiber)
parameters:
  type: gp3
  iops: "3000"
reclaimPolicy: Delete
allowVolumeExpansion: true

Wenn du keine Klasse im PVC angibst, nimmt K8s die default StorageClass (Markiert mit Annotation: storageclass.kubernetes.io/is-default-class: "true"). Prüfe immer: kubectl get sc.

1. WaitForFirstConsumer (VolumeBindingMode)

Das wichtigste Feature für Multi-Zone Cluster. Standard: Immediate. Du erstellst PVC. K8s erstellt sofort eine EBS-Disk in Zone eu-central-1a. Dann startest du den Pod. Der Scheduler merkt: "Ups, Node 1a ist voll. Ich muss Node 1b nehmen." Der Pod landet in 1b. Aber die Disk ist in 1a! AWS erlaubt kein Cross-Zone Mounting. Ergebnis: Pod hängt für immer (VolumeNodeAffinityConflict). Lösung: volumeBindingMode: WaitForFirstConsumer. K8s wartet mit dem Erstellen der Disk, bis der Scheduler entschieden hat, wo der Pod läuft. Dann erstellt er die Disk in der richtigen Zone.

2. Reclaim Policy (Retain!)

Standard StorageClasses (GKE/EKS) haben oft reclaimPolicy: Delete. Wenn du den PVC löschst, löscht AWS die Disk. Für Produktions-Datenbanken willst du das nicht! Erstelle eine eigene StorageClass fast-retain mit reclaimPolicy: Retain. Selbst wenn ein Junior-Admin kubectl delete pvc db tippt, bleibt die Disk bei AWS erhalten (als "orphaned"). Dein Job gerettet.

3. CSI Parameters

Jeder Provider hat eigene Parameter.

• AWS: type: io1, iopsPerGB: 50.
• Azure: skuName: Premium_LRS.
• NFS: server: 192.168.1.5. Du kannst StorageClasses nutzen, um dem User Optionen zu geben, ohne dass er die Details (IPs) kennen muss.

VolumeBindingMode: Das Scheduling-Nadelöhr

Das zentrale Problem beim Storage in großen Clustern ist die physische Limitierung von Block Storage (wie AWS EBS). Eine EBS-Disk in Availability Zone eu-central-1a kann technisch unmöglich an einen Worker Node in eu-central-1b gehängt werden. Wenn die StorageClass auf Immediate steht, triggert der K8s-Provisioner die Anlage der Cloud-Disk sofort beim Erstellen des PVCs in einer vom Zufall diktierten AZ. Findet Kubelet dann aber heraus, dass in 1a CPU/RAM fehlt und der Pod zwingend nach 1b muss, stirbt das Scheduling ("Pending" Hölle). Die Lösung ist WaitForFirstConsumer. Die Disk-Erstellung ruht auf Kubernetes-Seite solange, bis der Pod-Scheduler 100% evaluiert hat (anhand CPU-Node-Affinity oder Taints), auf welchem physischen Node (und damit AZ) der Pod definitiv landen wird. Erst dann diktiert der Scheduler dem CSI-Treiber: Erzeuge die Storage genau dort.

CSI Topology-Aware Storage

Was "WaitForFirstConsumer" vorbereitet, wird durch CSI Topology in die Cloud übersetzt. Moderne CSI-Treiber hängen bei der Node-Registrierung topologische Meta-Labels an die K8s-Nodes (z. B. topology.kubernetes.io/zone=us-east-1a). Wenn in der StorageClass nun allowedTopologies definiert ist, kann K8s den Storage-Provisioner zwingen, SSDs ausschließlich in einer hochsicheren AZ anzulegen. Dies verhindert, dass Applikationen über Kontinente stretchen (Datenlokalität und DSGVO-Regulierungen).

Volume Expansion & FS-Resize Events

Szenario: Eine 100 GB Postgres DB wird hart ans Limit gefahren. Man aktualisiert den PVC im laufenden Betrieb: requests.storage: 200Gi. Voraussetzung 1: Die StorageClass muss allowVolumeExpansion: true besitzen, sonst verweigert der API-Server das Update als "Forbidden". Voraussetzung 2: Der komplexe 2-Step CSI Lifecycle. Erst ruft der Cloud-Controller bei der Cloud (AWS) an, um das Backend-Blockgerät zu strecken ("ControllerResize"). Wenn dies geglückt ist, steht die Blockdisk auf 200GB, aber das Dateisystem (ext4) ist noch auf 100GB. Im Step 2 spürt Kubelet via CSI-Node-Agent dies und feuert live im laufenden Mount den Dateisystem-Resize-Befehl (resize2fs). Manchmal frieren Dateisysteme beim live Resizen ein, weshalb Production-Ops das lieber manuell bei Traffic-Pausen anstoßen.