Kubernetes Storage — Volumes, PersistentVolumes & Claims

In diesem Modul (70 Minuten Input, 30 Minuten Hands-on) klärt ihr die Frage, die jedem zustandsbehafteten Workload vorausgeht: Welche Daten überleben einen Pod-Neustart – und welche nicht? Kurzer Rückblick auf emptyDir, das ihr bereits im Modul Anwendungsdesign als Sidecar-Sharing-Mechanismus gesehen habt, dann hostPath als node-gebundenes Volume mit klarer Einschränkung für produktive Multi-Node-Cluster. Der eigentliche Kern des Moduls ist die Unterscheidung zwischen einfachen Volumes (an Pod oder Node gebunden, kein eigenständiges Kubernetes-Objekt) und einem PersistentVolume (PV) – einem eigenständigen Cluster-Objekt für Speicher, dessen Lebenszyklus unabhängig vom Pod ist und das entweder vom Administrator vorab angelegt oder dynamisch über eine StorageClass provisioniert wird. Damit ein Pod ein PV nutzen kann, braucht er eine PersistentVolumeClaim (PVC): die Anforderung eines Pods an Speicher (Größe, accessModes wie ReadWriteOnce), die Kubernetes einem passenden PV zuordnet – erst mit dieser Zuordnung wird die PVC gültig. Im Hands-on legt ihr auf einem lokalen Minikube-Cluster eine PVC an, startet einen Pod damit, schreibt Daten hinein, löscht den Pod wieder und erstellt ihn neu – und weist live nach, dass die Daten erhalten bleiben. Genau das ist der Unterschied zu emptyDir, den dieses Modul greifbar macht. Voraussetzung ist das Modul “Kubernetes Workloads & Konfiguration” – die Session läuft weiterhin vollständig lokal über Minikube, ohne Cloud-Account und ohne Kostenwirkung.