kalafoto - stock.adobe.com
Das sollten Sie über Kubernetes Container Storage wissen
Wir erklären die Grundlagen der Speichererstellung und dessen Spezifizierung für Anwendungen für Container mittels Kubernetes Persistent Volumes und Persistent Volume Claims.
Die Verwendung von containerisierten Anwendungen, in der Regel mit einem Container-Orchestrator wie Kubernetes, ist derzeit ein enormer Trend in der IT, der bei Anwendern aus allen Bereichen nahezu allgegenwärtig ist. Bei containerisierten Anwendungen handelt es sich um eine Form der Anwendungsvirtualisierung, die jedoch die Notwendigkeit mehrerer Iterationen eines Betriebssystems (OS) überflüssig macht. Container sind so etwas wie „traditionelle“ Virtuelle Maschinen (VMs), nutzen aber das Server-Betriebssystem, anstatt eigene kleine Versionen zu erstellen.
Container – oft Docker, aber es gibt auch andere auf dem Markt – enthalten alles, was für die Ausführung einer Anwendung benötigt wird, und können erstellt, in Betrieb genommen, geklont und skaliert werden und sehr schnell wieder gelöscht werden.
Aus diesem Grund eignen sich Container gut für Arbeitslasten, bei denen die Nachfrage massiv ansteigt, insbesondere im Web und vor allem dort, wo die Automatisierungsfunktionalität von Kubernetes dies schnell ermöglicht.
Container sind von Natur aus zustandslos, und wir werden uns zunächst ansehen, wie diese funktionieren, obwohl sich der größte Teil dieses Artikels mit dem persistenten Speicher in Kubernetes befasst, das sich dies zur Standardplattform für die Container-Orchestrierung entwickelt hat.
Kubernetes befasst sich mit Funktionen wie der Erstellung, Verwaltung, Automatisierung, Lastverteilung, Beziehung zur Hardware – einschließlich des Speichers – von Containern, die in Kubernetes-Sprache in Pods organisiert sind, was wir jede Sammlung eines oder mehrerer Container nennen.
Von Natur aus vergänglich, bei Bedarf ausdauernd
Im einfachsten Fall ist das Storage in Kubernetes flüchtig (nicht persistent). Es ist Speicher, der in den Container geschrieben und aus temporärem Speicherplatz auf dem Host-Rechner geschaffen wird, der für die Lebensdauer des Kubernetes-Pods existiert. Er wird über den Befehl emptyDir erstellt und ist portabel, aber nicht persistent.
Kubernetes unterstützt auch persistenten Speicher, der in einer Vielzahl von On-Premises- und Cloud-Formaten vorliegen kann, darunter Datei-, Block-, Objekt- und zahlreiche Speicherklassen der Cloud-Anbieter. Speicher kann auch als Datendienste, wie zum Beispiel Datenbanken, vorhanden sein, die letztlich auch auf die Existenz von physischem Speicher angewiesen sind.
Der Speicher kann direkt aus dem Inneren des Pods referenziert werden, aber dies wird nicht empfohlen, da es gegen das Portabilitätsprinzip von Container/Pod verstößt. Stattdessen werden Persistent Volumes und Persistent Volume Claims (PV/PVC) verwendet, um Speicher- und Anwendungsanforderungen zu definieren.
PVs und PVCs entkoppeln die Speicherimplementierung von ihrer Funktion und ermöglichen es, dass die Block-/Datei-/Objektspeicherung von einem Pod auf portable Art und Weise verbraucht werden kann. Sie entkoppeln auch die Bedürfnisse des Anwenders/der Anwendung und die Speicherkonfiguration.
Bei einem PV definieren Admins den Speicher und seine Leistungs- und Kapazitätsparameter – das heißt, es definiert ein persistentes Speicher-Volume. Es enthält Details über den Speicher wie Leistungs-/Kostenklasse, Kapazität, sowie das verwendete Volume-Plug-in, Pfade, IP-Adressen, Benutzernamen und Passwörter und was nach der Verwendung mit dem Volume zu tun ist. PVs sind nicht über Kubernetes-Cluster hinweg portabel.
Ein PVC hingegen wird verwendet, um den Speicherplatz zu beschreiben, den ein Benutzer/die Entwickler für ihre Anwendung wünscht. Diese sind portabel und werden mit der Anwendung mitgeführt. Kubernetes ermittelt, welcher Speicher von definierten PVs verfügbar ist, und bindet das PVC daran.
PVCs werden in der YAML des Pods definiert, so dass der Anspruch mit dem Pod „mitreist“ und ziemlich einfach sein kann, indem beispielsweise nur Kapazität und Speicherebene angegeben werden.
Es gibt Vorkehrungen für mehrere geklonte Pods in Kubernetes, die als Deployment bezeichnet werden und sich ein einzelnes PVC teilen, aber dies kann zu Problemen wie Abstürzen führen. Eine Alternative ist das Stateful Set, bei dem PVC über mehrere Pods hinweg dupliziert wird.
Speicherklassengruppen persistenter Volumes
Eine Sammlung von PVs kann in einer Speicherklasse gruppiert werden, bei der es sich um eine Kubernetes-Programmierschnittstelle (API) handelt, die Speicherparameter festlegt. Es handelt sich dabei um eine dynamische Bereitstellungsmethode, die die Möglichkeit bietet, bei Bedarf neue Volumes zu erstellen.
Die Speicherklasse gibt das verwendete Volume-Plug-in, den externen Provider, wie zum Beispiel Cloud-Provider, und den Namen des CSI-Treibers an. Container Storage Interfaces (CSI) sind Treiber, die es Containern ermöglichen, mit Produkten von Cloud- und Speicheranbietern zu interagieren.
Es ist eine gute Praxis, eine Speicherklasse als „Standard“ zu markieren, damit sie nicht durch die Verwendung eines PVCs aufgerufen werden muss, oder damit sie aufgerufen werden kann, wenn ein Benutzer keine Speicherklasse in einem PVC angibt.
Eine Speicherklasse kann auch für alte Daten erstellt werden, auf die möglicherweise von containerisierten Anwendungen zugegriffen werden muss.
Andere Optionen für Storage in Kubernetes
Es gibt andere Methoden zur Schaffung von Kubernetes-Speichern, aber diese haben ihre Nachteile, wie beispielsweise die mangelnde Portabilität.
Das ist der Fall beim Host-Pfad, der ein Verzeichnis auf dem Host-Rechner freilegt. Das wird natürlich nicht portabel sein, da der Pfad nicht zugänglich sein wird, wenn der Pod/Container verschoben wird, und das ist etwas, was die meisten Pod-Bereitstellungen nicht wollen.
Lokale persistente Volumes können auch durch Block-, Datei- oder Objektspeicherung erstellt werden. Dies kann unter anderem zum Aufbau eines verteilten Speichersystems auf Kubernetes verwendet werden, wodurch effektiv ein virtualisierter/containerisierter Speicherpool geschaffen wird, der in etwa dem entspricht, was von Rook erstellt wurde.
