**Unterstützung für die Verbesserung dieser Seite beitragen**
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Stellen Sie den FSx for Lustre-Treiber bereit
In diesem Thema erfahren Sie, wie Sie den [FSx for Lustre CSI-Treiber](fsx-csi.md) in Ihrem Amazon EKS-Cluster bereitstellen und überprüfen, ob er funktioniert. Wir empfehlen die neueste Version des Treibers zu verwenden. Die verfügbaren Versionen finden Sie in der [Kompatibilitätsmatrix der CSI-Spezifikation](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/README.md#csi-specification-compatibility-matrix) unter GitHub.
**Anmerkung**
Der Treiber wird in Fargate oder Amazon EKS Hybrid Nodes nicht unterstützt.
Eine ausführliche Beschreibung der verfügbaren Parameter und vollständige Beispiele zur Veranschaulichung der Treiberfunktionen finden Sie im [Treiberprojekt FSx for Lustre Container Storage Interface (CSI)](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) unter GitHub.
## Voraussetzungen
+ Einen vorhandenen -Cluster.
+ Das Amazon FSx CSI Driver EKS-Add-On benötigt den EKS Pod Identity-Agenten für die Authentifizierung. Ohne diese Komponente schlägt das Add-On mit dem Fehler `Amazon EKS Pod Identity agent is not installed in the cluster` fehl, wodurch Volume-Operationen verhindert werden. Installieren Sie den Pod Identity-Agenten vor oder nach der Bereitstellung des FSx CSI-Treiber-Add-ons. Weitere Informationen finden Sie unter [Einrichtung des Amazon-EKS-Pod-Identity-Agenten](pod-id-agent-setup.md).
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Version `0.215.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](https://eksctl.io/installation).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer 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 [`kubectl` und `eksctl` einrichten](install-kubectl.md).
## Schritt 1: Erstellen einer IAM-Rolle
Das Amazon FSx CSI-Plugin benötigt IAM-Berechtigungen, um in Ihrem Namen Anrufe tätigen AWS APIs zu können.
**Anmerkung**
Pods haben Zugriff auf die Berechtigungen, die der IAM-Rolle zugewiesen sind, es sei denn, Sie blockieren den Zugriff auf IMDS. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster mit bewährten Methoden sichern](security-best-practices.md).
Das folgende Verfahren zeigt Ihnen, wie Sie eine IAM-Rolle erstellen und ihr die AWS verwaltete Richtlinie zuordnen.
1. Erstellen Sie eine IAM-Rolle und fügen Sie die AWS verwaltete Richtlinie mit dem folgenden Befehl an. Ersetzen Sie `my-cluster` durch den Namen des Clusters, den Sie verwenden möchten. Der Befehl stellt einen AWS CloudFormation Stack bereit, der eine IAM-Rolle erstellt und ihr die IAM-Richtlinie anhängt.
```
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
```
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-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"
```
Notieren Sie sich den Namen des AWS CloudFormation Stacks, der bereitgestellt wurde. In der vorigen Beispielausgabe lautet der Name des Stacks `eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa`.
Nachdem Sie die IAM-Rolle des Amazon FSx CSI-Treibers erstellt haben, können Sie mit dem nächsten Abschnitt fortfahren. Wenn Sie das Add-on mit dieser IAM-Rolle bereitstellen, wird ein Servicekonto mit dem Namen `fsx-csi-controller-sa` erstellt und für die Verwendung konfiguriert. Das Servicekonto ist an ein Kubernetes `clusterrole` gebunden, dem die erforderlichen Kubernetes-Berechtigungen zugewiesen sind.
## Schritt 2: Installieren Sie den Amazon FSx CSI-Treiber
Wir empfehlen, den Amazon FSx CSI-Treiber über das Amazon EKS-Add-on zu installieren, um die Sicherheit zu verbessern und den Arbeitsaufwand zu reduzieren. Wenn Sie ein Amazon-EKS-Add-on zu Ihrem Cluster hinzufügen möchten, lesen Sie [Erstellung eines Amazon-EKS-Add-Ons](creating-an-add-on.md). Weitere Informationen zu Add-ons finden Sie unter [Amazon-EKS-Add-ons](eks-add-ons.md).
**Wichtig**
Bereits vorhandene Amazon FSx CSI-Treiberinstallationen im Cluster können zu Fehlern bei der Installation von Add-Ons führen. Wenn Sie versuchen, die Amazon EKS-Add-On-Version zu installieren, während ein FSx Nicht-EKS-CSI-Treiber vorhanden ist, schlägt die Installation aufgrund von Ressourcenkonflikten fehl. Verwenden Sie während der Installation das `OVERWRITE`-Flag, um dieses Problem zu beheben.
```
aws eks create-addon --addon-name aws-fsx-csi-driver --cluster-name my-cluster --resolve-conflicts OVERWRITE
```
Wenn Sie alternativ eine selbstverwaltete Installation des Amazon FSx CSI-Treibers wünschen, finden Sie weitere Informationen unter [Installation](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/install.md) auf GitHub.
## Schritt 3: Speicherklasse, persistenter Volume-Anspruchs und Beispiel-App bereitstellen
Bei diesem Verfahren wird das [ GitHub Treiber-Repository FSx für Lustre Container Storage Interface (CSI)](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) verwendet, um ein dynamisch FSx bereitgestelltes Volume für Lustre zu nutzen.
1. Beachten Sie die Sicherheitsgruppe für Ihren Cluster. Sie können es im AWS-Managementkonsole Abschnitt **Netzwerk** oder mit dem folgenden AWS CLI-Befehl sehen. Ersetzen Sie `my-cluster` durch den Namen des Clusters, den Sie verwenden möchten.
```
aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```
1. Erstellen Sie eine Sicherheitsgruppe für Ihr FSx Amazon-Dateisystem gemäß den Kriterien, die im [Amazon FSx for Lustre-Benutzerhandbuch unter Amazon VPC-Sicherheitsgruppen](https://docs.aws.amazon.com/fsx/latest/LustreGuide/limit-access-security-groups.html#fsx-vpc-security-groups) aufgeführt sind. 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.
1. 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
```
1. Bearbeiten Sie den Parameterabschnitt in der Datei `storageclass.yaml`. Ersetzen Sie jeden Beispielwert 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 der suchen, AWS-Managementkonsole indem Sie die Knotengruppe im Abschnitt Compute auswählen.**
+ Wenn das von Ihnen angegebene Subnetz nicht dasselbe Subnetz ist, in dem Sie Knoten haben, VPCs müssen Sie [verbunden](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html) sein und 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](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step1.html).
+ **andere Parameter (optional)** — Informationen zu den anderen Parametern finden Sie unter [Bearbeiten StorageClass](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass) am GitHub.
1. Erstellen Sie das Speicherklassen-Manifest.
```
kubectl apply -f storageclass.yaml
```
Eine Beispielausgabe sieht wie folgt aus.
```
storageclass.storage.k8s.io/fsx-sc created
```
1. 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
```
1. (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.
1. Erstellen Sie den dauerhaften Volume-Anspruch.
```
kubectl apply -f claim.yaml
```
Eine Beispielausgabe sieht wie folgt aus.
```
persistentvolumeclaim/fsx-claim created
```
1. 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.
1. 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
```
1. 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
```
1. Ü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
```
1. 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 [Ressourcen bereinigen](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step4.html) im *FSx for Lustre-Benutzerhandbuch*.
## Leistungssteigerung für FSx für Lustre
Wenn Sie FSx for Lustre mit Amazon EKS verwenden, können Sie die Leistung optimieren, indem Sie Lustre-Tunings während der Knoteninitialisierung anwenden. Der empfohlene Ansatz besteht darin, Startvorlagen-Benutzerdaten zu verwenden, um eine konsistente Konfiguration auf allen Knoten sicherzustellen.
Diese Optimierungen umfassen:
+ Netzwerk- und RPC-Optimierungen
+ Lustre-Modulverwaltung
+ LRU-Abstimmungen (Lock Resource Unit)
+ Einstellungen für die Client-Cache-Steuerung
+ RPC-Steuerungen für OST und MDC
Für detaillierte Anweisungen zur Implementierung dieser Leistungsoptimierungen:
+ Zur Optimierung der Leistung für Standardknoten (nicht EFA) finden Sie unter [Optimieren Sie die Leistung von Amazon FSx for Lustre auf Knoten (ohne EFA)](fsx-csi-tuning-non-efa.md) ein vollständiges Skript, das Sie zu Ihren Benutzerdaten der Startvorlage hinzufügen können.
+ Informationen zur Optimierung der Leistung für EFA-fähige Knoten finden Sie unter [Optimieren Sie die Leistung von Amazon FSx for Lustre auf Knoten (EFA)](fsx-csi-tuning-efa.md).