Am einfachsten lassen sich die Objekte, ihr Zweck und ihre Interaktion verstehen, indem man eine einzelne Speicheranfrage eines Kubernetes-Benutzers verfolgt:

Ein Kubernetes PersistentVolumeClaim Ein Objekt ist eine Speicheranforderung, die von einem Kubernetes-Cluster-Benutzer gestellt wird.

Zusätzlich zur Standardspezifikation ermöglicht Trident den Benutzern, die folgenden volumespezifischen Annotationen anzugeben, wenn sie die in der Backend-Konfiguration festgelegten Standardeinstellungen überschreiben möchten:

Wenn die erstellte PV die Delete Gemäß der Rückforderungsrichtlinie löscht Trident sowohl das PV als auch das zugehörige Datenvolumen, wenn das PV freigegeben wird (d. h. wenn der Benutzer das PVC löscht). Sollte der Löschvorgang fehlschlagen, kennzeichnet Trident den PV entsprechend und wiederholt den Vorgang regelmäßig, bis er erfolgreich ist oder der PV manuell gelöscht wird. Wenn die PV die Retain Trident ignoriert diese Richtlinie und geht davon aus, dass der Administrator das Volume aus Kubernetes und dem Backend entfernt, sodass es vor seiner Löschung gesichert oder überprüft werden kann. Beachten Sie, dass das Löschen des PV nicht dazu führt, dass Trident das zugehörige Datenträgervolumen löscht. Sie sollten es mithilfe der REST-API entfernen.(tridentctl ).

Trident unterstützt die Erstellung von Volume Snapshots mithilfe der CSI-Spezifikation: Sie können einen Volume Snapshot erstellen und ihn als Datenquelle verwenden, um vorhandene PVCs zu klonen. Auf diese Weise können zeitpunktbezogene Kopien von PVs in Form von Snapshots für Kubernetes bereitgestellt werden. Die Snapshots können dann verwendet werden, um neue PVs zu erstellen. Schau dir das mal an On-Demand Volume Snapshots um zu sehen, wie das funktionieren würde.

Trident bietet außerdem die cloneFromPVC Und splitOnClone Anmerkungen zum Erstellen von Klonen. Mithilfe dieser Annotationen können Sie ein PVC klonen, ohne die CSI-Implementierung verwenden zu müssen.

Hier ein Beispiel: Wenn ein Benutzer bereits eine PVC namens besitzt mysql Der Benutzer kann eine neue PVC erstellen, die mysqlclone durch Verwendung der Annotation, wie zum Beispiel trident.netapp.io/cloneFromPVC: mysql . Mit dieser Annotation klont Trident das Volume, das dem MySQL-PVC entspricht, anstatt ein Volume von Grund auf neu zu erstellen.

Beachten Sie folgende Punkte:

Der sample-input Das Verzeichnis enthält Beispiele für PVC-Definitionen zur Verwendung mit Trident. Siehe Eine vollständige Beschreibung der Parameter und Einstellungen im Zusammenhang mit Trident -Volumes finden Sie hier.

Ein Kubernetes PersistentVolume Das Objekt repräsentiert einen Speicherbereich, der dem Kubernetes-Cluster zur Verfügung gestellt wird. Es hat einen Lebenszyklus, der unabhängig von der Kapsel ist, die es verwendet.

Wenn Sie ein PVC erstellen, das sich auf ein Trident-basiertes System bezieht StorageClass Trident provisioniert ein neues Volume unter Verwendung der entsprechenden Speicherklasse und registriert ein neues PV für dieses Volume. Bei der Konfiguration des bereitgestellten Volumes und des zugehörigen PV befolgt Trident die folgenden Regeln:

Kubernetes StorageClass Objekte werden anhand ihres Namens angegeben in PersistentVolumeClaims Speicherplatz mit einer Reihe von Eigenschaften bereitstellen. Die Speicherklasse selbst identifiziert den zu verwendenden Provisionierer und definiert diesen Satz von Eigenschaften in einer für den Provisionierer verständlichen Weise.

Es handelt sich um eines von zwei grundlegenden Objekten, die vom Administrator erstellt und verwaltet werden müssen. Das andere ist das Trident Backend-Objekt.

Ein Kubernetes StorageClass Ein Objekt, das Trident verwendet, sieht folgendermaßen aus:

Diese Parameter sind Trident-spezifisch und geben Trident an, wie Volumes für die Klasse bereitgestellt werden sollen.

Die Parameter der Speicherklasse sind:

Speicherattribute und ihre möglichen Werte lassen sich in Speicherpool-Auswahlattribute und Kubernetes-Attribute unterteilen.

Kubernetes VolumeSnapshotClass Objekte sind analog zu StorageClasses . Sie helfen dabei, mehrere Speicherklassen zu definieren und werden von Volume-Snapshots referenziert, um den Snapshot der erforderlichen Snapshot-Klasse zuzuordnen. Jeder Volume-Snapshot ist einer einzelnen Volume-Snapshot-Klasse zugeordnet.

A VolumeSnapshotClass Um Snapshots zu erstellen, muss ein Administrator dies definieren. Eine Volume-Snapshot-Klasse wird mit folgender Definition erstellt:

Der driver legt fest, dass Kubernetes Anfragen für Volume-Snapshots des csi-snapclass Die Klassen werden von Trident verwaltet. Der deletionPolicy legt fest, welche Aktion ausgeführt werden soll, wenn ein Snapshot gelöscht werden muss. Wann deletionPolicy ist eingestellt auf Delete Beim Löschen eines Snapshots werden sowohl die Volume-Snapshot-Objekte als auch der zugrunde liegende Snapshot auf dem Speichercluster entfernt. Alternativ können Sie es auch so einstellen: Retain bedeutet, dass VolumeSnapshotContent und die physische Momentaufnahme wird beibehalten.

Ein Kubernetes VolumeSnapshot Bei „object“ handelt es sich um eine Anfrage zur Erstellung eines Snapshots eines Volumes. So wie ein PVC eine Anfrage eines Benutzers nach einem Volume darstellt, ist ein Volume-Snapshot eine Anfrage eines Benutzers zur Erstellung eines Snapshots eines bestehenden PVC.

Wenn eine Anfrage für einen Volume-Snapshot eingeht, verwaltet Trident automatisch die Erstellung des Snapshots für das Volume im Backend und stellt den Snapshot durch die Erstellung einer eindeutigen ID bereit.
VolumeSnapshotContent Objekt. Sie können Snapshots aus bestehenden PVCs erstellen und diese Snapshots als Datenquelle beim Erstellen neuer PVCs verwenden.

Ein Kubernetes VolumeSnapshotContent Das Objekt stellt eine Momentaufnahme eines bereits bereitgestellten Volumes dar. Es ist analog zu einem PersistentVolume und kennzeichnet einen bereitgestellten Snapshot auf dem Speichercluster. Ähnlich PersistentVolumeClaim Und PersistentVolume Objekte, wenn ein Snapshot erstellt wird, VolumeSnapshotContent Das Objekt verwaltet eine Eins-zu-Eins-Zuordnung zum VolumeSnapshot Objekt, das die Erstellung des Snapshots angefordert hatte.

Der VolumeSnapshotContent Das Objekt enthält Details, die den Snapshot eindeutig identifizieren, wie zum Beispiel die snapshotHandle . Das snapshotHandle ist eine einzigartige Kombination aus dem Namen der PV und dem Namen der VolumeSnapshotContent Objekt.

Wenn eine Snapshot-Anfrage eingeht, erstellt Trident den Snapshot im Backend. Nachdem der Snapshot erstellt wurde, konfiguriert Trident einen VolumeSnapshotContent Das Objekt wird erstellt und somit der Kubernetes-API zugänglich gemacht.

Kubernetes VolumeGroupSnapshotClass Objekte sind analog zu VolumeSnapshotClass . Sie helfen dabei, mehrere Speicherklassen zu definieren und werden von Volume-Gruppen-Snapshots referenziert, um den Snapshot der erforderlichen Snapshot-Klasse zuzuordnen. Jeder Volume-Group-Snapshot ist einer einzelnen Volume-Group-Snapshot-Klasse zugeordnet.

A VolumeGroupSnapshotClass Um eine Gruppe von Snapshots zu erstellen, muss dies von einem Administrator definiert werden. Eine Snapshot-Klasse für eine Volumengruppe wird mit folgender Definition erstellt:

Der driver legt fest, dass Kubernetes Anfragen für Volume-Gruppen-Snapshots der csi-group-snap-class Die Klassen werden von Trident verwaltet. Der deletionPolicy legt die Aktion fest, die ausgeführt werden soll, wenn ein Gruppen-Snapshot gelöscht werden muss. Wann deletionPolicy ist eingestellt auf Delete Beim Löschen eines Snapshots werden sowohl die Volume-Group-Snapshot-Objekte als auch der zugrunde liegende Snapshot auf dem Speichercluster entfernt. Alternativ können Sie es auch so einstellen: Retain bedeutet, dass VolumeGroupSnapshotContent und die physische Momentaufnahme wird beibehalten.

Ein Kubernetes VolumeGroupSnapshot Das Objekt ist eine Anfrage zur Erstellung eines Snapshots mehrerer Volumes. So wie eine PVC eine Anfrage eines Benutzers nach einem Volume darstellt, ist ein Volume-Gruppen-Snapshot eine Anfrage eines Benutzers zur Erstellung eines Snapshots einer bestehenden PVC.

Wenn eine Anfrage für einen Volume-Gruppen-Snapshot eingeht, verwaltet Trident automatisch die Erstellung des Gruppen-Snapshots für die Volumes im Backend und stellt den Snapshot durch die Erstellung einer eindeutigen Kennung bereit. VolumeGroupSnapshotContent Objekt. Sie können Snapshots aus bestehenden PVCs erstellen und diese Snapshots als Datenquelle beim Erstellen neuer PVCs verwenden.

Ein Kubernetes VolumeGroupSnapshotContent Das Objekt stellt einen Gruppen-Snapshot dar, der von einem bereits bereitgestellten Volume erstellt wurde. Es ist analog zu einem PersistentVolume und kennzeichnet einen bereitgestellten Snapshot auf dem Speichercluster. Ähnlich PersistentVolumeClaim Und PersistentVolume Objekte, wenn ein Snapshot erstellt wird, VolumeSnapshotContent Das Objekt verwaltet eine Eins-zu-Eins-Zuordnung zum VolumeSnapshot Objekt, das die Erstellung des Snapshots angefordert hatte.

Der VolumeGroupSnapshotContent Das Objekt enthält Details, die die Snapshot-Gruppe identifizieren, wie zum Beispiel die volumeGroupSnapshotHandle und und einzelne VolumeSnapshotHandles, die auf dem Speichersystem vorhanden sind.

Wenn eine Snapshot-Anforderung eingeht, erstellt Trident im Backend den Volume-Group-Snapshot. Nachdem der Snapshot der Volumengruppe erstellt wurde, konfiguriert Trident einen VolumeGroupSnapshotContent Das Objekt wird erstellt und somit der Kubernetes-API zugänglich gemacht.

Kubernetes Custom Resources sind Endpunkte in der Kubernetes-API, die vom Administrator definiert werden und dazu dienen, ähnliche Objekte zu gruppieren. Kubernetes unterstützt die Erstellung benutzerdefinierter Ressourcen zum Speichern einer Sammlung von Objekten. Sie können diese Ressourcendefinitionen durch Ausführen von kubectl get crds .

Custom Resource Definitions (CRDs) und die zugehörigen Objektmetadaten werden von Kubernetes in seinem Metadatenspeicher abgelegt. Dadurch entfällt die Notwendigkeit eines separaten Ladengeschäfts für Trident.

Trident Anwendungen CustomResourceDefinition Objekte, um die Identität von Trident -Objekten wie Trident -Backends, Trident -Speicherklassen und Trident Volumes zu erhalten. Diese Objekte werden von Trident verwaltet. Darüber hinaus führt das CSI-Volume-Snapshot-Framework einige CRDs ein, die zur Definition von Volume-Snapshots erforderlich sind.

CRDs sind ein Konstrukt von Kubernetes. Objekte der oben definierten Ressourcen werden von Trident erstellt. Ein einfaches Beispiel: Wenn ein Backend erstellt wird mit tridentctl ein entsprechendes tridentbackends Ein CRD-Objekt wird zur Verwendung durch Kubernetes erstellt.

Hier einige Punkte, die Sie bei Tridents CRDs beachten sollten:

Trident erstellt passende Speicherklassen für Kubernetes. StorageClass Objekte, die spezifizieren csi.trident.netapp.io in ihrem Bereitstellungsfeld. Der Name der Speicherklasse stimmt mit dem von Kubernetes überein. StorageClass Das Objekt, das es repräsentiert.

Speicherklassen umfassen eine Reihe von Anforderungen an Datenträger. Trident gleicht diese Anforderungen mit den Attributen jedes Speicherpools ab; wenn sie übereinstimmen, ist dieser Speicherpool ein gültiges Ziel für die Bereitstellung von Volumes mit dieser Speicherklasse.

Sie können Speicherklassenkonfigurationen erstellen, um Speicherklassen direkt über die REST-API zu definieren. Bei Kubernetes-Bereitstellungen gehen wir jedoch davon aus, dass sie bei der Registrierung neuer Kubernetes-Instanzen erstellt werden. StorageClass Objekte.

Backends stellen die Speicheranbieter dar, auf denen Trident Volumes bereitstellt; eine einzelne Trident -Instanz kann beliebig viele Backends verwalten.

Weitere Informationen zum Erstellen dieser Objekte finden Sie unter"Backends konfigurieren" .

Speicherpools stellen die verschiedenen Speicherorte dar, die auf jedem Backend für die Bereitstellung zur Verfügung stehen. Für ONTAP entsprechen diese Aggregaten in SVMs. Bei NetApp HCI/ SolidFire entsprechen diese den vom Administrator festgelegten QoS-Bändern. Für den Cloud Volumes Service entsprechen diese den Regionen der Cloud-Anbieter. Jeder Speicherpool verfügt über eine Reihe unterschiedlicher Speicherattribute, die seine Leistungsmerkmale und Datenschutzeigenschaften definieren.

Im Gegensatz zu den anderen Objekten hier werden Speicherpoolkandidaten immer automatisch erkannt und verwaltet.

Volumes sind die grundlegende Bereitstellungseinheit und umfassen Backend-Endpunkte wie NFS-Freigaben sowie iSCSI- und FC-LUNs. In Kubernetes entsprechen diese direkt PersistentVolumes . Wenn Sie ein Volume erstellen, stellen Sie sicher, dass es über eine Speicherklasse verfügt, die festlegt, wo dieses Volume bereitgestellt werden kann, sowie über eine Größe.

Eine Volumenkonfiguration definiert die Eigenschaften, die ein bereitgestelltes Volumen haben soll.

Trident erzeugt internalName beim Erstellen des Volumens. Dies besteht aus zwei Schritten. Zunächst wird das Speicherpräfix vorangestellt (entweder das Standardpräfix). trident oder dem Präfix in der Backend-Konfiguration) zum Volume-Namen, was zu einem Namen der Form führt <prefix>-<volume-name> . Anschließend wird der Name bereinigt, indem im Backend nicht zulässige Zeichen ersetzt werden. Bei ONTAP Backends werden Bindestriche durch Unterstriche ersetzt (dadurch wird der interne Name zu <prefix>_<volume-name> ). Bei Element-Backends werden Unterstriche durch Bindestriche ersetzt.

Sie können Volume-Konfigurationen verwenden, um Volumes direkt über die REST-API bereitzustellen, aber bei Kubernetes-Bereitstellungen gehen wir davon aus, dass die meisten Benutzer die Standard-Kubernetes-Konfiguration verwenden. PersistentVolumeClaim Verfahren. Trident erstellt dieses Volume-Objekt automatisch im Rahmen des Bereitstellungsprozesses.

Snapshots sind Momentaufnahmen von Datenträgern, die zur Bereitstellung neuer Datenträger oder zur Wiederherstellung des vorherigen Zustands verwendet werden können. In Kubernetes entsprechen diese direkt VolumeSnapshotContent Objekte. Jeder Snapshot ist mit einem Volume verknüpft, das die Datenquelle für den Snapshot darstellt.

Jede Snapshot Das Objekt umfasst die unten aufgeführten Eigenschaften:

Wenn ein Kubernetes VolumeSnapshot Wenn eine Objektanforderung erstellt wird, funktioniert Trident , indem ein Snapshot-Objekt auf dem zugrunde liegenden Speichersystem erstellt wird. Der internalName Dieses Snapshot-Objekt wird durch die Kombination des Präfixes generiert. snapshot- mit dem UID der VolumeSnapshot Objekt (zum Beispiel, snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660 ). volumeName Und volumeInternalName werden durch Abrufen der Details des zugrunde liegenden Volumens befüllt.

Der Trident Dämonensatz verzehrt einen system-node-critical Prioritätsklasse – die höchste in Kubernetes verfügbare Prioritätsklasse – um sicherzustellen, dass Trident Volumes während des ordnungsgemäßen Herunterfahrens von Knoten identifizieren und bereinigen kann und dass Trident -Daemonset-Pods in Clustern mit hohem Ressourcendruck Workloads mit niedrigerer Priorität unterbrechen können.

Um dies zu erreichen, setzt Trident ein ResourceQuota Objekt, um sicherzustellen, dass eine Prioritätsklasse "system-node-critical" auf dem Trident -Daemonset erfüllt ist. Vor der Bereitstellung und der Erstellung des Daemonsets sucht Trident nach den ResourceQuota Objekt und, falls nicht gefunden, wendet es an.

Wenn Sie mehr Kontrolle über das Standardressourcenkontingent und die Prioritätsklasse benötigen, können Sie eine generieren. custom.yaml oder konfigurieren Sie die ResourceQuota Objekt, das das Helm-Chart verwendet.

Nachfolgend ein Beispiel für ein ResourceQuota-Objekt, das dem Trident -Daemonset Priorität einräumt.

Weitere Informationen zu Ressourcenkontingenten finden Sie unter"Kubernetes: Ressourcenkontingente" .