Warum benötigen wir Persistent Storage / Persistent Storage Claim in Kubernetes?

​​​In diesem Beitrag geht es um das Thema Persistent Storage / Persistent Storage Claim in Containers and Kubernetes.

 
Am Anfang seiner technologischen Entwicklung waren Container ausschließlich für die Bereitstellung von stateless (zustandsloseren) Applikationen vorgesehen. Das bedeutet, dass die ephemeren Objekte nur in der beschreibbaren Schicht eines Containers (Pods) existieren und jedes Mal verloren gehen, wenn ein Pod (in dem ein Container läuft) „zerstört“ und neu erstellt wird. Infolgedessen war die Entwicklung einer Technologie notwendig, die dafür sorgte, dass die Applikationsdaten auch nach einem Recreate oder bessergesagt während des ganzen Lifecycles eines Pods weiterhin verfügbar sind. Folgende API-Objekte helfen uns die beschriebene Herausforderung zu meistern: Persistent Volume, Persistent Volume Claim und Storage Class.

Volume vs Persistent Volume

 
Im Laufe der Jahre wurden immer mehr stateful (zustandsbehaftet) Applikationen in containerisierter Form bereitgestellt, besonders die Applikationen, die eine Datenbank benötigen.

Überblick über die Komponenten

  • Volume
  • Persistent Volume
  • Persistent Volume Claim
  • Storage Class
  • Access Modes​ 

Vol​ume

Wie Sie aus der vorherigen Ausführung bereits entnehmen konnten, werden die Volumes nur zum Speichern temporärer Daten während der Lebenszeit eines Pods verwendet. Wenn der Pod gelöscht wird, werden auch alle dazu zugehörige Volume ebenfalls entfernt.
 

Persistent Volume

Persistent Volume Claim

Persistent Volume (PV) ist ein API-Objekt, welches den eigentlichen Speicher darstellt. Wie der Name auch hindeutet, ist der Lebenszyklus eines Persistent Volumes völlig unabhängig vom Lebenszyklus eines Pods. Ein Persistent Volume kann von einem Administrator oder dynamisch in einem Kubernetes Cluster bereitgestellt werden. Das PV steht dem ganzen Cluster zur Verfügung und ist keinem Namespace zugeordnet.

Aus technischer Sicht werden die Persistent Volume Objekte im API-Server erstellt. Die Persistent Volumes werden den einzelnen Worker Node gemappt. Das Kubelet mappt die PVs an die einzelne Pods. Sobald der Speicher dem Knoten zugeordnet wurde und der Pod gestartet ist, wird das Persistent Volume zu dem Container gemountet.

PVs können entweder manuell durch einen Administrator oder dynamisch durch einen Storage-Klassen-Controller bereitgestellt werden. Eine Storage-Klasse definiert eine Gruppe von Speichertypen, die von einer dynamischen Provisionslogik verwendet werden, um automatisch PVs zu erstellen. Wenn ein Pod einen PVC anfordert und keine passenden PVs verfügbar sind, wird automatisch ein neues PV erstellt.

Wenn man ein Persistent Volume definiert, hat man eine Wahl zwischen vielen verschiedenen Arten von Persistent Volumes, die innerhalb von Kubernetes bereitgestellt werden können. Dies ist von der angeschlossenen Storage-Infrastruktur abhängig und lässt sich grob in vier Typen aufteilen: Local-, Netzwerk-, Block- und Cloud-Storage.​

  • Local Disk
  • Netzwerk: NFS, azureFIle
  • Block: Fibre Channel, iSCSI
  • Cloud: z.B. awsElasticBlockStore, azureDisk, gcePersistentDisk

Die Art des verwendeten Storage ist von der Use Case und / oder Infrastruktur abhängig.

Hier finden Sie eine vollständige Liste: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

Persistent Volume Claim

Der Persistent Volume Claim (PVC) ist eine Anforderung des Benutzers an dem Cluster, ihm eine bestimmte Menge an Speicherplatz zu gewähren.

Wenn ein Persistent Volume Claim gestellt wird, müssen dabei eine Reihe von Eigenschaften definiert werden: die Größe des PersistentVolumes, den Zugriffsmodus (Access Mode) für dieses PersistentVolume, die Speicherklasse (Storage Class) usw. Wenn ein geeignetes Persistent Volume, welches den gestellten Anforderungen entspricht, gefunden wird, wird dieses dann bereitgestellt.

Access Modes​

PV Storage Class

Persistent Volumes und Persistent Volume Claims stehen vier verschiedenen Zugriffsmodi zur Verfügung: 

  • RWO – ReadWriteOnce bedeutet, dass ein Node das Volume sowohl für den Lese- als auch für den Schreib-Zugriff mounten kann.
  • RWX – ReadWriteMany bedeutet, dass mehr als ein Node das Volume für den Lese-Schreib-Zugriff mounten kann.
  • ROM – ReadOnlyMany bedeutet, dass mehr als ein Node das Volume für den reinen Lesezugriff mounten kann.
  • RWOP – ReadWriteOncePod bedeutet, dass ein Volume nur von einem einzelnen Pod im gesamten Cluster mit Lese-Schreib-Zugriff gemountet werden kann. Die Option ist nur ab Version 1.22 und nur für PVC verfügbar.

Wichtig zu merken, dass die zugrunde liegende Storage-Komponenten immer noch seine eigenen Eigenschaften haben, die in Wiederspruch zu den konfigurierten Einstellungen stehen können. 

Static Provisioning

Bei der statischen Bereitstellung wird das Persistent Volume durch einen Administrator vorab erstellt. Dabei legt der Administrator die Spezifikationen (Zugriffsmodi, Größe, Name usw.) fest. 

Dynamic Provisioning

Bei einer dynamischen Bereitstellung das Persistent Volume zeitgleich mit der Erstellung von PVC angelegt. Dies passiert in der Regel, wenn die verfügbaren statischen PVs nicht mit der PVC-Spezifikation übereinstimmen. In diesem Fall basiert die Bereitstellung anhand von vordefinierten Storage Klassen.
 

Storage Class

Das Objekt Storage Class bietet die Möglichkeit bestimmte Eigenschaft wie z.B. Leistung, Größe oder Zugriffsart, sowie die infrastrukturspezifischen Parameter zu definieren. Innerhalb des StorageClass werden auch die Schritte definiert (reclaim policy) was mit einem dynamisch zugewiesenen PersistentVolumes geschehen soll, sobald die PVC gelöscht ist.

Auch klassische Storage Konzepte, die auf sich auf Performance Werten basieren, können in Storage Klassen abgebildet werden.
 
 

Storage Lifecycle

 
PV Storage Lifecycle

​ 
Den gesamten Lebenszyklus der PVs/PVCs können wir in drei Phasen aufteilen: Binding, Using und Reclaim. Hier ist eine grobe Beschreibung der einzelnen Schritte.
 

Provisioning – die erste Phase ist bereits oben erklärt und beinhaltet eine statische oder eine dynamische Provisionierung.

Binding – ist ein Prozess der Zuordnung eines PersistentVolumeClaim zu einem PersistentVolume für den weiteren Zugriff von einem Pod. Aus technischer Sicht passiert Folgendes: wenn der PersistentVolumeClaim erstellt wird, findet ein Control Loop diesen PersistentVolumeClaim und versucht, ein passendes PersistentVolume zu finden. Dies kann entweder statisch oder dynamisch passieren.  Wenn der Control Loop kein PersistentVolume finden kann, bleibt der Pod, welcher diesen PersistentVolumeClaim verwenden wollte, in dem Pending-Zustand, und zwar so lange bis die passende Ressource verfügbar wird.

Using – Das Volume steht dem Pod während seiner Lebensdauer zur Verfügung.

Reclaiming – in dieser Phase wird festgelegt, was mit dem Volume geschehen soll. Sie haben eine Wahl zwischen zwei möglichen Optionen Retain und Delete.

Retain - dem zugrundeliegenden Storage wird mitteilt, dass der Volume noch manuell zurückgefordert werden kann.

Delete – die Phase ist selbst erklärend. Diese Option wird überwiegend in dynamischen Provisioning Szenarien verwendet.​ 

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.