Kubernetes Persistent Volume: Tutorial

Kubernetes Persistent Volumes (PVs) spielen eine entscheidende Rolle in der effizienten Verwaltung von Daten in Kubernetes-Clustern. Sie abstrahieren Daten und erlauben eine konsistente Speicherung über die Lebenszyklen von Pods.

Was ist ein Kubernetes Persistent Volume?

Ein Kubernetes Persistent Volume (PV) ist eine fundamentale Ressource innerhalb der Kubernetes-Orchestrierung, die für eine effiziente und skalierbare Verwaltung von Daten in Container-Clustern entwickelt wurde. Der Zweck eines PV besteht darin, einen standardisierten und persistenten Speicherbereich bereitzustellen. Ein PV kann von verschiedenen Pods genutzt werden, unabhängig davon, auf welchen physischen Speicherressourcen das Cluster zugreift. Dies schafft eine höhere Abstraktionsebene, indem die Speicherdetails von der Anwendungslogik getrennt werden.

PVs gibt es in statischer und dynamischer Form. Statische Bereitstellung bedeutet, dass die Speicherressourcen manuell vordefiniert sind, während bei der dynamischen Bereitstellung PVs automatisch erstellt werden, wenn ein Pod spezielle Speicheranforderungen hat. Diese Flexibilität sorgt für eine effiziente Verwaltung von persistenten Daten in Kubernetes-Clustern, wodurch Anwendungen robust und skalierbar werden.

Was ist der Unterschied zwischen Volume und Persistent Volume?

In Kubernetes gibt es zwei grundlegende Arten von Speichervolumen: Volumes und Persistent Volumes. Ein normales Volume ist an die Lebensdauer eines einzelnen Pods gebunden. Es wird direkt in der Pod-Konfiguration deklariert und dient hauptsächlich zur temporären Datenspeicherung während der Ausführung des zugehörigen Pods. Wenn der Pod beendet wird, wird auch das normale Volume freigegeben und alle darin enthaltenen Daten werden gelöscht.

Im Gegensatz dazu hat ein Kubernetes Persistent Volume eine längere Lebensdauer und ist unabhängig von einem bestimmten Pod. Es kann von mehreren Pods in verschiedenen Lebenszyklen beansprucht und freigegeben werden. Persistent Volumes werden separat von den Pods deklariert und dann an Persistent Volume Claims (PVCs) gekoppelt. Die Bindung zwischen einem PVC und einem PV erfolgt dynamisch oder manuell. Persistent Volumes sind ideal für Daten, die über die Lebensdauer eines einzelnen Pods hinaus persistieren müssen, und bieten eine Möglichkeit, Daten zwischen verschiedenen Pods zu teilen und zu speichern, selbst wenn Pods erstellt oder gelöscht werden.

Welche Typen von Persistent Volumes gibt es?

In Kubernetes gibt es verschiedene Typen von Persistent Volumes, die unterschiedliche Speicherlösungen und -technologien repräsentieren. Hier sind einige der gängigsten Typen von Persistent Volumes:

• hostPath: Der HostPath-Typ bindet ein Persistent Volume an einen Pfad auf dem Host-Knoten im Kubernetes-Cluster. Dies ermöglicht den Zugriff auf lokale Speicherressourcen des Hosts und eignet sich gut für Entwicklungs- und Testumgebungen. Es sollte jedoch mit Vorsicht in Produktionsumgebungen verwendet werden, da die Daten nicht zwischen den Knoten repliziert werden.
• emptyDir: emptyDir erstellt ein temporäres und leerlaufendes Volume jedes Mal, wenn ein Pod erstellt wird. Es eignet sich für temporäre Daten oder den Datenaustausch zwischen Containern innerhalb desselben Pods. Das Volume wird jedoch gelöscht, wenn der Pod beendet wird.
• GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, AzureFile: Diese Typen binden ein Kubernetes Persistent Volume an externe Cloud-Speicherlösungen wie Google Compute Engine Persistent Disks, Amazon EBS Volumes oder Azure Disks und Azure File Shares. Sie bieten eine Möglichkeit, Daten über Pods und sogar Cluster hinweg zu persistieren und sind gut geeignet für Anwendungen, die in Cloud-Umgebungen bereitgestellt werden.
• nfs (Network File System): PVs vom Typ NFS binden an eine Netzwerkfreigabe, die über das Network File System (NFS) bereitgestellt wird. Dies führt zur geteilten Nutzung von Daten zwischen verschiedenen Pods und ist praktisch, wenn mehrere Pods auf gemeinsame Dateien zugreifen müssen.
• iscsi (Internet Small Computer System Interface): ISCSI-basierte PVs binden an Blockspeichergeräte, die über das ISCSI-Protokoll zur Verfügung stehen. Es ist eine Möglichkeit, externe Blockspeichergeräte in Kubernetes-Clustern zu nutzen, und bietet eine flexible und skalierbare Lösung für persistente Daten.
• local: Der Local-Typ ermöglicht den direkten Zugriff auf physische Speicherressourcen auf dem lokalen Knoten im Kubernetes-Cluster. Dies ist besonders nützlich für Anwendungen, die auf schnellen lokalen Speicher angewiesen sind. Allerdings sollten Sie Vorsicht walten lassen, da lokale Speicherressourcen nicht zwischen den Knoten repliziert werden und bei Ausfall des Knotens Daten verloren gehen können.
• csi (Container Storage Interface): Der CSI-Typ erlaubt es, externe Speicheranbieter über das Container Storage Interface zu integrieren. Container-Orchestrierungssysteme wie Kubernetes können so mit verschiedenen Speicherlösungen von Drittanbietern kommunizieren. Dies schafft Flexibilität und erlaubt die Nutzung einer breiten Palette von Speichersystemen, die das CSI unterstützen.
• cephfs: CephFS ist ein verteiltes Dateisystem und Persistent Volumes vom Typ CephFS sind an dieses verteilte Dateisystem gebunden. Diese Art von PV wird für Anwendungen verwendet, die gemeinsamen Dateizugriff benötigen und in einem verteilten Speicherumfeld betrieben werden, wie es bei Ceph der Fall ist.
• fc (Fibre Channel): FC-basierte Persistent Volumes sind an Fibre Channel-Speichergeräte gebunden. Durch diesen Typ können Sie auf externe Fibre-Channel-basierte Speicherlösungen zugreifen. Er ist in Umgebungen üblich, in denen Fibre-Channel-Netzwerke für die Bereitstellung von blockbasiertem Speicher verwendet werden.
• rbd (RADOS Block Device): Der RBD-Typ bindet an blockbasierte Speichergeräte im Ceph-Cluster, die als RADOS Block Devices fungieren. Dieser Typ gibt Ihnen die Möglichkeit, auf das blockbasierte Speichersystem von Ceph zuzugreifen, was besonders in verteilten Speicherumgebungen mit hoher Skalierbarkeit von Vorteil ist.

Kubernetes Persistent Volume Access Modes

In Kubernetes bestimmen Persistent Volume Access Modes, wie Pods auf die daran gebundenen Persistent Volumes zugreifen können. Es gibt drei Haupttypen von Access Modes:

• ReadWriteOnce (RWO): Dieser Modus erlaubt einem einzelnen Pod, das Persistent Volume gleichzeitig in den Lese- und Schreibmodus zu mounten. Es ist nützlich für Anwendungen, die eine exklusive Schreibzugriffskontrolle benötigen. Ein PV mit diesem Modus kann nur von einem Pod gleichzeitig gemountet werden.
• ReadOnlyMany (ROX): ReadOnlyMany ermöglicht es mehreren Pods, das Persistent Volume gleichzeitig im Lesezugriffsmodus zu mounten. Dies ist sinnvoll für Anwendungen, die Daten in einem gemeinsamen Modus teilen können, bei dem Schreibzugriffe jedoch eingeschränkt sind. Mehrere Pods können parallel auf die Daten zugreifen, jedoch nur im Lesezugriffsmodus.
• ReadWriteMany (RWX): Bei ReadWriteMany können mehrere Pods das Persistent Volume gleichzeitig sowohl im Lese- als auch im Schreibzugriffsmodus mounten. Dieser Modus wird in Situationen angewendet, in denen eine gemeinsame Datenbasis erforderlich ist und bei der mehrere Pods Schreibzugriff auf die Daten haben können.

Bei der Festlegung des Access Modes sollten Sie die Art der Datenzugriffe Ihrer Anwendung berücksichtigen und prüfen, dass der gewählte Modus die erforderlichen Zugriffsmuster unterstützt.

Bitte beachten Sie, dass nicht alle Storage-Klassen und Volume-Typen alle drei Access Modes unterstützen. Die Unterstützung hängt von der zugrunde liegenden Speicherinfrastruktur und dem konkreten Persistent Volume-Typ ab. Daher ist es ratsam, die Dokumentation der jeweiligen Storage-Klasse und des Persistent Volume-Typs zu konsultieren, um sicherzustellen, dass die gewünschten Zugriffsmuster erlaubt sind.

Lebenszyklus eines Persistent Volumes (PV)

Die Lebenszyklen von Kubernetes Persistent Volumes können in verschiedenen Phasen unterteilt werden, die den Prozess der Bereitstellung, Nutzung und Freigabe von persistentem Speicher im Cluster repräsentieren.

1. Erstellung (Provisioning): Der Lebenszyklus eines PVs beginnt mit der Erstellung oder Bereitstellung. Ein Clusteradministrator erstellt ein Persistent Volume und konfiguriert es entweder statisch mit festen Speicherressourcen oder dynamisch, indem er eine Storage-Klasse (Storage Class) verwendet, die dynamische Provisionierung ermöglicht.
2. Binding: Ein PV wird an einen PVC (Persistent Volume Claim) gebunden, wenn ein Pod einen Speicherbedarf anmeldet, der mit den Spezifikationen des PVs übereinstimmt. Dieser Schritt stellt sicher, dass das PV den Anforderungen eines bestimmten Pods entspricht.
3. Nutzung durch den Pod: Nachdem der Binding-Prozess abgeschlossen ist, kann das PV von einem Pod genutzt werden. Der Pod kann das gemountete Volume lesen oder beschreiben, je nach den Zugriffsmodi, die bei der PV-Erstellung festgelegt wurden.
4. Ablauf der Nutzung: Wenn ein Pod seinen Dienst beendet oder gelöscht wird, kann das zugehörige PV von einem anderen Pod wiederverwendet werden. Das PV bleibt erhalten, bis er manuell oder durch eine dynamische Speicherklasse gelöscht wird.
5. Freigabe (Release): Ein PV kann explizit freigegeben werden, indem es von einem PVC getrennt wird. Dadurch kann das PV erneut gebunden werden, möglicherweise von einem anderen PVC oder Pod.
6. Löschen: Schließlich können Sie ein PV auch löschen, wenn es nicht mehr benötigt wird. Dies kann manuell erfolgen oder automatisch, wenn die PV-Replikation durch die Speicherklasse eingestellt ist.

Ein Kubernetes Persistent Volume erstellen

Die Erstellung eines Persistent Volumes in Kubernetes ist ein mehrstufiger Prozess, der eine sorgfältige Konfiguration erfordert.

Schritt 1: Konfiguration des Persistent Volumes

Der erste Schritt beinhaltet das Öffnen eines Texteditors und die Erstellung einer YAML-Datei, die die Konfiguration des Kubernetes Persistent Volumes enthält. Sie können diese Datei beispielsweise pv.yaml nennen. Im Folgenden geben wir Ihnen ein einfaches Beispiel für eine PV-Konfiguration:

apiVersion: v1
kind: PersistentVolume
metadata:
    name: my-pv
spec:
    capacity:
        storage: 1Gi
    volumeMode: Filesystem
    accessModes:
        - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    storageClassName: manual
    hostPath:
        path: "/mnt/data"

• apiVersion: Gibt die Kubernetes API-Version an. Hier ist es v1.
• kind: Der Typ des Kubernetes-Objekts, in diesem Fall PersistentVolume.
• metadata: Enthält Metadaten für das Persistent Volume, zum Beispiel den Namen des Volumes. spec: Definiert die Spezifikation des Volumes.
• capacity: Gibt die Speicherkapazität an, in diesem Beispiel 1 GB.
• volumeMode: Hier wird der Modus für das Volume angegeben, entweder Filesystem oder Block. In diesem Beispiel verwenden wir Filesystem.
• accessModes: Definiert die Zugriffsmodi. Hier steht ReadWriteOnce für exklusiven Lese- und Schreibzugriff.
• persistentVolumeReclaimPolicy: Gibt an, wie mit dem Volume umgegangen werden soll, wenn es nicht mehr benötigt wird. Retain bedeutet, dass das Volume manuell gelöscht werden muss.
• storageClassName: Weist dem Persistent Volume eine Storage-Klasse zu.
• hostPath: Definiert den Pfad im Host-Dateisystem, der als Speicher für das Persistent Volume verwendet wird.

Schritt 2: Anwenden der Konfiguration

Nachdem Sie die PV-Konfigurationsdatei beschrieben haben, können Sie sie mit Kubelet aktivieren:

kubectl apply -f pv.yaml

Dieser Befehl sendet die Konfigurationsdatei an das Kubernetes-Cluster, das die darin enthaltenen Ressourcen erstellt.

Schritt 3: Anwenden der Konfiguration

Um sicherzustellen, dass das Kubernetes Persistent Volume erfolgreich angelegt wurde, können Sie das folgende Kommando verwenden:

kubectl get pv

Dies listet alle vorhandenen Persistent Volumes im Cluster auf.

NAME   CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS  CLAIM  STORAGECLASS  REASON  AGE
my-pv    1Gi          RWX          Retain     Available           manual             1h

Schritt 4: Ein Persistent Volume Claim (PVC) erstellen

Füllen Sie eine YAML-Datei, die die Konfiguration des Persistent Volume Claims festlegt:

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

Wenden Sie die PVC-Konfigurationsdatei auf das Kubernetes-Cluster an:

kubectl apply -f pvc.yaml

Überprüfen Sie, ob das Persistent Volume Claim erfolgreich erstellt wurde, und nutzen Sie den folgenden Befehl:

kubectl get pvc

Die Ausgabe sollte ähnlich wie hier aussehen:

NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc     Bound    my-pv     1Gi           RWO          manual       1m

Nun legen wir das YAML-Manifest pvc-dynamic.yaml an, um die dynamische Bereitstellung eines Persistent Volume Claims (PVC) in Kubernetes zu demonstrieren. Das Manifest erstellt und beansprucht automatisch ein neues Kubernetes Persistent Volume mit einer Größe von 1 Gigabyte, das von der Storage-Klasse standard unterstützt wird.

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

Nachdem die Konfigurationen definiert wurden, aktivieren wir das Manifest:

kubectl apply -f pvc-dynamic.yaml

Schritt 5: PVCs an Pods anbinden

Für eine Kopplung zwischen PVC und Pod müssen Sie die Konfiguration für den Pod einrichten, der den persistenten Speicher nutzen wird.

apiVersion: v1
kind: Pod
metadata:
    name: mypod
spec:
    volumes:
    - name: mypvc-volume
        persistentVolumeClaim:
            claimName: my-pvc
    containers:
    - name: mycontainer
        image: myimage
        volumeMounts:
        - mountPath: "/app/data"
            name: mypvc-volume

Wenden Sie die Pod-Konfiguration auf das Kubernetes-Cluster an, um den Pod zu erstellen:

kubectl apply -f pod.yaml

Falls Sie gerade in Kubernetes einsteigen, finden Sie alle wichtigen Informationen zur Installation und Einrichtung eines Clusters im Kubernetes-Tutorial in unserem Ratgeber.