Ku­ber­netes Per­sis­tent Volume: Tutorial

Ku­ber­netes Per­sis­tent Volumes (PVs) spielen eine ent­schei­den­de Rolle in der ef­fi­zi­en­ten Ver­wal­tung von Daten in Ku­ber­netes-Clustern. Sie abs­tra­hie­ren Daten und erlauben eine kon­sis­ten­te Spei­che­rung über die Le­bens­zy­klen von Pods.

Was ist ein Ku­ber­netes Per­sis­tent Volume?

Ein Ku­ber­netes Per­sis­tent Volume (PV) ist eine fun­da­men­ta­le Ressource innerhalb der Ku­ber­netes-Or­ches­trie­rung, die für eine ef­fi­zi­en­te und ska­lier­ba­re Ver­wal­tung von Daten in Container-Clustern ent­wi­ckelt wurde. Der Zweck eines PV besteht darin, einen stan­dar­di­sier­ten und per­sis­ten­ten Spei­cher­be­reich be­reit­zu­stel­len. Ein PV kann von ver­schie­de­nen Pods genutzt werden, un­ab­hän­gig davon, auf welchen phy­si­schen Spei­cher­res­sour­cen das Cluster zugreift. Dies schafft eine höhere Abs­trak­ti­ons­ebe­ne, indem die Speich­er­de­tails von der An­wen­dungs­lo­gik getrennt werden.

PVs gibt es in sta­ti­scher und dy­na­mi­scher Form. Statische Be­reit­stel­lung bedeutet, dass die Spei­cher­res­sour­cen manuell vor­de­fi­niert sind, während bei der dy­na­mi­schen Be­reit­stel­lung PVs au­to­ma­tisch erstellt werden, wenn ein Pod spezielle Spei­cher­an­for­de­run­gen hat. Diese Fle­xi­bi­li­tät sorgt für eine ef­fi­zi­en­te Ver­wal­tung von per­sis­ten­ten Daten in Ku­ber­netes-Clustern, wodurch An­wen­dun­gen robust und ska­lier­bar werden.

Was ist der Un­ter­schied zwischen Volume und Per­sis­tent Volume?

In Ku­ber­netes gibt es zwei grund­le­gen­de Arten von Spei­cher­vo­lu­men: Volumes und Per­sis­tent Volumes. Ein normales Volume ist an die Le­bens­dau­er eines einzelnen Pods gebunden. Es wird direkt in der Pod-Kon­fi­gu­ra­ti­on de­kla­riert und dient haupt­säch­lich zur tem­po­rä­ren Da­ten­spei­che­rung während der Aus­füh­rung des zu­ge­hö­ri­gen Pods. Wenn der Pod beendet wird, wird auch das normale Volume frei­ge­ge­ben und alle darin ent­hal­te­nen Daten werden gelöscht.

Im Gegensatz dazu hat ein Ku­ber­netes Per­sis­tent Volume eine längere Le­bens­dau­er und ist un­ab­hän­gig von einem be­stimm­ten Pod. Es kann von mehreren Pods in ver­schie­de­nen Le­bens­zy­klen be­an­sprucht und frei­ge­ge­ben werden. Per­sis­tent Volumes werden separat von den Pods de­kla­riert und dann an Per­sis­tent Volume Claims (PVCs) gekoppelt. Die Bindung zwischen einem PVC und einem PV erfolgt dynamisch oder manuell. Per­sis­tent Volumes sind ideal für Daten, die über die Le­bens­dau­er eines einzelnen Pods hinaus per­sis­tie­ren müssen, und bieten eine Mög­lich­keit, Daten zwischen ver­schie­de­nen Pods zu teilen und zu speichern, selbst wenn Pods erstellt oder gelöscht werden.

Welche Typen von Per­sis­tent Volumes gibt es?

In Ku­ber­netes gibt es ver­schie­de­ne Typen von Per­sis­tent Volumes, die un­ter­schied­li­che Spei­cher­lö­sun­gen und -tech­no­lo­gien re­prä­sen­tie­ren. Hier sind einige der gän­gigs­ten Typen von Per­sis­tent Volumes:

• hostPath: Der HostPath-Typ bindet ein Per­sis­tent Volume an einen Pfad auf dem Host-Knoten im Ku­ber­netes-Cluster. Dies er­mög­licht den Zugriff auf lokale Spei­cher­res­sour­cen des Hosts und eignet sich gut für Ent­wick­lungs- und Test­um­ge­bun­gen. Es sollte jedoch mit Vorsicht in Pro­duk­ti­ons­um­ge­bun­gen verwendet werden, da die Daten nicht zwischen den Knoten re­pli­ziert werden.
• emptyDir: emptyDir erstellt ein tem­po­rä­res und leer­lau­fen­des Volume jedes Mal, wenn ein Pod erstellt wird. Es eignet sich für temporäre Daten oder den Da­ten­aus­tausch zwischen Con­tai­nern innerhalb desselben Pods. Das Volume wird jedoch gelöscht, wenn der Pod beendet wird.
• GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, AzureFile: Diese Typen binden ein Ku­ber­netes Per­sis­tent Volume an externe Cloud-Spei­cher­lö­sun­gen wie Google Compute Engine Per­sis­tent Disks, Amazon EBS Volumes oder Azure Disks und Azure File Shares. Sie bieten eine Mög­lich­keit, Daten über Pods und sogar Cluster hinweg zu per­sis­tie­ren und sind gut geeignet für An­wen­dun­gen, die in Cloud-Um­ge­bun­gen be­reit­ge­stellt werden.
• nfs (Network File System): PVs vom Typ NFS binden an eine Netz­werk­frei­ga­be, die über das Network File System (NFS) be­reit­ge­stellt wird. Dies führt zur geteilten Nutzung von Daten zwischen ver­schie­de­nen Pods und ist praktisch, wenn mehrere Pods auf ge­mein­sa­me Dateien zugreifen müssen.
• iscsi (Internet Small Computer System Interface): ISCSI-basierte PVs binden an Block­spei­cher­ge­rä­te, die über das ISCSI-Protokoll zur Verfügung stehen. Es ist eine Mög­lich­keit, externe Block­spei­cher­ge­rä­te in Ku­ber­netes-Clustern zu nutzen, und bietet eine flexible und ska­lier­ba­re Lösung für per­sis­ten­te Daten.
• local: Der Local-Typ er­mög­licht den direkten Zugriff auf physische Spei­cher­res­sour­cen auf dem lokalen Knoten im Ku­ber­netes-Cluster. Dies ist besonders nützlich für An­wen­dun­gen, die auf schnellen lokalen Speicher an­ge­wie­sen sind. Al­ler­dings sollten Sie Vorsicht walten lassen, da lokale Spei­cher­res­sour­cen nicht zwischen den Knoten re­pli­ziert werden und bei Ausfall des Knotens Daten verloren gehen können.
• csi (Container Storage Interface): Der CSI-Typ erlaubt es, externe Spei­cher­an­bie­ter über das Container Storage Interface zu in­te­grie­ren. Container-Or­ches­trie­rungs­sys­te­me wie Ku­ber­netes können so mit ver­schie­de­nen Spei­cher­lö­sun­gen von Dritt­an­bie­tern kom­mu­ni­zie­ren. Dies schafft Fle­xi­bi­li­tät und erlaubt die Nutzung einer breiten Palette von Spei­cher­sys­te­men, die das CSI un­ter­stüt­zen.
• cephfs: CephFS ist ein ver­teil­tes Da­tei­sys­tem und Per­sis­tent Volumes vom Typ CephFS sind an dieses verteilte Da­tei­sys­tem gebunden. Diese Art von PV wird für An­wen­dun­gen verwendet, die ge­mein­sa­men Da­tei­zu­griff benötigen und in einem ver­teil­ten Spei­cher­um­feld betrieben werden, wie es bei Ceph der Fall ist.
• fc (Fibre Channel): FC-basierte Per­sis­tent Volumes sind an Fibre Channel-Spei­cher­ge­rä­te gebunden. Durch diesen Typ können Sie auf externe Fibre-Channel-basierte Spei­cher­lö­sun­gen zugreifen. Er ist in Um­ge­bun­gen üblich, in denen Fibre-Channel-Netzwerke für die Be­reit­stel­lung von block­ba­sier­tem Speicher verwendet werden.
• rbd (RADOS Block Device): Der RBD-Typ bindet an block­ba­sier­te Spei­cher­ge­rä­te im Ceph-Cluster, die als RADOS Block Devices fungieren. Dieser Typ gibt Ihnen die Mög­lich­keit, auf das block­ba­sier­te Spei­cher­sys­tem von Ceph zu­zu­grei­fen, was besonders in ver­teil­ten Spei­cher­um­ge­bun­gen mit hoher Ska­lier­bar­keit von Vorteil ist.

Ku­ber­netes Per­sis­tent Volume Access Modes

In Ku­ber­netes bestimmen Per­sis­tent Volume Access Modes, wie Pods auf die daran ge­bun­de­nen Per­sis­tent Volumes zugreifen können. Es gibt drei Haupt­ty­pen von Access Modes:

• ReadWriteOnce (RWO): Dieser Modus erlaubt einem einzelnen Pod, das Per­sis­tent Volume gleich­zei­tig in den Lese- und Schreib­mo­dus zu mounten. Es ist nützlich für An­wen­dun­gen, die eine exklusive Schreib­zu­griffs­kon­trol­le benötigen. Ein PV mit diesem Modus kann nur von einem Pod gleich­zei­tig gemountet werden.
• ReadOnlyMany (ROX): ReadOnlyMany er­mög­licht es mehreren Pods, das Per­sis­tent Volume gleich­zei­tig im Le­se­zu­griffs­mo­dus zu mounten. Dies ist sinnvoll für An­wen­dun­gen, die Daten in einem ge­mein­sa­men Modus teilen können, bei dem Schreib­zu­grif­fe jedoch ein­ge­schränkt sind. Mehrere Pods können parallel auf die Daten zugreifen, jedoch nur im Le­se­zu­griffs­mo­dus.
• ReadWriteMany (RWX): Bei ReadWriteMany können mehrere Pods das Per­sis­tent Volume gleich­zei­tig sowohl im Lese- als auch im Schreib­zu­griffs­mo­dus mounten. Dieser Modus wird in Si­tua­tio­nen an­ge­wen­det, in denen eine ge­mein­sa­me Da­ten­ba­sis er­for­der­lich ist und bei der mehrere Pods Schreib­zu­griff auf die Daten haben können.

Bei der Fest­le­gung des Access Modes sollten Sie die Art der Da­ten­zu­grif­fe Ihrer Anwendung be­rück­sich­ti­gen und prüfen, dass der gewählte Modus die er­for­der­li­chen Zu­griffs­mus­ter un­ter­stützt.

Bitte beachten Sie, dass nicht alle Storage-Klassen und Volume-Typen alle drei Access Modes un­ter­stüt­zen. Die Un­ter­stüt­zung hängt von der zugrunde liegenden Spei­cher­in­fra­struk­tur und dem konkreten Per­sis­tent Volume-Typ ab. Daher ist es ratsam, die Do­ku­men­ta­ti­on der je­wei­li­gen Storage-Klasse und des Per­sis­tent Volume-Typs zu kon­sul­tie­ren, um si­cher­zu­stel­len, dass die ge­wünsch­ten Zu­griffs­mus­ter erlaubt sind.

Le­bens­zy­klus eines Per­sis­tent Volumes (PV)

Die Le­bens­zy­klen von Ku­ber­netes Per­sis­tent Volumes können in ver­schie­de­nen Phasen un­ter­teilt werden, die den Prozess der Be­reit­stel­lung, Nutzung und Freigabe von per­sis­ten­tem Speicher im Cluster re­prä­sen­tie­ren.

1. Er­stel­lung (Pro­vi­sio­ning): Der Le­bens­zy­klus eines PVs beginnt mit der Er­stel­lung oder Be­reit­stel­lung. Ein Clus­terad­mi­nis­tra­tor erstellt ein Per­sis­tent Volume und kon­fi­gu­riert es entweder statisch mit festen Spei­cher­res­sour­cen oder dynamisch, indem er eine Storage-Klasse (Storage Class) verwendet, die dy­na­mi­sche Pro­vi­sio­nie­rung er­mög­licht.
2. Binding: Ein PV wird an einen PVC (Per­sis­tent Volume Claim) gebunden, wenn ein Pod einen Spei­cher­be­darf anmeldet, der mit den Spe­zi­fi­ka­tio­nen des PVs über­ein­stimmt. Dieser Schritt stellt sicher, dass das PV den An­for­de­run­gen eines be­stimm­ten Pods ent­spricht.
3. Nutzung durch den Pod: Nachdem der Binding-Prozess ab­ge­schlos­sen ist, kann das PV von einem Pod genutzt werden. Der Pod kann das ge­moun­te­te Volume lesen oder be­schrei­ben, je nach den Zu­griffs­mo­di, die bei der PV-Er­stel­lung fest­ge­legt wurden.
4. Ablauf der Nutzung: Wenn ein Pod seinen Dienst beendet oder gelöscht wird, kann das zu­ge­hö­ri­ge PV von einem anderen Pod wie­der­ver­wen­det werden. Das PV bleibt erhalten, bis er manuell oder durch eine dy­na­mi­sche Spei­cher­klas­se gelöscht wird.
5. Freigabe (Release): Ein PV kann explizit frei­ge­ge­ben werden, indem es von einem PVC getrennt wird. Dadurch kann das PV erneut gebunden werden, mög­li­cher­wei­se 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 au­to­ma­tisch, wenn die PV-Re­pli­ka­ti­on durch die Spei­cher­klas­se ein­ge­stellt ist.

Ein Ku­ber­netes Per­sis­tent Volume erstellen

Die Er­stel­lung eines Per­sis­tent Volumes in Ku­ber­netes ist ein mehr­stu­fi­ger Prozess, der eine sorg­fäl­ti­ge Kon­fi­gu­ra­ti­on erfordert.

Schritt 1: Kon­fi­gu­ra­ti­on des Per­sis­tent Volumes

Der erste Schritt be­inhal­tet das Öffnen eines Text­edi­tors und die Er­stel­lung einer YAML-Datei, die die Kon­fi­gu­ra­ti­on des Ku­ber­netes Per­sis­tent Volumes enthält. Sie können diese Datei bei­spiels­wei­se pv.yaml nennen. Im Folgenden geben wir Ihnen ein einfaches Beispiel für eine PV-Kon­fi­gu­ra­ti­on:

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 Ku­ber­netes API-Version an. Hier ist es v1.
• kind: Der Typ des Ku­ber­netes-Objekts, in diesem Fall Per­sis­tent­Vo­lu­me.
• metadata: Enthält Metadaten für das Per­sis­tent Volume, zum Beispiel den Namen des Volumes. spec: Definiert die Spe­zi­fi­ka­ti­on des Volumes.
• capacity: Gibt die Spei­cher­ka­pa­zi­tä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 Zu­griffs­mo­di. Hier steht ReadWriteOnce für ex­klu­si­ven Lese- und Schreib­zu­griff.
• persistentVolumeReclaimPolicy: Gibt an, wie mit dem Volume um­ge­gan­gen werden soll, wenn es nicht mehr benötigt wird. Retain bedeutet, dass das Volume manuell gelöscht werden muss.
• storageClassName: Weist dem Per­sis­tent Volume eine Storage-Klasse zu.
• hostPath: Definiert den Pfad im Host-Da­tei­sys­tem, der als Speicher für das Per­sis­tent Volume verwendet wird.

Schritt 2: Anwenden der Kon­fi­gu­ra­ti­on

Nachdem Sie die PV-Kon­fi­gu­ra­ti­ons­da­tei be­schrie­ben haben, können Sie sie mit Kubelet ak­ti­vie­ren:

kubectl apply -f pv.yaml

Dieser Befehl sendet die Kon­fi­gu­ra­ti­ons­da­tei an das Ku­ber­netes-Cluster, das die darin ent­hal­te­nen Res­sour­cen erstellt.

Schritt 3: Anwenden der Kon­fi­gu­ra­ti­on

Um si­cher­zu­stel­len, dass das Ku­ber­netes Per­sis­tent Volume er­folg­reich angelegt wurde, können Sie das folgende Kommando verwenden:

kubectl get pv

Dies listet alle vor­han­de­nen Per­sis­tent 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 Per­sis­tent Volume Claim (PVC) erstellen

Füllen Sie eine YAML-Datei, die die Kon­fi­gu­ra­ti­on des Per­sis­tent Volume Claims festlegt:

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

Wenden Sie die PVC-Kon­fi­gu­ra­ti­ons­da­tei auf das Ku­ber­netes-Cluster an:

kubectl apply -f pvc.yaml

Über­prü­fen Sie, ob das Per­sis­tent Volume Claim er­folg­reich 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 dy­na­mi­sche Be­reit­stel­lung eines Per­sis­tent Volume Claims (PVC) in Ku­ber­netes zu de­mons­trie­ren. Das Manifest erstellt und be­an­sprucht au­to­ma­tisch ein neues Ku­ber­netes Per­sis­tent Volume mit einer Größe von 1 Gigabyte, das von der Storage-Klasse standard un­ter­stützt wird.

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

Nachdem die Kon­fi­gu­ra­tio­nen definiert wurden, ak­ti­vie­ren 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 Kon­fi­gu­ra­ti­on für den Pod ein­rich­ten, der den per­sis­ten­ten 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-Kon­fi­gu­ra­ti­on auf das Ku­ber­netes-Cluster an, um den Pod zu erstellen:

kubectl apply -f pod.yaml

Falls Sie gerade in Ku­ber­netes ein­stei­gen, finden Sie alle wichtigen In­for­ma­tio­nen zur In­stal­la­ti­on und Ein­rich­tung eines Clusters im Ku­ber­netes-Tutorial in unserem Ratgeber.