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) oder ReadWriteMany (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.