Vielleicht ist der einfachste Weg, die Objekte, ihren Zweck und ihre Interaktion zu verstehen, einer einzelnen Speicheranfrage eines Kubernetes-Benutzers zu folgen:

Ein Kubernetes PersistentVolumeClaim-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 das erstellte PV die Delete Reclaim-Richtlinie hat, löscht Trident sowohl das PV als auch das zugehörige Volume, sobald das PV freigegeben wird (das heißt, wenn der Benutzer das PVC löscht). Schlägt der Löschvorgang fehl, markiert Trident das PV entsprechend und wiederholt die Operation regelmäßig, bis sie erfolgreich ist oder das PV manuell gelöscht wird. Verwendet das PV die Retain Richtlinie, ignoriert Trident es und geht davon aus, dass der Administrator es aus Kubernetes und dem Backend entfernt, sodass das Volume vor seiner Entfernung gesichert oder überprüft werden kann. Beachten Sie, dass das Löschen des PV nicht dazu führt, dass Trident das zugehörige Volume löscht. Sie sollten es über die REST-API entfernen (tridentctl.

Trident unterstützt die Erstellung von Volume-Snapshots gemäß der CSI-Spezifikation: Sie können einen Volume-Snapshot erstellen und ihn als Datenquelle zum Klonen vorhandener PVCs verwenden. Auf diese Weise können zeitpunktgenaue Kopien von PVs in Form von Snapshots für Kubernetes bereitgestellt werden. Die Snapshots können dann zum Erstellen neuer PVs verwendet werden. Sehen Sie sich On-Demand Volume Snapshots an, um zu sehen, wie das funktioniert.

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

Hier ist ein Beispiel: Wenn ein Benutzer bereits eine PVC namens mysql besitzt, kann der Benutzer eine neue PVC namens mysqlclone erstellen, indem er die Annotation wie trident.netapp.io/cloneFromPVC: mysql verwendet. Mit dieser Annotation klont Trident das Volume, das der mysql PVC entspricht, anstatt ein Volume von Grund auf bereitzustellen.

Beachten Sie folgende Punkte:

Das sample-input Verzeichnis enthält Beispiele für PVC-Definitionen zur Verwendung mit Trident. Siehe für eine vollständige Beschreibung der Parameter und Einstellungen, die mit Trident-Volumes verbunden sind.

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

Wenn Sie eine PVC erstellen, die auf ein Trident-basiertes StorageClass verweist, stellt Trident ein neues Volume mit der entsprechenden Speicherklasse bereit 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 in PersistentVolumeClaims spezifiziert, um Speicher mit einer Reihe von Eigenschaften bereitzustellen. Die Speicherklasse selbst identifiziert den zu verwendenden Provisionierer und definiert diese 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-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 können in Attribute zur Auswahl von Speicherpools und Kubernetes-Attribute eingeteilt werden.

Kubernetes VolumeSnapshotClass Objekte sind analog zu StorageClasses. Sie helfen dabei, mehrere Speicherklassen zu definieren und werden von Volume-Snapshots referenziert, um den Snapshot mit der erforderlichen Snapshot-Klasse zu verknüpfen. Jeder Volume-Snapshot ist mit einer einzigen Volume-Snapshot-Klasse verknüpft.

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

Das driver gibt Kubernetes an, dass Anfragen für Volume-Snapshots der csi-snapclass Klasse von Trident verarbeitet werden. Das deletionPolicy gibt die Aktion an, die ausgeführt werden soll, wenn ein Snapshot gelöscht werden muss. Wenn deletionPolicy auf Delete gesetzt ist, werden sowohl die Volume-Snapshot-Objekte als auch der zugrunde liegende Snapshot auf dem Storage-Cluster entfernt, wenn ein Snapshot gelöscht wird. Alternativ bedeutet das Setzen auf Retain, dass VolumeSnapshotContent und der physische Snapshot erhalten bleiben.

Ein Kubernetes VolumeSnapshot Objekt ist eine Anfrage zum Erstellen eines Snapshots eines Volumes. Genau wie ein PVC eine Anfrage eines Benutzers für ein Volume darstellt, ist ein Volume Snapshot eine Anfrage eines Benutzers zum Erstellen eines Snapshots eines bestehenden PVC.

Wenn eine Volume-Snapshot-Anfrage eingeht, verwaltet Trident automatisch die Erstellung des Snapshots für das Volume im Backend und stellt den Snapshot durch die Erstellung eines eindeutigen
VolumeSnapshotContent Objekts bereit. Sie können Snapshots von bestehenden PVCs erstellen und die Snapshots als DataSource beim Erstellen neuer PVCs verwenden.

Ein Kubernetes VolumeSnapshotContent-Objekt stellt einen Snapshot eines bereits bereitgestellten Volumes dar. Es ist analog zu einem PersistentVolume und kennzeichnet einen bereitgestellten Snapshot im Speicher-Cluster. Ähnlich wie PersistentVolumeClaim und PersistentVolume Objekten, wenn ein Snapshot erstellt wird, behält das VolumeSnapshotContent Objekt eine Eins-zu-eins-Zuordnung zum VolumeSnapshot Objekt bei, das die Snapshot-Erstellung angefordert hat.

Das VolumeSnapshotContent Objekt enthält Details, die den Snapshot eindeutig identifizieren, wie zum Beispiel das 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 im Backend. Nachdem der Snapshot erstellt wurde, konfiguriert Trident ein VolumeSnapshotContent Objekt und stellt den Snapshot somit der Kubernetes-API zur Verfügung.

Kubernetes VolumeGroupSnapshotClass-Objekte sind analog zu VolumeSnapshotClass. Sie helfen dabei, mehrere Speicherklassen zu definieren und werden von Volume-Gruppen-Snapshots referenziert, um den Snapshot mit der erforderlichen Snapshot-Klasse zu verknüpfen. Jeder Volume-Gruppen-Snapshot ist mit genau einer Volume-Gruppen-Snapshot-Klasse verknüpft.

A VolumeGroupSnapshotClass sollte von einem Administrator definiert werden, um eine Gruppe von Snapshots zu erstellen. Eine Volume Group Snapshot Class wird mit der folgenden Definition erstellt:

Die driver gibt in Kubernetes an, dass Anfragen für Volume-Gruppen-Snapshots der csi-group-snap-class Klasse von Trident verarbeitet werden. Die deletionPolicy gibt die Aktion an, die ausgeführt werden soll, wenn ein Gruppen-Snapshot gelöscht werden muss. Wenn deletionPolicy auf Delete gesetzt ist, werden sowohl die Volume-Gruppen-Snapshot-Objekte als auch der zugrunde liegende Snapshot auf dem Storage-Cluster entfernt, wenn ein Snapshot gelöscht wird. Alternativ bedeutet das Setzen auf Retain, dass VolumeGroupSnapshotContent und der physische Snapshot erhalten bleiben.

Ein Kubernetes VolumeGroupSnapshot-Objekt ist eine Anfrage zum Erstellen eines Snapshots mehrerer Volumes. Genau wie ein PVC eine Anfrage eines Benutzers für ein Volume darstellt, ist ein Volume-Gruppen-Snapshot eine Anfrage eines Benutzers zum Erstellen eines Snapshots eines bestehenden PVC.

Wenn eine Volume-Gruppen-Snapshot-Anfrage eingeht, verwaltet Trident automatisch die Erstellung des Gruppen-Snapshots für die Volumes im Backend und stellt den Snapshot durch die Erstellung eines eindeutigen VolumeGroupSnapshotContent Objekts bereit. Sie können Snapshots von bestehenden PVCs erstellen und die Snapshots als DataSource beim Erstellen neuer PVCs verwenden.

Ein Kubernetes VolumeGroupSnapshotContent-Objekt repräsentiert einen Gruppen-Snapshot, der von einem bereits bereitgestellten Volume erstellt wurde. Es ist analog zu einem PersistentVolume und kennzeichnet einen bereitgestellten Snapshot im Speichercluster. Ähnlich wie PersistentVolumeClaim und PersistentVolume Objekten, wenn ein Snapshot erstellt wird, verwaltet das VolumeSnapshotContent Objekt eine Eins-zu-Eins-Zuordnung zu dem VolumeSnapshot Objekt, das die Snapshot-Erstellung angefordert hat.

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

Wenn eine Snapshot-Anfrage eingeht, erstellt Trident den Volume-Group-Snapshot im Backend. Nachdem der Volume-Group-Snapshot erstellt wurde, konfiguriert Trident ein VolumeGroupSnapshotContent Objekt und stellt den Snapshot somit der Kubernetes-API zur Verfügung.

Kubernetes Custom Resources sind Endpunkte in der Kubernetes-API, die vom Administrator definiert werden und zur Gruppierung ähnlicher Objekte verwendet werden. Kubernetes unterstützt die Erstellung von Custom Resources zum Speichern einer Sammlung von Objekten. Sie können diese Ressourcendefinitionen abrufen, indem Sie kubectl get crds ausführen.

Benutzerdefinierte Ressourcendefinitionen (CRDs) und die zugehörigen Objektmetadaten werden von Kubernetes in seinem Metadatenspeicher abgelegt. Dadurch entfällt die Notwendigkeit eines separaten Speichers für Trident.

Trident verwendet CustomResourceDefinition Objekte, um die Identität von Trident-Objekten wie Trident Backends, Trident Storage Classes 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. Als einfaches Beispiel: Wenn ein Backend mit tridentctl erstellt wird, wird ein entsprechendes tridentbackends CRD-Objekt zur Verwendung durch Kubernetes erzeugt.

Hier sind einige Punkte, die Sie bei den CRDs von Trident beachten sollten:

Trident erstellt passende Speicherklassen für Kubernetes StorageClass-Objekte, die csi.trident.netapp.io in ihrem Provisioner-Feld angegeben sind. Der Name der Speicherklasse entspricht dem Namen des Kubernetes StorageClass-Objekts, das sie repräsentiert.

Speicherklassen umfassen eine Reihe von Anforderungen für Volumes. Trident gleicht diese Anforderungen mit den Attributen ab, die in jedem Speicherpool vorhanden sind; 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 erwarten wir jedoch, dass sie bei der Registrierung neuer Kubernetes StorageClass Objekte erstellt werden.

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

Weitere Informationen darüber, wie Sie diese Objekte erstellen, finden Sie unter "Backends konfigurieren".

Speicherpools repräsentieren die verschiedenen, für die Bereitstellung auf jedem Backend verfügbaren Speicherorte. Für ONTAP entsprechen diese Aggregaten in SVMs. Für NetApp HCI/SolidFire entsprechen sie den vom Administrator festgelegten QoS-Bändern. Jeder Speicherpool verfügt über eine Reihe spezifischer Speicherattribute, die seine Leistungs- und Datenschutzmerkmale definieren.

Im Gegensatz zu den anderen Objekten hier werden Speicherpool-Kandidaten 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 eine Speicherklasse hat, die bestimmt, wo dieses Volume bereitgestellt werden kann, sowie eine Größe.

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

Trident generiert internalName beim Erstellen des Volumes einen Namen. Dies besteht aus zwei Schritten. Zuerst wird dem Volume-Namen das Speicherpräfix vorangestellt (entweder das Standard trident oder das in der Backend-Konfiguration festgelegte Präfix), sodass ein Name der Form <prefix>-<volume-name> entsteht. Anschließend wird der Name bereinigt, indem Zeichen ersetzt werden, die im Backend nicht zulässig sind. Für ONTAP-Backends werden Bindestriche durch Unterstriche ersetzt (dadurch wird der interne Name zu <prefix>_<volume-name>). Für 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 Standardmethode von Kubernetes PersistentVolumeClaim verwenden. Trident erstellt dieses Volume-Objekt automatisch im Rahmen des Bereitstellungsprozesses.

Snapshots sind eine zeitpunktgenaue Kopie von Volumes, die zur Bereitstellung neuer Volumes oder zur Wiederherstellung des Zustands verwendet werden können. 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 umfasst die unten aufgeführten Eigenschaften:

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

Der Trident Daemonset verwendet eine system-node-critical Priority Class – die höchste in Kubernetes verfügbare Priority Class –, um sicherzustellen, dass Trident Volumes während des ordnungsgemäßen Herunterfahrens von Knoten identifizieren und bereinigen kann und damit Trident Daemonset Pods Workloads mit niedrigerer Priorität in Clustern mit hohem Ressourcendruck verdrängen können.

Um dies zu erreichen, verwendet Trident ein ResourceQuota Objekt, um sicherzustellen, dass die „system-node-critical“ Priority Class beim Trident-Daemonset erfüllt ist. Vor der Bereitstellung und der Erstellung des Daemonsets sucht Trident nach dem ResourceQuota Objekt und wendet es an, falls es nicht gefunden wird.

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

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

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