Pilote CSI Amazon FSx pour Lustre - Amazon EKS

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.

Pilote CSI Amazon FSx pour Lustre

Le pilote FSx for Lustre 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 FSx for Lustre. Pour plus d'informations, consultez le Guide de l'utilisateur FSx pour Lustre.

Cette rubrique explique comment déployer le pilote CSI FSx for Lustre 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 sur GitHub.

Note

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

Pour la description détaillée des paramètres disponibles et des exemples complets démontrant les fonctions du pilote, consultez le projet de pilote FSx for Lustre Container Storage Interface (CSI) sur GitHub.

Prérequis

Vous devez disposer de ce qui suit :

  • Version 2.12.3 ou version ultérieure 1.27.160 ou version ou ultérieure du AWS Command Line Interface (AWS CLI) installé et configuré sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez aws --version | cut -d / -f2 | cut -d ' ' -f1. Les gestionnaires de package, par exemple yum, apt-get, Homebrew ou macOS, sont souvent antérieurs de plusieurs versions à la AWS CLI. Pour installer la dernière version, consultez Installation, mise à jour et désinstallation de l’ AWS CLI et Configuration rapide avec aws configure dans le Guide de l’utilisateur AWS Command Line Interface . La AWS CLI version 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 AWS CLI dans votre répertoire personnel dans le guide de AWS CloudShell l'utilisateur.

  • Version 0.175.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 dans la documentation de eksctl.

  • L'outil de ligne de commande kubectl est installé sur votre appareil ou AWS CloudShell. La version peut être identique à la version Kubernetes de votre cluster ou être maximum une version mineure antérieure ou ultérieure. Par exemple, si la version de votre cluster est 1.28, vous pouvez utiliser la version kubectl 1.27, 1.28 ou 1.29. Pour installer ou mettre à niveau kubectl, veuillez consulter Installation ou mise à jour de kubectl.

Les procédures suivantes vous aident à créer un cluster de test simple avec le pilote CSI FSx pour Lustre afin que vous puissiez voir comment il fonctionne. Nous déconseillons l'utilisation du cluster de test pour les charges de travail de production. Pour ce tutoriel, nous vous recommandons d'utiliser les example values, sauf lorsqu'il est noté de les remplacer. Vous pouvez remplacer n'importe quel example value lors des étapes propres à un cluster de production. Nous vous recommandons d'effectuer toutes les étapes dans le même terminal, car les variables sont définies et utilisées tout au long des étapes et n'existent pas dans des terminaux différents.

Pour déployer le pilote CSI FSx for Lustre dans un cluster Amazon EKS
  1. Définissez quelques variables à utiliser lors des étapes restantes. Remplacez-le my-csi-fsx-cluster par le nom du cluster de test que vous souhaitez créer et region-code par le Région AWS nom dans lequel vous souhaitez créer votre cluster de test.

    export cluster_name=my-csi-fsx-cluster export region_code=region-code
  2. Créez un cluster de test.

    eksctl create cluster \ --name $cluster_name \ --region $region_code \ --with-oidc \ --ssh-access \ --ssh-public-key my-key

    L'approvisionnement de cluster dure plusieurs minutes. Lors de la création du cluster, vous verrez plusieurs lignes de sortie. La dernière ligne de sortie est similaire à celle de l'exemple suivant.

    [✓]  EKS cluster "my-csi-fsx-cluster" in "region-code" region is ready
  3. Créez un compte Kubernetes de service pour le pilote et associez la politique AmazonFSxFullAccess AWS gérée au compte de service à l'aide de la commande suivante. Si votre cluster se trouve dans AWS GovCloud (USA Est) ou AWS GovCloud (USA Ouest) Régions AWS, remplacez-le pararn:aws:. arn:aws-us-gov:

    eksctl create iamserviceaccount \ --name fsx-csi-controller-sa \ --namespace kube-system \ --cluster $cluster_name \ --attach-policy-arn arn:aws:iam::aws:policy/AmazonFSxFullAccess \ --approve \ --role-name AmazonEKSFSxLustreCSIDriverFullAccess \ --region $region_code

    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-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
    [ℹ]  deploying stack "eksctl-my-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
    [ℹ]  waiting for CloudFormation stack "eksctl-my-csi-fsx-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-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa.

  4. Installez le pilote avec la commande suivante : Remplacez release-X.XX par la branche de votre choix. La branche master n'est pas prise en charge car elle peut contenir des fonctionnalités à venir incompatibles avec la version stable du pilote actuellement disponible. Nous vous recommandons d'utiliser la dernière version publiée. Pour obtenir la liste des branches actives, voir aws-fsx-csi-driverci-dessous GitHub.

    Note

    Vous pouvez afficher le contenu appliqué dans aws-fsx-csi-driver sur GitHub.

    kubectl apply -k "github.com/kubernetes-sigs/aws-fsx-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-X.XX"

    L'exemple qui suit illustre un résultat.

    serviceaccount/fsx-csi-controller-sa created
    serviceaccount/fsx-csi-node-sa created
    clusterrole.rbac.authorization.k8s.io/fsx-csi-external-provisioner-role created
    clusterrole.rbac.authorization.k8s.io/fsx-external-resizer-role created
    clusterrolebinding.rbac.authorization.k8s.io/fsx-csi-external-provisioner-binding created
    clusterrolebinding.rbac.authorization.k8s.io/fsx-csi-resizer-binding created
    deployment.apps/fsx-csi-controller created
    daemonset.apps/fsx-csi-node created
    csidriver.storage.k8s.io/fsx.csi.aws.com created
  5. Notez l'ARN du rôle créé. Si vous ne l'avez pas noté plus tôt et qu'il n'est plus disponible dans la AWS CLI sortie, vous pouvez procéder comme suit pour le voir dans le AWS Management Console.

    1. Ouvrez la AWS CloudFormation console à l'adresse https://console.aws.amazon.com/cloudformation.

    2. Assurez-vous que la console est configurée sur Région AWS celle dans laquelle vous avez créé votre rôle IAM, puis sélectionnez Stacks.

    3. Sélectionnez la pile nommée eksctl-my-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa.

    4. Sélectionnez l'onglet Outputs (Sorties). L'ARN Role1 est répertorié sur la page Sorties (1).

  6. Appliquez un correctif sur le déploiement du pilote pour ajouter le compte de service que vous avez créé précédemment avec la commande suivante. Remplacez l'ARN par l'ARN que vous avez noté. Remplacez 111122223333 par votre ID de compte. Si votre cluster se trouve dans AWS GovCloud (USA Est) ou AWS GovCloud (USA Ouest) Régions AWS, remplacez-le pararn:aws:. arn:aws-us-gov:

    kubectl annotate serviceaccount -n kube-system fsx-csi-controller-sa \ eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/AmazonEKSFSxLustreCSIDriverFullAccess --overwrite=true

    L'exemple qui suit illustre un résultat.

    serviceaccount/fsx-csi-controller-sa annotated
Pour déployer une classe de stockage Kubernetes, une revendication de volume persistant et une application type afin de vérifier que le pilote CSI fonctionne

Cette procédure utilise le référentiel GitHub du pilote FSx for Lustre Container Storage Interface (CSI) pour utiliser un volume FSx for Lustre alloué dynamiquement.

  1. Notez le groupe de sécurité de votre cluster. Vous pouvez le voir dans la section Réseau AWS Management Console sous la section Réseau ou en utilisant la AWS CLI commande suivante.

    aws eks describe-cluster --name $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId
  2. Créez un groupe de sécurité pour votre système de fichiers Amazon FSx en fonction des critères indiqués dans Groupes de sécurité Amazon VPC dans le Guide de l'utilisateur Amazon FSx pour 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.

  3. 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
  4. Modifiez la section des paramètres du fichier storageclass.yaml. Remplacez chaque example value 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 du sous-réseau dans lequel le système de fichiers Amazon FSx pour 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 à l'adresse https://console.aws.amazon.com/fsx/ pour confirmer 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, vos VPC doivent être connectés et vous devez 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, voir Créer votre système de fichiers Amazon FSx for Lustre.

    • autres paramètres (facultatif) — Pour plus d'informations sur les autres paramètres, voir Modifier StorageClass surGitHub.

  5. 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
  6. 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
  7. (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.

  8. Créez la revendication de volume persistant.

    kubectl apply -f claim.yaml

    L'exemple qui suit illustre un résultat.

    persistentvolumeclaim/fsx-claim created
  9. 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.

  10. 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
  11. 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
  12. 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
  13. Vérifiez que les données ont été écrites sur 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, veillez à supprimer le système de fichiers FSx for Lustre. Pour de plus d'informations, veuillez consulter Nettoyage des ressources dans le Guide de l'utilisateur FSx for Lustre.