

 **このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# FSx for Lustre ドライバーをデプロイする
<a name="fsx-csi-create"></a>

このトピックでは、[FSx for Lustre CSI ドライバー](fsx-csi.md)を Amazon EKS クラスターにデプロイし、動作することを確かめる方法について説明します。最新バージョンのドライバーを使用することをお勧めします。利用可能なバージョンについては、GitHub の「[CSI Specification Compatibility Matrix](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/README.md#csi-specification-compatibility-matrix)」(CSI 仕様互換性マトリックス) を参照してください。

**注記**  
ドライバーは、Fargate または Amazon EKS Hybrid Nodes ではサポートされていません。

使用可能なパラメータの詳細と、ドライバーの機能を示す完全な例については、GitHub の 「[FSx for Lustre Container Storage Interface (CSI) driver](https://github.com/kubernetes-sigs/aws-fsx-csi-driver)」プロジェクトを参照してください。

## 前提条件
<a name="fsx-csi-prereqs"></a>
+ 既存のクラスター。
+ Amazon FSx CSI ドライバー EKS アドオンの認証には、EKS Pod Identity エージェントが必要です。このコンポーネントがないと、アドオンは「`Amazon EKS Pod Identity agent is not installed in the cluster`」というエラーで失敗し、ボリュームオペレーションが回避されます。FSx CSI ドライバーアドオンをデプロイする前後に Pod Identity エージェントをインストールします。詳細については、「[Amazon EKS Pod Identity エージェントのセットアップ](pod-id-agent-setup.md)」を参照してください。
+ ご使用のデバイスまたは AWS クラウドシェル で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS CloudShell にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。

## ステップ 1: IAM ロールを作成する
<a name="fsx-create-iam-role"></a>

Amazon FSx CSI プラグインでは、ユーザーに代わって AWS API の呼び出しを行うための IAM アクセス許可が必要です。

**注記**  
Pod は、IMDS へのアクセスをブロックする場合を除き、IAM ロールに割り当てられたアクセス許可にアクセスできます。詳細については、「[ベストプラクティスによる Amazon EKS クラスターの保護](security-best-practices.md)」を参照してください。

以下の手順は、IAM ロールを作成し、それに AWS マネージドポリシーをアタッチする方法を示しています。

1. IAM ロールを作成し、次のコマンドで AWS マネージドポリシーをアタッチします。`my-cluster` を、使用するクラスターの名前に置き換えます。このコマンドは IAM ロールを作成して IAM ポリシーをアタッチする AWS CloudFormation スタックをデプロイします。

   ```
   eksctl create iamserviceaccount \
       --name fsx-csi-controller-sa \
       --namespace kube-system \
       --cluster my-cluster \
       --role-name AmazonEKS_FSx_CSI_DriverRole \
       --role-only \
       --attach-policy-arn arn:aws:iam::aws:policy/AmazonFSxFullAccess \
       --approve
   ```

   サービスアカウントが作成されると、数行の出力が表示されます。出力の最後の数行は、次のようになります。

   ```
   [ℹ]  1 task: {
       2 sequential sub-tasks: {
           create IAM role for serviceaccount "kube-system/fsx-csi-controller-sa",
           create serviceaccount "kube-system/fsx-csi-controller-sa",
       } }
   [ℹ]  building iamserviceaccount stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
   [ℹ]  deploying stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
   [ℹ]  waiting for CloudFormation stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
   [ℹ]  created serviceaccount "kube-system/fsx-csi-controller-sa"
   ```

   デプロイされた AWS CloudFormation スタックの名前を書き留めます。前述の出力例では、スタックの名前は `eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa` です。

Amazon FSx CSI ドライバーの IAM ロールを作成したので、次のセクションに進むことができます。この IAM ロールを使用してアドオンをデプロイすると、`fsx-csi-controller-sa` という名前のサービスアカウントが作成され、それを使用されるように設定されます。サービスアカウントは Kubernetes `clusterrole` にバインドされます。これには、必要な Kubernetes アクセス許可が割り当てられています。

## ステップ 2: Amazon FSx CSI ドライバーをインストールする
<a name="fsx-csi-deploy-driver"></a>

セキュリティを強化し、作業量を削減するために、Amazon EKS アドオンを通じて Amazon FSx CSI ドライバーをインストールすることをお勧めします。Amazon EKS アドオンをクラスターに追加するには、「[Amazon EKS アドオンを作成する](creating-an-add-on.md)」を参照してください。アドオンの詳細については、「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。

**重要**  
クラスターに既存の Amazon FSx CSI ドライバーをインストールすると、アドオンのインストールに失敗する可能性があります。EKS 以外の FSx CSI ドライバーが存在するところに Amazon EKS のアドオンバージョンをインストールしようとすると、リソースの競合によりインストールが失敗します。この問題を解消するには、インストール時に `OVERWRITE` フラグを使用します。  

```
aws eks create-addon --addon-name aws-fsx-csi-driver --cluster-name my-cluster --resolve-conflicts OVERWRITE
```

または、Amazon FSx CSI ドライバーのセルフマネージド型インストールが必要な場合は、GitHub の「[Installation](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/install.md)」を参照してください。

## ステップ 3: ストレージクラス、永続的なボリューム要求、サンプルアプリケーションをデプロイする
<a name="fsx-csi-deploy-storage-class"></a>

この手順では、「[FSx for Lustre Container Storage Interface (CSI) driver](https://github.com/kubernetes-sigs/aws-fsx-csi-driver)」(FSx for Lustre コンテナストレージインターフェイス (CSI) ドライバー) GitHub リポジトリを使用して、動的にプロビジョニングされた FSx for Lustre ボリュームを使用します。

1. クラスターのセキュリティグループを書き留めます。AWS マネジメントコンソール の **[ネットワーク]** セクションまたは次の AWS CLI コマンドを使用して確認できます。`my-cluster` を、使用するクラスターの名前に置き換えます。

   ```
   aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId
   ```

1. 「Amazon FSx for Lustre ユーザーガイド」の「[Amazon VPC セキュリティグループ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/limit-access-security-groups.html#fsx-vpc-security-groups)」に示す基準に従って、Amazon FSx ファイルシステムのセキュリティグループを作成します。**[VPC]** で、**[ネットワーク]** セクションに示されているようにクラスターの VPC を選択します。「Lustre クライアントに関連付けられているセキュリティグループ」には、クラスターセキュリティグループを使用します。アウトバウンドルールをそのままにして、**[すべてのトラフィック]** を許可することができます。

1. 次のコマンドを使用して、ストレージクラスマニフェストをダウンロードします。

   ```
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml
   ```

1. `storageclass.yaml` ファイルの parameters セクションを編集します。各サンプル値は独自の値に置き換えます。

   ```
   parameters:
     subnetId: subnet-0eabfaa81fb22bcaf
     securityGroupIds: sg-068000ccf82dfba88
     deploymentType: PERSISTENT_1
     automaticBackupRetentionDays: "1"
     dailyAutomaticBackupStartTime: "00:00"
     copyTagsToBackups: "true"
     perUnitStorageThroughput: "200"
     dataCompressionType: "NONE"
     weeklyMaintenanceStartTime: "7:09:00"
     fileSystemTypeVersion: "2.12"
   ```
   +  ** `subnetId` ** – Amazon FSx for Lustre ファイルシステムが作成されるサブネット ID。Amazon FSx for Lustre は、すべてのアベイラビリティーゾーンでサポートされているわけではありません。[https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/) で Amazon FSx for Lustre コンソールを開き、使用するサブネットが、サポートされているアベイラビリティーゾーンにあることを確認します。次のように、サブネットにノードを含めることも、別のサブネットまたは VPC にすることもできます。
     + AWS マネジメントコンソール で **[コンピューティング]** セクションのノードグループを選択すると、ノードサブネットを確認できます。
     + 指定するサブネットが、ノードがあるサブネットと同じでない場合は、VPC が[接続](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html)されている必要があり、セキュリティグループで必要なポートが開いていることを確認する必要があります。
   +  ** `securityGroupIds` ** – ファイルシステム用に作成したセキュリティグループの ID。
   +  ** `deploymentType` (オプション)** – ファイルシステムのデプロイのタイプ。有効な値は、`SCRATCH_1`、`SCRATCH_2`、`PERSISTENT_1`、および `PERSISTENT_2` です。デプロイのタイプの詳細については、「[Amazon FSx for Lustre ファイルシステムを作成する](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step1.html)」を参照してください。
   +  **他のパラメータ (オプション)** – 他のパラメータについては、GitHub の「[Edit StorageClass](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass)」(StorageClass の編集) を参照してください。

1. ストレージクラスマニフェストを作成します。

   ```
   kubectl apply -f storageclass.yaml
   ```

   出力例は次のとおりです。

   ```
   storageclass.storage.k8s.io/fsx-sc created
   ```

1. 永続的なボリューム要求マニフェストをダウンロードします。

   ```
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/claim.yaml
   ```

1. (オプション) `claim.yaml` ファイルを編集します。ストレージ要件と前のステップで選択した `deploymentType` に基づいて、`1200Gi` を次のいずれかの増分値に変更します。

   ```
   storage: 1200Gi
   ```
   +  `SCRATCH_2` および `PERSISTENT` – `1.2 TiB`、`2.4 TiB`、または 2.4 TiB を超えると 2.4 TiB の増分。
   +  `SCRATCH_1` – `1.2 TiB`、`2.4 TiB`、`3.6 TiB`、または 3.6 TiB を超えると 3.6 TiB の増分。

1. 永続的なボリューム要求を作成します。

   ```
   kubectl apply -f claim.yaml
   ```

   出力例は次のとおりです。

   ```
   persistentvolumeclaim/fsx-claim created
   ```

1. ファイルシステムがプロビジョニングされていることを確認します。

   ```
   kubectl describe pvc
   ```

   出力例は次のとおりです。

   ```
   Name:          fsx-claim
   Namespace:     default
   StorageClass:  fsx-sc
   Status:        Bound
   [...]
   ```
**注記**  
`Status` は、`Pending` になる前に 5～10 分間 `Bound` と表示されることがあります。`Status` が `Bound` になるまで次のステップに進まないでください。`Status` が 10 分を超えて `Pending` になっている場合は、`Events` 内の警告メッセージを問題に対処するための参考として使用します。

1. サンプルアプリケーションをデプロイします。

   ```
   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml
   ```

1. サンプルアプリケーションが実行中であることを確認します。

   ```
   kubectl get pods
   ```

   出力例は次のとおりです。

   ```
   NAME      READY   STATUS              RESTARTS   AGE
   fsx-app   1/1     Running             0          8s
   ```

1. ファイルシステムがアプリケーションによって正しくマウントされていることを確認します。

   ```
   kubectl exec -ti fsx-app -- df -h
   ```

   出力例は次のとおりです。

   ```
   Filesystem                   Size  Used Avail Use% Mounted on
   overlay                       80G  4.0G   77G   5% /
   tmpfs                         64M     0   64M   0% /dev
   tmpfs                        3.8G     0  3.8G   0% /sys/fs/cgroup
   192.0.2.0@tcp:/abcdef01      1.1T  7.8M  1.1T   1% /data
   /dev/nvme0n1p1                80G  4.0G   77G   5% /etc/hosts
   shm                           64M     0   64M   0% /dev/shm
   tmpfs                        6.9G   12K  6.9G   1% /run/secrets/kubernetes.io/serviceaccount
   tmpfs                        3.8G     0  3.8G   0% /proc/acpi
   tmpfs                        3.8G     0  3.8G   0% /sys/firmware
   ```

1. データがサンプルアプリケーションによって FSx for Lustre ファイルシステムに書き込まれたことを確認します。

   ```
   kubectl exec -it fsx-app -- ls /data
   ```

   出力例は次のとおりです。

   ```
   out.txt
   ```

   この出力例は、サンプルアプリケーションが `out.txt` ファイルをファイルシステムに正常に書き込んだことを示しています。

**注記**  
クラスターを削除する前に FSx for Lustre ファイルシステムを必ず削除してください。詳細については、*FSx for Lustre ユーザーガイド*の「[リソースをクリーンアップする](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step4.html)」を参照してください。

## FSx for Lustre のパフォーマンスチューニング
<a name="_performance_tuning_for_fsx_for_lustre"></a>

Amazon EKS で FSx for Lustre を使用する場合、ノードの初期化中に Lustre のチューニングを適用するとパフォーマンスを最適化できます。推奨されるアプローチは、起動テンプレートのユーザーデータを使用して、すべてのノードで一貫した設定を確保することです。

チューニングの内容は次のとおりです。
+ ネットワークと RPC の最適化
+ Lustre モジュールの管理
+ LRU (ロックリソースユニット) の調整
+ クライアントキャッシュコントロールの設定
+ OST および MDC の RPC コントロール

これらのパフォーマンスチューニングを実装する詳細な手順については、以下を参照してください。
+ 標準ノード (EFA 以外) のパフォーマンスを最適化するには、「[ノードでの Amazon FSx for Lustre のパフォーマンスを最適化する (EFA 以外)](fsx-csi-tuning-non-efa.md)」で起動テンプレートのユーザーデータに追加できる完全なスクリプトを参照してください。
+ EFA 対応ノードのパフォーマンスを最適化するには、「[ノードでの Amazon FSx for Lustre のパフォーマンスを最適化する (EFA)](fsx-csi-tuning-efa.md)」を参照してください。