**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.
# Utiliser le stockage de données d’application pour votre cluster
Vous pouvez utiliser une gamme de services de AWS stockage avec Amazon EKS pour répondre aux besoins de stockage de vos applications. Grâce à un large éventail de pilotes d'interface de stockage de conteneurs (CSI) pris en AWS charge, vous pouvez facilement utiliser Amazon EBS, Amazon S3, Amazon EFS, Amazon FSX et Amazon File Cache pour répondre aux besoins de stockage de vos applications exécutées sur Amazon EKS. Pour gérer les sauvegardes de votre cluster Amazon EKS, consultez la section [Support AWS de sauvegarde pour Amazon EKS](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-supported-services.html#working-with-eks).
Ce chapitre couvre les options de stockage pour les clusters Amazon EKS.
**Topics**
+ [Utilisez le stockage de volumes Kubernetes avec Amazon EBS](ebs-csi.md)
+ [Utilisation du stockage en système de fichiers Elastic avec Amazon EFS](efs-csi.md)
+ [Utilisez un stockage d’applications haute performance avec Amazon FSx pour Lustre](fsx-csi.md)
+ [Utilisez un stockage d’applications haute performance avec FSx pour NetApp ONTAP](fsx-ontap.md)
+ [Utilisez le stockage de données avec Amazon FSx pour OpenZFS](fsx-openzfs-csi.md)
+ [Minimisez le temps de latence avec Amazon File Cache](file-cache-csi.md)
+ [Accéder aux objets Amazon S3 avec le pilote CSI Mountpoint pour Amazon S3](s3-csi.md)
+ [Activer la fonctionnalité d’instantané pour les volumes CSI](csi-snapshot-controller.md)
# Utilisez le stockage de volumes Kubernetes avec Amazon EBS
**Note**
**Nouveau :** le mode automatique Amazon EKS automatise les tâches de routine pour le stockage par blocs. Découvrez comment [Déployer un exemple de charge de travail avec état dans le mode automatique EKS](sample-storage-workload.md).
Le [pilote CSI (Container Storage Interface) Amazon Elastic Block Store (Amazon EBS)](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/) gère le cycle de vie des volumes Amazon EBS en tant que stockage pour les volumes Kubernetes que vous créez. Le pilote CSI Amazon EBS crée des volumes Amazon EBS pour ces types de volumes Kubernetes : [volumes éphémères](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) génériques et [volumes persistants](https://kubernetes.io/docs/concepts/storage/persistent-volumes/).
## Considérations
+ Il n’est pas nécessaire d’installer le contrôleur CSI Amazon EBS sur les clusters du mode automatique EKS.
+ Vous ne pouvez pas monter des volumes Amazon EBS sur des pods Fargate.
+ Vous pouvez exécuter le contrôleur CSI Amazon EBS sur les nœuds Fargate, mais le nœud CSI `DaemonSet` Amazon EBS ne peut fonctionner que sur des instances Amazon EC2.
+ Les volumes Amazon EBS et le pilote CSI Amazon EBS ne sont pas compatibles avec les nœuds hybrides Amazon EKS.
+ Une assistance sera fournie pour la dernière version complémentaire et la version précédente. Les correctifs de bogues ou de vulnérabilités découverts dans la dernière version seront rétroportés vers la version précédente en tant que nouvelle version mineure.
+ Le mode automatique EKS nécessite des classes de stockage pour utiliser `ebs.csi.eks.amazonaws.com` comme provisionneur. Le pilote Amazon EBS CSI standard (`ebs.csi.aws.com`) gère ses propres volumes séparément. Pour utiliser les volumes existants avec le mode automatique EKS, migrez-les à l’aide de snapshots de volume vers une classe de stockage qui utilise le provisionneur en mode automatique.
**Important**
Pour utiliser la fonctionnalité de snapshot du pilote CSI Amazon EBS, vous devez d’abord installer le contrôleur de snapshot CSI. Pour de plus amples informations, veuillez consulter [Activer la fonctionnalité d’instantané pour les volumes CSI](csi-snapshot-controller.md).
## Conditions préalables
+ Un cluster existant. Pour afficher la version requise de la plateforme, exécutez la commande suivante.
```
aws eks describe-addon-versions --addon-name aws-ebs-csi-driver
```
+ Le pilote EBS CSI a besoin d'autorisations AWS IAM.
+ AWS suggère d'utiliser EKS Pod Identities. Pour de plus amples informations, veuillez consulter [Présentation de la configuration des identités du pod EKS](pod-identities.md#pod-id-setup-overview).
+ Pour plus d’informations sur les rôles IAM pour les comptes de service, consultez [Créer un fournisseur d'identité OIDC IAM pour votre cluster](enable-iam-roles-for-service-accounts.md).
## Étape 1 : Créer un rôle IAM
Le plug-in Amazon EBS CSI nécessite des autorisations IAM pour passer des appels en votre AWS APIs nom. Si vous ne suivez pas ces étapes, la tentative d’installation et d’exécution de `kubectl describe pvc` affichera `failed to provision volume with StorageClass` et s’accompagnera d’une erreur `could not create volume in EC2: UnauthorizedOperation`. Pour plus d'informations, consultez [Configuration de l'autorisation du pilote](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#set-up-driver-permissions) sur GitHub.
**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. Pour mettre en œuvre cette procédure, vous pouvez utiliser l’un des outils suivants :
+ [`eksctl`](#eksctl_store_app_data)
+ [AWS Management Console](#console_store_app_data)
+ [AWS CLI](#awscli_store_app_data)
**Note**
Vous pouvez créer une politique autogérée avec des autorisations limitées. Vérifiez [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html) et créez une politique IAM personnalisée avec des autorisations réduites.
**Note**
Les étapes spécifiques de cette procédure sont destinées à l'utilisation du pilote en tant que module complémentaire d'Amazon EKS. Différentes étapes sont nécessaires pour utiliser le pilote en tant que module complémentaire autogéré. Pour plus d'informations, voir [Configurer les autorisations du conducteur](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#set-up-driver-permissions) sur GitHub.
### `eksctl`
1. Créez un rôle IAM et associez une politique. AWS gère une politique AWS gérée ou vous pouvez créer votre propre politique personnalisée. Vous pouvez créer un rôle IAM et associer la politique AWS gérée à l'aide de la commande suivante. Remplacez *my-cluster* par le nom de votre cluster. 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 ebs-csi-controller-sa \
--namespace kube-system \
--cluster my-cluster \
--role-name AmazonEKS_EBS_CSI_DriverRole \
--role-only \
--attach-policy-arn arn:aws: iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
--approve
```
1. Vous pouvez ignorer cette étape si vous n’utilisez pas de [clé KMS](https://aws.amazon.com/kms/) personnalisée. Si vous en utilisez un pour le chiffrement sur vos volumes Amazon EBS, personnalisez le rôle IAM selon vos besoins. Par exemple, procédez comme suit :
1. Copiez et collez le code suivant dans un nouveau fichier `kms-key-for-encryption-on-ebs.json`. Remplacez *custom-key-arn* par l'[ARN de clé KMS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key) personnalisé.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"]
}
]
}
```
1. Créez la politique. Vous pouvez remplacer *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* par un autre nom. Cependant, si vous le remplacez, assurez-vous de le remplacer également dans les étapes suivantes.
```
aws iam create-policy \
--policy-name KMS_Key_For_Encryption_On_EBS_Policy \
--policy-document file://kms-key-for-encryption-on-ebs.json
```
1. Attachez la politique IAM au rôle à l'aide de la commande suivante. Remplacez *111122223333* par votre ID de compte.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::111122223333:policy/KMS_Key_For_Encryption_On_EBS_Policy \
--role-name AmazonEKS_EBS_CSI_DriverRole
```
### AWS Management Console
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Sur la page **Rôles**, choisissez **Créer un rôle**.
1. Sur la page **Select trusted entity** (Sélectionnez une entité de confiance), procédez comme suit :
1. Dans la section **Trusted entity type** (Type d'entité de confiance), sélectionnez **Web identity** (Identité web).
1. Pour **Fournisseur d'identité**, choisissez l'**URL du fournisseur OpenID Connect** pour votre cluster (comme indiqué sous **Présentation** dans Amazon EKS).
1. Pour **Audience**, choisissez `sts.amazonaws.com`.
1. Choisissez **Suivant**.
1. Sur la page **Add permissions** (Ajouter des autorisations), procédez comme suit :
1. Dans la zone **Filter policies** (Politiques de filtre), saisissez `AmazonEBSCSIDriverPolicy`.
1. Cochez la case à gauche du `AmazonEBSCSIDriverPolicy` renvoyé dans la recherche.
1. Choisissez **Suivant**.
1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), procédez comme suit :
1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, *AmazonEKS\$1EBS\$1CSI\$1DriverRole*.
1. Sous **Ajouter des balises (Facultatif)**, ajoutez des métadonnées au rôle en attachant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez la rubrique [Balisage des ressources IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le *Guide de l'utilisateur IAM*.
1. Choisissez **Créer un rôle**.
1. Une fois le rôle créé, choisissez le rôle dans la console pour l'ouvrir et le modifier.
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la politique d'approbation).
1. Trouvez la ligne qui ressemble à la ligne suivante :
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
```
Ajoutez une virgule à la fin de la ligne précédente, puis ajoutez la ligne suivante après la ligne précédente. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. Remplacez *EXAMPLED539D4633E53DE1B71EXAMPLE* par l’ID du fournisseur OIDC de votre cluster.
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"
```
1. Sélectionnez **Update Trust Policy** (Mettre à jour la politique d'approbation) pour terminer.
1. Si vous utilisez une [clé KMS](https://aws.amazon.com/kms/) personnalisée pour le chiffrement de vos volumes Amazon EBS, personnalisez le rôle IAM en fonction des besoins. Par exemple, procédez comme suit :
1. Dans le volet de navigation de gauche, choisissez **Politiques**.
1. Sur la page **Politiques**, choisissez **Créer une politique**.
1. Sur la page **Créer une politique**, choisissez l'onglet **JSON**.
1. Copiez et collez le code suivant dans l'éditeur, en remplaçant *custom-key-arn* par l'[ARN de clé KMS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key) personnalisée.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"]
}
]
}
```
1. Choisissez **Suivant : Balises**.
1. Sur la page **Ajouter des balises (facultatif)**, choisissez **Suivant : Vérifier**.
1. Dans **Nom**, attribuez un nom unique à votre politique (par exemple *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy*).
1. Choisissez **Create Policy** (Créer une politique).
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Choisissez le ***AmazonEKS\$1EBS\$1CSI\$1DriverRole***dans la console pour l'ouvrir en vue de le modifier.
1. Dans la liste déroulante **Ajouter des autorisations**, choisissez **Associer des politiques**.
1. Dans la zone **Filter policies** (Politiques de filtre), saisissez *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy*.
1. Cochez la case à gauche du *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* renvoyé dans la recherche.
1. Choisissez **Attacher des politiques**.
### AWS CLI
1. Affichez l’URL du fournisseur OIDC de votre cluster. Remplacez *my-cluster* par le nom de votre cluster. Si la sortie de la commande est `None`, consultez **Prérequis**.
```
aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text
```
L'exemple qui suit illustre un résultat.
```
https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
```
1. Créez le rôle IAM et attachez-y l'action `AssumeRoleWithWebIdentity`.
1. Copiez le contenu suivant dans un fichier nommé `aws-ebs-csi-driver-trust-policy.json`. Remplacez *111122223333* par votre ID de compte. Remplacez *EXAMPLED539D4633E53DE1B71EXAMPLE* et *region-code* par les valeurs renvoyées par l'étape précédente.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"
}
}
}
]
}
```
1. Créez le rôle. Vous pouvez remplacer *AmazonEKS\$1EBS\$1CSI\$1DriverRole* par un autre nom. Si vous le remplacez, assurez-vous de le remplacer dans les étapes suivantes.
```
aws iam create-role \
--role-name AmazonEKS_EBS_CSI_DriverRole \
--assume-role-policy-document file://"aws-ebs-csi-driver-trust-policy.json"
```
1. Joignez une politique. AWS gère une politique AWS gérée ou vous pouvez créer votre propre politique personnalisée. Attachez la politique AWS gérée au rôle à l'aide de la commande suivante.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
--role-name AmazonEKS_EBS_CSI_DriverRole
```
1. Si vous utilisez une [clé KMS](https://aws.amazon.com/kms/) personnalisée pour le chiffrement de vos volumes Amazon EBS, personnalisez le rôle IAM en fonction des besoins. Par exemple, procédez comme suit :
1. Copiez et collez le code suivant dans un nouveau fichier `kms-key-for-encryption-on-ebs.json`. Remplacez *custom-key-arn* par l'[ARN de clé KMS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key) personnalisé.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"]
}
]
}
```
1. Créez la politique. Vous pouvez remplacer *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* par un autre nom. Cependant, si vous le remplacez, assurez-vous de le remplacer également dans les étapes suivantes.
```
aws iam create-policy \
--policy-name KMS_Key_For_Encryption_On_EBS_Policy \
--policy-document file://kms-key-for-encryption-on-ebs.json
```
1. Attachez la politique IAM au rôle à l'aide de la commande suivante. Remplacez *111122223333* par votre ID de compte.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::111122223333:policy/KMS_Key_For_Encryption_On_EBS_Policy \
--role-name AmazonEKS_EBS_CSI_DriverRole
```
Maintenant que vous avez créé le rôle IAM du pilote CSI Amazon EBS, 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é `ebs-csi-controller-sa`. Le compte de service est lié à un Kubernetes `clusterrole` auquel sont attribuées les autorisations Kubernetes requises.
## Étape 2 : obtenir le pilote CSI Amazon EBS
Nous vous recommandons d’installer le pilote Amazon EBS 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**
Avant d’ajouter le pilote Amazon EBS en tant que module complémentaire Amazon EKS, vérifiez qu’aucune version autogérée du pilote n’est déjà installée sur votre cluster. Si c'est le cas, voir [Désinstallation d'un pilote CSI Amazon EBS autogéré](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#uninstalling-the-ebs-csi-driver) sur GitHub.
**Note**
Par défaut, le rôle RBAC utilisé par le CSI EBS est autorisé à muter les nœuds afin de prendre en charge sa fonction de suppression des taches. En raison des limites de Kubernetes RBAC, cela lui permet également de muter n'importe quel autre nœud du cluster. Le graphique Helm comporte un paramètre (`node.serviceAccount.disableMutation`) qui désactive la mutation des autorisations RBAC des nœuds pour le ebs-csi-node compte de service. Lorsqu'elles sont activées, les fonctionnalités du pilote telles que la suppression des taches ne fonctionneront pas.
[Sinon, si vous souhaitez une installation autogérée du pilote Amazon EBS CSI, consultez la section Installation sur.](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) GitHub
## Étape 3 : déployer un exemple d’application
Vous pouvez déployer une variété d'applications types et les modifier selon vos besoins. Pour plus d'informations, consultez les exemples de [Kubernetes sur.](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes) GitHub
# Utilisation du stockage en système de fichiers Elastic avec Amazon EFS
[Amazon Elastic File System](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) (Amazon EFS) fournit un stockage de fichiers entièrement élastique sans serveur pour vous permettre de partager des données de fichiers sans provisionner ni gérer la capacité et les performances de stockage. Le [pilote Amazon EFS Container Storage Interface (CSI)](https://github.com/kubernetes-sigs/aws-efs-csi-driver) fournit une interface CSI qui permet aux clusters Kubernetes exécutés de gérer le cycle de vie des AWS systèmes de fichiers Amazon EFS. Cette rubrique vous montre comment déployer le pilote Amazon EFS CSI dans votre cluster Amazon EKS.
## Considérations
+ Le pilote Amazon EFS CSI n’est pas compatible avec les images de conteneurs basées sur Windows.
+ Vous ne pouvez pas utiliser [l’approvisionnement dynamique](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) pour les volumes persistants avec les nœuds Fargate, mais vous pouvez utiliser [l’approvisionnement statique](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md).
+ [L’approvisionnement dynamique](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) nécessite la version [1.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v12) ou ultérieure du pilote. Vous pouvez utiliser [l’approvisionnement statique](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md) pour les volumes persistants à l’aide de la version `1.1` du pilote sur n’importe quelle version de cluster Amazon EKS prise en charge (voir Versions [Amazon EKS prises en charge](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)).
+ La version [1.3.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v132) ou ultérieure de ce pilote prend en charge l'architecture Arm64, y compris les instances basées sur Amazon EC2 Graviton.
+ Les versions [1.4.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v142) et ultérieures de ce pilote prennent en charge l’utilisation de FIPS pour le montage de systèmes de fichiers.
+ Prenez note des quotas de ressources pour Amazon EFS. Par exemple, un quota de 1 000 points d’accès peut être créé pour chaque système de fichiers Amazon EFS. Pour plus d'informations, consultez les [quotas de ressources Amazon EFS que vous ne pouvez pas modifier](https://docs.aws.amazon.com/efs/latest/ug/limits.html#limits-efs-resources-per-account-per-region).
+ À partir de la version [2.0.0](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-2.x.md#v200), ce pilote est passé de l’utilisation de `stunnel` à celle de `efs-proxy` pour les connexions TLS. Lorsque `efs-proxy` est utilisé, il ouvre un nombre de threads égal à un plus le nombre de cœurs pour le nœud sur lequel il s’exécute.
+ Le pilote CSI Amazon EFS n’est pas compatible avec les nœuds Amazon EKS.
## Conditions préalables
+ Le pilote Amazon EFS CSI nécessite des autorisations AWS Identity and Access Management (IAM).
+ AWS suggère d'utiliser EKS Pod Identities. Pour de plus amples informations, veuillez consulter [Présentation de la configuration des identités du pod EKS](pod-identities.md#pod-id-setup-overview).
+ Pour plus d’informations sur les rôles IAM pour les comptes de service et la configuration d’un fournisseur IAM OpenID Connect (OIDC) pour votre cluster, consultez [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` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` 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*.
+ 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).
**Note**
Un Pod fonctionnant sur Fargate monte automatiquement un système de fichiers Amazon EFS, sans nécessiter d’étapes manuelles d’installation de pilotes.
## Étape 1 : Créer un rôle IAM
Le pilote CSI Amazon EFS nécessite des autorisations IAM pour interagir avec votre système de fichiers. Créez un rôle IAM et associez-y la politique AWS gérée requise. Pour mettre en œuvre cette procédure, vous pouvez utiliser l’un des outils suivants :
+ [`eksctl`](#eksctl_efs_store_app_data)
+ [AWS Management Console](#console_efs_store_app_data)
+ [AWS CLI](#awscli_efs_store_app_data)
**Note**
Les étapes spécifiques de cette procédure sont destinées à l'utilisation du pilote en tant que module complémentaire d'Amazon EKS. Pour plus de détails sur les installations autogérées, voir [Configurer l'autorisation du pilote](https://github.com/kubernetes-sigs/aws-efs-csi-driver#set-up-driver-permission) sur GitHub.
### `eksctl`
#### Si vous utilisez les identités du pod
Exécutez les commandes suivantes pour créer un rôle IAM et une association d’identité de pod avec `eksctl`. Remplacez `my-cluster` par le nom de votre cluster. Vous pouvez aussi remplacer `AmazonEKS_EFS_CSI_DriverRole` par un nom différent.
```
export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
eksctl create podidentityassociation \
--service-account-name efs-csi-controller-sa \
--namespace kube-system \
--cluster $cluster_name \
--role-name $role_name \
--permission-policy-arns arn:aws: iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy
```
#### Si vous utilisez des rôles IAM pour des comptes de service
Exécutez les commandes suivantes pour créer un rôle IAM avec `eksctl`. Remplacez `my-cluster` par le nom de votre cluster. Vous pouvez aussi remplacer `AmazonEKS_EFS_CSI_DriverRole` par un nom différent.
```
export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
eksctl create iamserviceaccount \
--name efs-csi-controller-sa \
--namespace kube-system \
--cluster $cluster_name \
--role-name $role_name \
--role-only \
--attach-policy-arn arn:aws: iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--approve
TRUST_POLICY=$(aws iam get-role --output json --role-name $role_name --query 'Role.AssumeRolePolicyDocument' | \
sed -e 's/efs-csi-controller-sa/efs-csi-*/' -e 's/StringEquals/StringLike/')
aws iam update-assume-role-policy --role-name $role_name --policy-document "$TRUST_POLICY"
```
### AWS Management Console
Exécutez la commande suivante pour créer un rôle IAM avec AWS Management Console.
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Sur la page **Rôles**, choisissez **Créer un rôle**.
1. Sur la page **Select trusted entity** (Sélectionner une entité de confiance), procédez comme suit :
1. Si vous utilisez les identités de pod EKS :
1. Dans la section **Type d'entité fiable**, sélectionnez ** AWS service**.
1. Dans le menu déroulant **Service ou cas d’utilisation**, sélectionnez **EKS**.
1. Dans la section **Cas d’utilisation**, sélectionnez **EKS – Identité du pod**.
1. Choisissez **Suivant**.
1. Si vous utilisez des rôles IAM pour des comptes de service :
1. Dans la section **Trusted entity type** (Type d'entité de confiance), sélectionnez **Web identity** (Identité web).
1. Pour **Fournisseur d'identité**, choisissez l'**URL du fournisseur OpenID Connect** pour votre cluster (comme indiqué sous **Présentation** dans Amazon EKS).
1. Pour **Audience**, choisissez `sts.amazonaws.com`.
1. Choisissez **Suivant**.
1. Sur la page **Add permissions** (Ajouter des autorisations), procédez comme suit :
1. Dans la zone **Filter policies** (Politiques de filtre), saisissez `AmazonEFSCSIDriverPolicy`.
1. Cochez la case à gauche du `AmazonEFSCSIDriverPolicy` renvoyé dans la recherche.
1. Choisissez **Suivant**.
1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), procédez comme suit :
1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, `AmazonEKS_EFS_CSI_DriverRole`.
1. Sous **Ajouter des balises (Facultatif)**, ajoutez des métadonnées au rôle en attachant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez la rubrique [Balisage des ressources IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le *Guide de l'utilisateur IAM*.
1. Choisissez **Créer un rôle**.
1. Une fois le rôle créé :
1. Si vous utilisez les identités de pod EKS :
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer l’association d’identité de pod EKS.
1. Choisissez l’onglet **Access**.
1. Dans **Associations d’identité du pod**, sélectionnez **Créer**.
1. Choisissez la liste déroulante du **rôle IAM** et sélectionnez le rôle que vous venez de créer.
1. Sélectionnez le champ **Espace de noms Kubernetes** et saisissez `kube-system`.
1. Sélectionnez le champ **Compte de service Kubernetes** et saisissez `efs-csi-controller-sa`.
1. Choisissez **Créer**.
1. Pour plus d’informations sur la création d’associations d’identités de pod, consultez [Création d'une association Pod Identity (AWS console)](pod-id-association.md#pod-id-association-create).
1. Si vous utilisez des rôles IAM pour des comptes de service :
1. Choisissez le rôle pour l’ouvrir en vue de le modifier.
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la politique d'approbation).
1. Trouvez la ligne qui ressemble à la ligne suivante :
```
"oidc.eks.region-code.amazonaws.com/id/:aud": "sts.amazonaws.com"
```
Ajoutez la ligne suivante au-dessus de la ligne précédente. Remplacez `` par la AWS région dans laquelle se trouve votre cluster. Remplacez `` par l’ID du fournisseur OIDC de votre cluster.
```
"oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount:kube-system:efs-csi-*",
```
1. Modifiez l'opérateur `Condition` de `"StringEquals"` en `"StringLike"`.
1. Sélectionnez **Update Trust Policy** (Mettre à jour la politique d'approbation) pour terminer.
### AWS CLI
Exécutez les commandes suivantes pour créer un rôle IAM avec la AWS CLI.
#### Si vous utilisez les identités du pod
1. Créez le rôle IAM qui accorde les actions `AssumeRole` et `TagSession` au service `pods.eks.amazonaws.com`.
1. Copiez le contenu suivant dans un fichier nommé `aws-efs-csi-driver-trust-policy-pod-identity.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Créez le rôle. Remplacez `my-cluster` par le nom de votre cluster. Vous pouvez aussi remplacer `AmazonEKS_EFS_CSI_DriverRole` par un nom différent.
```
export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
aws iam create-role \
--role-name $role_name \
--assume-role-policy-document file://"aws-efs-csi-driver-trust-policy-pod-identity.json"
```
1. Associez la politique AWS gérée requise au rôle à l'aide de la commande suivante.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--role-name $role_name
```
1. Exécutez la commande suivante pour créer l’association d’identité de pod. Remplacer ` arn:aws: iam::<111122223333>:role/my-role` par le rôle créé lors des étapes précédentes.
```
aws eks create-pod-identity-association --cluster-name $cluster_name --role-arn {arn-aws}iam::<111122223333>:role/my-role --namespace kube-system --service-account efs-csi-controller-sa
```
1. Pour plus d’informations sur la création d’associations d’identités de pod, consultez [Création d'une association Pod Identity (AWS console)](pod-id-association.md#pod-id-association-create).
#### Si vous utilisez des rôles IAM pour des comptes de service
1. Affichez l’URL du fournisseur OIDC de votre cluster. Remplacez `my-cluster` par le nom de votre cluster. Vous pouvez aussi remplacer `AmazonEKS_EFS_CSI_DriverRole` par un nom différent.
```
export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text
```
L'exemple qui suit illustre un résultat.
```
https://oidc.eks..amazonaws.com/id/
```
Si la sortie de la commande est `None`, consultez **Prérequis**.
1. Créez le rôle IAM qui accorde l'action `AssumeRoleWithWebIdentity`.
1. Copiez le contenu suivant dans un fichier nommé `aws-efs-csi-driver-trust-policy.json`. Remplacez `<111122223333>` par votre ID de compte. Remplacez `` et `` par les valeurs renvoyées par l'étape précédente.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:efs-csi-*",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. Créez le rôle.
```
aws iam create-role \
--role-name $role_name \
--assume-role-policy-document file://"aws-efs-csi-driver-trust-policy.json"
```
1. Associez la politique AWS gérée requise au rôle à l'aide de la commande suivante.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--role-name $role_name
```
## Étape 2 : obtenir le pilote CSI Amazon EFS
Nous vous recommandons d'installer le pilote CSI Amazon EFS en utilisant le module complémentaire Amazon EKS. 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). Si vous ne parvenez pas à utiliser le module complémentaire Amazon EKS, nous vous encourageons à signaler les raisons pour lesquelles vous ne pouvez pas utiliser le module complémentaire Amazon EKS dans le [ GitHub référentiel de feuilles de route pour les conteneurs](https://github.com/aws/containers-roadmap/issues).
**Important**
Avant d’ajouter le pilote Amazon EFS en tant que module complémentaire Amazon EKS, vérifiez qu’aucune version autogérée du pilote n’est déjà installée sur votre cluster. Dans ce cas, consultez la section [Désinstallation du pilote Amazon EFS CSI](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#uninstalling-the-amazon-efs-csi-driver) sur. GitHub
Sinon, si vous souhaitez une installation autogérée du pilote CSI Amazon EFS, voir [Installation](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#installation) sur GitHub.
## Étape 3 : Créer un système de fichiers Amazon EFS
Pour créer un système de fichiers Amazon EFS, voir [Création d'un système de fichiers Amazon EFS pour Amazon EKS](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/efs-create-filesystem.md) sur GitHub.
## Étape 4 : déployer un exemple d’application
Vous pouvez déployer une variété d'applications types et les modifier selon vos besoins. Pour plus d'informations, consultez la section [Exemples](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#examples) sur GitHub.
# Utilisez un stockage d’applications haute performance avec Amazon FSx pour Lustre
Le [pilote Container Storage Interface (CSI) Amazon FSx pour Lustre](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) fournit une interface CSI qui permet aux clusters Amazon EKS de gérer le cycle de vie des systèmes de fichiers Amazon FSx pour Lustre. Pour plus d’informations, consultez le [Guide de l’utilisateur Amazon FSx pour Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html).
Pour plus d’informations sur le déploiement du pilote CSI Amazon FSx pour Lustre sur votre cluster Amazon EKS et la vérification de son bon fonctionnement, consultez [Déployez le pilote FSx for Lustre](fsx-csi-create.md).
# Déployez le pilote FSx for Lustre
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 ou sur les nœuds hybrides Amazon EKS.
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
+ Un cluster existant.
+ Le module complémentaire Amazon FSx CSI Driver EKS nécessite l'agent EKS Pod Identity pour l'authentification. Sans ce composant, le module complémentaire échouera avec l’erreur `Amazon EKS Pod Identity agent is not installed in the cluster`, empêchant les opérations sur le volume. 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).
+ 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` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` 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
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
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
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
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).
# Optimisez les performances FSx d'Amazon for Lustre sur les nœuds (EFA)
Cette rubrique explique comment configurer le réglage d'Elastic Fabric Adapter (EFA) avec Amazon EKS et FSx Amazon for Lustre.
**Note**
Pour plus d'informations sur la création et le déploiement du pilote CSI FSx for Lustre, consultez[Déployez le pilote FSx for Lustre](fsx-csi-create.md).
Pour optimiser les nœuds standard sans EFA, voir [Optimisez les performances FSx d'Amazon for Lustre sur les nœuds (non EFA)](fsx-csi-tuning-non-efa.md).
## Étape 1. Créer un cluster EKS
Créez un cluster à l’aide du fichier de configuration fourni :
```
# Create cluster using efa-cluster.yaml
eksctl create cluster -f efa-cluster.yaml
```
Exemple `efa-cluster.yaml` :
```
#efa-cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: csi-fsx
region: us-east-1
version: "1.30"
iam:
withOIDC: true
availabilityZones: ["us-east-1a", "us-east-1d"]
managedNodeGroups:
- name: my-efa-ng
instanceType: c6gn.16xlarge
minSize: 1
desiredCapacity: 1
maxSize: 1
availabilityZones: ["us-east-1b"]
volumeSize: 300
privateNetworking: true
amiFamily: Ubuntu2204
efaEnabled: true
preBootstrapCommands:
- |
#!/bin/bash
eth_intf="$(/sbin/ip -br -4 a sh | grep $(hostname -i)/ | awk '{print $1}')"
efa_version=$(modinfo efa | awk '/^version:/ {print $2}' | sed 's/[^0-9.]//g')
min_efa_version="2.12.1"
if [[ "$(printf '%s\n' "$min_efa_version" "$efa_version" | sort -V | head -n1)" != "$min_efa_version" ]]; then
sudo curl -O https://efa-installer.amazonaws.com/aws-efa-installer-1.37.0.tar.gz
tar -xf aws-efa-installer-1.37.0.tar.gz && cd aws-efa-installer
echo "Installing EFA driver"
sudo apt-get update && apt-get upgrade -y
sudo apt install -y pciutils environment-modules libnl-3-dev libnl-route-3-200 libnl-route-3-dev dkms
sudo ./efa_installer.sh -y
modinfo efa
else
echo "Using EFA driver version $efa_version"
fi
echo "Installing Lustre client"
sudo wget -O - https://fsx-lustre-client-repo-public-keys.s3.amazonaws.com/fsx-ubuntu-public-key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/fsx-ubuntu-public-key.gpg > /dev/null
sudo echo "deb [signed-by=/usr/share/keyrings/fsx-ubuntu-public-key.gpg] https://fsx-lustre-client-repo.s3.amazonaws.com/ubuntu jammy main" > /etc/apt/sources.list.d/fsxlustreclientrepo.list
sudo apt update | tail
sudo apt install -y lustre-client-modules-$(uname -r) amazon-ec2-utils | tail
modinfo lustre
echo "Loading Lustre/EFA modules..."
sudo /sbin/modprobe lnet
sudo /sbin/modprobe kefalnd ipif_name="$eth_intf"
sudo /sbin/modprobe ksocklnd
sudo lnetctl lnet configure
echo "Configuring TCP interface..."
sudo lnetctl net del --net tcp 2> /dev/null
sudo lnetctl net add --net tcp --if $eth_intf
# For P5 instance type which supports 32 network cards,
# by default add 8 EFA interfaces selecting every 4th device (1 per PCI bus)
echo "Configuring EFA interface(s)..."
instance_type="$(ec2-metadata --instance-type | awk '{ print $2 }')"
num_efa_devices="$(ls -1 /sys/class/infiniband | wc -l)"
echo "Found $num_efa_devices available EFA device(s)"
if [[ "$instance_type" == "p5.48xlarge" || "$instance_type" == "p5e.48xlarge" ]]; then
for intf in $(ls -1 /sys/class/infiniband | awk 'NR % 4 == 1'); do
sudo lnetctl net add --net efa --if $intf --peer-credits 32
done
else
# Other instances: Configure 2 EFA interfaces by default if the instance supports multiple network cards,
# or 1 interface for single network card instances
# Can be modified to add more interfaces if instance type supports it
sudo lnetctl net add --net efa --if $(ls -1 /sys/class/infiniband | head -n1) --peer-credits 32
if [[ $num_efa_devices -gt 1 ]]; then
sudo lnetctl net add --net efa --if $(ls -1 /sys/class/infiniband | tail -n1) --peer-credits 32
fi
fi
echo "Setting discovery and UDSP rule"
sudo lnetctl set discovery 1
sudo lnetctl udsp add --src efa --priority 0
sudo /sbin/modprobe lustre
sudo lnetctl net show
echo "Added $(sudo lnetctl net show | grep -c '@efa') EFA interface(s)"
```
## Étape 2. Créer un groupe de nœuds
Créer un groupe de nœuds activée pour EFA :
```
# Create node group using efa-ng.yaml
eksctl create nodegroup -f efa-ng.yaml
```
**Important**
=== Ajustez ces valeurs en fonction de votre environnement dans la section `# 5. Mount FSx filesystem`.
```
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
```
===
Exemple `efa-ng.yaml` :
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: final-efa
region: us-east-1
managedNodeGroups:
- name: ng-1
instanceType: c6gn.16xlarge
minSize: 1
desiredCapacity: 1
maxSize: 1
availabilityZones: ["us-east-1a"]
volumeSize: 300
privateNetworking: true
amiFamily: Ubuntu2204
efaEnabled: true
preBootstrapCommands:
- |
#!/bin/bash
exec 1> >(logger -s -t $(basename $0)) 2>&1
#########################################################################################
# Configuration Section #
#########################################################################################
# File System Configuration
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
# Lustre Tuning Parameters
LUSTRE_LRU_MAX_AGE=600000
LUSTRE_MAX_CACHED_MB=64
LUSTRE_OST_MAX_RPC=32
LUSTRE_MDC_MAX_RPC=64
LUSTRE_MDC_MOD_RPC=50
# File paths
FUNCTIONS_SCRIPT="/usr/local/bin/lustre_functions.sh"
TUNINGS_SCRIPT="/usr/local/bin/apply_lustre_tunings.sh"
SERVICE_FILE="/etc/systemd/system/lustre-tunings.service"
#EFA
MIN_EFA_VERSION="2.12.1"
# Function to check if a command was successful
check_success() {
if [ $? -eq 0 ]; then
echo "SUCCESS: $1"
else
echo "FAILED: $1"
return 1
fi
}
echo "********Starting FSx for Lustre configuration********"
# 1. Install Lustre client
if grep -q '^ID=ubuntu' /etc/os-release; then
echo "Detected Ubuntu, proceeding with Lustre setup..."
# Add Lustre repository
sudo wget -O - https://fsx-lustre-client-repo-public-keys.s3.amazonaws.com/fsx-ubuntu-public-key.asc | sudo gpg --dearmor | sudo tee /usr/share/keyrings/fsx-ubuntu-public-key.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/fsx-ubuntu-public-key.gpg] https://fsx-lustre-client-repo.s3.amazonaws.com/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/fsxlustreclientrepo.list
sudo apt-get update
sudo apt-get install -y lustre-client-modules-$(uname -r)
sudo apt-get install -y lustre-client
else
echo "Not Ubuntu, exiting"
exit 1
fi
check_success "Install Lustre client"
# Ensure Lustre tools are in the PATH
export PATH=$PATH:/usr/sbin
# 2. Apply network and RPC tunings
echo "********Applying network and RPC tunings********"
if ! grep -q "options ptlrpc ptlrpcd_per_cpt_max" /etc/modprobe.d/modprobe.conf; then
echo "options ptlrpc ptlrpcd_per_cpt_max=64" | sudo tee -a /etc/modprobe.d/modprobe.conf
check_success "Set ptlrpcd_per_cpt_max"
else
echo "ptlrpcd_per_cpt_max already set in modprobe.conf"
fi
if ! grep -q "options ksocklnd credits" /etc/modprobe.d/modprobe.conf; then
echo "options ksocklnd credits=2560" | sudo tee -a /etc/modprobe.d/modprobe.conf
check_success "Set ksocklnd credits"
else
echo "ksocklnd credits already set in modprobe.conf"
fi
# 3. Load Lustre modules
manage_lustre_modules() {
echo "Checking for existing Lustre modules..."
if lsmod | grep -q lustre; then
echo "Existing Lustre modules found."
# Check for mounted Lustre filesystems
echo "Checking for mounted Lustre filesystems..."
if mount | grep -q "type lustre"; then
echo "Found mounted Lustre filesystems. Attempting to unmount..."
mounted_fs=$(mount | grep "type lustre" | awk '{print $3}')
for fs in $mounted_fs; do
echo "Unmounting $fs"
sudo umount $fs
check_success "Unmount filesystem $fs"
done
else
echo "No Lustre filesystems mounted."
fi
# After unmounting, try to remove modules
echo "Attempting to remove Lustre modules..."
sudo lustre_rmmod
if [ $? -eq 0 ]; then
echo "SUCCESS: Removed existing Lustre modules"
else
echo "WARNING: Could not remove Lustre modules. They may still be in use."
echo "Please check for any remaining Lustre processes or mounts."
return 1
fi
else
echo "No existing Lustre modules found."
fi
echo "Loading Lustre modules..."
sudo modprobe lustre
check_success "Load Lustre modules" || exit 1
echo "Checking loaded Lustre modules:"
lsmod | grep lustre
}
# Managing Lustre kernel modules
echo "********Managing Lustre kernel modules********"
manage_lustre_modules
# 4. Initializing Lustre networking
echo "********Initializing Lustre networking********"
sudo lctl network up
check_success "Initialize Lustre networking" || exit 1
# 4.5 EFA Setup and Configuration
setup_efa() {
echo "********Starting EFA Setup********"
# Get interface and version information
eth_intf="$(/sbin/ip -br -4 a sh | grep $(hostname -i)/ | awk '{print $1}')"
efa_version=$(modinfo efa | awk '/^version:/ {print $2}' | sed 's/[^0-9.]//g')
min_efa_version=$MIN_EFA_VERSION
# Install or verify EFA driver
if [[ "$(printf '%s\n' "$min_efa_version" "$efa_version" | sort -V | head -n1)" != "$min_efa_version" ]]; then
echo "Installing EFA driver..."
sudo curl -O https://efa-installer.amazonaws.com/aws-efa-installer-1.37.0.tar.gz
tar -xf aws-efa-installer-1.37.0.tar.gz && cd aws-efa-installer
# Install dependencies
sudo apt-get update && apt-get upgrade -y
sudo apt install -y pciutils environment-modules libnl-3-dev libnl-route-3-200 libnl-route-3-dev dkms
# Install EFA
sudo ./efa_installer.sh -y
modinfo efa
else
echo "Using existing EFA driver version $efa_version"
fi
}
configure_efa_network() {
echo "********Configuring EFA Network********"
# Load required modules
echo "Loading network modules..."
sudo /sbin/modprobe lnet
sudo /sbin/modprobe kefalnd ipif_name="$eth_intf"
sudo /sbin/modprobe ksocklnd
# Initialize LNet
echo "Initializing LNet..."
sudo lnetctl lnet configure
# Configure TCP interface
echo "Configuring TCP interface..."
sudo lnetctl net del --net tcp 2> /dev/null
sudo lnetctl net add --net tcp --if $eth_intf
# For P5 instance type which supports 32 network cards,
# by default add 8 EFA interfaces selecting every 4th device (1 per PCI bus)
echo "Configuring EFA interface(s)..."
instance_type="$(ec2-metadata --instance-type | awk '{ print $2 }')"
num_efa_devices="$(ls -1 /sys/class/infiniband | wc -l)"
echo "Found $num_efa_devices available EFA device(s)"
if [[ "$instance_type" == "p5.48xlarge" || "$instance_type" == "p5e.48xlarge" ]]; then
# P5 instance configuration
for intf in $(ls -1 /sys/class/infiniband | awk 'NR % 4 == 1'); do
sudo lnetctl net add --net efa --if $intf --peer-credits 32
done
else
# Standard configuration
# Other instances: Configure 2 EFA interfaces by default if the instance supports multiple network cards,
# or 1 interface for single network card instances
# Can be modified to add more interfaces if instance type supports it
sudo lnetctl net add --net efa --if $(ls -1 /sys/class/infiniband | head -n1) --peer-credits 32
if [[ $num_efa_devices -gt 1 ]]; then
sudo lnetctl net add --net efa --if $(ls -1 /sys/class/infiniband | tail -n1) --peer-credits 32
fi
fi
# Configure discovery and UDSP
echo "Setting up discovery and UDSP rules..."
sudo lnetctl set discovery 1
sudo lnetctl udsp add --src efa --priority 0
sudo /sbin/modprobe lustre
# Verify configuration
echo "Verifying EFA network configuration..."
sudo lnetctl net show
echo "Added $(sudo lnetctl net show | grep -c '@efa') EFA interface(s)"
}
# Main execution
setup_efa
configure_efa_network
# 5. Mount FSx filesystem
if [ ! -z "$FSX_DNS" ] && [ ! -z "$MOUNT_NAME" ]; then
echo "********Creating mount point********"
sudo mkdir -p $MOUNT_POINT
check_success "Create mount point"
echo "Mounting FSx filesystem..."
sudo mount -t lustre ${FSX_DNS}@tcp:/${MOUNT_NAME} ${MOUNT_POINT}
check_success "Mount FSx filesystem"
else
echo "Skipping FSx mount as DNS or mount name is not provided"
fi
# 6. Applying Lustre performance tunings
echo "********Applying Lustre performance tunings********"
# Get number of CPUs
NUM_CPUS=$(nproc)
# Calculate LRU size (100 * number of CPUs)
LRU_SIZE=$((100 * NUM_CPUS))
#Apply LRU tunings
echo "Apply LRU tunings"
sudo lctl set_param ldlm.namespaces.*.lru_max_age=${LUSTRE_LRU_MAX_AGE}
check_success "Set lru_max_age"
sudo lctl set_param ldlm.namespaces.*.lru_size=$LRU_SIZE
check_success "Set lru_size"
# Client Cache Control
sudo lctl set_param llite.*.max_cached_mb=${LUSTRE_MAX_CACHED_MB}
check_success "Set max_cached_mb"
# RPC Controls
sudo lctl set_param osc.*OST*.max_rpcs_in_flight=${LUSTRE_OST_MAX_RPC}
check_success "Set OST max_rpcs_in_flight"
sudo lctl set_param mdc.*.max_rpcs_in_flight=${LUSTRE_MDC_MAX_RPC}
check_success "Set MDC max_rpcs_in_flight"
sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=${LUSTRE_MDC_MOD_RPC}
check_success "Set MDC max_mod_rpcs_in_flight"
# 7. Verify all tunings
echo "********Verifying all tunings********"
# Function to verify parameter value
verify_param() {
local param=$1
local expected=$2
local actual=$3
if [ "$actual" == "$expected" ]; then
echo "SUCCESS: $param is correctly set to $expected"
else
echo "WARNING: $param is set to $actual (expected $expected)"
fi
}
echo "Verifying all parameters:"
# LRU tunings
actual_lru_max_age=$(lctl get_param -n ldlm.namespaces.*.lru_max_age | head -1)
verify_param "lru_max_age" "600000" "$actual_lru_max_age"
actual_lru_size=$(lctl get_param -n ldlm.namespaces.*.lru_size | head -1)
verify_param "lru_size" "$LRU_SIZE" "$actual_lru_size"
# Client Cache
actual_max_cached_mb=$(lctl get_param -n llite.*.max_cached_mb | grep "max_cached_mb:" | awk '{print $2}')
verify_param "max_cached_mb" "64" "$actual_max_cached_mb"
# RPC Controls
actual_ost_rpcs=$(lctl get_param -n osc.*OST*.max_rpcs_in_flight | head -1)
verify_param "OST max_rpcs_in_flight" "32" "$actual_ost_rpcs"
actual_mdc_rpcs=$(lctl get_param -n mdc.*.max_rpcs_in_flight | head -1)
verify_param "MDC max_rpcs_in_flight" "64" "$actual_mdc_rpcs"
actual_mdc_mod_rpcs=$(lctl get_param -n mdc.*.max_mod_rpcs_in_flight | head -1)
verify_param "MDC max_mod_rpcs_in_flight" "50" "$actual_mdc_mod_rpcs"
# Network and RPC configurations from modprobe.conf
actual_ptlrpc=$(grep "ptlrpc ptlrpcd_per_cpt_max" /etc/modprobe.d/modprobe.conf | awk '{print $3}')
verify_param "ptlrpcd_per_cpt_max" "ptlrpcd_per_cpt_max=64" "$actual_ptlrpc"
actual_ksocklnd=$(grep "ksocklnd credits" /etc/modprobe.d/modprobe.conf | awk '{print $3}')
verify_param "ksocklnd credits" "credits=2560" "$actual_ksocklnd"
# 8. Setup persistence
setup_persistence() {
# Create functions file
cat << EOF > $FUNCTIONS_SCRIPT
#!/bin/bash
apply_lustre_tunings() {
local NUM_CPUS=\$(nproc)
local LRU_SIZE=\$((100 * NUM_CPUS))
echo "Applying Lustre performance tunings..."
lctl set_param ldlm.namespaces.*.lru_max_age=$LUSTRE_LRU_MAX_AGE
lctl set_param ldlm.namespaces.*.lru_size=\$LRU_SIZE
lctl set_param llite.*.max_cached_mb=$LUSTRE_MAX_CACHED_MB
lctl set_param osc.*OST*.max_rpcs_in_flight=$LUSTRE_OST_MAX_RPC
lctl set_param mdc.*.max_rpcs_in_flight=$LUSTRE_MDC_MAX_RPC
lctl set_param mdc.*.max_mod_rpcs_in_flight=$LUSTRE_MDC_MOD_RPC
}
EOF
# Create tuning script
cat << EOF > $TUNINGS_SCRIPT
#!/bin/bash
exec 1> >(logger -s -t \$(basename \$0)) 2>&1
source $FUNCTIONS_SCRIPT
# Function to check if Lustre is mounted
is_lustre_mounted() {
mount | grep -q "type lustre"
}
# Function to mount Lustre
mount_lustre() {
echo "Mounting Lustre filesystem..."
mkdir -p $MOUNT_POINT
mount -t lustre ${FSX_DNS}@tcp:/${MOUNT_NAME} $MOUNT_POINT
return \$?
}
# Main execution
# Try to mount if not already mounted
if ! is_lustre_mounted; then
echo "Lustre filesystem not mounted, attempting to mount..."
mount_lustre
fi
# Wait for successful mount (up to 5 minutes)
for i in {1..30}; do
if is_lustre_mounted; then
echo "Lustre filesystem mounted, applying tunings..."
apply_lustre_tunings
exit 0
fi
echo "Waiting for Lustre filesystem to be mounted... (attempt $i/30)"
sleep 10
done
echo "Timeout waiting for Lustre filesystem mount"
exit 1
EOF
# Create systemd service
# Create systemd directory if it doesn't exist
sudo mkdir -p /etc/systemd/system/
# Create service file directly for Ubuntu
cat << EOF > $SERVICE_FILE
[Unit]
Description=Apply Lustre Performance Tunings
After=network.target remote-fs.target
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'source $FUNCTIONS_SCRIPT && $TUNINGS_SCRIPT'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
# Make scripts executable and enable service
sudo chmod +x $FUNCTIONS_SCRIPT
sudo chmod +x $TUNINGS_SCRIPT
systemctl enable lustre-tunings.service
systemctl start lustre-tunings.service
}
echo "********Setting up persistent tuning********"
setup_persistence
echo "FSx for Lustre configuration completed."
```
## (Facultatif) Étape 3. Vérifier EFA
Accéder au nœud via SSH :
```
# Get instance ID from EKS console or {aws} CLI
ssh -i /path/to/your-key.pem ec2-user@
```
Vérifier EFA :
```
sudo lnetctl net show
```
Consultez les journaux de configuration :
```
sudo cat /var/log/cloud-init-output.log
```
Voici un exemple de sortie attendue pour `lnetctl net show` :
```
net:
- net type: tcp
...
- net type: efa
local NI(s):
- nid: xxx.xxx.xxx.xxx@efa
status: up
```
## Exemple de déploiement
### a. Créer claim.yaml
```
#claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: fsx-claim-efa
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 4800Gi
volumeName: fsx-pv
```
Appliquez la réclamation :
```
kubectl apply -f claim.yaml
```
### b. Créer pv.yaml
Mettre à jour le :``
```
#pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: fsx-pv
spec:
capacity:
storage: 4800Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
mountOptions:
- flock
persistentVolumeReclaimPolicy: Recycle
csi:
driver: fsx.csi.aws.com
volumeHandle: fs-<1234567890abcdef0>
volumeAttributes:
dnsname: fs-<1234567890abcdef0>.fsx.us-east-1.amazonaws.com
mountname:
```
Appliquez le volume persistant :
```
kubectl apply -f pv.yaml
```
### c. Créer pod.yaml
```
#pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: fsx-efa-app
spec:
containers:
- name: app
image: amazonlinux:2
command: ["/bin/sh"]
args: ["-c", "while true; do dd if=/dev/urandom bs=100M count=20 > data/test_file; sleep 10; done"]
resources:
requests:
vpc.amazonaws.com/efa: 1
limits:
vpc.amazonaws.com/efa: 1
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: fsx-claim-efa
```
Appliquez le pod :
```
kubectl apply -f pod.yaml
```
## Commandes de vérification supplémentaires
Vérifiez que Pod monte et écrit sur le système de fichiers :
```
kubectl exec -ti fsx-efa-app -- df -h | grep data
# Expected output:
# <192.0.2.0>@tcp:/ 4.5T 1.2G 4.5T 1% /data
kubectl exec -ti fsx-efa-app -- ls /data
# Expected output:
# test_file
```
Connectez-vous au nœud en SSH pour vérifier que le trafic passe par EFA :
```
sudo lnetctl net show -v
```
Le résultat attendu affichera les interfaces EFA avec les statistiques de trafic.
## Informations connexes
+ [Déployez le pilote FSx for Lustre](fsx-csi-create.md)
+ [Optimisez les performances FSx d'Amazon for Lustre sur les nœuds (non EFA)](fsx-csi-tuning-non-efa.md)
+ [Amazon FSx pour Lustre Performance](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html)
+ [Elastic Fabric Adapter (EFA)](https://docs.aws.amazon.com/ec2/latest/userguide/efa.html)
# Optimisez les performances FSx d'Amazon for Lustre sur les nœuds (non EFA)
Vous pouvez optimiser les performances d'Amazon FSx for Lustre en appliquant des paramètres de réglage lors de l'initialisation du nœud à l'aide des données utilisateur du modèle de lancement.
**Note**
Pour plus d'informations sur la création et le déploiement du pilote CSI FSx for Lustre, consultez[Déployez le pilote FSx for Lustre](fsx-csi-create.md). Pour optimiser les performances avec les nœuds compatibles EFA, consultez [Optimisez les performances FSx d'Amazon for Lustre sur les nœuds (EFA)](fsx-csi-tuning-efa.md).
## Pourquoi utiliser les données utilisateur du modèle de lancement ?
+ Applique automatiquement les réglages lors de l’initialisation du nœud.
+ Assure une configuration cohérente sur tous les nœuds.
+ Élimine le besoin de configuration manuelle des nœuds.
## Aperçu de l’exemple de script
Le script d’exemple défini dans cette rubrique effectue les opérations suivantes :
### `# 1. Install Lustre client`
+ Détecte automatiquement la version de votre système d'exploitation Amazon Linux (AL).
+ Installe le package client Lustre approprié.
### `# 2. Apply network and RPC tunings`
+ Ensembles `ptlrpcd_per_cpt_max=64` pour le traitement RPC parallèle.
+ Configure `ksocklnd credits=2560` pour optimiser les tampons réseau.
### `# 3. Load Lustre modules`
+ Supprime en toute sécurité les modules Lustre existants, le cas échéant.
+ Gère le démontage des systèmes de fichiers existants.
+ Charge les modules Lustre récents.
### `# 4. Lustre Network Initialization`
+ Initialise la configuration réseau Lustre.
+ Configure les paramètres réseau requis.
### `# 5. Mount FSx filesystem`
+ Vous devez ajuster les valeurs pour votre environnement dans cette section.
### `# 6. Apply tunings`
+ Réglages LRU (Lock Resource Unit) :
+ `lru_max_age=600000`
+ `lru_size` calculé en fonction du nombre de processeurs
+ Contrôle du cache client : `max_cached_mb=64`
+ Contrôles RPC :
+ OST `max_rpcs_in_flight=32`
+ MDC `max_rpcs_in_flight=64`
+ MDC `max_mod_rpcs_in_flight=50`
### `# 7. Verify tunings`
+ Vérifie tous les réglages appliqués.
+ Signale le succès ou l’avertissement pour chaque paramètre.
### `# 8. Setup persistence`
+ Vous devez également ajuster les valeurs pour votre environnement dans cette section.
+ Détecte automatiquement la version de votre système d'exploitation (AL2023) pour déterminer le `Systemd` service à appliquer.
+ Le système démarre.
+ `Systemd` démarre le service `lustre-tunings` (en raison de `WantedBy=multi-user.target`).
+ Le service exécute `apply_lustre_tunings.sh` qui :
+ Vérifie si le système de fichiers est monté.
+ Monte le système de fichiers s’il n’est pas déjà monté.
+ Attend que le montage soit réussi (jusqu’à cinq minutes).
+ Applique les paramètres de réglage après un montage réussi.
+ Les paramètres restent actifs jusqu’au redémarrage.
+ Le service se termine après l’exécution du script.
+ Systemd marque le service comme « actif (fermé) ».
+ Le processus se répète au prochain redémarrage.
## Création d’un modèle de lancement
1. Ouvrez la EC2 console Amazon à l'adresse https://console.aws.amazon.com/ec2/.
1. Choisissez **Lancer modèles**.
1. Choisissez **Créer un modèle de lancement**.
1. Dans les **détails avancés**, repérez la section **Données utilisateur**.
1. Collez le script ci-dessous, en mettant à jour tout ce qui est nécessaire.
**Important**
Ajustez ces valeurs en fonction de votre environnement dans les sections `# 5. Mount FSx filesystem` et dans la fonction `setup_persistence()` de `apply_lustre_tunings.sh` dans la section `# 8. Setup persistence` :
```
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
```
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
exec 1> >(logger -s -t $(basename $0)) 2>&1
# Function definitions
check_success() {
if [ $? -eq 0 ]; then
echo "SUCCESS: $1"
else
echo "FAILED: $1"
return 1
fi
}
apply_tunings() {
local NUM_CPUS=$(nproc)
local LRU_SIZE=$((100 * NUM_CPUS))
local params=(
"ldlm.namespaces.*.lru_max_age=600000"
"ldlm.namespaces.*.lru_size=$LRU_SIZE"
"llite.*.max_cached_mb=64"
"osc.*OST*.max_rpcs_in_flight=32"
"mdc.*.max_rpcs_in_flight=64"
"mdc.*.max_mod_rpcs_in_flight=50"
)
for param in "${params[@]}"; do
lctl set_param $param
check_success "Set ${param%%=*}"
done
}
verify_param() {
local param=$1
local expected=$2
local actual=$3
if [ "$actual" == "$expected" ]; then
echo "SUCCESS: $param is correctly set to $expected"
else
echo "WARNING: $param is set to $actual (expected $expected)"
fi
}
verify_tunings() {
local NUM_CPUS=$(nproc)
local LRU_SIZE=$((100 * NUM_CPUS))
local params=(
"ldlm.namespaces.*.lru_max_age:600000"
"ldlm.namespaces.*.lru_size:$LRU_SIZE"
"llite.*.max_cached_mb:64"
"osc.*OST*.max_rpcs_in_flight:32"
"mdc.*.max_rpcs_in_flight:64"
"mdc.*.max_mod_rpcs_in_flight:50"
)
echo "Verifying all parameters:"
for param in "${params[@]}"; do
name="${param%%:*}"
expected="${param#*:}"
actual=$(lctl get_param -n $name | head -1)
verify_param "${name##*.}" "$expected" "$actual"
done
}
setup_persistence() {
# Create functions file
cat << 'EOF' > /usr/local/bin/lustre_functions.sh
#!/bin/bash
apply_lustre_tunings() {
local NUM_CPUS=$(nproc)
local LRU_SIZE=$((100 * NUM_CPUS))
echo "Applying Lustre performance tunings..."
lctl set_param ldlm.namespaces.*.lru_max_age=600000
lctl set_param ldlm.namespaces.*.lru_size=$LRU_SIZE
lctl set_param llite.*.max_cached_mb=64
lctl set_param osc.*OST*.max_rpcs_in_flight=32
lctl set_param mdc.*.max_rpcs_in_flight=64
lctl set_param mdc.*.max_mod_rpcs_in_flight=50
}
EOF
# Create tuning script
cat << 'EOF' > /usr/local/bin/apply_lustre_tunings.sh
#!/bin/bash
exec 1> >(logger -s -t $(basename $0)) 2>&1
# Source the functions
source /usr/local/bin/lustre_functions.sh
# FSx details
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
# Function to check if Lustre is mounted
is_lustre_mounted() {
mount | grep -q "type lustre"
}
# Function to mount Lustre
mount_lustre() {
echo "Mounting Lustre filesystem..."
mkdir -p ${MOUNT_POINT}
mount -t lustre ${FSX_DNS}@tcp:/${MOUNT_NAME} ${MOUNT_POINT}
return $?
}
# Main execution
# Try to mount if not already mounted
if ! is_lustre_mounted; then
echo "Lustre filesystem not mounted, attempting to mount..."
mount_lustre
fi
# Wait for successful mount (up to 5 minutes)
for i in {1..30}; do
if is_lustre_mounted; then
echo "Lustre filesystem mounted, applying tunings..."
apply_lustre_tunings
exit 0
fi
echo "Waiting for Lustre filesystem to be mounted... (attempt $i/30)"
sleep 10
done
echo "Timeout waiting for Lustre filesystem mount"
exit 1
EOF
# Create systemd service
cat << 'EOF' > /etc/systemd/system/lustre-tunings.service
[Unit]
Description=Apply Lustre Performance Tunings
After=network.target remote-fs.target
StartLimitIntervalSec=0
[Service]
Type=oneshot
ExecStart=/usr/local/bin/apply_lustre_tunings.sh
RemainAfterExit=yes
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
EOF
chmod +x /usr/local/bin/lustre_functions.sh
chmod +x /usr/local/bin/apply_lustre_tunings.sh
systemctl enable lustre-tunings.service
systemctl start lustre-tunings.service
}
echo "Starting FSx for Lustre configuration..."
# 1. Install Lustre client
if grep -q 'VERSION="2"' /etc/os-release; then
amazon-linux-extras install -y lustre
elif grep -q 'VERSION="2023"' /etc/os-release; then
dnf install -y lustre-client
fi
check_success "Install Lustre client"
# 2. Apply network and RPC tunings
export PATH=$PATH:/usr/sbin
echo "Applying network and RPC tunings..."
if ! grep -q "options ptlrpc ptlrpcd_per_cpt_max" /etc/modprobe.d/modprobe.conf; then
echo "options ptlrpc ptlrpcd_per_cpt_max=64" | tee -a /etc/modprobe.d/modprobe.conf
echo "options ksocklnd credits=2560" | tee -a /etc/modprobe.d/modprobe.conf
fi
# 3. Load Lustre modules
modprobe lustre
check_success "Load Lustre modules" || exit 1
# 4. Lustre Network Initialization
lctl network up
check_success "Initialize Lustre networking" || exit 1
# 5. Mount FSx filesystem
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
if [ ! -z "$FSX_DNS" ] && [ ! -z "$MOUNT_NAME" ]; then
mkdir -p $MOUNT_POINT
mount -t lustre ${FSX_DNS}@tcp:/${MOUNT_NAME} ${MOUNT_POINT}
check_success "Mount FSx filesystem"
fi
# 6. Apply tunings
apply_tunings
# 7. Verify tunings
verify_tunings
# 8. Setup persistence
setup_persistence
echo "FSx for Lustre configuration completed."
--==MYBOUNDARY==--
```
1. Lorsque vous créez des groupes de nœuds Amazon EKS, sélectionnez ce modèle de lancement. Pour de plus amples informations, veuillez consulter [Création d’un groupe de nœuds gérés pour votre cluster](create-managed-node-group.md).
## Informations connexes
+ [Déployez le pilote FSx for Lustre](fsx-csi-create.md)
+ [Optimisez les performances FSx d'Amazon for Lustre sur les nœuds (EFA)](fsx-csi-tuning-efa.md)
+ [Amazon FSx pour Lustre Performance](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html)
# Utilisez un stockage d’applications haute performance avec FSx pour NetApp ONTAP
NetApp Trident offre une orchestration dynamique du stockage à l’aide d’un pilote compatible avec l’interface CSI (Container Storage Interface). Cela permet aux clusters Amazon EKS de gérer le cycle de vie des volumes persistants (PV) basés sur les systèmes de fichiers Amazon FSx pour NetApp ONTAP. Veuillez noter que le pilote Amazon FSx pour NetApp ONTAP CSI n’est pas compatible avec les nœuds hybrides Amazon EKS. Pour commencer, consultez la section [Utilisation de Trident avec Amazon FSx pour NetApp ONTAP](https://docs.netapp.com/us-en/trident/trident-use/trident-fsx.html) dans la documentation NetApp Trident.
Amazon FSx for NetApp ONTAP est un service de stockage qui vous permet de lancer et d'exécuter des systèmes de fichiers ONTAP entièrement gérés dans le cloud. ONTAP est la technologie de système de fichiers de NetApp qui offre un ensemble largement adopté de fonctionnalités d’accès aux données et de gestion des données. FSx for ONTAP offre les fonctionnalités, les performances et les API des systèmes de fichiers NetApp sur site, avec l’agilité, la capacité de mise à l’échelle et la simplicité d’un service AWS entièrement géré. Pour plus d'informations, consultez le [Guide de l'utilisateur FSx for ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html).
**Important**
Si vous utilisez Amazon FSx pour NetApp ONTAP avec le pilote Amazon EBS CSI pour provisionner des volumes EBS, vous devez spécifier dans le fichier `multipath.conf` de ne pas utiliser de périphériques EBS. Pour connaître les méthodes prises en charge, consultez la [Liste noire des fichiers de configuration](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/dm_multipath/config_file_blacklist#config_file_blacklist). Voici un exemple.
```
defaults {
user_friendly_names yes
find_multipaths no
}
blacklist {
device {
vendor "NVME"
product "Amazon Elastic Block Store"
}
}
```
# Utilisez le stockage de données avec Amazon FSx pour OpenZFS
Amazon FSx pour OpenZFS est un service de stockage de fichiers entièrement géré qui facilite le transfert de données vers AWS à partir de serveurs de fichiers ZFS sur site ou d'autres serveurs de fichiers basés sur Linux. Vous pouvez le faire sans modifier le code de votre application ni la façon dont vous gérez les données. Il offre un stockage de fichiers hautement fiable, évolutif, efficace et riche en fonctionnalités basé sur le système de fichiers open source OpenZFS. Il associe ces fonctionnalités à l'agilité, à l'évolutivité et à la simplicité d'un service AWS entièrement géré. Pour plus d'informations, consultez le [Guide de l'utilisateur Amazon FSx pour OpenZFS](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/what-is-fsx.html).
Le pilote FSx pour OpenZFS Container Storage Interface (CSI) fournit une interface CSI qui permet aux clusters Amazon EKS de gérer le cycle de vie des volumes FSx pour OpenZFS. Veuillez noter que le pilote CSI Amazon FSx pour OpenZFS n’est pas compatible avec les nœuds hybrides Amazon EKS. Pour déployer le pilote FSx pour OpenZFS CSI sur votre cluster Amazon EKS, consultez [aws-fsx-openzfs-csi-driver](https://github.com/kubernetes-sigs/aws-fsx-openzfs-csi-driver) sur GitHub.
# Minimisez le temps de latence avec Amazon File Cache
Amazon File Cache est un cache haut débit entièrement géré sur AWS qui est utilisé pour traiter les données des fichiers, quel que soit leur emplacement de stockage. Amazon File Cache charge automatiquement les données dans le cache lorsque vous y accédez pour la première fois et les publie lorsqu’elles ne sont pas utilisées. Pour de plus amples informations, veuillez consulter le [Guide de l'utilisateur Amazon File Cache](https://docs.aws.amazon.com/fsx/latest/FileCacheGuide/what-is.html).
Le pilote Amazon File Cache Container Storage Interface (CSI) fournit une interface CSI qui permet aux clusters Amazon EKS de gérer le cycle de vie des systèmes de fichiers Amazon. Veuillez noter que le pilote CSI Amazon File Cache n’est pas compatible avec les nœuds hybrides Amazon EKS. Pour déployer le pilote CSI Amazon File Cache sur votre cluster Amazon EKS, consultez [aws-file-cache-csi-driver](https://github.com/kubernetes-sigs/aws-file-cache-csi-driver) sur GitHub.
# Accéder aux objets Amazon S3 avec le pilote CSI Mountpoint pour Amazon S3
Avec le [Pilote Container Storage Interface (CSI) Mountpoint pour Amazon S3](https://github.com/awslabs/mountpoint-s3-csi-driver), vos applications Kubernetes peuvent accéder aux objets Amazon S3 via une interface de système de fichiers, ce qui permet d’obtenir un débit global élevé sans modifier le code de l’application. Créé sur [Mountpoint pour Amazon S3](https://github.com/awslabs/mountpoint-s3), le pilote CSI présente un compartiment Amazon S3 comme un volume accessible par les conteneurs dans Amazon EKS et les clusters Kubernetes autogérés.
## Considérations
+ Le pilote CSI Mountpoint pour Amazon S3 n’est actuellement pas compatible avec les images de conteneurs Windows.
+ Le pilote CSI Mountpoint pour Amazon S3 n’est actuellement pas compatible avec les nœuds hybrides Amazon EKS.
+ Le pilote CSI Mountpoint pour Amazon S3 ne prend pas en charge AWS Fargate. Cependant, les conteneurs qui s’exécutent dans Amazon EC2 (avec Amazon EKS ou une installation Kubernetes personnalisée) sont pris en charge.
+ Le pilote CSI Mountpoint pour Amazon S3 ne prend en charge que l’approvisionnement statique. L’approvisionnement dynamique, ou la création de nouveaux compartiments, n’est pas pris en charge.
**Note**
L’approvisionnement statique fait référence à l’utilisation d’un compartiment Amazon S3 existant qui est spécifié comme `bucketName` dans les `volumeAttributes` de l’objet `PersistentVolume`. Pour plus d’informations, consultez [Approvisionnement statique](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/examples/kubernetes/static_provisioning/README.md) sur GitHub.
+ Les volumes montés avec le pilote Mountpoint pour Amazon S3 CSI ne prennent pas en charge toutes les fonctionnalités du système de fichiers POSIX. Pour plus d’informations sur le comportement du système de fichiers, consultez [Comportement du système de fichiers Mountpoint pour Amazon S3](https://github.com/awslabs/mountpoint-s3/blob/main/doc/SEMANTICS.md) sur GitHub.
Pour plus d’informations sur le déploiement du pilote, consultez [Déployer le pilote Mountpoint pour Amazon S3](s3-csi-create.md). Pour plus d’informations sur la suppression du pilote, consultez [Supprimer le module complémentaire Mountpoint pour Amazon S3 pour Amazon EKS](removing-s3-csi-eks-add-on.md).
# Déployer le pilote Mountpoint pour Amazon S3
Avec le [Pilote Container Storage Interface (CSI) Mountpoint pour Amazon S3](https://github.com/awslabs/mountpoint-s3-csi-driver), vos applications Kubernetes peuvent accéder aux objets Amazon S3 via une interface de système de fichiers, ce qui permet d’obtenir un débit global élevé sans modifier le code de l’application.
Cette procédure vous montrera comment déployer le [pilote CSI Mountpoint pour Amazon S3 pour Amazon EKS](s3-csi.md). Avant de continuer, consultez les [Considérations](s3-csi.md#s3-csi-considerations).
## Conditions préalables
+ Un fournisseur IAM ( AWS Identity and Access Management) (IAM) OpenID Connect (OIDC) existant pour votre cluster. Pour déterminer si vous en avez déjà un, ou pour en créer un, consultez [Créer un fournisseur d'identité OIDC IAM pour votre cluster](enable-iam-roles-for-service-accounts.md).
+ Version 2.12.3 ou ultérieure de la AWS CLI installée et configurée sur votre appareil ou. AWS CloudShell
+ 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 une politique IAM
Le pilote CSI Mountpoint pour Amazon S3 nécessite des autorisations Amazon S3 pour interagir avec votre système de fichiers. Cette section montre comment créer une politique IAM qui accorde les autorisations nécessaires.
L’exemple de politique suivant respecte les recommandations d’autorisation IAM pour Mountpoint. Vous pouvez également utiliser la politique AWS gérée [AmazonS3 FullAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AmazonS3FullAccess$jsonEditor), mais cette politique gérée accorde plus d'autorisations que ce qui est nécessaire pour Mountpoint.
Pour plus d'informations sur les autorisations recommandées pour Mountpoint, consultez la section Autorisations [Mountpoint](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#iam-permissions) IAM sur. GitHub
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Politiques**.
1. Sur la page **Politiques**, choisissez **Créer une politique**.
1. Dans **Éditeur de politique**, choisissez **JSON**.
1. Sous **Éditeur de politique**, copiez et collez ce qui suit :
**Important**
Remplacez `amzn-s3-demo-bucket1` par votre propre nom de compartiment Amazon S3.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MountpointFullBucketAccess",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1"
]
},
{
"Sid": "MountpointFullObjectAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*"
]
}
]
}
```
Les compartiments de répertoires, introduits avec la classe de stockage Amazon S3 Express One Zone, utilisent un mécanisme d’authentification différent de celui des compartiments à usage général. Au lieu d’utiliser les actions `s3:*`, vous devez utiliser l’action `s3express:CreateSession`. Pour plus d’informations sur les compartiments de répertoires, consultez [Compartiments de répertoires](https://docs.aws.amazon.com/AmazonS3/latest/userguide/directory-buckets-overview.html) dans le *Guide de l’utilisateur Amazon S3*.
Vous trouverez ci-dessous un exemple de politique de privilège minimal que vous pouvez utiliser pour un compartiment répertoire.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3express:CreateSession",
"Resource": "arn:aws:s3express:us-west-2:111122223333:bucket/amzn-s3-demo-bucket1--usw2-az1--x-s3"
}
]
}
```
1. Choisissez **Suivant**.
1. Sur la page **Vérifier et créer**, donnez un nom à votre politique. Cet exemple de démonstration utilise le nom `AmazonS3CSIDriverPolicy`.
1. Choisissez **Create Policy** (Créer une politique).
## Étape 2 : Créer un rôle IAM
Le pilote CSI Mountpoint pour Amazon S3 nécessite des autorisations Amazon S3 pour interagir avec votre système de fichiers. Cette section montre comment créer un rôle IAM pour déléguer ces autorisations. Pour créer ce rôle, vous pouvez utiliser l’un des outils suivants :
+ [eksctl](#eksctl_s3_store_app_data)
+ [AWS Management Console](#console_s3_store_app_data)
+ [AWS CLI](#awscli_s3_store_app_data)
**Note**
La politique IAM `AmazonS3CSIDriverPolicy` a été créée dans la section précédente.
### eksctl
**Pour créer votre rôle IAM du pilote CSI Mountpoint pour Amazon S3 avec `eksctl` **
Pour créer le rôle IAM et le compte de service Kubernetes, exécutez les commandes suivantes. Ces commandes associent également la politique IAM `AmazonS3CSIDriverPolicy` au rôle, annotent le compte de service Kubernetes (`s3-csi-controller-sa`) avec le nom d’Amazon Resource Name (ARN) du rôle IAM et ajoutent le nom du compte de service Kubernetes à la politique d’approbation pour le rôle IAM.
```
CLUSTER_NAME=my-cluster
REGION=region-code
ROLE_NAME=AmazonEKS_S3_CSI_DriverRole
POLICY_ARN=AmazonEKS_S3_CSI_DriverRole_ARN
eksctl create iamserviceaccount \
--name s3-csi-driver-sa \
--namespace kube-system \
--cluster $CLUSTER_NAME \
--attach-policy-arn $POLICY_ARN \
--approve \
--role-name $ROLE_NAME \
--region $REGION \
--role-only
```
### AWS Management Console
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Sur la page **Rôles**, choisissez **Créer un rôle**.
1. Sur la page **Select trusted entity** (Sélectionnez une entité de confiance), procédez comme suit :
1. Dans la section **Trusted entity type** (Type d'entité de confiance), sélectionnez **Web identity** (Identité web).
1. Pour **Fournisseur d'identité**, choisissez l'**URL du fournisseur OpenID Connect** pour votre cluster (comme indiqué sous **Présentation** dans Amazon EKS).
Si ce n' URLs est pas le cas, passez en revue les [conditions préalables](#s3-csi-prereqs).
1. Pour **Audience**, choisissez `sts.amazonaws.com`.
1. Choisissez **Suivant**.
1. Sur la page **Add permissions** (Ajouter des autorisations), procédez comme suit :
1. Dans le champ **Politiques de filtrage**, saisissez la politique d'AmazonS3CSIDriver.
**Note**
Cette politique a été créée dans la section précédente.
1. Cochez la case à gauche du résultat `AmazonS3CSIDriverPolicy` renvoyé par la recherche.
1. Choisissez **Suivant**.
1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), procédez comme suit :
1. Dans **Nom du rôle**, entrez un nom unique pour votre rôle, tel que DriverRole AmazoneKS\$1S3\$1CSI\$1.
1. Sous **Ajouter des balises (Facultatif)**, ajoutez des métadonnées au rôle en attachant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez la rubrique [Balisage des ressources IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le *Guide de l'utilisateur IAM*.
1. Choisissez **Créer un rôle**.
1. Une fois le rôle créé, choisissez le rôle dans la console pour l'ouvrir et le modifier.
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la politique d'approbation).
1. Trouvez la ligne qui ressemble à ce qui suit :
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
```
Ajoutez une virgule à la fin de la ligne précédente, puis ajoutez la ligne suivante. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. Remplacez *EXAMPLED539D4633E53DE1B71EXAMPLE* par l’ID du fournisseur OIDC de votre cluster.
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:s3-csi-driver-sa"
```
1. Assurez-vous que l’opérateur `Condition` est défini sur `"StringEquals"`.
1. Sélectionnez **Update Trust Policy** (Mettre à jour la politique d'approbation) pour terminer.
### AWS CLI
1. Affichez l'URL du fournisseur OIDC de votre cluster. Remplacez *my-cluster* par le nom de votre cluster. Si la sortie de la commande est `None`, consultez [Prérequis](#s3-csi-prereqs).
```
aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text
```
L'exemple qui suit illustre un résultat.
```
https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
```
1. Créez le rôle IAM, en accordant au compte de service Kubernetes l'action `AssumeRoleWithWebIdentity`.
1. Copiez le contenu suivant dans un fichier nommé `aws-s3-csi-driver-trust-policy.json`. Remplacez *111122223333* par votre ID de compte. Remplacez *EXAMPLED539D4633E53DE1B71EXAMPLE* et *region-code* par les valeurs renvoyées par l'étape précédente.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:s3-csi-driver-sa",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. Créez le rôle. Vous pouvez changer le nom de *AmazonEKS\$1S3\$1CSI\$1DriverRole*. Dans ce cas, veillez à le changer également dans les étapes suivantes.
```
aws iam create-role \
--role-name AmazonEKS_S3_CSI_DriverRole \
--assume-role-policy-document file://"aws-s3-csi-driver-trust-policy.json"
```
1. Attachez la politique IAM créée précédemment au rôle à l'aide de la commande suivante.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonS3CSIDriverPolicy \
--role-name AmazonEKS_S3_CSI_DriverRole
```
**Note**
La politique IAM `AmazonS3CSIDriverPolicy` a été créée dans la section précédente.
1. Ignorez cette étape si vous installez le pilote en tant que module complémentaire Amazon EKS. Pour les installations autogérées du pilote, créez des comptes de service Kubernetes annotés avec l’ARN du rôle IAM que vous avez créé.
1. Enregistrez le contenu suivant dans un fichier nommé `mountpoint-s3-service-account.yaml`. Remplacez *111122223333* par votre ID de compte.
```
---
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/name: aws-mountpoint-s3-csi-driver
name: mountpoint-s3-csi-controller-sa
namespace: kube-system
annotations:
eks.amazonaws.com/role-arn: arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole
```
1. Créez le compte de service Kubernetes sur votre cluster. Le compte de service Kubernetes (`mountpoint-s3-csi-controller-sa`) est annoté avec le nom du rôle IAM que vous avez créé. *AmazonEKS\$1S3\$1CSI\$1DriverRole*
```
kubectl apply -f mountpoint-s3-service-account.yaml
```
**Note**
Lorsque vous déployez le plugin dans cette procédure, il crée et est configuré pour utiliser un compte de service nommé `s3-csi-driver-sa`.
## Étape 3 : installer le pilote CSI Mountpoint pour Amazon S3
Vous pouvez installer le pilote CSI Mountpoint pour Amazon S3 via le module complémentaire Amazon EKS. Vous pouvez utiliser les outils suivants pour ajouter le module complémentaire à votre cluster :
+ [eksctl](#eksctl_s3_add_store_app_data)
+ [AWS Management Console](#console_s3_add_store_app_data)
+ [AWS CLI](#awscli_s3_add_store_app_data)
Vous pouvez également installer le pilote CSI Mountpoint pour Amazon S3 en tant qu’installation autogérée. Pour savoir comment procéder à une installation autogérée, consultez [Installation](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/docs/install.md#deploy-driver) sur GitHub.
À partir de la version `v1.8.0`, vous pouvez configurer les rejets à tolérer pour les pods du pilote CSI. Pour ce faire, spécifiez un ensemble personnalisé de rejets à tolérer avec `node.tolerations` ou tolérez tous les rejets avec `node.tolerateAllTaints`. Pour plus d’informations, consultez [Rejets et tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dans la documentation de Kubernetes.
### eksctl
**Pour ajouter le module complémentaire CSI Amazon S3 à l’aide de `eksctl` **
Exécutez la commande suivante. Remplacez *my-cluster* par le nom de votre cluster, *111122223333* par l'ID de votre compte et *AmazonEKS\$1S3\$1CSI\$1DriverRole* par le nom du [rôle IAM créé précédemment](#s3-create-iam-role).
```
eksctl create addon --name aws-mountpoint-s3-csi-driver --cluster my-cluster \
--service-account-role-arn arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole --force
```
Si vous supprimez l'option *--force* et si des paramètres du module complémentaire Amazon EKS entrent en conflit avec vos paramètres existants, alors la mise à jour du module complémentaire Amazon EKS échoue et vous recevez un message d'erreur pour vous aider à résoudre le conflit. Avant de spécifier cette option, assurez-vous que le module complémentaire Amazon EKS ne gère pas les paramètres que vous devez gérer, car ces paramètres sont remplacés par cette option. Pour plus d'informations sur les autres options de ce paramètre, consultez [Modules complémentaires](https://eksctl.io/usage/addons/) dans la documentation `eksctl`. Pour plus d’informations sur la gestion des champs Amazon EKS Kubernetes, consultez [Déterminez les champs que vous pouvez personnaliser pour les modules complémentaires Amazon EKS](kubernetes-field-management.md).
Vous pouvez personnaliser `eksctl` à l’aide de fichiers de configuration. Pour plus d’informations, consultez [Utilisation des valeurs de configuration](https://eksctl.io/usage/addons/#working-with-configuration-values) dans la documentation `eksctl`. L’exemple suivant montre comment tolérer tous les rejets.
```
# config.yaml
...
addons:
- name: aws-mountpoint-s3-csi-driver
serviceAccountRoleARN: arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole
configurationValues: |-
node:
tolerateAllTaints: true
```
### AWS Management Console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Choisissez le nom du cluster pour lequel vous voulez configurer le module complémentaire Mountpoint pour Amazon S3 CSI.
1. Choisissez l’onglet **Modules complémentaires**.
1. Choisissez **Obtenez plus de modules complémentaires**.
1. Sur la page **Sélectionner des modules complémentaires**, procédez comme suit :
1. Dans la section **Modules complémentaires Amazon EKS**, sélectionnez la case à cocher **Pilote CSI Mountpoint pour Amazon S3**.
1. Choisissez **Suivant**.
1. Sur la page **Configurer les paramètres des modules complémentaires sélectionnés**, procédez comme suit :
1. Sélectionnez la **Version** que vous souhaitez utiliser.
1. Pour **Sélectionner un rôle IAM**, sélectionnez le nom d’un rôle IAM auquel vous avez associé la politique IAM du pilote CSI Mountpoint pour Amazon S3.
1. (Facultatif) Mettez à jour la **Méthode de résolution des conflits** après avoir développé les **Paramètres de configuration facultatifs**. Si vous sélectionnez **Remplacer**, un ou plusieurs paramètres du module complémentaire existant peuvent être remplacés par les paramètres du module complémentaire Amazon EKS. Si vous n’activez pas cette option et qu’il y a un conflit avec vos paramètres existants, l’opération échoue. Vous pouvez utiliser le message d'erreur qui en résulte pour résoudre le conflit. Avant de sélectionner cette option, veuillez vous assurer que le module complémentaire Amazon EKS ne gère pas les paramètres que vous devez gérer vous-même.
1. (Facultatif) Veuillez configurer les tolérances dans le champ **Valeurs de configuration** après avoir développé les **Paramètres de configuration facultatifs**.
1. Choisissez **Suivant**.
1. Sur la page **Vérifier et ajouter**, choisissez **Créer**. Une fois l'installation du module complémentaire terminée, vous pouvez voir le module complémentaire installé.
### AWS CLI
**Pour ajouter le module complémentaire CSI Mountpoint pour Amazon S3 à l'aide de la CLI AWS **
Exécutez la commande suivante. Remplacez *my-cluster* par le nom de votre cluster, *111122223333* par l'ID de votre compte, et *AmazonEKS\$1S3\$1CSI\$1DriverRole* par le nom du rôle créé précédemment.
```
aws eks create-addon --cluster-name my-cluster --addon-name aws-mountpoint-s3-csi-driver \
--service-account-role-arn arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole
```
Vous pouvez personnaliser la commande à l’aide de l’indicateur `--configuration-values`. L’exemple alternatif suivant montre comment tolérer tous les rejets.
```
aws eks create-addon --cluster-name my-cluster --addon-name aws-mountpoint-s3-csi-driver \
--service-account-role-arn arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole \
--configuration-values '{"node":{"tolerateAllTaints":true}}'
```
## Étape 4 : configurer Mountpoint pour Amazon S3
Dans la plupart des cas, vous pouvez configurer Mountpoint pour Amazon S3 avec uniquement un nom de compartiment. Pour obtenir des instructions sur la configuration de Mountpoint pour Amazon S3, consultez [Configuration de Mountpoint pour Amazon S3 sur](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md). GitHub
## Étape 5 : déployer un exemple d’application
Vous pouvez déployer l'allocation statique au pilote sur un compartiment Amazon S3 existant. Pour plus d'informations, consultez la section [Provisionnement statique](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/examples/kubernetes/static_provisioning/README.md) activé GitHub.
# Supprimer le module complémentaire Mountpoint pour Amazon S3 pour Amazon EKS
Vous disposez de deux options pour supprimer le [pilote CSI Mountpoint pour Amazon S3](s3-csi.md).
+ **Conserver le logiciel complémentaire sur votre cluster** : cette option supprime la gestion de tous les paramètres par Amazon EKS. Elle supprime également la possibilité pour Amazon EKS de vous informer des mises à jour et de mettre automatiquement à jour le module complémentaire Amazon EKS après le lancement d'une mise à jour. Toutefois, elle préserve le logiciel complémentaire sur votre cluster. Cette option fait du module complémentaire une installation autogérée plutôt qu'un module complémentaire Amazon EKS. Avec cette option, il n’y a pas de durée d’indisponibilité pour le module complémentaire. Les commandes dans cette procédure utilisent cette option.
+ **Supprimer entièrement le logiciel complémentaire de votre cluster** : nous vous recommandons de supprimer le module complémentaire Amazon EKS de votre cluster uniquement si aucune ressource de votre cluster n'en dépend. Pour effectuer cette option, supprimez `--preserve` à partir de la commande que vous utilisez dans cette procédure.
Si le module complémentaire est associé à un compte IAM, celui-ci n’est pas supprimé.
Vous pouvez utiliser les outils suivants pour supprimer le module complémentaire Amazon S3 CSI :
+ [eksctl](#eksctl_s3_remove_store_app_data)
+ [AWS Management Console](#console_s3_remove_store_app_data)
+ [AWS CLI](#awscli_s3_remove_store_app_data)
## eksctl
**Pour supprimer le module complémentaire CSI Amazon S3 à l’aide de `eksctl` **
Remplacez *my-cluster* par le nom de votre cluster, puis exécutez la commande suivante.
```
eksctl delete addon --cluster my-cluster --name aws-mountpoint-s3-csi-driver --preserve
```
## AWS Management Console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Choisissez le nom du cluster pour lequel vous souhaitez supprimer le module complémentaire CSI Amazon EBS.
1. Choisissez l'onglet **Modules complémentaires**.
1. Sélectionnez **Pilote CSI Mountpoint pour Amazon S3**.
1. Sélectionnez **Remove (Supprimer)**.
1. Dans la boîte de dialogue de confirmation **Supprimer : aws-mountpoint-s3-csi-driver**, procédez comme suit :
1. Si vous voulez qu'Amazon EKS cesse de gérer les paramètres du module complémentaire, sélectionnez **Conserver sur le cluster**. Faites ceci si vous voulez retenir le logiciel du module complémentaire sur votre cluster. Ceci afin que vous puissiez gérer vous-même tous les paramètres du module complémentaire.
1. Saisissez `aws-mountpoint-s3-csi-driver`.
1. Sélectionnez **Remove** (Retirer).
## AWS CLI
**Pour supprimer le module complémentaire CSI Amazon S3 à l’aide de l’AWS CLI**
Remplacez *my-cluster* par le nom de votre cluster, puis exécutez la commande suivante.
```
aws eks delete-addon --cluster-name my-cluster --addon-name aws-mountpoint-s3-csi-driver --preserve
```
# Activer la fonctionnalité d’instantané pour les volumes CSI
La fonctionnalité Instantané permet de réaliser des copies ponctuelles de vos données. Pour que cette fonctionnalité fonctionne dans Kubernetes, vous avez besoin à la fois d’un pilote CSI prenant en charge les instantanés (tel que le pilote Amazon EBS CSI) et d’un contrôleur d’instantanés CSI. Le contrôleur de snapshot est disponible soit sous forme de module complémentaire géré par Amazon EKS, soit sous forme d’installation autogérée.
Voici quelques éléments à prendre en compte lors de l’utilisation du contrôleur d’instantané CSI.
+ Le contrôleur d’instantané doit être installé aux côtés d’un pilote CSI doté d’une fonctionnalité d’instantané. Pour obtenir les instructions d’installation du pilote CSI Amazon EBS, consultez [Utilisez le stockage de volumes Kubernetes avec Amazon EBS](ebs-csi.md).
+ Kubernetes ne prend pas en charge les instantanés de volumes fournis via la migration CSI, tels que les volumes Amazon EBS utilisant un `StorageClass` avec un provisionneur `kubernetes.io/aws-ebs`. Les volumes doivent être créés avec un `StorageClass` qui fait référence au provisionneur de pilote CSI, `ebs.csi.aws.com`.
+ Le mode automatique Amazon EKS n’inclut pas le contrôleur de snapshots. La capacité de stockage du mode automatique EKS est compatible avec le contrôleur de snapshots.
Nous vous recommandons d’installer le contrôleur d’instantané CSI via le module complémentaire géré Amazon EKS. Ce module complémentaire comprend les définitions de ressources personnalisées (CRD) nécessaires pour créer et gérer des instantanés sur Amazon EKS. 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).
Sinon, si vous souhaitez installer vous-même le contrôleur de snapshots CSI, consultez la section [Utilisation](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage) dans le Kubernetes en amont `external-snapshotter` sur GitHub.