Container zustandslos (stateless) zu betreiben, schien am Anfang der beste Ansatz zu sein. Das vereinfacht die Sache natürlich ungemein. Dadurch lassen sich containerbasierte Anwendungen skalieren, indem auf zusätzlichen Hosts weitere Container starten. Gibt es mit einem Container Probleme, lässt sich dieser einfach beenden und auf einem anderen Node neu starten – soweit die Theorie.
In der Praxis können Anwender mit den zustandslosen Containern leider weniger erreichen, als die meisten sich wünschen. Und so hat beispielsweise die Container-Plattform Kubernetes in der Anfangszeit von Release zu Release entsprechend neue Features hinzugewonnen, etwa die Stateful Sets oder das Storage-Interface für persistente Volumes. Der Hersteller implementierte auch das Container Storage Interface (CSI), das die Cloud Native Computing Foundation (CNCF) zum Standard erhoben hat. Neben den mitgelieferten Möglichkeiten für persistente Volumes gibt es in der Kubernetes-Welt zahlreiche Anbieter von Storage-Produkten, die auf Container-Cluster zugeschnitten sind. Läuft Kubernetes auf einer der großen Cloudplattformen, gibt es typischerweise ein Interface zum entsprechenden Storage-Service, etwa GCEPersistentDisk (Google) oder AWS-ElasticBlockStore (Amazon). Dann besteht die Möglichkeit, klassische Storage-Protokolle wie NFS, iSCSI und FibreChannel zu verwenden oder moderne verteilte Dateisysteme wie Ceph oder GlusterFS.
Eine weitere Gruppe von Storage-Lösungen versucht, das Problem bei der Wurzel zu packen, und entwickelt von Grund auf Technologien, die mit den Besonderheiten einer Container-Landschaft umzugehen wissen. Beispiele für diese Cloud-Native-Storage-Ansätze sind Rook, das wir schon in einem früheren Heft [1] vorgestellt haben, Portworx, StorageOS oder OpenEBS (Elastic Block Storage ) [2], das wir uns im Folgenden genauer ansehen.
OpenEBS ist ein
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.