Amazon FSx for Lustre-CSI-Treiber

Der Treiber für FSx for Lustre Container Storage Interface (CSI) bietet eine CSI-Schnittstelle, mit der Amazon-EKS-Cluster den Lebenszyklus von FSx-for-Lustre-Dateisystemen verwalten können. Weitere Informationen finden Sie im FSx-for-Lustre-Benutzerhandbuch.

In diesem Thema erfahren Sie, wie Sie den FSx-for-Lustre-CSI-Treiber für Ihren Amazon-EKS-Cluster bereitstellen und überprüfen, ob er funktioniert. Wir empfehlen die neueste Version des Treibers zu verwenden. Verfügbare Versionen finden Sie in der Kompatibilitätsmatrix der CSI-Spezifikation unter GitHub.

Anmerkung

Der Treiber wird auf Fargate nicht unterstützt.

Detaillierte Beschreibungen der verfügbaren Parameter und vollständige Beispiele, die die Features des Treibers demonstrieren, finden Sie im Projekt Treiber für FSx for Lustre Container Storage Interface (CSI) auf GitHub.

Voraussetzungen

Sie müssen über Folgendes verfügen:

• Version 2.12.3 oder höher oder Version 1.27.160 oder höher von AWS Command Line Interface (AWS CLI), die auf Ihrem Gerät installiert und konfiguriert ist, oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie aws --version | cut -d / -f2 | cut -d ' ' -f1. Paket-Manager wie yum, apt-get oder Homebrew für macOS sind oft mehrere Versionen hinter der neuesten Version von AWS CLI. Informationen zur Installation der neuesten Version von finden Sie unter Installation, Aktualisierung und Deinstallation der AWS CLI und Schnellkonfiguration mit aws configure im AWS Command Line Interface -Benutzerhandbuch. Die AWS CLI Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie unter Installation AWS CLI in Ihrem Home-Verzeichnis im AWS CloudShell Benutzerhandbuch.

• Version 0.183.0 oder höher des eksctl-Befehlszeilen-Tools, das auf Ihrem Computer oder in der AWS CloudShell installiert ist. Informationen zum Installieren und Aktualisieren von eksctl finden Sie in der Dokumentation zu eksctl unter Installation.

• Das kubectl-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann der Kubernetes-Version Ihres Clusters entsprechen oder eine Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise 1.29 ist, können Sie kubectl-Version 1.28, 1.29, oder 1.30 damit verwenden. Informationen zum Installieren oder Aktualisieren von kubectl finden Sie unter Installieren oder Aktualisieren von kubectl.

Die folgenden Verfahren helfen Ihnen beim Erstellen eines einfachen Testclusters mit dem CSI-Treiber für FSx für Lustre, damit Sie sehen können, wie es funktioniert. Es wird nicht empfohlen, den Test-Cluster für Produktions-Workloads zu verwenden. Für dieses Tutorial empfehlen wir die Verwendung der example values, außer es gibt eine Anmerkung, diese zu ersetzen. Sie können jeden example value ersetzen, wenn Sie die Schritte für einen Produktionscluster ausführen. Wir empfehlen, alle Schritte auf demselben Terminal auszuführen, weil Variablen während der Schritte festgelegt und verwendet werden und diese in anderen Terminals nicht vorhanden sind.

So stellen Sie den Treiber für FSx for Lustre CSI in einem Amazon-EKS-Cluster bereit

1. Legen Sie einige Variablen fest, die in den verbleibenden Schritten verwendet werden sollen. my-csi-fsx-clusterErsetzen Sie es durch den Namen des Testclusters, den Sie erstellen möchten, und region-code durch den Namen AWS-Region , in dem Sie Ihren Testcluster erstellen möchten.

   export cluster_name=my-csi-fsx-cluster
   export region_code=region-code
   

2. Erstellen Sie einen Testcluster.

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

   Die Clusterbereitstellung dauert mehrere Minuten. Während der Clustererstellung werden mehrere Ausgabezeilen angezeigt. Die letzte Ausgabezeile ähnelt der folgenden Beispielzeile.

   [✓]  EKS cluster "my-csi-fsx-cluster" in "region-code" region is ready

3. Erstellen Sie ein Kubernetes Dienstkonto für den Treiber und fügen Sie die AmazonFSxFullAccess AWS-managed Policy mit dem folgenden Befehl an das Dienstkonto an. Wenn sich Ihr Cluster in den Ländern AWS GovCloud (US-Ost) oder AWS GovCloud (US-West) befindet AWS-Regionen, ersetzen Sie ihn durch. arn: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
   

   Beim Erstellen des Servicekontos werden Ihnen mehrere Ausgabezeilen angezeigt. Die letzten Ausgabezeilen ähneln den folgenden.

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

   Notieren Sie sich den Namen des AWS CloudFormation Stacks, der bereitgestellt wurde. In der vorigen Beispielausgabe lautet der Name des Stacks eksctl-my-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa.

4. Stellen Sie den Treiber mit dem folgenden Befehl bereit. Ersetzen Sie release-X.XX durch die gewünschte Branch. Die Master-Branch wird nicht unterstützt, da sie möglicherweise zukünftige Features enthält, die mit der aktuell veröffentlichten stabilen Version des Treibers nicht kompatibel sind. Wir empfehlen die Verwendung der neuesten veröffentlichten Version. Eine Liste der aktiven Branches finden Sie aws-fsx-csi-driverunter GitHub.

   Anmerkung

   Sie die angewendeten Inhalte unter aws-fsx-csi-driver auf GitHub anzeigen.

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

   Eine Beispielausgabe sieht wie folgt aus.

   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. Notieren Sie sich den ARN für die Rolle, die erstellt wurde. Wenn Sie es vorher nicht bemerkt haben und es in der AWS CLI Ausgabe nicht mehr verfügbar ist, können Sie wie folgt vorgehen, um es in der zu sehen AWS Management Console.

   1. Öffnen Sie die AWS CloudFormation Konsole unter https://console.aws.amazon.com/cloudformation.

   2. Stellen Sie sicher, dass die Konsole auf die Konsole eingestellt ist AWS-Region , in der Sie Ihre IAM-Rolle erstellt haben, und wählen Sie dann Stacks aus.

   3. Wählen Sie den Stack mit dem Namen eksctl-my-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa aus.

   4. Wählen Sie die Registerkarte Ausgaben aus. Der Role1-ARN wird auf der Seite Outputs (1) ((Ausgaben (1)) aufgeführt.

6. Patchen Sie die Treiberbereitstellung, um das zuvor erstellte Servicekonto mit dem folgenden Befehl hinzuzufügen. Ersetzen Sie den ARN durch den ARN, den Sie notiert haben. Ersetzen Sie 111122223333 durch Ihre Konto-ID. Wenn sich Ihr Cluster in den Ländern AWS GovCloud (US-Ost) oder AWS GovCloud (US-West) befindet AWS-Regionen, ersetzen Sie ihn durch. arn: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
   

   Eine Beispielausgabe sieht wie folgt aus.

   serviceaccount/fsx-csi-controller-sa annotated

Eine Kubernetes-Speicherklasse, einen dauerhaften Volume-Anspruch und eine Beispielanwendung bereitstellen, um zu überprüfen, ob der CSI-Treiber funktioniert

In diesem Verfahren wird das GitHub-Repository-Treiber für FSx für Lustre Container Storage Interface (CSI) verwendet, um ein dynamisch bereitgestelltes FSx-für-Lustre-Volume zu verwenden.

1. Beachten Sie die Sicherheitsgruppe für Ihren Cluster. Sie können es im AWS Management Console Bereich Netzwerk oder mit dem folgenden AWS CLI Befehl sehen.

   aws eks describe-cluster --name $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId
   

2. Erstellen Sie gemäß den im Benutzerhandbuch für Amazon FSx für Lustre unter Amazon-VPC-Sicherheitsgruppen aufgeführten Kriterien eine Sicherheitsgruppe für Ihr Amazon-FSx-Dateisystem. Als VPC wählen Sie die VPC Ihres Clusters aus, die im Abschnitt Networking (Netzwerk) gezeigt wird. Unter „the security groups associated with your Lustre clients“ (die mit Ihren Lustre-Clients verknüpften Sicherheitsgruppen) wählen Sie Ihre Cluster-Sicherheitsgruppe aus. Wenn Sie keine Regeln für ausgehenden Datenverkehr festlegen, können Sie den All traffic (gesamten Datenverkehr) erlauben.

3. Laden Sie das Speicherklassen-Manifest mit dem folgenden Befehl herunter.

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

4. Bearbeiten Sie den Parameterabschnitt in der Datei storageclass.yaml. Ersetzen Sie jede example value durch Ihre eigenen Werte.

   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 – Die Subnetz-ID, in der das Amazon-FSx-for-Lustre-Dateisystem erstellt werden soll. Amazon FSx for Lustre wird nicht in allen Availability Zones unterstützt. Öffnen Sie die Amazon FSx for Lustre-Konsole unter https://console.aws.amazon.com/fsx/, um zu bestätigen, dass sich das Subnetz, das Sie verwenden möchten, in einer unterstützten Availability Zone befindet. Das Subnetz kann Ihre Knoten enthalten oder ein anderes Subnetz oder eine andere VPC sein:

     • Sie können nach den Knoten-Subnetzen in suchen, AWS Management Console indem Sie die Knotengruppe im Abschnitt Compute auswählen.

     • Wenn das von Ihnen angegebene Subnetz nicht das Subnetz ist, in dem Knoten vorhanden sind, müssen die VPCs verbunden sein und Sie müssen sicherstellen, dass die erforderlichen Ports in Ihren Sicherheitsgruppen geöffnet sind.

   • securityGroupIds – Die ID der Sicherheitsgruppe, die Sie für das Dateisystem erstellt haben.

   • deploymentType(optional) – Der Bereitstellungstyp des Dateisystems. Gültige Werte sind SCRATCH_1, SCRATCH_2, PERSISTENT_1 und PERSISTENT_2. Weitere Informationen zu Bereitstellungstypen finden Sie unter Erstellen Sie Ihr Amazon-FSx-for-Lustre-Dateisystem.

   • andere Parameter (optional) — Informationen zu den anderen Parametern finden Sie unter Bearbeiten StorageClass amGitHub.

5. Erstellen Sie das Speicherklassen-Manifest.

   kubectl apply -f storageclass.yaml
   

   Eine Beispielausgabe sieht wie folgt aus.

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

6. Laden Sie das Manifest für den dauerhaften Volume-Anspruch herunter.

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

7. (Optional) Bearbeiten Sie die claim.yaml-Datei. Ändern Sie 1200Gi in einen der folgenden Inkrementwerte, basierend auf Ihren Speicheranforderungen und dem deploymentType, den Sie in einem vorherigen Schritt ausgewählt haben.

   storage: 1200Gi

   • SCRATCH_2 und PERSISTENT – 1.2 TiB, 2.4 TiB oder Schritte von 2,4 TiB über 2,4 TiB.

   • SCRATCH_1 – 1.2 TiB, 2.4 TiB, 3.6 TiB oder Schritte von 3,6 TiB über 3,6 TiB.

8. Erstellen Sie den dauerhaften Volume-Anspruch.

   kubectl apply -f claim.yaml
   

   Eine Beispielausgabe sieht wie folgt aus.

   persistentvolumeclaim/fsx-claim created

9. Vergewissern Sie sich, dass das Dateisystem bereitgestellt wurde.

   kubectl describe pvc
   

   Eine Beispielausgabe sieht wie folgt aus.

   Name:          fsx-claim
   Namespace:     default
   StorageClass:  fsx-sc
   Status:        Bound
   [...]

   Anmerkung

   Der Status kann für 5-10 Minuten als Pending angezeigt werden, bevor er zu Bound wechselt. Fahren Sie nicht mit dem nächsten Schritt fort, bis der Status Bound ist. Wenn der Status länger als 10 Minuten Pending anzeigt, verwenden Sie die Warnmeldungen in den Events als Referenz zur Behebung von Problemen.

10. Stellen Sie die Beispielanwendung bereit.

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

11. Stellen Sie sicher, dass die Beispielanwendung ausgeführt wird.

    kubectl get pods
    

    Eine Beispielausgabe sieht wie folgt aus.

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

12. Überprüfen Sie, ob das Dateisystem ordnungsgemäß von der Anwendung aufgespielt wurde.

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

    Eine Beispielausgabe sieht wie folgt aus.

    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. Stellen Sie sicher, dass Daten von der Beispiel-App in das FSx-for-Lustre-Dateisystem geschrieben wurden.

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

    Eine Beispielausgabe sieht wie folgt aus.

    out.txt

    Diese Beispielausgabe zeigt, dass die Beispiel-App erfolgreich die out.txt-Datei in das Dateisystem geschrieben hat.

Anmerkung

Stellen Sie vor dem Löschen des Clusters sicher, dass Sie das FSx-for-Lustre-Dateisystem löschen. Weitere Informationen finden Sie unter Bereinigen von Ressourcen im Benutzerhandbuch zu FSx for Lustre.