Zdenk Kluka - stock.adobe.com
Container Storage Interface und Container Storage erklärt
Wir erklären Container Storage Interface, eine Schnittstelle zu persistentem Speicher in Produkten der Storage-Hersteller, was sie bietet und wie sie mit Kubernetes funktioniert.
Container erobern das Rechenzentrum. Sie sind eine abgespeckte Methode zur Virtualisierung von Anwendungen, ermöglichen eine schnelle Skalierung und enthalten alles, was zur Ausführung von Prozessen in einer Vielzahl von Umgebungen mit wenigen Abhängigkeiten erforderlich ist.
Aber sie benötigen Speicherplatz. Und während Container ursprünglich so konzipiert waren, dass sie so zustandslos (stateless) gespeichert werden sollten wie sie selbst, wurde bald klar, dass containerisierte Anwendungen die Daten länger aufbewahren mussten.
Daher wurden verschiedene Möglichkeiten entwickelt, um einen persistenten (dauerhaften) Speicher für Container bereitzustellen – weitgehend vertreten durch Docker und den Container-Orchestrator Kubernetes, obwohl es auch andere gibt.
Lassen Sie uns zunächst die Grundlagen des Kubernetes-Storage und ihre wichtigsten Methoden zur Definition und zum Aufruf des Speichers rekapitulieren.
Persistente Datenträger, definieren die verfügbaren Speicher-Volumes durch eine Reihe von Parametern, zu denen Leistung und Kapazität gehören; die Speicherklasse, die die verfügbaren persistenten Datenträger und die Methode der Verbindung mit Kubernetes gruppiert und die Angaben zu persistenten Datenträgern, die die Anforderungen des Entwicklers oder der Anwendung sind und die je nach Bedarf an persistente Datenträger gebunden sind.
Rook läuft im Kubernetes-Cluster und exponiert und orchestriert persistentes Storage über eine Reihe von Speichertypen. Bei Rook handelt es sich im Wesentlichen um softwaredefinierten Speicher (SDS), der innerhalb von Kubernetes aufgebaut ist und eine containerisierte Architektur verwendet, um den Speicher in einer Art hyperkonvergenten oder hyperskalierten Infrastruktur bereitzustellen.
Rook zielt nicht darauf ab, Mainstream-Speicher-Arrays als Kapazität zu verwenden – sie verfügen über eingebaute Controller-Fähigkeiten. Stattdessen konzentriert er sich auf die Verwaltung der Kapazität einer Reihe von Speichertypen, die Ceph-Datei, Block und Objekt, einige parallele und NAS-Dateisysteme und einige Datenbankdienste umfassen.
In diesem Artikel gehen wir auf die CSI-Treiber (Container Storage Interface) ein, die es Speicherherstellern ermöglichen, ihre Produkte Kubernetes als persistenten Speicher zur Verfügung zu stellen.
CSI: Verbindet Kubernetes mit über 60 Speicherprodukten
CSI ist die Schnittstelle zu Container-Speicher. Es handelt sich um ein Plug-in für Kubernetes und andere Container-Orchestratoren, das es Speicheranbietern ermöglicht, ihre Produkte containerisierten Anwendungen als dauerhaften Speicher darzustellen.
Zum Zeitpunkt der Erstellung dieses Artikels sind mehr als 60 CSIs für eine Vielzahl von Datei-, Block- und Objektspeichern in Hardware- und Cloud-Formaten verfügbar.
CSI ist im Wesentlichen eine Schnittstelle zwischen Container-Workloads und Speicher von Drittanbietern, die die Erstellung und Konfiguration von persistentem Speicher außerhalb des Orchestrators, dessen Ein-/Ausgabe (I/O) und erweiterte Funktionen wie Snapshots und Klonen unterstützt.
CSI ersetzt Plug-ins, die früher in der Kubernetes-Evolution entwickelt wurden, wie zum Beispiel In-Tree-Volume-Plug-ins und FlexVolume-Plug-ins. Ohne ins Detail zu gehen, liegt der Vorteil von CSI darin, dass es so konzipiert wurde, dass es einen vereinfachten Satz von Spezifikationen bietet, nach denen Speicheranbieter ihre Plug-ins schreiben können, und dass sie nicht vom Kubernetes-Release-Zyklus abhängig sind.
Orientierung: CSI in PVs, Speicherklassen und PVCs
Sobald Sie ein CSI in einem Kubernetes-Cluster implementiert haben, steht es für die Verwendung mit persistenten Volumes (PV), Speicherklassen und persistenten Volumes Claims (PVCs) zur Verfügung.
Sie können beispielsweise eine Speicherklasse erstellen, die auf externen Speicher verweist, der durch ein CSI-Plug-in definiert ist. Dann könnte die dynamische Bereitstellung durch ein PVC ausgelöst werden, das eine Speicherklasse angibt. Wenn dies anschließend die Erstellung eines Volumes auslöst, wird es durch den externen Speicher über das CSI-Plug-in ausgeführt, und das PV wird an das PVC gebunden. Alternativ ist es auch möglich, ein bereits vorhandenes Volumen über ein PV freizulegen.
Das CSI erhielt den Status der allgemeinen Verfügbarkeit mit der Version 1.13 von Kubernetes, die zum Zeitpunkt des Erscheinens dieses Artikels bei 1.17 lag.
Zu den Beta-Funktionen, die es wahrscheinlich in künftige Versionen schaffen werden, gehören die Möglichkeit, reinen (raw) Blockspeicher für den Container freizugeben, die Kenntnis darüber, wo der Speicher in Bezug auf Cloud-Zonen und -Regionen bereitgestellt wird, und Volumen-Snapshots.
