# Kubernetes Storage: Persistenz, Volumes & CSI-Schnittstellen

TL;DR / Management Summary Ein Pod (Artikel 812) hat standardmäßig kein Gedächtnis. Um Daten über Neustarts und Host-Ausfälle hinweg zu retten, benötigt Kubernetes Persistent Volumes (PV). Wir nutzen das CSI (Container Storage Interface), um Proxmox-Speicher (ZFS/Ceph) oder externe NAS-Systeme (NFS) anzubinden. Ein Senior Admin nutzt StorageClasses, damit Applikationen ihren Speicherplatz vollautomatisch und “on-demand” anfordern können, ohne dass der Admin für jede VM manuell eingreifen muss.

# 1. Die drei Säulen des K8s Storage

Trennung von Bedarf und Angebot.

  1. Persistent Volume (PV): Das physische Angebot. (z.B. eine 100 GB LUN auf dem Ceph-Cluster).
  2. Persistent Volume Claim (PVC): Die Anforderung des Entwicklers. “Ich brauche 10 GB Speicher mit Read-Write-Zugriff”.
  3. StorageClass (SC): Der Vermittler. Definiert, welcher Treiber (Provisioner) genutzt wird, um das PV automatisch zu erstellen.

# 2. Access Modes: Wer darf schreiben?

Den Zugriff steuern.

Nicht jeder Speicher unterstützt jeden Zugriffstyp:

# 3. Deep Dive: CSI (Container Storage Interface)

Die universelle Steckdose.

CSI ist der Standard, mit dem Kubernetes mit Storage-Herstellern spricht.

# 4. Day-2 Operations: Backup von PVs

Sicherheit für die Claims.

Sichern Sie die Daten unterhalb von Kubernetes.

# 5. Troubleshooting & “War Stories”

Wenn der Mount-Point ‘hängt’.

# Top 3 Fehlerbilder

  1. Symptom: Pod bleibt im Status ContainerCreating.

    • Ursache: Das PVC kann nicht gemountet werden (“Multi-Attach Error”).
    • Lösung: Prüfen Sie, ob ein alter Pod auf einem anderen Knoten das Volume noch sperrt. (Node-Drain Problem).

  2. Symptom: “StorageClass not found”.

    • Ursache: Tippfehler im YAML oder der Provisioner-Dienst ist abgestürzt.

  3. Symptom: Datenverlust nach Pod-Neustart.

    • Ursache: Die Applikation nutzt fälschlicherweise emptyDir (flüchtig) statt eines PVCs.

# “War Story”: Der “Stale” NFS-Mount

Ein Admin betrieb einen WordPress-Cluster auf Kubernetes und nutzte NFS für die Bilder. Das Ereignis: Das NAS (Artikel 657) startete nach einem Update neu. Das Ergebnis: Alle Kubernetes-Knoten verloren den Kontakt zum NFS. Da der Linux-Kernel standardmäßig bei NFS-Timeouts blockiert (“Stale File Handle”), hingen alle Pods fest. Ein einfacher Neustart der Pods half nicht, da die Mount-Points auf den Host-Systemen (den VMs) korrupt waren. Lehre: Nutzen Sie für Netzwerk-Storage in Kubernetes immer CSI-Treiber mit aktivem Monitoring, die Mount-Fehler erkennen und die betroffenen Knoten automatisch neu initialisieren.

# 6. Monitoring & Reporting

Füllstände im Cluster.

# Storage Dashboards

Überwachen Sie via Prometheus:

# 7. Fazit & Empfehlung

Storage ist der komplizierteste Teil von Kubernetes.

# Anhang: Cheatsheet (kubectl storage)

Aufgabe Befehl
PVs auflisten kubectl get pv
PVC Status kubectl get pvc
StorageClasses kubectl get sc
Volume Details kubectl describe pv <name>

# Referenzen