19 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.

19.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.

19.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.

19.3 PVC Lifecycles und Policies

19.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.

19.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.

19.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

19.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

19.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.

19.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.

19.5 Beispiel Storage class

In diesem Beispiel wird eine Kubernetes-Umgebung dargestellt, in der eine StorageClass für das dynamische Volumen-Provisioning definiert ist. Es wird gezeigt, wie ein PersistentVolume (PV) und ein PersistentVolumeClaim (PVC) erstellt werden, um Speicherressourcen zuzuweisen. Ein Pod verwendet diesen Claim, um einen Speicherbereich an einen Mount-Punkt innerhalb des Containers zu binden.

19.5.1 StorageClass Konfiguration

Die StorageClass my-local-storage definiert, wie ein PersistentVolume (PV) bereitgestellt wird. Es wird angegeben, dass kein automatischer Provisioner für die Bereitstellung des Volumes genutzt wird (provisioner: kubernetes.io/no-provisioner). Das Volume wird erst gebunden (volumeBindingMode: WaitForFirstConsumer), wenn ein Pod, der es anfordert, tatsächlich instanziiert wird. Die Möglichkeit zur Erweiterung des Volumes wird durch allowVolumeExpansion: true gegeben.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

19.5.2 PersistentVolume Konfiguration

my-persistent-volume definiert ein PV mit 1 Gi Speicherplatz. Die Zugriffsmöglichkeit ist auf ReadWriteOnce gesetzt, was bedeutet, dass das Volume auf genau einem Node im Read-Write-Modus gemountet werden kann. Durch hostPath wird ein lokaler Pfad (/var/tmp/my-data) auf dem Node als Speicherort für das Volume festgelegt. Die persistentVolumeReclaimPolicy: Recycle besagt, dass Daten auf dem Volume beim Löschen des PV nicht dauerhaft gelöscht, sondern für neue Claims zur Verfügung stehen.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-persistent-volume
spec:
  storageClassName: my-local-storage
  persistentVolumeReclaimPolicy: Recycle
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /var/tmp/my-data

19.5.3 PersistentVolumeClaim Konfiguration

Das PVC my-pvc fordert Speicher von der my-local-storage StorageClass an, mit der Zugriffsmöglichkeit ReadWriteOnce und einer Größe von 100 Mi. Dieses PVC wird dann verwendet, um Speicheranforderungen für Pods zu erfüllen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: my-local-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi

19.5.4 Pod Konfiguration

Der Pod my-pv-pod startet einen Container mit dem Image busybox und führt einen Befehl aus, der eine Nachricht in eine Datei (/output/erfolg.txt) innerhalb des gemounteten Volumes schreibt. Der volumeMounts-Abschnitt verbindet das durch my-pvc definierte PVC mit dem Pfad /output im Container. Der Pod verwendet Never als restartPolicy, was bedeutet, dass der Container nicht automatisch neu gestartet wird, wenn er beendet wird.

apiVersion: v1
kind: Pod
metadata:
  name: my-pv-pod
spec:
  restartPolicy: Never
  containers:
    - name: my-busybox
      image: busybox
      command: ["sh", "-c", "echo Hallo, dies ist ein Persistent Volume Claim Test >> /output/erfolg.txt"]
      volumeMounts:
      - mountPath: /output
        name: my-volume-mount
  volumes:
    - name: my-volume-mount
      persistentVolumeClaim:
        claimName: my-pvc