Ein PersistentVolumeClaim (PVC) ist in Kubernetes die Speicher-Anfrage einer Anwendung: Er beschreibt, wie viel Speicher und welche Zugriffsart ein Pod benötigt. Kubernetes sucht dazu ein passendes PersistentVolume (PV) und bindet den Claim an dieses Volume. Der Claim lebt in einem Namespace, das PV ist clusterweit.
Ein PVC anlegen
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: daten-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
Wichtige Felder:
- accessModes:
ReadWriteOnce(ein Knoten beschreibend),ReadOnlyMany(mehrere Knoten lesend) oderReadWriteMany(mehrere Knoten lesend und schreibend). - resources.requests.storage: die gewünschte Größe, etwa
10Gi. - storageClassName: wählt die StorageClass; fehlt das Feld, greift die als Standard markierte Klasse.
Statische und dynamische Bereitstellung
Bei der statischen Bereitstellung legt ein Administrator vorab PVs an; der PVC wird an ein passendes freies PV gebunden. Bei der dynamischen Provisionierung erzeugt eine StorageClass auf Wunsch automatisch ein neues PV samt Backend-Speicher. Ohne passendes PV bleibt der Claim im Zustand Pending, bis Speicher verfügbar ist.
Volumes im Pod nutzen
volumes:
- name: daten
persistentVolumeClaim:
claimName: daten-claim
Der Pod referenziert den Claim über persistentVolumeClaim.claimName und mountet ihn mit einem volumeMounts-Eintrag. Wird der Pod gelöscht, bleibt der PVC erhalten – ein neuer Pod kann denselben Claim verwenden und auf die Daten zugreifen. Typische Nutzer sind StatefulSets, die mit volumeClaimTemplates für jeden Pod einen eigenen Claim erzeugen.
Der Lebenszyklus eines PV läuft nach dem Löschen des Claims je nach Reclaim-Policy weiter: Retain bewahrt die Daten, Delete entfernt das PV samt Backend. Ganz anders die flüchtigen Volume-Typen: Ein emptyDir ist reiner Zwischenspeicher für die Pod-Laufzeit, ein hostPath hängt direkt einen Node-Pfad ein. Nur der PVC bietet Speicher, der unabhängig von Pod und Knoten weiterlebt.