おそらく、オブジェクト、その目的、相互作用の仕方を理解する最も簡単な方法は、Kubernetes ユーザーからの単一のストレージ要求を追跡することです：

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

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

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

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

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

例：ユーザーがすでにPVC `mysql`を持っている場合、アノテーション `trident.netapp.io/cloneFromPVC: mysql`を使用して、新しいPVC `mysqlclone`を作成できます。このアノテーションが設定されていると、Tridentはmysql PVCに対応するボリュームをクローンし、新規にボリュームをプロビジョニングするのではなく複製します。

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

Kubernetes `PersistentVolume`オブジェクトは、Kubernetesクラスタで使用できるストレージの一部を表します。これには、それを使用するポッドから独立したライフサイクルがあります。

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

Kubernetes `StorageClass`オブジェクトは `PersistentVolumeClaims`で名前によって指定され、一連のプロパティを持つストレージをプロビジョニングします。ストレージクラス自体は、使用するプロビジョナーを識別し、プロビジョナーが理解できる用語でそのプロパティセットを定義します。

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

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

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

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

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

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

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

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

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

スナップショットのリクエストが来ると、Tridentはバックエンドにスナップショットを作成します。スナップショットが作成されると、Tridentは `VolumeSnapshotContent`オブジェクトを構成し、スナップショットをKubernetes APIに公開します。

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

Kubernetes `VolumeGroupSnapshot`オブジェクトは、複数のボリュームのスナップショットを作成する要求です。PVCがボリュームに対するユーザーの要求を表すのと同様に、ボリューム グループ スナップショットは、既存のPVCのスナップショットを作成するためのユーザーの要求です。

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

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

スナップショットのリクエストが来ると、Tridentはバックエンドにボリューム グループのスナップショットを作成します。ボリューム グループのスナップショットが作成されると、Tridentは `VolumeGroupSnapshotContent`オブジェクトを構成し、スナップショットをKubernetes APIに公開します。

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

カスタム リソース定義（CRD）とそれに関連付けられたオブジェクト メタデータは、Kubernetesによってメタデータ ストアに保存されます。これにより、Trident用の別のストアが不要になります。

Tridentは、 `CustomResourceDefinition`オブジェクトを使用して、Tridentバックエンド、Tridentストレージクラス、TridentボリュームなどのTridentオブジェクトのアイデンティティを保持します。これらのオブジェクトはTridentによって管理されます。さらに、CSIボリュームSnapshotフレームワークでは、ボリュームSnapshotを定義するために必要ないくつかのCRDが導入されています。

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

以下に、TridentのCRDについて留意すべき点をいくつか示します：

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

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

REST APIを使用してストレージクラスを直接定義するストレージクラス構成を作成できます。ただし、Kubernetesのデプロイメントの場合、新しいKubernetes `StorageClass`オブジェクトを登録するときに作成されることを想定しています。

バックエンドは、Tridentがボリュームをプロビジョニングするストレージプロバイダーを表します。単一のTridentインスタンスは任意の数のバックエンドを管理できます。

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

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

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

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

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

Tridentは、ボリュームを作成するときに `internalName`を生成します。これは2つのステップで構成されます。まず、ストレージプレフィックス（デフォルトの `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デーモンセットポッドが優先度の低いワークロードをプリエンプトできます。

これを実現するために、Tridentは `ResourceQuota`オブジェクトを使用して、Trident daemonsetで「system-node-critical」優先度クラスが満たされるようにします。導入とdaemonsetの作成前に、Tridentは `ResourceQuota`オブジェクトを検索し、検出されない場合は適用します。

デフォルトのResource QuotaとPriority Classをさらに制御する必要がある場合は、 `custom.yaml`を生成するか、Helmチャートを使用して `ResourceQuota`オブジェクトを設定できます。

以下は、Tridentデーモンセットを優先する`ResourceQuota`オブジェクトの例です。

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