Auf cloudnative Umgebungen mit Containern unter Kubernetes-Orchestrierung laufen längst auch geschäftswichtige Applikationen. Das hat mit Weiterentwicklungen der Container-Technik im Bereich Management von Speicher und persistenten Daten zu tun. Dabei ist ein Container eigentlich nur eine Softwarebox ohne eigenes Betriebssystem. Sie enthielt in der Urversion neben der App oder dem Mikroservice auch alle benötigten Treiber, Abhängigkeiten und Daten, die die jeweilige Applikation zum Laufen brauchte. Wurde der Container gelöscht, war das alles weg. Es musste also ein Datenspeicher her, der unabhängig von der Existenz eines Containers oder seines Pods am Leben bleibt.
Zwei Varianten sind in dem Bereich verfügbar: Persistent Volumes (PV) und Persistent Volume Calls (PVC). Persistent Volumes sind statisch. Sie werden vom Admin vorausschauend definiert, gehören zu einem Kubernetes-Cluster und gehen mit diesem unter – überleben aber das Löschen einzelner Container. Der Administrator schreibt ihnen alle charakteristischen Eigenschaften zu: Größe, Speicherklasse, Pfade, IP-Adressen, Benutzer, Kennungen und das zu verwendende Plug-in.
Storage-Klassen haben dabei bestimmte Merkmale wie QoS, Replikation, Kompression, Sicherung oder mehr, die das Container Storage Interface (CSI), nicht jedoch Kubernetes selbst versteht. Es gibt inzwischen viele unterschiedliche Storage-Klassen für PVs in Kubernetes-Cluster: von lokalem Speicher über solchen, der mit NFS, iSCSI oder FC angebunden ist, bis zu Blockstorage von Azure, AWS oder Google. Alle PVs einer Speicherklasse sind über das gleiche API zugänglich beziehungsweise an den Pod gekoppelt.
PVCs dagegen werden vom Applikationsverantwortlichen als Storage-Klasse gemäß dem Applikationsbedarf angefordert. Je nach Anforderung entsteht ein PVC aus dem Template der entsprechenden Storage-Klasse und ist
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.