おそらく、オブジェクト、その目的、操作方法を理解する最も簡単な方法は、 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には、クローンを作成するためのアノテーションとが splitOnClone`用意されています `cloneFromPVC。これらの注釈を使用して、CSI実装を使用せずにPVCのクローンを作成できます。

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

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

この `sample-input`ディレクトリには、Tridentで使用するPVC定義の例が含まれています。Tridentボリュームに関連するパラメータと設定の詳細については、を参照してください。

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

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

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

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

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

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

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

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

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

スナップショットを作成するには、管理者がを `VolumeSnapshotClass`定義する必要があります。ボリューム Snapshot クラスは、次の定義で作成されます。

は driver、Kubernetesに対して、クラスのボリュームSnapshotの要求がTridentで処理されるように指定します csi-snapclass。は、 `deletionPolicy`Snapshotを削除する必要がある場合に実行する処理を指定します。 `deletionPolicy`をに設定する `Delete`と、Snapshotを削除すると、ボリュームSnapshotオブジェクトとストレージクラスタ上の基盤となるSnapshotが削除されます。または、に設定する `Retain`と、 `VolumeSnapshotContent`物理Snapshotが保持されます。

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

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

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

Trident では、スナップショット要求を受信すると、バックエンドにスナップショットが作成されます。スナップショットが作成されると、Tridentはオブジェクトを構成し VolumeSnapshotContent、スナップショットを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`と、Kubernetesで使用するために対応する `tridentbackends`CRDオブジェクトが作成されます。

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

Tridentは、プロビジョニングツールフィールドで指定されたKubernetesオブジェクト csi.trident.netapp.io`に一致するストレージクラスを作成します `StorageClass。ストレージクラス名は、そのストレージクラスが表すKubernetesオブジェクトの名前と一致し `StorageClass`ます。

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

REST API を使用して、ストレージクラスを直接定義するストレージクラス設定を作成できます。ただし、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オブジェクトを作成することで機能します。このSnapshotオブジェクトのは `internalName、プレフィックスと VolumeSnapshot`オブジェクトのを `UID`組み合わせることで生成され `snapshot-`ます（例： `snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660）。 `volumeName`および `volumeInternalName`は、バッキングボリュームの詳細を取得することによって読み込まれます。

Tridentデーモンセットは、Kubernetesで利用可能な最高の優先度クラスであるプライオリティクラスを使用して system-node-critical、ノードの正常なシャットダウン時にAstra Tridentがボリュームを特定してクリーンアップできるようにし、リソースへの負荷が高いクラスタでは、Tridentデーモンセットポッドが優先度の低いワークロードをプリエンプトできるようにします。

これを実現するために、Astra Tridentではオブジェクトを使用し ResourceQuota`て、Tridentデーモンセットで「system-node-critical」優先クラスを確実に満たします。導入とデーモンセットの作成の前に、Astra Tridentがオブジェクトを検索し `ResourceQuota、検出されなかった場合は適用します。

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

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

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