

 **Aidez à améliorer cette page** 

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Déployez le pilote FSx for Lustre
<a name="fsx-csi-create"></a>

Cette rubrique explique comment déployer le [pilote CSI FSx for Lustre](fsx-csi.md) sur votre cluster Amazon EKS et vérifier qu'il fonctionne. Nous vous recommandons d'utiliser la dernière version du pilote. Pour les versions disponibles, consultez la [matrice de compatibilité des spécifications CSI](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/README.md#csi-specification-compatibility-matrix) sur GitHub.

**Note**  
Le pilote n'est pas pris en charge sur Fargate.

Pour une description détaillée des paramètres disponibles et des exemples complets illustrant les fonctionnalités du pilote, consultez le projet de [pilote FSx pour Lustre Container Storage Interface (CSI)](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) sur GitHub.

## Conditions préalables
<a name="fsx-csi-prereqs"></a>
+ Un cluster existant.
+ Le module complémentaire Amazon FSx CSI Driver EKS prend en charge l'authentification via EKS Pod Identity ou IAM Roles for Service Accounts (IRSA). Pour utiliser EKS Pod Identity, installez l'agent Pod Identity avant ou après le déploiement du module complémentaire FSx CSI Driver. Pour de plus amples informations, veuillez consulter [Configurer l’agent de l’identité du pod Amazon EKS](pod-id-agent-setup.md). Pour utiliser IRSA à la place, voir[Créer un fournisseur d'identité OIDC IAM pour votre cluster](enable-iam-roles-for-service-accounts.md).
+ Version `2.12.3` ou version ultérieure `1.27.160` ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de packages tels que `yum``apt-get`, ou Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*. La version de la AWS CLI installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section [Installation de la AWS CLI dans votre répertoire](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) de base dans le *guide de AWS CloudShell l'utilisateur*.
+ Version `0.215.0` ou ultérieure de l'outil de ligne de commande `eksctl` installée sur votre appareil ou AWS CloudShell. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`.
+ L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est `1.29`, vous pouvez utiliser la version `kubectl` `1.28`, `1.29` ou `1.30`. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).

## Étape 1 : Créer un rôle IAM
<a name="fsx-create-iam-role"></a>

Le plug-in Amazon FSx CSI nécessite des autorisations IAM pour passer des appels en votre AWS APIs nom.

**Note**  
Les pods auront accès aux autorisations attribuées au rôle IAM, sauf si vous bloquez l’accès à IMDS. Pour de plus amples informations, veuillez consulter [Sécuriser les clusters Amazon EKS avec les bonnes pratiques](security-best-practices.md).

La procédure suivante explique comment créer un rôle IAM et y associer la politique AWS gérée.

1. Créez un rôle IAM et associez la politique AWS gérée à l'aide de la commande suivante. Remplacez `my-cluster` par le nom du cluster que vous souhaitez utiliser. La commande déploie une AWS CloudFormation pile qui crée un rôle IAM et y attache la politique IAM.

   ```
   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
   ```

   Vous verrez plusieurs lignes de sortie lorsque le compte de service sera créé. Les dernières lignes de sortie sont similaires à celle de l'exemple suivant.

   ```
   [ℹ]  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"
   ```

   Notez le nom de la AWS CloudFormation pile qui a été déployée. Dans l'exemple de sortie ci-dessus, la pile est nommée `eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa`.

Maintenant que vous avez créé le rôle IAM du pilote Amazon FSx CSI, vous pouvez passer à la section suivante. Lorsque vous déployez le module complémentaire avec ce rôle IAM, il crée et est configuré pour utiliser un compte de service nommé `fsx-csi-controller-sa`. Le compte de service est lié à un Kubernetes `clusterrole` auquel sont attribuées les autorisations Kubernetes requises.

## Étape 2 : Installation du pilote Amazon FSx CSI
<a name="fsx-csi-deploy-driver"></a>

Nous vous recommandons d'installer le pilote Amazon FSx CSI via le module complémentaire Amazon EKS afin d'améliorer la sécurité et de réduire la charge de travail. Pour ajouter un module complémentaire Amazon EKS à votre cluster, voir [Créer un module complémentaire Amazon EKS](creating-an-add-on.md). Pour plus d'informations sur les modules complémentaires, voir [Modules complémentaires Amazon EKS](eks-add-ons.md).

**Important**  
Les installations préexistantes du pilote Amazon FSx CSI dans le cluster peuvent provoquer l'échec de l'installation des modules complémentaires. Lorsque vous tentez d'installer la version complémentaire Amazon EKS alors qu'un pilote FSx CSI autre qu'EKS existe, l'installation échoue en raison de conflits de ressources. Utilisez le drapeau `OVERWRITE` lors de l’installation pour résoudre ce problème.  

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

Sinon, si vous souhaitez une installation autogérée du pilote Amazon FSx CSI, consultez la section [Installation](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/install.md) sur. GitHub

## Étape 3 : déployer une classe de stockage, une demande de volume persistant et un exemple d’application
<a name="fsx-csi-deploy-storage-class"></a>

Cette procédure utilise le GitHub référentiel de [pilotes CSI (FSx for Lustre Container Storage Interface)](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) pour utiliser un volume configuré dynamiquement FSx pour Lustre.

1. Notez le groupe de sécurité de votre cluster. Vous pouvez le voir dans la AWS Management Console section **Mise en réseau** ci-dessous ou en utilisant la commande AWS CLI suivante. Remplacez `my-cluster` par le nom du cluster que vous souhaitez utiliser.

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

1. Créez un groupe de sécurité pour votre système de FSx fichiers Amazon conformément aux critères indiqués dans la section [Groupes de sécurité Amazon VPC](https://docs.aws.amazon.com/fsx/latest/LustreGuide/limit-access-security-groups.html#fsx-vpc-security-groups) du guide de l'utilisateur Amazon FSx for Lustre. Pour le **VPC**, sélectionnez le VPC de votre cluster, comme indiqué dans la section **Mise en réseau**. Pour « les groupes de sécurité associés à vos clients Lustre », utilisez le groupe de sécurité de votre cluster. Vous pouvez juste laisser les règles sortantes pour autoriser **Tout le trafic**.

1. Téléchargez le manifeste de la classe de stockage à l'aide de la commande suivante.

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

1. Modifiez la section des paramètres du fichier `storageclass.yaml`. Remplacez chaque valeur d’exemple par vos propres valeurs.

   ```
   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`**— L'ID de sous-réseau dans lequel le système de fichiers Amazon FSx for Lustre doit être créé. Amazon FSx for Lustre n'est pas pris en charge dans toutes les zones de disponibilité. Ouvrez la console Amazon FSx for Lustre https://console.aws.amazon.com/fsx/ à l'adresse pour vérifier que le sous-réseau que vous souhaitez utiliser se trouve dans une zone de disponibilité prise en charge. Le sous-réseau peut inclure vos nœuds, ou peut être un sous-réseau ou un VPC différent.
     + Vous pouvez vérifier la présence des sous-réseaux de nœuds dans le en AWS Management Console sélectionnant le groupe de nœuds dans la section **Calculer**.
     + Si le sous-réseau que vous spécifiez n'est pas le même que celui dans lequel vous avez des nœuds, vous VPCs devez être [connecté](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html) et vous assurer que les ports nécessaires sont ouverts dans vos groupes de sécurité.
   +  ** `securityGroupIds` ** : l’ID du groupe de sécurité que vous avez créé pour le système de fichiers.
   +  ** `deploymentType` (facultatif)** : le type de déploiement du système de fichiers. Les valeurs valides sont `SCRATCH_1`, `SCRATCH_2`, `PERSISTENT_1` et `PERSISTENT_2`. Pour plus d'informations sur les types de déploiement, consultez [Créer votre système de fichiers Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step1.html).
   +  **autres paramètres (facultatif)** — Pour plus d'informations sur les autres paramètres, voir [Modifier StorageClass](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass) sur GitHub.

1. Créez le manifeste de la classe de stockage.

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

   L'exemple qui suit illustre un résultat.

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

1. Téléchargez le manifeste de revendication de volume persistant.

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

1. (Facultatif) Modifiez le fichier `claim.yaml`. Remplacez `1200Gi` par l'une des valeurs d'incrément ci-dessous, en fonction de vos besoins de stockage et du `deploymentType` que vous avez sélectionné à l'étape précédente.

   ```
   storage: 1200Gi
   ```
   +  `SCRATCH_2` et `PERSISTENT` – `1.2 TiB`, `2.4 TiB` ou des incréments de 2,4 Tio au-dessus de 2,4 Tio.
   +  `SCRATCH_1` – `1.2 TiB`, `2.4 TiB`, `3.6 TiB` ou des incréments de 3,6 Tio au-dessus de 3,6 Tio.

1. Créez la revendication de volume persistant.

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

   L'exemple qui suit illustre un résultat.

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

1. Vérifiez que le système de fichiers est approvisionné.

   ```
   kubectl describe pvc
   ```

   L'exemple qui suit illustre un résultat.

   ```
   Name:          fsx-claim
   Namespace:     default
   StorageClass:  fsx-sc
   Status:        Bound
   [...]
   ```
**Note**  
Le `Status` peut indiquer `Pending` pendant 5-10 minutes avant de devenir `Bound`. Ne passez pas à l’étape suivante tant que le `Status` n’est pas `Bound`. Si le `Status` affiche `Pending` pendant plus de 10 minutes, utilisez des messages d'avertissement dans les `Events` comme référence afin de résoudre tout problème.

1. Déployez un exemple d'application

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

1. Vérifiez que l'exemple d'application est en cours d'exécution.

   ```
   kubectl get pods
   ```

   L'exemple qui suit illustre un résultat.

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

1. Vérifiez que le système de fichiers est correctement monté par l'application.

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

   L'exemple qui suit illustre un résultat.

   ```
   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. Vérifiez que les données ont été écrites dans le système de fichiers FSx for Lustre par l'exemple d'application.

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

   L'exemple qui suit illustre un résultat.

   ```
   out.txt
   ```

   Cet exemple de sortie signifie que l'exemple d'application a réussi à écrire le fichier `out.txt` dans le système de fichiers.

**Note**  
Avant de supprimer le cluster, assurez-vous de supprimer le système de fichiers FSx for Lustre. Pour plus d'informations, consultez les [ressources de nettoyage](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step4.html) dans le *guide de l'utilisateur de FSx for Lustre*.

## Optimisation des performances FSx pour Lustre
<a name="_performance_tuning_for_fsx_for_lustre"></a>

Lorsque vous utilisez FSx for Lustre avec Amazon EKS, vous pouvez optimiser les performances en appliquant les réglages Lustre lors de l'initialisation du nœud. L’approche recommandée consiste à utiliser les données utilisateur du modèle de lancement afin de garantir une configuration cohérente sur tous les nœuds.

Ces accordages comprennent :
+ Optimisations du réseau et du RPC
+ Gestion du module Lustre
+ Réglages LRU (Lock Resource Unit)
+ Paramètres de contrôle du cache client
+ Commandes RPC pour OST et MDC

Pour obtenir des instructions détaillées sur la mise en œuvre de ces réglages de performance :
+ Pour optimiser les performances des nœuds standard (non EFA), consultez [Optimisez les performances FSx d'Amazon for Lustre sur les nœuds (non EFA)](fsx-csi-tuning-non-efa.md) pour obtenir le script complet qui peut être ajouté aux données utilisateur de votre modèle de lancement.
+ Pour optimiser les performances des nœuds compatibles EFA, consultez [Optimisez les performances FSx d'Amazon for Lustre sur les nœuds (EFA)](fsx-csi-tuning-efa.md).