Starnberg, 28. Sept. 2021 - Wie für containerisierte Apps und Microservices-Architekturen eine persistente (cloud-native) Umgebung realisiert werden kann; mit Podcast-Beitrag...
Um was geht es hier? Auf Grund der Einführung von Containern für die Entwicklung, Erstellung und Bereitstellung von Anwendungen rückt das Thema „Persistenter Speicher“ in dem Zusammenhang verstärkt in den Mittelpunkt von Verantwortlichen. Anfangs wurde ja meist davon ausgegangen, dass der Container Storage zustandslos ist, aber kritische Anwendungsfälle, bei denen Daten über den Lebenszyklus eines Containers hinaus bestehen bleiben müssen, erfordern eine andere „Denke“. Dies führte zu Konzepten für persistenten Speicher wie z.B. bind mounts bei Docker-Volumes zur Ausführung zustandsabhängiger Anwendungen.
Aktuell haben sich die Möglichkeiten zum Betrieb von persistentem Speicher für Container doch deutlich verbessert und durch die Verwendung von APIs lässt sich Datenpersistenz relativ einfach herstellen. Ein Volume-Plugin integriert dazu Container-Orchestrierungssysteme wie Kubernetes oder auch Docker Swarm über APIs mit den (extern) angeschlossenen Speichersystemen. Darüber können persistente Volumes nativ bereitgestellt und einer App zugeordnet werden, die in einem Container läuft.
Weil das persistente Volume die Beendigung eines Containers übersteht, bleiben die von der Anwendung geschriebenen Zustandsdaten über die Lebensdauer des Containers hinaus erhalten. Das Container Storage Interface (CSI)** stellt dazu eine inzwischen ziemlich breitgefasste und von vielen Speicherherstellern bzw. Drittanbietern unterstützte Spezifikation dar, um die Container-Orchestrierung zu vereinheitlichen.
Für Kubernetes können Entwickler mithilfe von CSI optimierte Plugins schreiben, um neue Speichersysteme in Kubernetes bereitzustellen, ohne dabei den Code von Kubernetes selbst zu modifizieren. Weiterer Vorteil: die dynamische Bereitstellung von Volumes. Link > Kubernetes Blog „How to deploy a CSI driver?“ Speicher in Kubernetes läßt sich über folg. Cluster-Ressourcen definieren:
- PersistentVolumeClaim (PVC), Anfrage zur Bereitstellung von dynamischen Speicherplatz.
- StorageClass, Bereitstellung von Speicher mit verschiedenen Serviceklassen.
- PersistentVolume (PV) Speicher.
Abb.: Containerized Applications (Bildquelle: Docker). Link > https://www.docker.com/resources/what-container
Für Docker kann der externe Speicher über Volume Plugins integriert werden. Während Volumes zwar generell von Docker verwaltet werden können, bietet ein externer Speicher jedoch deutlich umfangreichere bzw. optimierte Storage-Services sowie höhere Ausfallsicherheit.
Kurzes Fazit: Die genannten Speicheroptionen bieten Betreibern die Möglichkeit, beim Übergang zu containerisierten Anwendungen sowie Microservices-Architekturen eine persistente (cloud-native) Umgebung mit hohem Automatisierungsgrad und SLA-Funktionen für ihre wichtigen Anwendungsdaten zu schaffen, ohne dass ihre Bereitstellung dazu explizit IT-gebunden sein muss. Wichtig bei der Auswahl einer Lösung ist, dass in jedem Fall eine konsistente Anwendungsleistung mit QoS erzielbar ist.
-
Mehr Informationen zur Positionierung von CSI versus Cloud-Native Container Storage finden Sie in diesem Podcast (Hörzeit: 04:55 min.) unter diesem Link > https://podcasts.apple.com/de/podcast/persistenter-speicher-und-cloud-na...
-
Blogpost > Persistenter Speicher: Cloud-nativer Container Storage oder mit Container Storage Interface?
-
Weitere Podcast-Episoden > https://podcasts.apple.com/de/podcast/storage-consortium/id81294878