Persistente Volumes und Claims

Pods werden erstellt und beendet, aber die Daten Ihrer Anwendung müssen oft dauerhaft bestehen bleiben. Denken Sie beispielsweise an eine Datenbank oder von Benutzern hochgeladene Dateien.

• Wenn ein Pod neu gestartet oder neu eingeplant wird, gehen alle Daten verloren, die direkt im Dateisystem seines Containers gespeichert sind.
• Diese Flüchtigkeit ist für zustandslose Anwendungen unproblematisch, kritische Daten benötigen jedoch eine dauerhafte Lösung.
• Kubernetes bietet ein leistungsfähiges System zur Verwaltung persistenten Speichers, der über den Lebenszyklus von Pods hinaus bestehen bleibt.

Ein PersistentVolume (PV) ist ein Speicherbereich in Ihrem Kubernetes-Cluster.

• Es ist eine clusterweite Ressource und gehört daher zu keinem bestimmten Namespace.
• PVs werden von einem Administrator oder dynamisch durch eine StorageClass bereitgestellt.
• Sie abstrahieren die Details der zugrunde liegenden Speichertechnologie (z. B. Google Persistent Disk, AWS EBS oder eine NFS-Freigabe).

PVs werden mit Angaben wie Kapazität, Zugriffsmodi und Speichertyp definiert. Dieses YAML beschreibt ein PV mit einem hostPath (für lokale Tests) und 5 Gigabyte Speicher.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

Hinweis: hostPath ist normalerweise für die Entwicklung auf einem einzelnen Knoten gedacht und wird für den Produktivbetrieb nicht empfohlen.

Ein PersistentVolumeClaim (PVC) ist eine Speicheranforderung eines Benutzers oder einer Anwendung innerhalb eines bestimmten Namespace.

• Pods verwenden PVs nicht direkt, sondern fordern Speicher über ein PVC an.
• PVCs sind auf einen Namespace beschränkt und befinden sich daher innerhalb des Bereichs eines bestimmten Projekts oder Teams.
• Sie geben die gewünschte Größe, die Zugriffsmodi und optional eine StorageClass an.

Kubernetes ordnet ein PVC automatisch einem verfügbaren PV zu. Dieser Vorgang wird als Binding bezeichnet.

• Wenn ein PVC erstellt wird, sucht Kubernetes nach einem PV, der die Anforderungen des PVCs erfüllt (Größe, Zugriffsmodi und StorageClass).
• Sobald ein geeigneter PV gefunden wurde, werden beide in einer Eins-zu-eins-Beziehung miteinander „gebunden“.
• Durch dieses Binding erhält das PVC genau den angeforderten Speicher.

Zugriffsmodi legen fest, wie der Speicher von Pods eingebunden und verwendet werden kann. Diese Modi werden von PVCs angefordert und von PVs unterstützt:

• ReadWriteOnce (RWO): Das Volume kann von einem einzelnen Knoten mit Lese- und Schreibzugriff eingebunden werden.
• ReadOnlyMany (ROX): Das Volume kann von mehreren Knoten mit schreibgeschütztem Zugriff eingebunden werden.
• ReadWriteMany (RWX): Das Volume kann von mehreren Knoten mit Lese- und Schreibzugriff eingebunden werden.

Welche Modi verfügbar sind, hängt vom jeweiligen Speicheranbieter ab.

StorageClasses bieten Administratoren eine Möglichkeit, verschiedene „Klassen“ von Speicher zu beschreiben (z. B. „fast-ssd“ oder „slow-hdd“).

• Statt PVs manuell zu erstellen, kann eine StorageClass ein PV dynamisch bereitstellen, sobald ein PVC dies anfordert.
• Dadurch wird die Erstellung von PVs anhand vordefinierter Vorlagen automatisiert.
• Die Bereitstellung des Speichers wird von seiner Nutzung getrennt, was die Verwendung für Benutzer vereinfacht.

Erstellen wir ein PVC, das 1 Gigabyte Speicher mit dem Zugriff ReadWriteOnce anfordert. Dieses PVC sucht nach einem vorhandenen PV oder löst über eine StorageClass die dynamische Bereitstellung aus.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

Speichern Sie dies als pvc.yaml und wenden Sie es mit kubectl apply -f pvc.yaml an.

Sobald ein PVC gebunden ist, kann ein Pod es verwenden, indem er in seiner Volume-Konfiguration auf den Namen des PVCs verweist. Der Pod muss den zugrunde liegenden PV nicht kennen, sondern nur das PVC.

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

Dieser Pod schreibt eine Datei in das eingebundene persistente Volume.

Sie können den Status Ihrer Ressourcen für persistenten Speicher mit kubectl überwachen:

• Alle PVs anzeigen: kubectl get pv
• Alle PVCs in Ihrem Namespace anzeigen: kubectl get pvc
• Detaillierte Informationen einschließlich Status und Ereignissen abrufen:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

Stellen Sie sicher, dass Ihre PVs den Status Bound haben und die PVCs an den richtigen PV gebunden sind.

Ein Benutzer möchte eine Datenbank bereitstellen, die 50 GB persistenten Speicher benötigt. Welche Kubernetes-Ressource stellt direkt die Anforderung der Anwendung des Benutzers an diesen Speicher dar?

Wir haben behandelt, wie Kubernetes dauerhaften Speicher für Ihre Anwendungen verwaltet:

• PersistentVolumes (PVs) sind Clusterressourcen und stellen den tatsächlichen Speicher dar.
• PersistentVolumeClaims (PVCs) sind Speicheranforderungen von Benutzern.
• Kubernetes bindet PVCs entsprechend den Anforderungen an geeignete PVs.
• Zugriffsmodi legen fest, wie der Speicher verwendet werden kann (RWO, ROX und RWX).
• StorageClasses ermöglichen die dynamische Bereitstellung von PVs und automatisieren die Einrichtung.

Dieses System stellt sicher, dass die Daten Ihrer Anwendung auch dann bestehen bleiben, wenn Pods erstellt und beendet werden. Das sorgt für Zuverlässigkeit bei zustandsbehafteten Anwendungen.