おそらく、オブジェクト、その目的、操作方法を理解する最も簡単な方法は、 Kubernetes ユーザからのストレージ要求を 1 回だけ処理することです。

Kubernetesを PersistentVolumeClaim オブジェクトは、Kubernetesクラスタユーザが作成するストレージの要求です。

Trident では、標準仕様に加えて、バックエンド構成で設定したデフォルト設定を上書きする場合に、ボリューム固有の次のアノテーションを指定できます。

作成されたPVにがある場合 Delete ポリシーを再利用すると、PVが解放されたとき（つまり、ユーザがPVCを削除したとき）に、TridentはPVと元のボリュームの両方を削除します。削除操作が失敗した場合、 Trident は PV をマークします。そのような状態で操作が成功するか、 PV が手動で削除されるまで、定期的に再試行します。PVがを使用している場合 Retain Tridentはポリシーを無視し、管理者がKubernetesとバックエンドからクリーンアップすることを前提としているため、ボリュームを削除する前にバックアップや検査を実行できます。PV を削除しても、原因 Trident で元のボリュームが削除されないことに注意してください。REST APIを使用して削除する必要があります (tridentctl）。

Trident では CSI 仕様を使用したボリュームスナップショットの作成がサポートされています。ボリュームスナップショットを作成し、それをデータソースとして使用して既存の PVC のクローンを作成できます。これにより、 PVS のポイントインタイムコピーを Kubernetes にスナップショットの形で公開できます。作成した Snapshot を使用して新しい PVS を作成できます。を参照してください On-Demand Volume Snapshots これがどのように機能するかを確認します。

Tridentが提供するのも cloneFromPVC および splitOnClone クローンを作成するためのアノテーションこれらの注釈を使用して、CSI実装を使用せずにPVCのクローンを作成できます。

次に例を示します。ユーザがすでにというPVCを持っている場合 mysql`を使用すると、ユーザはという新しいPVCを作成できます `mysqlclone などのアノテーションを使用する trident.netapp.io/cloneFromPVC: mysql。このアノテーションセットを使用すると、 Trident はボリュームをゼロからプロビジョニングするのではなく、 MySQL PVC に対応するボリュームのクローンを作成します。

次の点を考慮してください。

。 sample-input Directoryには、Tridentで使用するPVC定義の例が含まれています。を参照してください をクリックして、Tridentボリュームに関連付けられているパラメータと設定の完全な概要を確認します。

Kubernetesを PersistentVolume オブジェクトは、Kubernetesクラスタで使用可能になるストレージを表します。ポッドに依存しないライフサイクルがあります。

Tridentベースを参照するPVCを作成する場合 `StorageClass`Tridentは、対応するストレージクラスを使用して新しいボリュームをプロビジョニングし、そのボリュームに新しいPVを登録します。プロビジョニングされたボリュームと対応する PV の構成では、 Trident は次のルールに従います。

Kubernetes StorageClass オブジェクトは、の名前で指定します PersistentVolumeClaims 一連のプロパティを指定してストレージをプロビジョニングします。ストレージクラス自体が、使用するプロビジョニングツールを特定し、プロビジョニングツールが理解できる一連のプロパティを定義します。

管理者が作成および管理する必要がある 2 つの基本オブジェクトのうちの 1 つです。もう 1 つは Trident バックエンドオブジェクトです。

Kubernetesを StorageClass Tridentを使用するオブジェクトは次のようになります。

これらのパラメータは Trident 固有で、クラスのボリュームのプロビジョニング方法を Trident に指示します。

ストレージクラスのパラメータは次のとおりです。

ストレージ属性とその有効な値は、ストレージプールの選択属性と Kubernetes 属性に分類できます。

Kubernetes VolumeSnapshotClass オブジェクトはに似ています StorageClasses。この Snapshot コピーは、複数のストレージクラスの定義に役立ちます。また、ボリューム Snapshot によって参照され、 Snapshot を必要な Snapshot クラスに関連付けます。各ボリューム Snapshot は、単一のボリューム Snapshot クラスに関連付けられます。

A VolumeSnapshotClass Snapshotを作成するには、管理者によって定義されている必要があります。ボリューム Snapshot クラスは、次の定義で作成されます。

。 driver のボリュームSnapshotを要求するKubernetesに指定します csi-snapclass クラスはTridentによって処理されます。。 deletionPolicy Snapshotを削除する必要がある場合に実行する処理を指定します。いつ deletionPolicy がに設定されます Delete`を指定すると、Snapshotが削除されたときに、ボリュームSnapshotオブジェクトおよびストレージクラスタ上の基盤となるSnapshotが削除されます。または、に設定します `Retain はそのことを示します VolumeSnapshotContent 物理スナップショットが保持されます。

Kubernetesを VolumeSnapshot objectは、ボリュームのSnapshotを作成する要求です。PVC がボリュームに対するユーザからの要求を表すのと同様に、ボリュームスナップショットは、ユーザが既存の PVC のスナップショットを作成する要求です。

ボリュームSnapshot要求が開始されると、TridentはバックエンドでのボリュームのSnapshotの作成を自動的に管理し、一意のを作成してSnapshotを公開します
VolumeSnapshotContent オブジェクト。既存の PVC からスナップショットを作成し、新しい PVC を作成するときにスナップショットを DataSource として使用できます。

Kubernetesを VolumeSnapshotContent オブジェクトは、すでにプロビジョニングされているボリュームから作成されたSnapshotを表します。これはに似ています PersistentVolume とは、ストレージクラスタにプロビジョニングされたSnapshotを表します。に似ています PersistentVolumeClaim および PersistentVolume オブジェクト。スナップショットが作成されると、が表示されます VolumeSnapshotContent オブジェクトは、への1対1のマッピングを保持します VolumeSnapshot オブジェクト。オブジェクトはSnapshotの作成を要求しました。

。 VolumeSnapshotContent Objectには、など、Snapshotを一意に識別する詳細が含まれます snapshotHandle。これ snapshotHandle は、PVの名前との名前を一意に組み合わせたものです VolumeSnapshotContent オブジェクト。

Trident では、スナップショット要求を受信すると、バックエンドにスナップショットが作成されます。スナップショットが作成されると、Tridentによってが設定されます VolumeSnapshotContent オブジェクトを作成することで、SnapshotをKubernetes APIに公開します。

Kubernetes カスタムリソースは、管理者が定義した Kubernetes API 内のエンドポイントであり、類似するオブジェクトのグループ化に使用されます。Kubernetes では、オブジェクトのコレクションを格納するためのカスタムリソースの作成をサポートしています。を実行すると、これらのリソース定義を取得できます kubectl get crds。

カスタムリソース定義（ CRD ）と関連するオブジェクトメタデータは、 Kubernetes によってメタデータストアに格納されます。これにより、 Trident の独立したストアが不要になります。

Astra Tridentが使用 CustomResourceDefinition Tridentバックエンド、Tridentストレージクラス、Tridentボリュームなど、TridentオブジェクトのIDを保持するオブジェクト。これらのオブジェクトは Trident によって管理されます。また、 CSI のボリュームスナップショットフレームワークには、ボリュームスナップショットの定義に必要ないくつかの SSD が導入されています。

CRD は Kubernetes の構成要素です。上記で定義したリソースのオブジェクトは Trident によって作成されます。簡単な例として、を使用してバックエンドを作成する場合を示します tridentctl`に対応します `tridentbackends CRDオブジェクトは、Kubernetesによって消費されるために作成されます。

Trident の CRD については、次の点に注意してください。

TridentではKubernetesに対応するストレージクラスが作成されます StorageClass を指定するオブジェクト csi.trident.netapp.io プロビジョニング担当者のフィールドに入力します。ストレージクラス名がKubernetesの名前と一致していること StorageClass 表すオブジェクト。

ストレージクラスは、ボリュームの一連の要件で構成されます。Trident は、これらの要件と各ストレージプール内の属性を照合し、一致する場合は、そのストレージプールが、そのストレージクラスを使用するボリュームのプロビジョニングの有効なターゲットになります。

REST API を使用して、ストレージクラスを直接定義するストレージクラス設定を作成できます。ただし、Kubernetes環境では、新しいKubernetesを登録するときにKubernetes環境が作成されることを想定しています StorageClass オブジェクト。

バックエンドとは、 Trident がボリュームをプロビジョニングする際にストレージプロバイダを表します。 1 つの Trident インスタンスであらゆる数のバックエンドを管理できます。

これらのオブジェクトの作成方法の詳細については、を参照してください。 "バックエンドの設定"。

ストレージプールは、各バックエンドでのプロビジョニングに使用できる個別の場所を表します。ONTAP の場合、これらは SVM 内のアグリゲートに対応します。NetApp HCI / SolidFire では、管理者が指定した QoS 帯域に対応します。Cloud Volumes Service の場合、これらはクラウドプロバイダのリージョンに対応します。各ストレージプールには、パフォーマンス特性とデータ保護特性を定義するストレージ属性があります。

他のオブジェクトとは異なり、ストレージプールの候補は常に自動的に検出されて管理されます。

ボリュームは、 NFS 共有や iSCSI LUN などのバックエンドエンドエンドエンドポイントで構成される、プロビジョニングの基本単位です。Kubernetesでは、これらはに直接対応します PersistentVolumes。ボリュームを作成するときは、そのボリュームにストレージクラスが含まれていることを確認します。このクラスによって、ボリュームをプロビジョニングできる場所とサイズが決まります。

ボリューム構成は、プロビジョニングされたボリュームに必要なプロパティを定義します。

Tridentが生成 internalName ボリュームを作成する場合。この構成は 2 つのステップで構成されます。最初に、ストレージプレフィックス（デフォルトのプレフィックス）を先頭に追加します trident またはバックエンド構成内のプレフィックス）をボリューム名に変更して、形式の名前を指定します <prefix>-<volume-name>。その後、名前の完全消去が行われ、バックエンドで許可されていない文字が置き換えられます。ONTAP バックエンドの場合、ハイフンをアンダースコアに置き換えます（内部名はになります） <prefix>_<volume-name>）。Element バックエンドの場合、アンダースコアはハイフンに置き換えられます。

ボリューム構成を使用してREST APIを使用してボリュームを直接プロビジョニングできますが、Kubernetes環境ではほとんどのユーザが標準のKubernetesを使用することを想定しています PersistentVolumeClaim メソッドプロビジョニングの一環としてTridentがこのボリュームオブジェクトを自動的に作成
プロセス：

Snapshot はボリュームのポイントインタイムコピーで、新しいボリュームのプロビジョニングやリストア状態に使用できます。Kubernetesでは、これらはに直接対応します VolumeSnapshotContent オブジェクト。各 Snapshot には、 Snapshot のデータのソースであるボリュームが関連付けられます。

各 Snapshot オブジェクトには、次のプロパティが含まれます。

Kubernetesを導入したとき VolumeSnapshot オブジェクト要求が作成されると、TridentはバッキングストレージシステムにSnapshotオブジェクトを作成することで機能します。。 internalName このSnapshotオブジェクトのプレフィックスを組み合わせると、が生成されます snapshot- を使用 UID の VolumeSnapshot オブジェクト（例： snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660）。 volumeName および volumeInternalName 裏付けの詳細を取得することで入力されます。
ボリューム：

Tridentのデーモンは、を消費します system-node-critical 優先度クラス：Kubernetesで最も高い優先度クラスです。Astra Tridentは、ノードの正常なシャットダウン中にボリュームを識別してクリーンアップし、Tridentのデミスタポッドがリソースの負荷が高いクラスタでより低い優先度でワークロードをプリエンプトできるようにします。

そのために、Astra Tridentはを採用しています ResourceQuota Tridentのデミスタに対する「システムノードクリティカル」の優先クラスを満たすことを保証するオブジェクト。導入とデマ作用の開始前に、Astra Tridentがを探します ResourceQuota オブジェクトを検出し、検出されない場合は適用します。

デフォルトのリソースクォータおよび優先クラスをより詳細に制御する必要がある場合は、を生成できます custom.yaml またはを設定します ResourceQuota Helmチャートを使用するオブジェクト。

次に示すのは'ResourceQuota'オブジェクトがTridentのデマ作用を優先する例です

リソースクォータの詳細については、を参照してください。 "Kubernetes：リソースクォータ"。