PersistentVolume (PV) & Claim (PVC)

Als Entwickler schreibst du nur den PVC:

kind: PersistentVolumeClaim
metadata:
  name: my-db-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Und nutzt ihn im Pod:

volumes:
- name: data
  persistentVolumeClaim:
    claimName: my-db-claim

Kubernetes erstellt dank StorageClass (Dynamic Provisioning) automatisch eine echte Cloud-Disk (EBS) im Hintergrund. Du musst das PV nicht manuell anlegen.

Praxisroutine

In der Praxis lernst du PersistentVolume (PV) & Claim (PVC), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Access Modes (RWO vs RWX)

• ReadWriteOnce (RWO): Die Disk kann nur von einem Node gleichzeitig gemountet werden (Block Storage wie AWS EBS). Klassisch für Datenbanken.
• ReadWriteMany (RWX): Viele Nodes können gleichzeitig lesen/schreiben (NFS, EFS, GlusterFS). Nötig für skalierende Webserver mit Shared Assets.
• ReadWriteOncePod (RWOP): Neu (K8s 1.22). Noch strikter: Nur ein Pod darf mounten. (RWO erlaubt technisch, dass 2 Pods auf dem gleichen Node mounten, was Race Conditions erzeugt).

2. Reclaim Policy (Retain vs Delete)

Was passiert, wenn du den PVC löschst?

• Delete (Standard in Cloud): Die echte Disk (EBS) wird gelöscht. Daten weg!
• Retain: Das PV wird "Released", aber die Daten bleiben auf der Disk. Ein Admin muss manuell aufräumen oder das PV wieder "Available" machen. Wichtig für Production DBs!

3. CSI (Container Storage Interface)

Früher war der Code für "AWS EBS Mounten" fest im Kubernetes-Code ("In-Tree"). Das war unflexibel. Jetzt gibt es CSI. Speicheranbieter schreiben eigene Treiber Plugins (als Pods!). Das erlaubt Snapshots, Volume Cloning und Resizing im laufenden Betrieb ("Expand PVC"), ohne dass K8s geupdated werden muss.

Container Storage Interface (CSI) Architektur

Ursprünglich war die gesamte Logik, wie man eine NetApp oder AWS EBS Disk einhängt, als Go-Code fest in den Kube-Controller ("In-Tree") eingebacken. Ein Update von AWS verlangte ein Update von ganz Kubernetes. Das CSI koppelt Storage radikal ab ("Out-of-Tree"). Ein CSI-Treiber besteht aus zwei Pod-Komponenten: Dem CSI-Controller (läuft oft im kube-system Namespace und redet per API mit dem Cloud-Provider zur Disk-Erstellung) und dem CSI-Node-DaemonSet (läuft auf jedem Worker-Node). Kubelet ruft per gRPC lokal auf dem Node den CSI-Node-Pod auf: "Hey, mountiere mir Bitte das Gerät /dev/nvmeX in das Filesystem für Pod Y". Somit können Drittanbieter beliebigen Storage abstrahieren.

VolumeBindingMode (WaitForFirstConsumer)

Der absolute Flaschenhals im Zusammenspiel zwischen Pod-Scheduler und Cloud-Storage. Wenn eine StorageClass auf Immediate steht, triggert der PVC sofort die Cloud-Disk-Erstellung. Nehmen wir an, AWS baut eine EBS-Disk in der Region eu-central-1a. Danach versucht K8s den Pod zu schedulen. Entdeckt K8s nun, dass in 1a kein CPU-RAM mehr frei ist, muss der Pod in eu-central-1b starten. Katastrophe: Eine EBS-Disk aus 1a kann man nicht in einen Worker in 1b mounten! Der Pod hängt auf ewig in "Pending". Lösung: VolumeBindingMode: WaitForFirstConsumer. Der PVC erstellt die Disk nicht sofort. Er signalisiert dem Scheduler: "Schau erst, wo der Pod am sichersten landen kann (CPU, RAM, Tolerations)". Erst wenn die Node-Wahl (z. B. in 1b) absolut final feststeht, funkt K8s die Zone an den Storage-Provisioner und baut die Disk exakt im korrekten RZ in 1b.

In-Place Volume Expansion Control

Braucht deine DB plötzlich 200 GB statt 100 GB, nützt das Bearbeiten des PVC-Manifests nur dann etwas, wenn in der StorageClass allowVolumeExpansion: true steht. Doch Vorsicht unter der Haube: Die Cloud vergrößert nur das Block-Gerät physikalisch (das ist Schritt 1). Das Dateisystem auf dem Block (z. B. xfs oder ext4) ist noch immer 100 GB. Kubelet spürt den Resizing-Wunsch, wartet bis der Pod gemountet ist ("Online Expansion") und schickt dem Kernel den resize2fs (oder xfs_growfs) Befehl, um den Mountpoint live auszudehnen ("FileSystemResizePending"-Phase). CNI und CSI müssen dies vollends unterstützen, fehlschlagende File-Resizes können den Pod im Reboot einfrieren.