Speicherkonzepte für Kubernetes
Kubernetes ist eine offene Plattform, die containerbasierte Anwendungen und die zugehörigen Netzwerk- und Speicherkomponenten verwaltet. Es bietet einen deklarativen Ansatz für Bereitstellungen und wird durch einen stabilen Satz an APIs für Verwaltungsvorgänge unterstützt.
Sie können moderne, portable, auf Microservices basierende Anwendungen entwickeln und ausführen, die Kubernetes zur Orchestrierung und Verwaltung der Verfügbarkeit der Anwendungskomponenten nutzen.
Containerverwaltung und -orchestrierung
Die Containerverwaltung ist der Prozess zum Organisieren, Hinzufügen, Entfernen oder Aktualisieren einer großen Anzahl von Containern. Ein Containerorchestrator ist ein System, das Container-Apps automatisch bereitstellt und verwaltet. Beispielsweise kann ein Orchestrator dynamisch auf Änderungen in der Umgebung reagieren, um die bereitgestellten Instanzen der verwalteten App zu erhöhen oder zu verringern, oder er kann sicherstellen, dass alle bereitgestellten Containerinstanzen aktualisiert werden, wenn eine neue Version eines Diensts veröffentlicht wird.
Kubernetes-Architektur
Die Architektur von Kubernetes basiert auf Clustern. Ein Kubernetes-Cluster ist in zwei Haupt-Infrastrukturkomponenten aufgeteilt:
- Die Steuerungsebene stellt die grundlegenden Kubernetes-Dienste und Orchestrierungsfunktionen für Anwendungsworkloads bereit.
- Knoten, auf denen Ihre Anwendungsworkloads ausgeführt werden. Jeder Cluster verfügt über mindestens einen Knoten, Sie können jedoch die Anzahl und Größe von Knoten definieren. Ein Knotenpool ist eine Gruppe von Knoten, die dieselbe Konfiguration aufweisen.
Die Ressourcen für Ihre Anwendungsworkloads sind in Podsenthalten. Ein Pod ist in Kubernetes eine kurzlebige Ressource, die eine einzelne Instanz Ihrer Anwendung darstellt. Sie besteht aus einem oder mehreren Containern mit freigegebenen Speicher- und Netzwerkressourcen und einer Spezifikation für die Ausführung der Container. Die Inhalte eines Pods werden immer gemeinsam gespeichert und geplant und in einem freigegebenen Kontext ausgeführt.
Dauerhafter Speicher in Kubernetes
In der vorherigen Lektion haben wir die Unterstützungsmechanismen in Windows-Containern kennengelernt, mit denen Sie beständigen Speicher für Ihre Anwendungen in einer lokalen Umgebung durch Binden von Bereitstellungen und benannten Volumes bereitstellen können. Volumes und Bind Mounts haben jedoch einige Nachteile, wenn sie in einer verteilten Umgebung wie Kubernetes verwendet werden.
Volumes und Bind Mounts sind an einen bestimmten Hostcomputer gebunden, was bedeutet, dass sie nicht über Knoten in einem Cluster portierbar sind. Wenn ein Container auf einem anderen Knoten als dem geplanten ist, in dem seine Daten gespeichert sind, kann er nicht darauf zugreifen. Darüber hinaus sind Volumes und Bind Mounts nicht skalierbar oder robust, da sie von der Verfügbarkeit und Kapazität eines einzelnen Hostcomputers abhängen.
Kubernetes löst die Speicherprobleme von Containern, indem zwei Abstraktionen eingeführt werden: dauerhafte Volumes und dauerhafte Volumeannsprüche.
Persistente Volumes
Ein dauerhafter Volume (PV) ist eine von der Kubernetes-API erstellte und verwaltete Speicherressource, die unabhängig von der Lebensdauer eines einzelnen Pods vorhanden sein kann. Ein Clusteradministrator kann einen PersistentVolume
oder den Kubernetes-API-Server dynamisch mithilfe von Speicherklassenerstellen. Eine PV ist eine Ressource im Cluster, genau wie ein Knoten eine Clusterressource. PVs haben einen Lebenszyklus unabhängig von jedem einzelnen Pod, der die PV verwendet.
Ansprüche auf persistente Volumes
Ein persistenter Volumenanspruch (PVC) fordert die Speicherung eines bestimmten Zugriffsmodus und einer bestimmten StorageClass
Größe an. Das PVC fungiert als Anspruchsprüfung für die Speicherressource. Wie bereits erwähnt, kann der Kubernetes-API-Server die zugrunde liegende Azure-Speicherressource dynamisch bereitstellen, wenn basierend auf der definierten StorageClass keine Ressource den Anspruch erfüllen kann.
StorageClass
bietet Administratoren die Möglichkeit, die von ihnen angebotenen Speicherklassen zu beschreiben. Verschiedene Klassen können Quality-of-Service-Ebenen oder Sicherungsrichtlinien oder beliebigen Richtlinien zugeordnet werden, die von den Clusteradministratoren bestimmt werden. Kubernetes selbst hat keine starke Vorstellung darüber, was Klassen darstellen.
Sobald der Kubernetes-API-Server dem Pod eine verfügbare Speicherressource zuweist, die Speicher anfordert, ist das PV an ein PVC gebunden. Persistente Volumes sind eine 1:1-Zuordnung zu einem dauerhaften Volumeanspruch.