【誌上ハンズオン】Amazon FSx for NetApp ONTAP+NetApp Trident+Amazon EKSを試す その2 Tridentインストール編【初心者向け】

みなさんこんにちは。福住です。前回は環境準備編としてEKSとFSx for NetApp ONTAPをデプロイするところまで実施しました。今回はデプロイしたONTAPへのアクセスとTridentのインストールを実施します。

Amazon FSx for NetApp ONTAPへのアクセス

前回までの手順でAmazon FSx for NetApp ONTAPはデプロイできました。それではONTAPにアクセスしてみましょう。
## 管理IPアドレスの確認 作成したFSxの「ファイルシステムID」をクリック 「ネットワークセキュリティ」タブのエンドポイント＞管理エンドポイント-IPアドレスをメモします。

CloudShell（VPC環境）の設定

CloudShellがVPC内にアクセスできるよう設定します。
＋＞Create VPC environment(max2)

• Name：Trident-ONTAP
• Virtual private cloud(VPC)：EKSをデプロイしたVPC
• Subnet：Amazon FSx for NetApp ONTAPをデプロイしたSubnet
• Security group：ONTAP-SG
• 「作成」をクリック

この後は

• CloudShell（デフォルト）:EKSを操作
• CloudShell（VPC環境）：Amazon FSx for NetApp ONTAPを操作

と区別します。コマンドを入力するCloudShellを間違えないよう注意してください。

ONTAPへのログイン

ssh fsxadmin@192.168.XXX.XXX  #先ほどメモした管理エンドポイント-IPアドレス

ログインできたら下記コマンドでAmazon FSx for NetApp ONTAPの情報を一括で確認します。

rows 0
cluster show
vserver show
network interface show
storage aggregate show
volume show

ONTAPストレージの詳細確認

先程のコマンドでONTAPの情報を取得しましたが、もう少し細かく情報を確認してみましょう。 ONTAPストレージはクラスタの中に、仮想化されたストレージ＝SVMを作り出し、SVMを一台の独立したストレージの様に扱う事が可能です。オンプレミス環境ではこのSVMを作成する必要がありますが、Amazon FSx for NetApp ONTAPではSVMは作成済みのため、ここでは確認作業のみ実施します。

1. SVMの確認
   vserver show -vserver fsx -instance

2. Network Interfaceの確認
   network interface show ※nfs_smb_management_1がNAS用のData LIF兼SVM Management LIFとなります。

3. Export Policy（アクセス許可）の確認
   vserver export-policy rule show -policyname default

4. Export Policy（アクセス許可）の編集
   kubernetes（EKS）クラスタのノードIPアドレス範囲（192.168.0.0/16）からのみアクセスできるようExport Policyを編集します。
   vserver export-policy rule modify -vserver fsx -policyname default -ruleindex 1 -protocol any -clientmatch 192.168.0.0/16

5. 変更を確認します。
   vserver export-policy rule show -policyname default

以上でONTAPの情報を一通り確認できました。

Worker Nodeでの下準備

Worker NodeへのNFSクライアントのインストール

通常、NFSを利用するにはNFSクライアント(nfs-utilsなど)のインストールが必要ですが、 今回利用するEKS最適化AMI(Amazon Linux)には標準でNFSクライアント機能が含まれており、 本ハンズオンで実際に確認した範囲では、追加のインストール作業なしにNFS(ontap-nas)の ボリュームが問題なくマウントできました。そのため今回は対応不要です。

補足: 一方でiSCSI(ontap-san)を利用する場合は、この後の章で説明する通り、 iscsi-initiator-utilsなどのパッケージを別途手動でインストールする必要があります。 NFSとiSCSIで、ワーカーノード側の準備作業に差があることに注意してください。

Worker NodeでのiSCSI設定

AWSマネジメントコンソールのSSM Session ManagerセッションマネージャーからWorker NodeにログインしてiSCSI設定をします。

この手順は、クラスタ内の全てのWorker Node(2台)に対して実施してください。 どちらのノードにPodがスケジュールされるか事前には分からないため、片方だけの実施だと後でopen-iscsi tools not found on hostなどのエラーが発生します。

• AWSマネジメントコンソール＞EC2>インスタンス＞インスタンス＞trident-eksctl-ng-XXXXX-Nodeにチェックを入れて「接続」をクリック

• 「セッションマネージャー」タブを選択し、「接続」をクリック

• システムパッケージのインストール

sudo yum install -y lsscsi iscsi-initiator-utils device-mapper-multipath

• iscsi-initiator-utils のバージョンが 6.2.0.874-2.el7 以降であることを確認します。

rpm -q iscsi-initiator-utils

• スキャンを手動に設定：

sudo sed -i 's/^\(node.session.scan\).*/\1 = manual/' /etc/iscsi/iscsid.conf

• マルチパス設定を作成し、EBSデバイスをmultipathの管理対象から除外します。

sudo tee /etc/multipath.conf > /dev/null << 'EOF'
defaults {
  user_friendly_names yes
  find_multipaths no
}
blacklist {
  device {
    vendor "NVME"
    product "Amazon Elastic Block Store"
  }
}
EOF

補足: EKSのワーカーノードはルートボリュームがAmazon EBS(NVMe)です。この除外設定がないと、multipathdがルートEBSボリュームまで管理しようとしてしまい、Device or resource busyのようなエラーが発生します。

• マルチパスデーモンの有効化

   sudo mpathconf --enable --with_multipathd y --find_multipaths n

• 「iscsid」と「multipathd」を有効化し、起動します。

   sudo systemctl enable --now iscsid multipathd

• iSCSIの有効化と開始

   sudo systemctl enable --now iscsi

• iSCSI関連のサービスが起動していることを確認します(任意)

  sudo systemctl is-active iscsid multipathd

両方とも active と表示されれば、下準備は完了です。

重要: ワーカーノードのiSCSI設定(このセクション)は、Tridentをインストールする前、 またはTridentのtrident-node Podが起動する前に完了させておくことを強く推奨します。

Tridentは起動時にノードのiSCSI対応状況を検出してキャッシュするため、 Trident起動後にiSCSIツールを追加した場合、trident-node Podを再起動しないと 認識が更新されず、igroupへのIQN自動登録が行われないことがあります。

もし後からiSCSI設定を行った場合は、念のため該当ノードのtrident-node Podを 再起動してください。
kubectl delete pod -n trident <該当ノードのtrident-node-linux-xxxx>

この手順をもう一方のNodeでも繰り返してください。

Tridentインストール

Helmの導入

Helmは最低でもバージョン3以上が必要となります。 CloudShell（デフォルト）から以下のコマンドを実行します。

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

Tridentの入手

以下コマンドでTridentをリポジトリに追加します。

helm repo add netapp-trident https://netapp.github.io/trident-helm-chart

Tridentをインストールします。

helm install trident netapp-trident/trident-operator --version 100.2602.0 --create-namespace --namespace trident

Tridentインストールの確認

下記コマンドを入力します。

kubectl get pod -n trident

下記状態になっていればインストール成功です。

~ $ kubectl get pod -n trident
NAME                                 READY   STATUS    RESTARTS      AGE
trident-controller-65cf8c7db-6zwv7   6/6     Running   0             116s
trident-node-linux-jbzz7             2/2     Running   1 (78s ago)   116s
trident-node-linux-rkzxc             2/2     Running   0             116s
trident-operator-667cf77498-9rwgs    1/1     Running   0             2m18s

Podの数が少ない場合、数分待ってから同じコマンドを入力してください。上記と同じPod数になっていればTridentのインストール完了です。

下記コマンドで名前、ネームスペース、グラフ、ステータス、アプリケーションのバージョン、リビジョン番号など、インストールの詳細を確認できます。

helm list -n trident

Kubernetes（EKS）内からのアクセス確認

ストレージとKubernetes（EKS）がネットワーク的に疎通可能かどうかを確認します。

ノードのIPからデータLIFへの疎通確認

• AWSマネジメントコンソール＞EC2>インスタンス＞インスタンス＞trident-eksctl-ng-XXXXX-Nodeにチェックを入れて「接続」をクリック

• 「セッションマネージャー」タブを選択し、「接続」をクリック

以下コマンドを入力

ping ［データLIFのIP］ -c 3

データLIFのIP＝nfs_smb_management_1のIPです。CloudShell（VPC環境）からnetwork interface showで確認してください。

Podの中から管理LIFへの疎通確認

CloudShell（デフォルト）から以下コマンドを入力します。

kubectl run -it --rm --image=alpine storage-test -- ping ［SVMの管理IPアドレス=nfs_smb_management_1］ -c 3

応答が返ってくれば問題ありません。

補足: kubectlやhelmで「Kubernetes cluster unreachable」や 「connection refused」というエラーが出た場合、CloudShellの再起動などで クラスタへの接続情報(kubeconfig)が失われている可能性があります。 以下のコマンドで再取得できます。

aws eks update-kubeconfig --name trident-eksctl --region ap-northeast-1

次回

今回はTridentをインストールしました。次回 blogs.networld.co.jp

は実際にTridentを使ってみます。

▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼
ネットワールドが開催する 年に一度の大イベント
【 Networld Wiz 2026 】お申込み受付中！！

本ブログでご紹介したメーカーもイベントへ出展します！

セッション & ブース出展情報 随時更新中
　　▼ぜひチェックしてください▼

セールスコンサルティング部
福住遊
AWS/NetAppのプロダクトセールス担当、エンジニア経験はありませんがBlog書いたりハンズオン作ったりします。

• ストレージ探偵ずーみん
• シロウト営業シリーズ：
  • K8S基盤を激安にする魔法！Spot Oceanをシロウト営業が試してみた