Am einfachsten ist es, die Objekte, deren Bedeutung und ihre Interaktion zu verstehen, wenn ein Kubernetes-Benutzer eine einzelne Storage-Anfrage bearbeitet:

Ein Kubernetes- `PersistentVolumeClaim`Objekt ist eine Anforderung von Storage, der von einem Kubernetes-Cluster-Benutzer erstellt wird.

Zusätzlich zur Standardspezifikation können Benutzer mit Trident die folgenden Volume-spezifischen Anmerkungen angeben, wenn sie die in der Back-End-Konfiguration festgelegten Standardeinstellungen überschreiben möchten:

Wenn das erstellte PV über die Zurückgewinnungsrichtlinie verfügt Delete, löscht Trident sowohl das PV als auch das Back-Volume, wenn das PV freigegeben wird (d. h. wenn der Benutzer die PVC löscht). Sollte die Löschaktion fehlschlagen, markiert Trident den PV als solche und wiederholt den Vorgang periodisch, bis er erfolgreich ist oder der PV manuell gelöscht wird. Wenn das PV die Richtlinie verwendet Retain, ignoriert Trident sie und geht davon aus, dass der Administrator sie von Kubernetes und dem Back-End bereinigt, sodass das Volume vor dem Entfernen gesichert oder inspiziert werden kann. Beachten Sie, dass das Löschen des PV nicht dazu führt, dass Trident das Backing-Volume löscht. Sie sollten es mit der REST API entfernen (tridentctl).

Trident unterstützt die Erstellung von Volume Snapshots anhand der CSI-Spezifikation: Sie können einen Volume Snapshot erstellen und ihn als Datenquelle zum Klonen vorhandener PVCs verwenden. So können zeitpunktgenaue Kopien von PVS in Form von Snapshots Kubernetes zugänglich gemacht werden. Die Snapshots können dann verwendet werden, um neue PVS zu erstellen. Schauen Sie sich an On-Demand Volume Snapshots, um zu sehen, wie das funktionieren würde.

Trident liefert außerdem die cloneFromPVC Annotationen und splitOnClone zum Erstellen von Klonen. Mit diesen Anmerkungen können Sie eine PVC klonen, ohne die CSI-Implementierung verwenden zu müssen.

Hier ist ein Beispiel: Wenn ein Benutzer bereits eine PVC aufgerufen hat mysql, kann der Benutzer eine neue PVC erstellen, die über die Anmerkung aufgerufen wird mysqlclone, wie `trident.netapp.io/cloneFromPVC: mysql`z.B. . Mit diesem Anmerkungsset klont Trident das Volume, das dem mysql PVC entspricht, anstatt ein Volume von Grund auf neu bereitzustellen.

Berücksichtigen Sie folgende Punkte:

Das sample-input Verzeichnis enthält Beispiele für PVC-Definitionen für die Verwendung mit Trident. Eine vollständige Beschreibung der Parameter und Einstellungen zu Trident Volumes finden Sie unter.

Ein Kubernetes- `PersistentVolume`Objekt ist ein Storage-Element, der dem Kubernetes Cluster zur Verfügung gestellt wird. Es weist einen Lebenszyklus auf, der unabhängig vom POD ist, der ihn nutzt.

Wenn Sie eine PVC erstellen, die sich auf ein Trident-basiertes bezieht StorageClass, stellt Trident ein neues Volume mit der entsprechenden Speicherklasse bereit und registriert ein neues PV für dieses Volume. Bei der Konfiguration des bereitgestellten Volume und des entsprechenden PV befolgt Trident folgende Regeln:

Kubernetes- StorageClass`Objekte werden mithilfe des Namens in angegeben `PersistentVolumeClaims, um Storage mit einem Satz von Eigenschaften bereitzustellen. Die Storage-Klasse selbst gibt die zu verwendenden bereitstellungsunternehmen an und definiert die Eigenschaftengruppe in Bezug auf die provisionierung von.

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

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

Diese Parameter sind Trident-spezifisch und Trident erläutert die Bereitstellung von Volumes für die Klasse.

Parameter der Storage-Klasse sind:

Storage-Attribute und ihre möglichen Werte können in Auswahlebene und Kubernetes-Attribute des Storage-Pools klassifiziert werden.

Kubernetes- VolumeSnapshotClass`Objekte sind analog zu `StorageClasses. Sie helfen, 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.

Ein VolumeSnapshotClass sollte von einem Administrator definiert werden, um Snapshots zu erstellen. Eine Volume-Snapshot-Klasse wird mit folgender Definition erstellt:

Der driver gibt an Kubernetes an, dass Anforderungen von Volume-Snapshots der csi-snapclass Klasse von Trident verarbeitet werden. Der deletionPolicy gibt die Aktion an, die ausgeführt werden soll, wenn ein Snapshot gelöscht werden muss. Wenn deletionPolicy auf festgelegt ist Delete, werden die Volume-Snapshot-Objekte sowie der zugrunde liegende Snapshot auf dem Speicher-Cluster entfernt, wenn ein Snapshot gelöscht wird. Wenn Sie diese Einstellung auf setzen Retain, bedeutet dies, dass VolumeSnapshotContent der physische Snapshot beibehalten wird.

Ein Kubernetes- `VolumeSnapshot`Objekt ist eine Anforderung zur Erstellung eines Snapshots eines Volumes. So wie eine PVC eine von einem Benutzer erstellte Anfrage für ein Volume darstellt, besteht bei einem Volume-Snapshot die Anforderung eines Benutzers, einen Snapshot eines vorhandenen PVC zu erstellen.

Wenn eine Volume-Snapshot-Anfrage eingeht, managt Trident automatisch die Erstellung des Snapshots für das Volume auf dem Backend und legt den Snapshot durch Erstellen eines eindeutigen Objekts dar.
VolumeSnapshotContent Sie können Snapshots aus vorhandenen VES erstellen und die Snapshots als Datenquelle beim Erstellen neuer VES verwenden.

Ein Kubernetes- VolumeSnapshotContent`Objekt ist ein Snapshot, der von einem bereits bereitgestellten Volume erstellt wurde. Er ist analog zu einem `PersistentVolume und bedeutet einen bereitgestellten Snapshot auf dem Storage-Cluster. Wenn ein Snapshot erstellt wird, behält das Objekt, ähnlich wie PersistentVolumeClaim Objekte VolumeSnapshotContent von und PersistentVolume, eine Eins-zu-eins-Zuordnung zu dem VolumeSnapshot Objekt bei, das die Snapshot-Erstellung angefordert hatte.

Das VolumeSnapshotContent Objekt enthält Details, die den Snapshot eindeutig identifizieren, z. B. snapshotHandle . Dies snapshotHandle ist eine eindeutige Kombination aus dem Namen des PV und dem Namen des VolumeSnapshotContent Objekts.

Wenn eine Snapshot-Anfrage eingeht, erstellt Trident den Snapshot auf dem Back-End. Nachdem der Snapshot erstellt wurde, konfiguriert Trident ein VolumeSnapshotContent Objekt und legt den Snapshot der Kubernetes-API vor.

Kubernetes Custom Ressourcen sind Endpunkte in der Kubernetes API, die vom Administrator definiert werden und zum Gruppieren ähnlicher Objekte verwendet werden. Kubernetes unterstützt das Erstellen individueller Ressourcen zum Speichern einer Sammlung von Objekten. Sie können diese Ressourcendefinitionen erhalten, indem Sie ausführen kubectl get crds.

CRDs (Custom Resource Definitions) und die zugehörigen Objektmetadaten werden durch Kubernetes im Metadatenspeicher gespeichert. Dadurch ist kein separater Speicher für Trident erforderlich.

Astra Trident verwendet CustomResourceDefinition Objekte zur Wahrung der Identität von Trident Objekten wie Trident Back-Ends, Trident Storage-Klassen und Trident Volumes. Diese Objekte werden von Trident gemanagt. Darüber hinaus werden im CSI-Volume-Snapshot-Framework einige CRS-IDs verwendet, die zum Definieren von Volume-Snapshots erforderlich sind.

CRDs stellen ein Kubernetes-Konstrukt dar. Objekte der oben definierten Ressourcen werden von Trident erstellt. Ein einfaches Beispiel: Wenn ein Backend mit erstellt tridentctl wird, wird ein entsprechendes tridentbackends CRD-Objekt für den Verbrauch durch Kubernetes erstellt.

Beachten Sie die folgenden CRDs von Trident:

Trident erstellt passende Storage-Klassen für Kubernetes- StorageClass`Objekte, die in ihrem Feld „bereitstellung“ angegeben werden `csi.trident.netapp.io. Der Name der Storage-Klasse stimmt mit dem Kubernetes-Objekt überein StorageClass, das sie darstellt.

Storage-Klassen umfassen eine Reihe von Anforderungen für Volumes. Trident stimmt diese Anforderungen mit den in jedem Storage-Pool vorhandenen Attributen überein. Ist dieser Storage-Pool ein gültiges Ziel für die Bereitstellung von Volumes anhand dieser Storage-Klasse.

Sie können Storage-Klassen-Konfigurationen erstellen, um Storage-Klassen direkt über DIE REST API zu definieren. Bei Kubernetes-Implementierungen erwarten wir jedoch, dass sie bei der Registrierung neuer Kubernetes-Objekte erstellt werden StorageClass.

Back-Ends stellen die Storage-Anbieter dar, über die Trident Volumes bereitstellt. Eine einzelne Trident Instanz kann eine beliebige Anzahl von Back-Ends managen.

Weitere Informationen zum Erstellen dieser Objekte finden Sie unter "Back-Ends werden konfiguriert".

Storage-Pools stellen die verschiedenen Standorte dar, die für die Provisionierung an jedem Back-End verfügbar sind. Für ONTAP entsprechen diese Aggregaten in SVMs. Bei NetApp HCI/SolidFire entsprechen diese den vom Administrator festgelegten QoS-Bands. Für Cloud Volumes Service entsprechen diese Regionen Cloud-Provider. Jeder Storage-Pool verfügt über eine Reihe individueller Storage-Attribute, die seine Performance-Merkmale und Datensicherungsmerkmale definieren.

Im Gegensatz zu den anderen Objekten hier werden Storage-Pool-Kandidaten immer automatisch erkannt und gemanagt.

Volumes sind die grundlegende Bereitstellungseinheit, die Back-End-Endpunkte umfasst, wie NFS-Freigaben und iSCSI-LUNs. In Kubernetes entsprechen diese direkt PersistentVolumes . Wenn Sie ein Volume erstellen, stellen Sie sicher, dass es über eine Storage-Klasse verfügt, die bestimmt, wo das Volume zusammen mit einer Größe bereitgestellt werden kann.

Eine Volume-Konfiguration definiert die Eigenschaften, über die ein bereitgestelltes Volume verfügen sollte.

Trident wird beim Erstellen des Volume generiert internalName. Dies besteht aus zwei Schritten. Zuerst wird das Speicherpräfix (entweder der Standard oder das Präfix in der Backend-Konfiguration) dem Volume-Namen vorangestellt trident, was zu einem Namen des Formulars führt <prefix>-<volume-name>. Anschließend wird der Name desinfiziert und die im Backend nicht zulässigen Zeichen ersetzt. Für ONTAP-Back-Ends ersetzt er Bindestriche durch Unterstriche (der interne Name lautet also <prefix>_<volume-name> ). Bei Element-Back-Ends werden Unterstriche durch Bindestriche ersetzt.

Sie können Volume-Konfigurationen verwenden, um Volumes direkt mit der REST-API bereitzustellen, doch in Kubernetes-Implementierungen erwarten wir, dass die meisten Benutzer die standardmäßige Kubernetes-Methode verwenden PersistentVolumeClaim. Trident erstellt dieses Volume-Objekt automatisch im Rahmen des Bereitstellungsprozesses.

Snapshots sind eine zeitpunktgenaue Kopie von Volumes, die zur Bereitstellung neuer Volumes oder für Restores verwendet werden kann. In Kubernetes entsprechen diese direkt VolumeSnapshotContent Objekten. Jeder Snapshot ist einem Volume zugeordnet, das die Quelle der Daten für den Snapshot ist.

Jedes Snapshot Objekt enthält die nachfolgend aufgeführten Eigenschaften:

Bei der Erstellung einer Kubernetes- VolumeSnapshot`Objektanforderung erstellt Trident ein Snapshot-Objekt auf dem zugrunde liegende Storage-System. Die `internalName des Snapshot-Objekts wird durch die Kombination des Präfixes mit dem UID des VolumeSnapshot Objekts generiert snapshot- (z. B. snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660 ). volumeName Und volumeInternalName werden mit den Details des Backing-Volumes gefüllt.

Der Trident-Deamonset nutzt eine system-node-critical Prioritätsklasse – die höchste in Kubernetes verfügbare Klasse –, um sicherzustellen, dass Astra Trident Volumes beim ordnungsgemäßen Herunterfahren von Nodes identifizieren und bereinigen kann. Trident-Dämonset-Pods vermeiden Workloads mit einer niedrigeren Priorität in Clustern, bei denen der Ressourcendruck hoch ist.

Dazu verwendet Astra Trident ein ResourceQuota Objekt, um sicherzustellen, dass eine „systemNode-kritische“ Prioritätsklasse auf dem Trident-Dämonset erfüllt wird. Vor der Implementierung und der Erstellung von Demonset sucht Astra Trident nach dem ResourceQuota Objekt und wendet es, falls es nicht erkannt wird, an.

Wenn Sie mehr Kontrolle über die Standardkontingente und Prioritätsklasse benötigen, können Sie ein Objekt mithilfe des Helm-Diagramms erzeugen custom.yaml oder konfigurieren ResourceQuota.

Im Folgenden finden Sie ein Beispiel für ein `ResourceQuota`Objekt mit Priorität des Trident-Dämonenset.

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