Inzwischen gibt es verschiedene Ansätze, die Daten von Containern dauerhaft verfügbar zu machen, zum Beispiel Volume-Plug-ins, FlexVolume, Container Storage Interface und PersistentVolume.
Kubernetes ist eine Orchestrierungsplattform, die skalierbar Anwendungen und Services in Containern verwaltet. Der Einsatz von Kubernetes nützt Unternehmen mit verschiedenen, sich ändernden Workloads, und die Plattform ist ein leistungsfähiges Tool, um Anwendungen in Containern zu orchestrieren.
Wie schon Container wurde Kubernetes entwickelt, um sehr dynamische „stateless“ Prozesse zu unterstützen, bei denen Container kontinuierlich geschaffen und wieder aufgelöst werden, um unterschiedlichen Workloads zu entsprechen. Doch Storage für Kubernetes kann kompliziert sein. Viele Prozesse verlangen, dass die Daten länger als die Lebenszeit von Containern vorhanden sind, was im Widerspruch zu der eigentlichen Natur von Containern steht.
Mit den Jahren haben Kubernetes-Entwickler Volume-Plug-ins in die Kubernetes-Plattform eingefügt, um dem Bedürfnis nach beständigem (persistent) Speicher zu entsprechen. Ein Volume-Plug-in ist ein Modul, das die Kubernetes-Schnittstelle bis zu einer Verbindung mit einem physischen Storage-Volumen verlängert.
Volume-Plug-ins versprachen eine wirksame Methode, Daten über die Lebensspanne eines Containers hinaus zu erhalten, aber sie besaßen auch eine Reihe von Herausforderungen. Um diese Herausforderungen in den Griff zu bekommen, führte Kubernetes das FlexVolume-Plug-in ein, aber auch damit verbanden sich Probleme. Erst vor kurzem kam Kubernetes mit einem Plug-in heraus, das dem neuen Standard Container Storage Interface (CSI) entspricht und das den Prozess der Beständigkeit von Daten für verschiedene Speicherplattformen vereinfachen soll.
Die Kubernetes-Umgebung
Kubernetes ist eine portierbare und erweiterbare Plattform, die sowohl Automatisierung und erklärende Konfiguration unterstützt. Die Kubernetes-Umgebung umfasst einen Satz von unabhängigen Kontrollprozessen für das Management von Anwender-Workloads durch die Orchestrierung von Compute-, Netzwerk- und Storage-Ressourcen über Kubernetes-Cluster hinweg.
Die Vorteile von Kubernetes schließen die Unterstützung von fast jeder Anwendung ein, die in einem Container laufen kann, wodurch es möglich wird, verschiedene und fluktuierende Workloads zu installieren. Jeder Container besitzt sein eigenes File-System und ist isoliert von den anderen Containern und dem Host. Das führt zu dem Resultat, dass die Container nicht die Prozesse der anderen Container sehen können. Zusätzlich können die Container über Cloud- und Betriebssystemumgebungen verteilt werden, weil sie von der zugrunde liegenden Infrastruktur entkoppelt sind.
Ein Kubernetes-Cluster besteht aus einem Master- und aus Knoten-Systemen. Der Master sorgt für den Cluster und dient als primärer Punkt für die Kommunikation mit externen Ressourcen. Die Knoten bestehen aus physischen Servern oder virtuellen Maschinen, auf denen die Container-Workloads laufen.
Kubernetes-Cluster unterstützen die folgenden Object-Typen für die Installation von Container-Workloads:
Pod: Eine logische Struktur für den Betrieb und das Management eines Sets von miteinander verbundenen Containern. Alle Container innerhalb eines Pods teilen sich die Storage- und Netzwerk-Ressourcen. Der Pod ist die kleinste einsetzbare Computing-Einheit in dem Kubernetes-Cluster.
Volume: Ein logisches Directory, definiert auf dem Pod-Niveau, das für die Container in diesem Pod zugänglich ist. Das Volume hat die gleiche Lebenszeit wie der Pod, was bedeutet, dass es alle Container in dem Pod überleben kann.
Service: Ein REST-Object, das als eine Abstraktionsschicht für den Zugang zu einem logischen Set von Pods dient, um Frontend-Kunden von Backend-Prozessen abzutrennen.
Namespace: Ein Set von virtuellen Clustern, die auf dem gleichen physischen Cluster beruhen. Namespaces sind auf Umgebungen ausgerichtet, die viele Anwender über mehrere Teams oder Projekte hinweg unterstützen.
Kubernetes stellt Controller zur Verfügung, die auf diesen grundlegenden Objekten aufsetzen und zusätzliche Funktionalitäten liefern. Kubernetes umfasst auch eine API, die auf jeden Object-Typ verweist, um einen Mechanismus für die Arbeit mit der Kubernetes-Umgebung anzubieten.
Zusätzlich enthält jeder Kubernetes-Cluster eine Control-Plane für das Management der Umgebungs- und Automatisierungsprozesse. Die Control-Plane umfasst sowohl alle Prozesse auf dem Master und auf den Knotensystemen. Auf dem Master laufen verschiedene Prozesse für den Betrieb der Controller, das Management der Pods und das Funktionieren der Kubernetes-API. Auf den Knoten laufen Prozesse für den Betrieb der Netzwerkvorschriften, der anstehenden Verbindungen und der Kontrolle für den Betrieb der Container.
Der Pod stellt den primären Building Block für die Installation von Container-Workloads zur Verfügung. Er enthält einen oder mehrere Container, geteilte Storage-Ressourcen und eine bestimmte Netzwerk-IP-Adresse. Ein Pod umfasst außerdem Optionen zur Kontrolle des Container-Betriebs. In den meisten Fällen unterstützt ein Pod nur eine einzige Anwendungsinstanz, während weitere Pods für zusätzliche Instanzen hinzugefügt werden.
Storage für Kubernetes findet auf dem Pod-Niveau statt. Ein Pod kann mit einem Set von Storage Volumes konfiguriert werden, wodurch die Container des Pods Storage teilen und für eine Beständigkeit der Daten sorgen können, die somit Neustarts von Containern überleben können. Kubernetes bietet eine große Bandbreite von Volume-Arten an, darunter zum Beispiel Azure Disk, CephFS, iSCSI, vSphere Volume, Portworx Volume und Amazon Elastic Block Store.
Kubernetes stellt außerdem eine besondere Art von Volume für persistente Daten zur Verfügung – jenseits der Lebensdauer von Containern und Pods. Bezeichnet als PersistentVolume (PV) abstrahiert dieses Volume von den Details, wie Storage bereitgestellt oder von den Containern des Pods konsumiert wird.
Kubernetes installiert PVs als Volume-Plug-ins, die eine vom Pod unabhängige Lebensdauer besitzen. Volume-Plug-ins erweitern die Kubernetes-Schnittstelle für Verbindungen mit externem Storage. Die Plug-ins sind „In-Tree-Module“, die direkt in das Binärzentrum von Kubernetes eingebaut sind, womit den Containern direkt Storage geliefert werden kann, sobald er benötigt wird.
Weil die Plug-ins in den Code von Kubernetes eingefügt sind, müssen die Hersteller beim Hinzufügen eines neuen Speichersystems ihren Plug-in-Code direkt mit dem zentralen Code-Repository in Einklang bringen, was zu Instabilität und Sicherheitsproblemen in der Kubernetes-Plattform führen kann. Dieser Prozess bindet die Hersteller auch an den Release-Zyklus von Kubernetes an, weil sie den Source Code ihres Plug-ins für jeden öffnen müssen, der Zugang zum Kubernetes-Code hat.
Weil die Plug-ins in den Code von Kubernetes eingefügt sind, müssen die Hersteller beim Hinzufügen eines neuen Speichersystems ihren Plug-in-Code direkt mit dem zentralen Code-Repository in Einklang bringen.
Um diesen Begrenzungen etwas entgegenzusetzen, hat Kubernetes das FlexVolume-Plug-in eingeführt, das eine „Out-of-Tree“-Plug-in-Schnittstelle für Storage-bezogene Verbindungen bereitstellt. Auf diese Weise können Storage-Hersteller Treiber für die Kubernetes-Umgebung entwickeln, in der sie an das FlexVolume-Plug-in angeschlossen werden können.
Während dieser Storage-Ansatz für Kubernetes einige Vorteile für manche Hersteller bietet, zeigen sich aber auch einige Probleme. Zum Beispiel kann das Plug-in schwierig einzusetzen sein, außerdem erfordert es Zugang zu dem Root-File-System auf jedem Cluster-System.
CSI Volume-Plug-in
Erst vor kurzem hat Kubernetes ein neues CSI-Volume-Plug-in eingeführt, das diese Probleme ansprechen soll. Es stellt eine „Out-of-Tree“-Lösung dar, die dem CSI-Standard entspricht. CSI unterstützt Storage-Systeme für Container-Workloads, die von Tools für Container-Orchestrierung wie zum Beispiel Kubernetes gemanagt werden. Der neue Standard ermöglicht es einem Hersteller, einen eigenen Treiber zu entwickeln, der jede CSI-konforme Lösung für Container-Orchestrierung unterstützt.
Das CSI-Plug-in wurde mit dem Release 1.13 generell für Kubernetes verfügbar. Wie schon mit dem FlexVolume-Plug-in kann ein Hersteller einen CSI-konformen Treiber für die Kubernetes-Umgebung entwickeln und damit viele der Probleme vermeiden, die mit dem FlexVolume-Plug-in verbunden sind. Der Hersteller muss nicht mehr den Kubernetes-Code anrühren oder sich darum kümmern, wie Kubernetes installiert wird. Wenn der Treiber installiert ist, können die Anwender das CSI-Volume-Plug-in für Aufgaben wie das Anfügen oder Mounting von Volumes für dauerhafte Daten benutzen.
Während es ursprünglich nur zur Unterstützung von „stateless“ Prozessen entwickelt worden war, gehört zu den Vorteilen von Kubernetes heute auch die Fähigkeit, Container-Workloads zu orchestrieren. In der Vergangenheit waren Anstrengungen, Daten über die Lebensdauer von Containern und Pods hinaus haltbar zu machen, oft mit Problemen verbunden. Mit der Einführung von CSI-Plug-ins wird es jedoch für Unternehmen einfacher, das Container-Modell für ihre Workloads zu verwenden, besonders dadurch, dass mehr Storage-Hersteller CSI-konforme Treiber anbieten. Für viele IT-Teams könnte CSI genau den Anstoß bieten, den es für den Übergang in die Welt von Kubernetes und die Einrichtung von Storage für Kubernetes braucht.
