要了解這些物件、它們的用途以及它們如何交互，最簡單的方法或許是追蹤 Kubernetes 用戶發出的單一儲存請求：

Kubernetes PersistentVolumeClaim object 是 Kubernetes 叢集使用者發出的儲存請求。

除了標準規格之外， Trident還允許使用者指定以下磁碟區特定的註釋，以便覆寫您在後端設定中設定的預設值：

如果創建的PV具有 Delete`根據回收策略，當 PV 被釋放時（即用戶刪除 PVC 時）， Trident會同時刪除 PV 和支援卷。如果刪除操作失敗， Trident會將 PV 標記為失敗，並定期重試該操作，直到操作成功或手動刪除 PV 為止。如果光伏發電使用 `Retain`策略方面， Trident會忽略它，並假定管理員會從 Kubernetes 和後端清理它，從而允許在刪除磁碟區之前對其進行備份或檢查。請注意，刪除 PV 不會導致Trident刪除備份磁碟區。您應該使用 REST API 將其刪除。(`tridentctl ）。

Trident支援使用 CSI 規範建立磁碟區快照：您可以建立磁碟區快照並將其用作資料來源來複製現有的 PVC。這樣，就可以將 PV 的特定時間點副本以快照的形式暴露給 Kubernetes。然後可以使用這些快照建立新的PV。看看 `On-Demand Volume Snapshots`看看這種方法是否可行。

Trident也提供 `cloneFromPVC`和 `splitOnClone`用於建立克隆的註釋。您可以使用這些註解來克隆 PVC，而無需使用 CSI 實作。

例如：如果使用者已經有一個名為 PVC 的 mysql`用戶可以建立一個名為「新PVC」的 `mysqlclone`透過使用註釋，例如 `trident.netapp.io/cloneFromPVC: mysql。有了這組註釋， Trident會克隆與 mysql PVC 對應的捲，而不是從頭開始配置卷。

請考慮以下幾點：

這 `sample-input`目錄包含可用於Trident的 PVC 定義範例。請參閱有關Trident音量相關參數和設定的完整說明。

Kubernetes `PersistentVolume`此物件代表一塊可供 Kubernetes 叢集使用的儲存空間。它的生命週期與使用它的艙等無關。

當您建立 PVC 時，指的是基於 Trident 的 `StorageClass`Trident使用對應的儲存類別來設定一個新磁碟區，並為該磁碟區註冊一個新的 PV。在配置已設定磁碟區和對應的 PV 時， Trident遵循以下規則：

Kubernetes `StorageClass`物件透過名稱指定。 `PersistentVolumeClaims`為儲存配置一組屬性。儲存類別本身標識要使用的配置器，並以配置器能夠理解的方式定義該群組屬性。

它是管理員需要建立和管理的兩個基本物件之一。另一個是Trident後端物件。

Kubernetes `StorageClass`使用Trident的物件看起來像這樣：

這些參數是 Trident 特有的，用於告訴Trident如何為該類別配置磁碟區。

儲存類別參數如下：

儲存屬性及其可能的值可以分為儲存池選擇屬性和 Kubernetes 屬性。

Kubernetes VolumeSnapshotClass`物體類似於 `StorageClasses。它們有助於定義多種儲存類別，並被磁碟區快照引用，以將快照與所需的快照類別關聯起來。每個磁碟區快照都與一個磁碟區快照類別相關聯。

一個 `VolumeSnapshotClass`應由管理員定義以建立快照。建立卷宗快照類別時，定義如下：

這 `driver`向 Kubernetes 指定請求卷快照的 `csi-snapclass`類別由Trident處理。這 `deletionPolicy`指定必須刪除快照時要執行的操作。什麼時候 `deletionPolicy`設定為 `Delete`當刪除快照時，儲存叢集上的磁碟區快照物件以及底層快照也會被刪除。或者，將其設為 `Retain`意味著 `VolumeSnapshotContent`並保留實體快照。

Kubernetes VolumeSnapshot object 是建立磁碟區快照的請求。 PVC 代表使用者對磁碟區的請求，磁碟區快照則是使用者對現有 PVC 建立快照的請求。

當收到磁碟區快照請求時， Trident會自動在後端建立磁碟區快照，並透過建立唯一識別碼來公開該快照。
`VolumeSnapshotContent`目的。您可以從現有的​​ PVC 建立快照，並在建立新的 PVC 時將這些快照用作資料來源。

Kubernetes `VolumeSnapshotContent`該物件表示從已配置的磁碟區中取得的快照。它類似於 `PersistentVolume`表示儲存叢集上已配置的快照。類似 `PersistentVolumeClaim`和 `PersistentVolume`當創建快照時，物件會… `VolumeSnapshotContent`物件與…保持一對一的映射關係 `VolumeSnapshot`該物件請求建立快照。

這 VolumeSnapshotContent`物件包含唯一標識快照的詳細信息，例如： `snapshotHandle 。這 `snapshotHandle`是PV名稱和名稱的獨特組合 `VolumeSnapshotContent`目的。

當收到快照請求時， Trident會在後端建立快照。快照建立完成後， Trident會配置一個 `VolumeSnapshotContent`對象，從而將快照暴露給 Kubernetes API。

Kubernetes VolumeGroupSnapshotClass`物體類似於 `VolumeSnapshotClass。它們有助於定義多種儲存類別，並被磁碟區組快照引用，以將快照與所需的快照類別關聯起來。每個磁碟區組快照都與一個磁碟區組快照類別相關聯。

一個 `VolumeGroupSnapshotClass`應由管理員定義以建立快照群組。使用下列定義建立磁碟區組快照類別：

這 `driver`向 Kubernetes 指定請求卷宗組快照的權限。 `csi-group-snap-class`類別由Trident處理。這 `deletionPolicy`指定必須刪除群組快照時要執行的操作。什麼時候 `deletionPolicy`設定為 `Delete`當刪除快照時，磁碟區組快照物件以及儲存叢集上的基礎快照也會被刪除。或者，將其設為 `Retain`意味著 `VolumeGroupSnapshotContent`並保留物理快照。

Kubernetes `VolumeGroupSnapshot`該物件是建立多個磁碟區的快照的請求。就像 PVC 代表使用者對磁碟區的請求一樣，磁碟區組快照是使用者對現有 PVC 建立快照的請求。

當收到磁碟區組快照請求時， Trident會自動在後端管理磁碟區的群組快照創建，並透過建立唯一識別碼來公開該快照。 `VolumeGroupSnapshotContent`目的。您可以從現有的​​ PVC 建立快照，並在建立新的 PVC 時將這些快照用作資料來源。

Kubernetes `VolumeGroupSnapshotContent`該物件表示從已配置的磁碟區中取得的群組快照。它類似於 `PersistentVolume`表示儲存叢集上已配置的快照。類似 `PersistentVolumeClaim`和 `PersistentVolume`當創建快照時，物件會… `VolumeSnapshotContent`物件與…保持一對一的映射關係 `VolumeSnapshot`該物件請求建立快照。

這 `VolumeGroupSnapshotContent`物件包含用於標識快照組的詳細信息，例如： `volumeGroupSnapshotHandle`以及儲存系統上存在的各個 volumeSnapshotHandles。

當收到快照請求時， Trident會在後端建立磁碟區組快照。卷冊組快照建立完成後， Trident會進行設定。 `VolumeGroupSnapshotContent`對象，從而將快照暴露給 Kubernetes API。

Kubernetes 自訂資源是 Kubernetes API 中的端點，由管理員定義，用於對類似物件進行分組。 Kubernetes 支援建立自訂資源來儲存物件集合。您可以透過執行以下命令來取得這些資源定義。 kubectl get crds 。

Kubernetes 將自訂資源定義 (CRD) 及其關聯的物件元資料儲存在其元資料儲存中。這樣就無需為Trident單獨開設商店了。

Trident的使用 `CustomResourceDefinition`用於保存Trident物件識別的對象，例如Trident後端、 Trident儲存類別和Trident磁碟區。這些物件由Trident管理。此外，CSI 卷快照框架引入了一些定義卷快照所需的 CRD。

CRD 是 Kubernetes 的一種建構。上述資源的物件由Trident建立。舉個簡單的例子，當使用以下方式建立後端時 `tridentctl`相應的 `tridentbackends`建立 CRD 物件供 Kubernetes 使用。

關於Trident的CRD，需要記住以下幾點：

Trident為 Kubernetes 建立相符的儲存類 `StorageClass`指定對象 `csi.trident.netapp.io`在他們的供應領域。儲存類別名稱與 Kubernetes 的名稱相符。 `StorageClass`它所代表的對象。

儲存類別包含對磁碟區的一系列要求。 Trident會將這些要求與每個儲存池中存在的屬性進行匹配；如果匹配，則該儲存池是使用該儲存類別配置磁碟區的有效目標。

您可以使用 REST API 建立儲存類別配置，直接定義儲存類別。但是，對於 Kubernetes 部署，我們期望在註冊新的 Kubernetes 執行個體時建立它們。 `StorageClass`物體。

後端代表儲存提供者， Trident在其上配置磁碟區；單一Trident實例可以管理任意數量的後端。

有關如何建構這些物件的更多信息，請參閱："配置後端" 。

儲存池代表每個後端可用於配置的不同位置。對於ONTAP而言，這些對應於 SVM 中的聚合。對於NetApp HCI/ SolidFire，這些對應於管理員指定的 QoS 頻段。對於Cloud Volumes Service，這些對應於雲端提供者區域。每個儲存池都有一組獨特的儲存屬性，這些屬性定義了其效能特徵和資料保護特徵。

與此處的其他物件不同，儲存池候選對象始終會自動發現和管理。

磁碟區是配置的基本單元，包括後端端點（例如 NFS 共用）以及 iSCSI 和 FC LUN。在 Kubernetes 中，這些直接對應於 PersistentVolumes。建立磁碟區時，請確保它具有儲存類別（決定磁碟區的部署位置）和大小。

卷配置定義了已配置磁碟區應具有的屬性。

Trident生成 internalName`建立卷時。這包括兩個步驟。首先，它會添加儲存前綴（預設值）。 `trident`或後端配置中的前綴）加到磁碟區名稱，從而得到如下形式的名稱 `<prefix>-<volume-name>。然後它會對名稱進行清理，替換後端不允許的字元。對於ONTAP後端，它會將連字號替換為底線（因此，內部名稱變為 <prefix>_<volume-name>）。對於 Element 後端，它會將下劃線替換為連字符。

您可以使用磁碟區配置透過 REST API 直接設定卷，但在 Kubernetes 部署中，我們預計大多數使用者將使用標準的 Kubernetes 管理配置。 `PersistentVolumeClaim`方法。 Trident會在設定過程中自動建立此磁碟區物件。

快照是磁碟區在特定時間點的副本，可用於設定新磁碟區或復原狀態。在 Kubernetes 中，這些直接對應於 `VolumeSnapshotContent`物體。每個快照都與一個磁碟區相關聯，該磁碟區是快照資料的來源。

每個 `Snapshot`物件包含以下屬性：

當 Kubernetes VolumeSnapshot`建立物件請求後， Trident 的工作原理是在後端儲存系統上建立快照物件。這 `internalName`此快照物件是透過組合前綴產生的。 `snapshot-`和 `UID`的 `VolumeSnapshot`物件（例如， `snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660 ）。 `volumeName`和 `volumeInternalName`透過取得支援卷的詳細資訊來填入。

Trident守護程式消耗一個 `system-node-critical`優先等級——Kubernetes 中可用的最高優先等級——以確保Trident能夠在節點優雅關閉期間識別和清理卷，並允許Trident daemonset pod 在資源壓力高的叢集中搶佔優先順序較低的工作負載。

為了實現這一目標， Trident採用了一種 `ResourceQuota`確保Trident守護程式集上的「system-node-critical」優先權類別已滿足。在部署和建立守護程序集之前， Trident會查找 `ResourceQuota`對象，如果未發現，則應用它。

如果您需要對預設資源配額和優先類別進行更多控制，您可以產生一個 `custom.yaml`或配置 `ResourceQuota`使用 Helm Chart 的物件。

以下是一個 ResourceQuota 物件優先考慮Trident守護程式集的範例。

有關資源配額的更多信息，請參閱"Kubernetes：資源配額"。