瞭解物件、物件的適用範圍及其互動方式、最簡單的方法可能是遵循Kubernetes使用者的單一儲存要求：

Kubernetes PersistentVolumeClaim 物件是Kubernetes叢集使用者所提出的儲存要求。

除了標準規格之外、Trident還可讓使用者指定下列Volume專屬附註、以覆寫您在後端組態中設定的預設值：

如果建立的PV具有 Delete 回收原則：Trident會在PV發行時（亦即使用者刪除PVc時）同時刪除PV和備用Volume。如果刪除動作失敗、Trident會將PV標示為這樣、並定期重試該作業、直到成功或手動刪除PV為止。如果PV使用 Retain 原則、Trident會忽略它、並假設系統管理員會從Kubernetes和後端進行清理、以便在移除磁碟區之前、先備份或檢查該磁碟區。請注意、刪除PV並不會導致Trident刪除背板Volume。您應該使用REST API將其移除 (tridentctl）。

Trident支援使用csi規格建立Volume Snapshot：您可以建立Volume Snapshot、並將其作為資料來源來複製現有的PVCS。如此一來、PV的時間點複本就能以快照形式呈現給Kubernetes。快照可用來建立新的PV。請看一下 On-Demand Volume Snapshots 以瞭解這項功能的運作方式。

Trident也提供 cloneFromPVC 和 splitOnClone 建立複本的附註。您可以使用這些附註來複製一個PVC,而不需要使用csi實作（在Kubernetes 1.13及更早版本上）或Kubernetes版本不支援beta Volume Snapshot（Kubernetes 1.16及更早版本）。請記住、Trident 19.10支援從PVc複製的csi工作流程。

以下是一個範例：如果使用者已經有一個名為的PVc mysql、使用者可以建立名為的新永久虛擬環境 mysqlclone 使用註釋、例如 trident.netapp.io/cloneFromPVC: mysql。使用此註釋集、Trident會複製對應於mySQL PVc的磁碟區、而非從頭開始配置磁碟區。

請考量以下幾點：

。 sample-input 目錄包含用於Trident的PVc定義範例。請參閱Trident Volume物件、以取得與Trident Volume相關的參數和設定完整說明。

Kubernetes PersistentVolume 物件代表Kubernetes叢集可用的一部分儲存設備。它的生命週期與使用它的Pod無關。

當您建立參照Trident型的PVc時 StorageClass、Trident會使用對應的儲存類別來配置新的Volume、並針對該Volume登錄新的PV。在設定已配置的Volume和對應的PV時、Trident遵循下列規則：

Kubernetes StorageClass 物件是以中的名稱來指定 PersistentVolumeClaims 以一組內容來配置儲存設備。儲存類別本身會識別要使用的資源配置程式、並根據資源配置程式所瞭解的方式來定義該組內容。

這是需要由系統管理員建立及管理的兩個基本物件之一。另一個是Trident後端物件。

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

這些參數是Trident專屬的、可告訴Trident如何為類別配置Volume。

儲存類別參數包括：

儲存屬性及其可能值可分類為儲存資源池選擇屬性和Kubernetes屬性。

Kubernetes VolumeSnapshotClass 物件類似 StorageClasses。它們有助於定義多種儲存類別、並由Volume Snapshot參考、以將快照與所需的Snapshot類別建立關聯。每個Volume Snapshot都與單一Volume Snapshot類別相關聯。

答 VolumeSnapshotClass 應由系統管理員定義以建立快照。建立具有下列定義的Volume Snapshot類別：

。 driver 指定要要求的Kubernetes磁碟區快照 csi-snapclass 類別由Trident處理。。 deletionPolicy 指定必須刪除快照時要採取的動作。何時 deletionPolicy 設為 Delete、刪除快照時、會移除儲存叢集上的Volume Snapshot物件及基礎快照。或者、將其設定為 Retain 也就是說 VolumeSnapshotContent 並保留實體快照。

Kubernetes VolumeSnapshot 物件是建立磁碟區快照的要求。就像使用者針對磁碟區所提出的要求一樣、磁碟區快照是使用者建立現有虛擬磁碟快照的要求。

當磁碟區快照要求出現時、Trident會在後端自動管理磁碟區的快照建立、並建立唯一的快照來公開快照
VolumeSnapshotContent 物件：您可以從現有的PVCS建立快照、並在建立新的PVCS時、將快照作為DataSource使用。

Kubernetes VolumeSnapshotContent 物件代表從已配置的磁碟區擷取的快照。類似於 PersistentVolume 並表示儲存叢集上已配置的快照。類似 PersistentVolumeClaim 和 PersistentVolume 建立快照時的物件 VolumeSnapshotContent 物件會將一對一的對應維持在上 VolumeSnapshot 物件、要求建立快照。

。 VolumeSnapshotContent 物件包含可唯一識別快照的詳細資料、例如 snapshotHandle。這 snapshotHandle 是PV名稱與名稱的獨特組合 VolumeSnapshotContent 物件：

當快照要求出現時、Trident會在後端建立快照。建立快照之後、Trident會設定 VolumeSnapshotContent 然後將快照公開給Kubernetes API。

Kubernetes自訂資源是Kubernetes API中由系統管理員定義的端點、用於將類似物件分組。Kubernetes支援建立自訂資源來儲存物件集合。您可以執行來取得這些資源定義 kubectl get crds。

自訂資源定義（CRD）及其相關的物件中繼資料會由Kubernetes儲存在其中繼資料儲存區中。如此一來、您就不需要另外建立Trident的儲存區。

從19.07版開始、Trident使用了許多 CustomResourceDefinition 保留Trident物件身分的物件、例如Trident後端、Trident儲存類別和Trident Volume。這些物件由Trident管理。此外、「csi Volume Snapshot」架構也引進了定義Volume快照所需的部分CRD。

CRD是Kubernetes建構。上述資源的物件是由Trident所建立。例如、使用建立後端時 tridentctl、對應的 tridentbackends CRD物件是由Kubernetes所建立、供其使用。

以下是Trident客戶需求日的幾點重點：

Trident為Kubernetes建立相符的儲存類別 StorageClass 指定的物件 csi.trident.netapp.io/netapp.io/trident 在他們的資源配置工具欄位中。儲存類別名稱與Kubernetes名稱相符 StorageClass 所代表的物件。

儲存類別包含一組磁碟區需求。Trident會將這些需求與每個儲存資源池中的屬性相符；如果符合、則該儲存資源池是使用該儲存類別來配置磁碟區的有效目標。

您可以使用REST API建立儲存類別組態、以直接定義儲存類別。不過、在Kubernetes部署中、我們預期在登錄新Kubernetes時會建立這些部署 StorageClass 物件：

後端代表儲存供應商、其中Trident會配置磁碟區；單一Trident執行個體可管理任何數量的後端。

如需如何建構這些物件的詳細資訊、請參閱 "設定後端"。

儲存資源池代表可在每個後端上進行資源配置的不同位置。就支援而言ONTAP 、這些項目對應於SVM中的集合體。對於NetApp HCI / SolidFire、這些服務會對應到系統管理員指定的QoS頻段。就架構而言、這些項目對應於雲端供應商所在的地區。Cloud Volumes Service每個儲存資源池都有一組獨特的儲存屬性、可定義其效能特性和資料保護特性。

與此處的其他物件不同、儲存資源池候選項目一律會自動探索及管理。

Volume是資源配置的基本單位、包含NFS共用和iSCSI LUN等後端端點。在Kubernetes中、這些項目會直接對應至 PersistentVolumes。建立磁碟區時、請確定它有一個儲存類別、決定該磁碟區可以配置的位置及大小。

Volume組態會定義已配置磁碟區應具備的內容。

Trident會產生 internalName 建立Volume時。這包括兩個步驟。首先、它會預先加上儲存前置詞（預設值之一 trident 或是後端組態中的前置字元）到磁碟區名稱、產生表單名稱 <prefix>-<volume-name>。然後、它會繼續清理名稱、取代後端不允許的字元。對於後端、它會以底線取代連字號（因此內部名稱會變成ONTAP <prefix>_<volume-name>）。對於元素後端、它會以連字號取代底線。

您可以使用Volume組態、使用REST API直接配置磁碟區、但在Kubernetes部署中、我們預期大多數使用者都會使用標準Kubernetes PersistentVolumeClaim 方法。Trident會自動建立此Volume物件、做為資源配置程序的一部分。

快照是磁碟區的時間點複本、可用來配置新的磁碟區或還原狀態。在Kubernetes中、這些項目會直接對應至 VolumeSnapshotContent 物件：每個快照都與一個Volume相關聯、該磁碟區是快照資料的來源。

每個 Snapshot 物件包含下列內容：

當Kubernetes時 VolumeSnapshot 物件要求已建立、Trident可在備份儲存系統上建立Snapshot物件。。 internalName 此快照物件的產生方式為結合前置詞 snapshot- 使用 UID 的 VolumeSnapshot 物件（例如、 snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660）。 volumeName 和 volumeInternalName 會透過取得備用磁碟區的詳細資料來填入。

Trident去除會耗用a system-node-critical 優先級類別是Kubernetes中最高的優先級類別、可確保Astra Trident在正常節點關機期間識別並清理磁碟區、並允許Trident的取消安裝Pod在資源壓力較高的叢集中預先配置優先級較低的工作負載。

為了達成此目標、Astra Trident採用 ResourceQuota 確保在Trident取消程式集上達到「系統節點關鍵」優先順序類別的物件。在部署和建立實體化設定之前、Astra Trident會先尋找 ResourceQuota 物件、如果未探索到、則套用它。

如果您需要更多控制預設資源配額和優先順序類別、可以產生 custom.yaml 或設定 ResourceQuota 使用Helm圖表的物件。

以下是「資源配額」物件優先處理Trident的範例。

如需資源配額的詳細資訊、請參閱 "Kubernetes：資源配額"。