18 Persistent Volume und Persistent Volume Claim in Kubernetes

Persistent Volumes (PV) und Persistent Volume Claims (PVC) stellen in Kubernetes dauerhafte Speicherkapazitäten zur Verfügung, die im Gegensatz zu ephemeren Volumen wie EmptyDir eine langfristige Datenpersistenz ermöglichen. Durch die Abstraktion der Speicherressourcen von den eigentlichen Pods vereinfachen PV und PVC die Speicherzuweisung und -verwaltung und gewährleisten eine effiziente und zuverlässige Datenhaltung.

18.1 Eigenschaften von Persistent Volumes

• Lebenszyklus: Unabhängig von Pods, sie existieren über den Lebenszyklus eines Pods hinaus.
• Speicher-Backends: Unterstützung für verschiedene Speicherlösungen wie NFS, iSCSI, AWS EBS und mehr.
• Kapazität und Zugriffsmodi: Definiert durch die PV-Spezifikation.

18.2 Eigenschaften von Persistent Volume Claims

• Speicheranforderung: Ein PVC fordert eine bestimmte Menge an Speicher und bestimmte Zugriffsmodi.
• Bindung: Ein PVC wird an ein verfügbares PV gebunden, das die Anforderungen erfüllt.
• Wiederverwendung: Einmal gebunden, kann das PVC von verschiedenen Pods verwendet werden.

18.3 PVC Lifecycles und Policies

18.3.1 Retain Policy

• Verhalten: Das Volume bleibt erhalten, nachdem das PersistentVolumeClaim (PVC) gelöscht wurde.
• Anwendungsfall: Ideal für Szenarien, in denen Daten über den Lebenszyklus des PVCs hinaus bestehen bleiben sollen, z.B. für Backups oder Archivierung.
• Prozess:
  • Das PVC wird gelöscht.
  • Das zugehörige PersistentVolume (PV) bleibt unverändert und ist im Zustand Released.
  • Administrator muss das Volume manuell wiederverwenden oder löschen.

18.3.2 Delete Policy

• Verhalten: Das Volume wird automatisch gelöscht, sobald das PVC gelöscht wird.
• Anwendungsfall: Geeignet für dynamische Umgebungen, in denen Volumes temporär genutzt werden, wie etwa in Entwicklungs- oder Testumgebungen.
• Prozess:
  • Das PVC wird gelöscht.
  • Das zugehörige PV löscht auch das dahinterliegende Storage im Backend.
  • Keine manuelle Bereinigung notwendig.

18.3.3 Recycle Policy

• Verhalten: Das Volume wird bereinigt (z.B. Daten werden gelöscht), um es für eine erneute Verwendung vorzubereiten.
• Anwendungsfall: Praktisch, wenn Volumes zwischen verschiedenen Projekten oder Nutzern wiederverwendet werden sollen, ohne dass sensible Daten übertragen werden.
• Prozess:
  • Das PVC wird gelöscht.
  • Das PV führt einen Clean-up-Prozess durch, wie etwa das Löschen von Daten auf dem Volume.
  • Nach Bereinigung steht das PV im Zustand Available für neue PVCs zur Verfügung.

Hinweis: Die Recycle Policy wird als veraltet betrachtet und ist in neueren Kubernetes-Versionen nicht mehr empfohlen. Stattdessen wird die Verwendung von StorageClass-Objekten mit der Delete Policy oder anderen dynamischen Provisionierungsmethoden empfohlen. ## Konfigurationsbeispiel

18.3.4 Persistent Volume

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  nfs:
    path: /var/lib/nfs/data
    server: 10.0.0.2

18.3.5 Persistent Volume Claim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard

In diesem Beispiel:

• Ein PV mit 10Gi Kapazität wird erstellt und über NFS bereitgestellt.
• Ein PVC fordert 5Gi Speicher und wird an das vorhandene PV gebunden.

18.4 Einschränkungen und Überlegungen

• Speicherklasse: Beide, PV und PVC, sollten die gleiche StorageClass haben, um gebunden zu werden.
• Reclaim Policy: Bestimmt, was mit dem PV passiert, wenn das PVC gelöscht wird. Optionen sind Retain, Delete und Recycle.
• Zugriffsmodi: Sowohl PV als auch PVC müssen kompatible Zugriffsmodi haben.