Skip to main content
NetApp virtualization solutions
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Red Hat OpenShift クラスタに Trident をインストールしてストレージオブジェクトを作成する

共同作成者 banum-netapp netapp-jsnyder kevin-hoke

Red Hat認定TridentオペレーターでTridentをインストールし、ONTAPおよびAmazon FSx for NetApp ONTAP用のストレージオブジェクトを作成して、コンテナおよびVMの動的ボリュームプロビジョニングを有効にします。必要に応じて、ブロックアクセス用のワーカーノードを準備します。

開始する前に
  • OpenShift Virtualizationをインストールする前に、このページの手順を完了してください。OpenShift VirtualizationでVMテンプレート用のゴールデンイメージを作成するには、デフォルトのTridentベースのStorageClassとVolumeSnapshotClassが必要です。

  • OpenShift VirtualizationをインストールしてからTridentを設定する前に、異なるストレージクラスで作成されたゴールデンイメージをすべて削除してください。Tridentをデフォルトとして設定すると、OpenShift VirtualizationはTridentストレージを使用してゴールデンイメージを再作成します。

    oc delete dv,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron

ステップ1:Tridentをインストールする

Red Hat認定Tridentオペレーターは、NetAppによってOpenShiftのオンプレミス、パブリッククラウド、およびROSAなどのマネージドサービスでサポートされています。Trident 25.02以降、オペレーターは、Amazon FSx for NetApp ONTAPを使用し、OpenShift Virtualization VMワークロードを実行する予定の場合に、iSCSI用のワーカーノードを準備することもできます。

その他のインストールオプションについては、"Tridentのドキュメント"を参照してください。

手順
  1. OperatorHub で、Certified NetApp Trident を選択します。

    例を表示

    オペレーターハブ

  2. 「インストール」ページで、最新バージョンを保持し、「インストール」を選択します。

    例を表示

    インストール

  3. オペレーターのインストール後、*オペレーターの表示*を選択し、Trident Orchestratorのインスタンスを作成します。

    iSCSI 用にワーカー ノードを準備する場合は、YAML ビューに切り替えて `iscsi`を `nodePrep`に追加します。

    例を表示

    ノードの準備のためにiSCSIを追加する

  4. すべての Trident ポッドがクラスター内で実行されていることを確認してください。

    例を表示

    Tridentを設置

  5. iSCSIノードの準備を有効にした場合は、ワーカーノードにログインして、 `iscsid`と `multipathd`がアクティブであり、 `multipath.conf`にエントリがあることを確認してください。

    例を表示

    iscsid 実行中

    例を表示

    multipathd 実行中

    例を表示

    multipath.conf ファイルの実行

ビデオデモンストレーション

以下のビデオでは、Red Hat認定のTridentオペレーターを使用してTridentをインストールする方法のデモンストレーションを示しています。

OpenShift で認定されたTrident Operator を使用してTrident 25.02.1 をインストールする

ステップ2:環境のストレージバックエンドとStorageClass設定ファイルを準備する

環境用のTridentBackendConfigとStorageClassの定義を作成します。環境内で複数のストレージ プロトコルを設定できます。使用するプロトコルごとにYAMLファイルを作成し、プレースホルダーの値を具体的な設定の詳細に置き換えてください。

メモ 環境に応じて、下記のオンプレミスまたは ROSA セクションのいずれかを完了してから、ステップ 3 に進んでください。

オンプレミスOpenShiftクラスタ

設定したいプロトコルごとにYAMLファイルを作成してください。以下のプロトコルの 1 つ以上を設定できます:NFS ベースのファイル ストレージ用の NAS、iSCSI ブロック ストレージ用の iSCSI、TCP 経由のハイパフォーマンス NVMe ブロック ストレージ用の NVMe/TCP、または Fibre Channel ブロック ストレージ用の FC。

各プロトコルのTridentBackendConfigとStorageClassを作成します。バックエンド構成には、Kubernetes Secret に保存されている認証情報が含まれます。

バックエンド構成の基本オプションに関する重要なガイドライン
  1. バックエンド構成ファイルは、ONTAP SVM管理 LIF を参照します。+

  2. ユーザー名とパスワードを使用して ONTAP で認証できます。クラスター管理者または vserver 管理者のユーザー名とパスワードを使用できます。+

  3. ONTAP との認証にはクライアント証明書も使用できます。クライアント証明書、秘密鍵、および CA 証明書の生成方法の詳細については、"Tridentドキュメントはこちら"を参照してください。

NASエコノミードライバーのバックエンド構成オプションに関する基本ガイドライン

NASエコノミードライバの設定には、以下のパラメータを含めることができます。

  1. qtreesPerFlexvol 値は50~300の範囲内である必要があります。デフォルト値は200です。+

  2. limitVolumePoolSize この値は、ontap-nas-economy バックエンドで qtrees を使用する際にリクエストする最大 FlexVol サイズです。デフォルト値は設定されておらず、このパラメータはデフォルトでは適用されません。このパラメータを設定すると、現在の FlexVol が指定されたサイズに達したときに、Trident オペレーターが新しい FlexVol を作成します。このパラメータは、PV のプロビジョニングに使用される FlexVols のサイズを制限することで、クラスターの容量使用率を制御するのに役立ちます。+

  3. denyNewVolumePools このパラメータは、ontap-nas-economy バックエンドが qtree を格納するための新しい FlexVol ボリュームを作成することを制限します。新しい PV のプロビジョニングには、既存の FlexVol のみが使用されます。

SANドライバのバックエンド構成オプションに関する重要なガイドライン

SANドライバの設定には、以下のパラメータを含めることができます。

  1. limitVolumeSize この値は、SANバックエンドを使用する際に要求する最大ボリュームサイズです。デフォルト値は設定されておらず、このパラメータはデフォルトでは適用されません。このパラメータを設定すると、要求されたボリュームサイズがこの値を超えた場合に Trident オペレーターはプロビジョニングに失敗します。このパラメータを使用すると、LUN 用に管理するボリュームの最大サイズを制限できます。+

  2. lunsPerFlexvol FlexVol あたりの最大 LUN 数。範囲は [50, 200] で、デフォルト値は 100 です。このパラメーターを設定すると、現在の FlexVol が指定された数の LUN に達したときに、Trident オペレーターが新しい FlexVol を作成します。このパラメーターを使用すると、PV のプロビジョニングに使用される FlexVol あたりの LUN 数を制限することで、クラスターの容量使用率を制御できます。

SANエコノミードライバーのバックエンド構成オプションに関する基本ガイドライン

SANエコノミードライバの設定には、以下のパラメータを含めることができます。

  1. limitVolumePoolSize この値は、SANエコノミーバックエンドを使用する際に要求する最大FlexVolサイズです。デフォルト値は設定されておらず、このパラメータはデフォルトでは適用されません。このパラメータを設定すると、Tridentオペレータは、flexvol内にLUNを作成するために作成できるflexvolの最大サイズを制限します。このパラメータは、PVのプロビジョニングに使用されるFlexVolsのサイズを制限することで、クラスターの容量使用率を制御するのに役立ちます。+

  2. denyNewVolumePools このパラメータは、SAN エコノミー バックエンドが LUN を格納するための新しい FlexVol ボリュームを作成することを制限します。新しい PV のプロビジョニングには、既存の FlexVol のみが使用されます。

プロビジョニングボリュームのバックエンド構成オプションに関する重要なガイドライン
メモ 各プロトコル用に提供されているサンプルYAMLファイルでは、storagePrefixが指定されていない場合は、デフォルトの接頭辞「trident」が使用されます。ontap-nas-economy と24文字以上のstoragePrefixを使用する場合、qtreeにはストレージプレフィックスは埋め込まれませんが、ボリューム名には含まれます。

ONTAP のシステムマネージャまたは CLI から直接ボリュームを作成する際に、すべてのオプションパラメータに値を指定しない場合、ボリュームのプロビジョニング中に以下に示すようないくつかのデフォルト値が自動的に設定されます。

ONTAP でボリュームを作成する

ボリュームパラメータのデフォルト値

以下は、Trident バックエンド設定を使用して作成されたボリュームの例です。デフォルトセクションでは、名前テンプレート以外に明示的に設定されているオプションはありません。

oc describe tbc -n trident tbc-nas
### output truncated for brevity
Spec:
  Backend Name:  tbc-nas
  Credentials:
    Name:  tbc-nas-secret
  Defaults: # There are no defaults set except for the volume name template.
    Name Template:      {{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}
  Management LIF:       10.192.102.50
  Storage Driver Name:  ontap-nas
  Storage Prefix:       testautomation
  Svm:                  oc-test-automation

このバックエンド構成を使用してボリュームを作成すると、バックエンド構成ファイルで設定されていないオプションは、以下に示すようにデフォルト値に設定されます。

Trident バックエンド構成を使用して作成されたボリューム

ただし、Tridentバックエンド構成のデフォルトセクションで値を設定すると、それらのパラメータに特定の値を持つボリュームを作成できます。次の例では、snapshotPolicyはデフォルトポリシーに設定されています(明示的に何も設定しない場合はnoneになります)。また、snapshotDirはバックエンド設定YAMLのdefaultセクションでtrueに設定されています。これらの設定により、バックエンドボリュームがこれらの値を取得することがわかります。(snapdir-accessはtrue、snapshot-policyはdefault)

明示的な値を持つデフォルトセクション

バックエンド設定で snapshotDir および snapshotPolicy の値を明示的に設定する

ボリュームで snapshotDir および snapshotPolicy の値を明示的に設定する

その他の追加パラメータについては、Trident のドキュメントを参照してください:

NAS

TridentBackendConfigとStorageClassを作成して、ONTAP NASでNFSベースの永続ストレージ プロビジョニングを有効にします。バックエンド構成には、Kubernetes Secretに保存されている認証情報が含まれており、ONTAP SVMと管理LIFを参照します。

ユーザー名とパスワード認証を使用したバックエンドシークレットとバックエンド設定ファイルのサンプル( `tbc-nas.yaml`として保存):

# tbc-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-nas-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas
  svm: zoneb #<replace with your SVM name>
  storagePrefix: testzoneb #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-nas-secret

クライアント証明書認証を使用するバックエンドシークレットとバックエンド構成ファイルのサンプル( `tbc-nas.yaml`として保存):

# tbc-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: ontap-nas-secret
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas
  svm: zoneb #<replace with your SVM name>
  storagePrefix: testzoneb #<replace with your prefix>
  credentials:
    name: ontap-nas-secret
  clientCertificate: <client certificate>

StorageClass定義( `sc-nas.yaml`として保存):

# sc-nas.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nas
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"
allowVolumeExpansion: true
NAS エコノミー

TridentBackendConfig と StorageClass を ONTAP NAS エコノミードライバー用に作成し、qtree を使用した NFS ベースの永続的なストレージ プロビジョニングを有効にします。バックエンド構成には、Kubernetes Secret に保存されている認証情報が含まれており、ONTAP SVM と管理 LIF を参照します。

ユーザー名とパスワード認証を使用したバックエンドシークレットとバックエンド設定ファイルのサンプル( tbc-nas-economy.yaml として保存):

# tbc-nas-economy.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-nas-economy-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas-economy
spec:
  version: 1
  storageDriverName: ontap-nas-economy
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas-eco
  svm: <replace with your SVM name>
  storagePrefix: <replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-nas-economy-secret

StorageClass定義( `sc-nas-economy.yaml`として保存):

# sc-nas-economy.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nas-economy
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas-economy"
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"
allowVolumeExpansion: true
メモ ontap-nas-economyドライバのバックエンド構成ファイルに含めることができる追加パラメータの詳細については、上記の「NASエコノミードライバのバックエンド構成オプションに関する基本ガイドライン」セクションを参照してください。
iSCSI SAN

iSCSI ベースのブロックストレージ プロビジョニングを有効にするために、ONTAP SAN with iSCSI 用の TridentBackendConfig と StorageClass を作成します。バックエンド構成では、ontap-san ドライバを使用し、Kubernetes Secret に格納された認証情報が含まれます。sanType パラメータは、省略した場合、デフォルトで iSCSI プロトコルが使用されます。

ユーザー名とパスワードによる認証を使用するバックエンドシークレットとバックエンド構成ファイル(保存先: tbc-iscsi.yaml):

# tbc-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-iscsi-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <management LIF>
  backendName: ontap-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-iscsi-secret

クライアント証明書認証を使用するバックエンドシークレットとバックエンド構成ファイル( `tbc-iscsi.yaml`として保存):

# tbc-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-iscsi-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <management LIF>
  backendName: ontap-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-iscsi-secret
  clientCertificate: <client certificate>

StorageClass定義( `sc-iscsi.yaml`として保存):

# sc-iscsi.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-iscsi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true
NVMe/TCP SAN

TridentBackendConfigとStorageClassを作成して、TCP経由のNVMeを使用したONTAP SANでハイパフォーマンスブロックストレージ プロビジョニングを有効にします。バックエンド構成では、NVMe/TCPトランスポート用に最適化されたontap-sanドライバを使用し、Kubernetes Secretに格納された認証情報が含まれています。

ユーザー名とパスワードによる認証を使用するバックエンドシークレットとバックエンド構成ファイル(保存先: tbc-nvme.yaml):

# tbc-nvme.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-nvme-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nvme
spec:
  version: 1
  storageDriverName: ontap-san
  sanType: nvme
  managementLIF: <ONTAP management LIF>
  backendName: backend-tbc-ontap-nvme
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-nvme-secret

クライアント証明書認証を使用するバックエンドシークレットとバックエンド構成ファイル( `tbc-nvme.yaml`として保存):

# tbc-nvme.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-nvme-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nvme
spec:
  version: 1
  storageDriverName: ontap-san
  sanType: nvme
  managementLIF: <ONTAP management LIF>
  backendName: backend-tbc-ontap-nvme
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-nvme-secret
  clientCertificate: <client certificate>

StorageClass定義( `sc-nvme.yaml`として保存):

# sc-nvme.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nvme
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true
メモ ReadWriteMany(RWX)ボリュームをNVMeプロトコルで使用する予定がある場合、Kubernetesクラスタでは、単一のRWX NVMeボリュームを64ノード以上でマウントすることはできません。この制限の詳細、およびTrident 26.02で導入されたSuper-subsystemモデルとTrident 26.02以前のPer-volume subsystemモデルについては、Tridentのドキュメントを参照してください: https://docs.netapp.com/us-en/trident/trident-use/ontap-san-prep.html#nvme-tcp-considerations
FC SAN

TridentBackendConfigとStorageClassを作成して、Fibre ChannelでONTAP SANのFCベースのブロックストレージ プロビジョニングを有効にします。バックエンド構成では、FCPプロトコルを指定したontap-sanドライバを使用し、Kubernetes Secretに格納された認証情報を含みます。

ユーザー名/パスワード認証方式またはクライアント証明書認証方式を使用して、ONTAP で認証します。クライアント証明書、秘密鍵、および CA 証明書の生成方法の詳細については、"Tridentドキュメントはこちら"を参照してください。両方の方法の例を以下に示します。

例を表示

バックエンドシークレットとバックエンド構成ファイルを使用した ONTAP ユーザー名とパスワードによる認証( `tbc-fc.yaml`として保存):

# tbc-fc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-fc-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-fc
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <ONTAP management LIF>
  backendName: tbc-fc
  svm: openshift-fc #<replace with your SVM name>
  sanType: fcp
  storagePrefix: demofc #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-fc-secret

クライアント証明書認証を使用するバックエンドシークレットとバックエンド構成ファイル( `tbc-fc.yaml`として保存):

# tbc-fc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-fc-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-fc
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <ONTAP management LIF>
  backendName: tbc-fc
  svm: openshift-fc #<replace with your SVM name>
  sanType: fcp
  storagePrefix: demofc #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-fc-secret
  clientCertificate: <client certificate>
# sc-fc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-fc
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true
iSCSI SANの経済性

TridentBackendConfig と StorageClass を作成して、iSCSI を使用した ONTAP SAN economy で iSCSI ベースのブロックストレージ プロビジョニングを有効にします。バックエンド構成では、iSCSI プロトコルを使用する ontap-san-economy ドライバーを使用し、Kubernetes Secret に格納された認証情報が含まれます。

クライアント証明書認証を使用するバックエンドシークレットとバックエンド構成ファイル( `tbc-san-eco.yaml`として保存):

# tbc-san-eco.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: ontap-san-cert-auth
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-san-eco-cert
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san-economy
  managementLIF: "<ONTAP management LIF>"
  backendName: tbc_san_eco
  svm: <replace with your SVM name>
  storagePrefix: <replace with your prefix>
  credentials:
    name: ontap-san-cert-auth
  clientCertificate: <client certificate>
# sc-san-eco.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-san-eco
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san-economy"
  provisioningType: "thin"
  snapshots: "true"

SANドライバおよびNASドライバでサポートされているアクセスモードとボリュームモードに関する情報、およびYAMLファイルの追加サンプルについては、Tridentのドキュメントを参照してください。

Amazon FSx for NetApp ONTAPを使用したROSAクラスター

設定したいプロトコルごとにYAMLファイルを作成してください。以下のプロトコルのいずれか、または両方を設定できます:NFSベースのファイルストレージにはNAS、ブロックストレージにはiSCSIを使用します。

NAS

TridentBackendConfigとStorageClassを作成して、Amazon FSx for NetApp ONTAPとONTAP NASを使用し、ROSAクラスター上でNFSベースの永続ストレージ プロビジョニングを有効にします。バックエンド構成では、管理LIFとデータLIF用のAmazon FSx for NetApp ONTAP DNS名を使用し、trident名前空間のKubernetes Secretに格納されている認証情報が含まれます。

バックエンドシークレットとバックエンド設定ファイル( `tbc-fsx-nas.yaml`として保存):

# tbc-fsx-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-fsx-ontap-nas-secret
type: Opaque
stringData:
  username: <FSx for ONTAP, for example fsxadmin>
  password: <FSx for ONTAP password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-fsx-ontap-nas
spec:
  version: 1
  backendName: fsx-ontap
  storageDriverName: ontap-nas
  managementLIF: <Management DNS name>
  dataLIF: <NFS DNS name>
  svm: <SVM NAME>
  credentials:
    name: backend-fsx-ontap-nas-secret

StorageClass定義( `sc-fsx-nas.yaml`として保存):

# sc-fsx-nas.yaml (storage class name is trident-csi)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: trident-csi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  fsType: "ext4"
allowVolumeExpansion: true
reclaimPolicy: Retain
iSCSI

TridentBackendConfigとStorageClassを作成して、Amazon FSx for NetApp ONTAP with ONTAP SANでROSAクラスター上のiSCSIベースのブロックストレージプロビジョニングを有効にします。バックエンド構成では、ontap-sanドライバを使用し、Kubernetes Secretに格納された認証情報が含まれます。ワーカーノードがiSCSIアクセス用に準備されていることを確認してください。

バックエンドシークレットとバックエンド設定ファイル( `tbc-fsx-iscsi.yaml`として保存):

# tbc-fsx-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-fsx-iscsi-secret
type: Opaque
stringData:
  username: <FSx for ONTAP, for example fsxadmin>
  password: <FSx for ONTAP password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: fsx-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <Management DNS name>
  backendName: fsx-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-fsx-iscsi-secret

StorageClass定義( `sc-fsx-iscsi.yaml`として保存):

# sc-fsx-iscsi.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-fsx-iscsi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

ステップ3:VolumeSnapshotClass設定ファイルを作成する

オンプレミスとROSAの両方の導入に対してVolumeSnapshotClass定義を作成します。この構成により、永続ボリュームに対するスナップショットベースの操作が可能になります。

VolumeSnapshotClass定義( `snapshot-class.yaml`として保存):

# snapshot-class.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: trident-snapshotclass
driver: csi.trident.netapp.io
deletionPolicy: Retain

ステップ4:構成ファイルをクラスタに適用する

前の手順で作成した構成ファイルをOpenShiftクラスタに適用します。

手順
  1. 設定したプロトコルごとにTridentBackendConfigとStorageClassファイルを適用します。

    オンプレミス クラスタの場合:

    oc create -f tbc-nas.yaml -n trident
    oc create -f sc-nas.yaml
    
    oc create -f tbc-nas-economy.yaml -n trident
    oc create -f sc-nas-economy.yaml
    
    oc create -f tbc-iscsi.yaml -n trident
    oc create -f sc-iscsi.yaml
    
    oc create -f tbc-nvme.yaml -n trident
    oc create -f sc-nvme.yaml
    
    oc create -f tbc-fc.yaml -n trident
    oc create -f sc-fc.yaml

    ROSAクラスタの場合:

    oc create -f tbc-fsx-nas.yaml -n trident
    oc create -f sc-fsx-nas.yaml
    
    oc create -f tbc-fsx-iscsi.yaml -n trident
    oc create -f sc-fsx-iscsi.yaml
  2. VolumeSnapshotClass構成を適用します。

    oc create -f snapshot-class.yaml
  3. リソースが正常に作成されたことを確認してください。

    TridentBackendConfigオブジェクトを確認:

    oc get tbc -n trident

    StorageClassオブジェクトを確認します:

    oc get storageclass

    VolumeSnapshotClassを確認:

    oc get volumesnapshotclass

ステップ5:デフォルトのTridentストレージおよびスナップショットクラスを設定する

OpenShift クラスターで Trident の StorageClass と VolumeSnapshotClass をデフォルトに設定します。これは、OpenShift Virtualization が VM テンプレート用のゴールデンイメージソースを作成するために必要です。

手順
  1. デフォルトのTrident StorageClassを設定します。

    Trident-backed StorageClassをクラスターのデフォルトとして設定すると、ストレージクラスが指定されていない場合にPersistentVolumeClaimsが自動的にそれを使用します。2つのアノテーションを設定する必要があります(1つはクラスタ全体のデフォルト用、もう1つはOpenShift Virtualization専用)。

    1. クラスター全体のデフォルトのStorageClassアノテーションを設定します。

      1つのStorageClassのみがデフォルトとして設定されていることを確認してください。別のStorageClassが既にデフォルトに設定されている場合は、そのアノテーションを false に設定します。

      コンソールで、注釈を編集します:

      storageclass.kubernetes.io/is-default-class: "true"

      CLIから:

      kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
    2. OpenShift Virtualization固有のデフォルトアノテーションを設定します。

      OpenShift Virtualization では、クラスタの一般的な `is-default-class`注釈よりも優先される特定の注釈が使用されます。別のStorageClassが既にデフォルトに設定されている場合は、その注釈を false に設定します。

      コンソールで、注釈を編集します:

      storageclass.kubevirt.io/is-default-virt-class: "true"

      CLIから:

    kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'
  2. デフォルトのTrident VolumeSnapshotClassを設定します。

    TridentベースのVolumeSnapshotClassをクラスタのデフォルトとして設定し、永続ボリュームのスナップショットベースの操作を有効にします。これにより、スナップショットクラスが指定されていない場合、VolumeSnapshotsは自動的にTrident CSIドライバを使用し、OpenShift Virtualizationがゴールデンイメージのスナップショットを作成できるようになります。

    1つのVolumeSnapshotClassのみがデフォルトとして設定されていることを確認してください。別のVolumeSnapshotClassが既にデフォルトに設定されている場合は、そのアノテーションをfalseに設定してください。

    コンソールで、注釈を編集します:

    snapshot.storage.kubernetes.io/is-default-class: "true"

    CLIから:

    oc patch volumesnapshotclass <snapshot class name> --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'