おそらく、オブジェクト、その目的、およびそれらがどのように相互作用するかを理解するための最も簡単な方法は、Kubernetes ユーザーからの単一のストレージ要求を追跡することです。

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 を複製できます。この方法では、PV のポイントインタイムコピーをスナップショットの形式で Kubernetes に公開できます。その後、スナップショットを使用して新しい PV を作成できます。見てみましょう `On-Demand Volume Snapshots`これがどのように機能するかを確認します。

Tridentはまた、 `cloneFromPVC`そして `splitOnClone`クローンを作成するための注釈。これらのアノテーションを使用すると、CSI 実装を使用せずに PVC を複製できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kubernetes `VolumeSnapshot`オブジェクトはボリュームのスナップショットを作成する要求です。 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 。

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

Tridentは `CustomResourceDefinition`Tridentバックエンド、 Tridentストレージ クラス、 TridentボリュームなどのTridentオブジェクトの ID を保持するためのオブジェクト。これらのオブジェクトは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 がボリュームをプロビジョニングするストレージ プロバイダーを表します。1 つのTridentインスタンスで任意の数のバックエンドを管理できます。

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

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

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

ボリュームはプロビジョニングの基本単位であり、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デーモンセットの「システム ノード クリティカル」優先度クラスが満たされていることを確認するオブジェクト。デプロイメントとデーモンセットの作成の前に、 Tridentは `ResourceQuota`オブジェクトを検索し、見つからない場合は適用します。

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

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

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