

 **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.

# EFA-Geräte auf Amazon EKS verwalten
<a name="device-management-efa"></a>

 [Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) (EFA) ist ein Netzwerkgerät für Amazon EC2 EC2-Instances, das leistungsstarke Kommunikation zwischen Knoten und RDMA (Remote Direct Memory Access) für künstliche Intelligenz, maschinelles Lernen und High Performance Computing (HPC) -Workloads ermöglicht. *Amazon EKS unterstützt zwei Mechanismen für die Verwaltung von EFA-Geräten in EKS-Clustern: den *EFA Dynamic Resource Allocation (DRA) -Treiber (DRANET)* und das EFA-Geräte-Plugin.*

Es wird empfohlen, den EFA-DRA-Treiber (DRANET) für neue Bereitstellungen auf EKS-Clustern zu verwenden, auf denen Kubernetes Version 1.34 oder höher mit von EKS verwalteten Knotengruppen oder selbstverwalteten Knotengruppen ausgeführt wird. Mit dem EFA-DRA-Treiber können Sie eine topologieorientierte Zuweisung konfigurieren, die EFA-Schnittstellen mit ihren topologisch-lokalen GPUs oder Neuron-Geräten verbindet und die gemeinsame Nutzung von Geräten zwischen Pods unterstützt.

Der EFA-DRA-Treiber wird im automatischen Modus von Karpenter oder EKS nicht unterstützt. Verwenden Sie das [EFA-Geräte-Plugin](#eks-efa-device-plugin) mit Karpenter und EKS Auto Mode. Das EFA-Geräte-Plugin wird auch weiterhin für von EKS verwaltete Knotengruppen und selbstverwaltete Knoten unterstützt.

## EFA-DRA-Treiber im Vergleich zum EFA-Geräte-Plugin
<a name="eks-efa-dra-vs-device-plugin"></a>


| Feature | EFA-DRA-Treiber | EFA-Geräte-Plugin | 
| --- | --- | --- | 
| Mindestversion von Kubernetes | 1.34 | Alle EKS-supported Kubernetes-Versionen | 
| EKS Compute | Verwaltete Knotengruppen, selbstverwaltete Knoten | EKS Auto Mode, Karpenter, verwaltete Knotengruppen, selbstverwaltete Knoten | 
| EKS-optimized AMIs | AL2023 (NVIDIA, Neuron), Bottlerocket | AL2023 (NVIDIA, Neuron), Bottlerocket | 
| Werbung für Geräte | Umfangreiche Attribute über `ResourceSlice` Objekte wie Gerätetyp, Topologie und PCIe-Lokalität | Ganzzahlzahl erweiterter Ressourcen `vpc.amazonaws.com/efa` | 
| GPU-EFA Affinität | DRA-native Bewusstsein für Topologie | Automatische Topologieerkennung (nur EKS-optimized AL2023-AMIs) | 
| Neuron-EFA Affinität | DRA-native Bewusstsein für Topologie | Automatische Topologieerkennung (nur EKS-optimized AL2023-AMIs) | 
| Gemeinsame Nutzung von Geräten | Mehrere Pods können dasselbe EFA-Gerät über gemeinsame `ResourceClaim` Referenzen gemeinsam nutzen | Nicht unterstützt Jedes EFA-Gerät ist ausschließlich einem Pod zugewiesen. | 

## EKS-Knoten mit EFA-Schnittstellen erstellen
<a name="eks-efa-nodes"></a>

Wenn Sie EKS-Knoten mit EFA-Schnittstellen erstellen, werden die EFA-Schnittstellen während der Instanzbereitstellung an die Instanz angehängt. Sie können die EFA-Konfiguration pro Gerät anpassen und [Platzierungsgruppen mit Karpenter, EKS-verwalteten Knotengruppen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) oder selbstverwalteten EKS-Knotengruppen verwenden. Mit Karpenter übergeben Sie die Konfiguration für jede Netzwerkschnittstelle über die. `NodeClass` [Bei von EKS verwalteten Knotengruppen oder selbstverwalteten Knoten übergeben Sie die Konfiguration für jede Netzwerkschnittstelle mit Startvorlagen.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) Die Unterstützung des automatischen Modus von EKS für gerätespezifische EFA-Konfigurationen und Platzierungsgruppen ist in Kürze verfügbar.

Bei Verwendung dieser `efaEnabled` Einstellung [`eksctl`](install-kubectl.md#eksctl-install-update)für die Bereitstellung von EKS-Knoten werden alle Schnittstellen mit dem Schnittstellentyp konfiguriert`EFA`, eine EFA-specific Sicherheitsgruppe wird erstellt und das EFA-Geräte-Plug-In wird auf dem Cluster installiert. [Wenn Sie bei der Verwendung die EFA-Konfiguration pro Gerät anpassen müssen, wird empfohlen`eksctl`, die Unterstützung von `eksctl für Startvorlagen zu verwenden.](https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html)

Die folgenden Beispiele zeigen, wie Vorlagen mit EFA-Schnittstellen konfiguriert `NodeClass` und gestartet werden. Dies ist nützlich, um die Schnittstellen, die für EFA-Verkehr verwendet werden, im Vergleich zu IP-based Standarddatenverkehr anzupassen. Informationen zur Anzahl der von den einzelnen Instance-Typen unterstützten EFA-Schnittstellen und zur Konfiguration dieser Schnittstellen für maximale Netzwerkbandbreite finden Sie unter [Maximieren der Netzwerkbandbreite für EFA-enabled Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) im *Amazon EC2 EC2-Benutzerhandbuch*.

## Karpenter
<a name="eks-efa-auto-karpenter"></a>

Jeder Eintrag in `networkInterfaces` gibt ein `networkCardIndex``deviceIndex`, und an. `interfaceType` Dies `interfaceType` kann `interface` für Standard-Netzwerkschnittstellen oder `efa-only` für EFA-Schnittstellen sein, die für RDMA-Verkehr vorgesehen sind und denen keine IP-Adressen zugewiesen sind. Wenn `networkInterfaces` konfiguriert, `NodeClass` verwenden Instances, die von der `NodePool` referenzierenden Person gestartet wurden, diese Konfiguration unabhängig davon, ob Pods Ressourcen anfordern. `vpc.amazonaws.com/efa`

Wenn Sie Karpenter ohne Angabe `networkInterfaces` in Ihrem verwenden, werden für Instanzen`NodeClass`, die für Pods erstellt wurden, die Anfragen `vpc.amazonaws.com/efa` stellen, alle Schnittstellen mit dem Schnittstellentyp konfiguriert. `EFA`

Die `networkInterfaces` Konfiguration für `EC2NodeClass` wurde in Karpenter v1.11 hinzugefügt. Das folgende Beispiel zeigt eine `EC2NodeClass` Konfiguration für eine P6-B200 Instanz mit 1 ENA-Schnittstelle und 8 Schnittstellen. EFA-only 

### Beispiel Karpenter EC2NodeClass mit EFA-only Schnittstellen für P6-B200
<a name="eks-efa-karpenter-example"></a>

```
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: efa-node-class
spec:
  networkInterfaces:
  - networkCardIndex: 0
    deviceIndex: 0
    interfaceType: interface
  - networkCardIndex: 0
    deviceIndex: 1
    interfaceType: efa-only
  - networkCardIndex: 1
    deviceIndex: 0
    interfaceType: efa-only
  - networkCardIndex: 2
    deviceIndex: 0
    interfaceType: efa-only
  - networkCardIndex: 3
    deviceIndex: 0
    interfaceType: efa-only
  - networkCardIndex: 4
    deviceIndex: 0
    interfaceType: efa-only
  - networkCardIndex: 5
    deviceIndex: 0
    interfaceType: efa-only
  - networkCardIndex: 6
    deviceIndex: 0
    interfaceType: efa-only
  - networkCardIndex: 7
    deviceIndex: 0
    interfaceType: efa-only
```

## Von EKS verwaltete Knotengruppen und selbstverwaltete Knoten
<a name="eks-efa-mng-self-managed"></a>

Bei von EKS verwalteten Knotengruppen oder selbstverwalteten Knoten übergeben Sie die Konfiguration für jede Netzwerkschnittstelle mit [Startvorlagen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html).

Das folgende Beispiel zeigt eine Startvorlage, die für eine P6-B200 Instance mit 1 ENA-Schnittstelle und 8 EFA-only Schnittstellen konfiguriert ist. Die primäre Netzwerkschnittstelle (Netzwerkkarte 0, Geräteindex 0) verwendet einen `interface` Standardtyp für IP-Verkehr, während zusätzliche Schnittstellen `efa-only` für dedizierten RDMA-Verkehr verwendet werden. Passen Sie die Anzahl der `efa-only` Schnittstellen an Ihren Instanztyp an. Die Anzahl der von den einzelnen Instance-Typen unterstützten EFA-Schnittstellen finden Sie unter [Maximieren der Netzwerkbandbreite für EFA-enabled Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) im *Amazon EC2 EC2-Benutzerhandbuch*.

### Beispiel für eine Startvorlage mit EFA-only Schnittstellen für P6-B200
<a name="eks-efa-launch-template-example"></a>

Ersetze es ` security-group-id ` durch deine Werte. Die Sicherheitsgruppe muss den gesamten eingehenden und ausgehenden Datenverkehr zu und von sich selbst zulassen, um die OS-bypass EFA-Funktionalität zu aktivieren. Weitere Informationen finden Sie unter [Schritt 1: Eine EFA-enabled Sicherheitsgruppe vorbereiten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) im *Amazon EC2 EC2-Benutzerhandbuch*.

**Wichtig**  
Geben Sie `SubnetId` in der Startvorlage nichts an, wenn Sie verwaltete EKS-Knotengruppen verwenden. EKS verlangt, dass alle Subnetze über die `CreateNodegroup` API angegeben werden, und lehnt Startvorlagen ab, die eine Subnetzkonfiguration enthalten.

```
{
  "LaunchTemplateName": "efa-launch-template",
  "LaunchTemplateData": {
    "InstanceType": "p6-b200.48xlarge",
    "NetworkInterfaces": [
      {
        "NetworkCardIndex": 0,
        "DeviceIndex": 0,
        "InterfaceType": "interface",
        "Groups": ["security-group-id"]
      },
      {
        "NetworkCardIndex": 0,
        "DeviceIndex": 1,
        "InterfaceType": "efa-only",
        "Groups": ["security-group-id"]
      },
      {
        "NetworkCardIndex": 1,
        "DeviceIndex": 0,
        "InterfaceType": "efa-only",
        "Groups": ["security-group-id"]
      },
      {
        "NetworkCardIndex": 2,
        "DeviceIndex": 0,
        "InterfaceType": "efa-only",
        "Groups": ["security-group-id"]
      },
      {
        "NetworkCardIndex": 3,
        "DeviceIndex": 0,
        "InterfaceType": "efa-only",
        "Groups": ["security-group-id"]
      },
      {
        "NetworkCardIndex": 4,
        "DeviceIndex": 0,
        "InterfaceType": "efa-only",
        "Groups": ["security-group-id"]
      },
      {
        "NetworkCardIndex": 5,
        "DeviceIndex": 0,
        "InterfaceType": "efa-only",
        "Groups": ["security-group-id"]
      },
      {
        "NetworkCardIndex": 6,
        "DeviceIndex": 0,
        "InterfaceType": "efa-only",
        "Groups": ["security-group-id"]
      },
      {
        "NetworkCardIndex": 7,
        "DeviceIndex": 0,
        "InterfaceType": "efa-only",
        "Groups": ["security-group-id"]
      }
    ]
  }
}
```

## Verwendung von AMIs mit EFA EKS-optimized
<a name="eks-amis-efa"></a>

[Die EKS-optimized AL203-beschleunigten AMIs (NVIDIA und Neuron) und alle Bottlerocket-AMIs enthalten die Komponenten auf Host-Ebene, die für die Verwendung von EFA erforderlich sind, insbesondere die Komponenten, die vom aws-efa-installer installiert wurden.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) Die AMIs EKS AL2023 und Bottlerocket **enthalten weder** den EFA-DRA-Treiber noch das EFA-Geräte-Plugin, und diese müssen vor der Bereitstellung von Workloads separat auf Ihrem Cluster installiert werden.

## Beibehaltung der IP-Adresszuweisung
<a name="eks-efa-conserve-ip"></a>

EFA-enabled Instanzen wie `p5.48xlarge` und `p6-b200.48xlarge` unterstützen viele Netzwerkschnittstellen. Standardmäßig weist das Amazon VPC CNI IP-Adressen allen IP-enabled angeschlossenen ENIs zu, wodurch eine große Anzahl von IP-Adressen aus Ihrem Subnetz verbraucht werden kann, auch wenn diese Adressen nicht aktiv von Pods verwendet werden. Bei Instances mit Dutzenden von Netzwerkschnittstellen kann dies den verfügbaren IP-Speicherplatz Ihres Subnetzes schnell erschöpfen.

Um den IP-Adressverbrauch auf EFA-enabled Knoten zu reduzieren, konfigurieren Sie Ihre Netzwerkschnittstellen so, dass sie `efa-only` für alle Schnittstellen außer der primären verwendet werden. EFA-only Schnittstellen sind für RDMA-Verkehr vorgesehen und ihnen sind keine IP-Adressen zugewiesen, sodass sie keine Adressen aus Ihrem Subnetz verwenden. Beispielkonfigurationen finden Sie unter [Karpenter](#eks-efa-auto-karpenter) und. [Von EKS verwaltete Knotengruppen und selbstverwaltete Knoten](#eks-efa-mng-self-managed) Das empfohlene Schnittstellenlayout für jeden Instance-Typ finden Sie unter [Maximieren der Netzwerkbandbreite für EFA-enabled Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) im *Amazon EC2 EC2-Benutzerhandbuch*.

Zusätzlich zur Verwendung von `efa-only` Schnittstellen können Sie Amazon VPC CNI so konfigurieren, dass die Anzahl der warmen (vorab zugewiesenen) IP-Adressen und ENIs begrenzt wird. Standardmäßig weist das VPC-CNI vorab einen warmen Pool von ENIs und IP-Adressen zu, um den Pod-Start zu beschleunigen. Bei großen Instances können dadurch jedoch Hunderte ungenutzter IP-Adressen reserviert werden. Stellen Sie die Umgebungsvariablen `WARM_IP_TARGET` und die `WARM_ENI_TARGET` Umgebungsvariablen auf, `aws-node` DaemonSet um zu steuern, wie viele Ersatz-IP-Adressen und ENIs das CNI verwaltet. Weitere Informationen zu diesen Einstellungen finden Sie unter [Amazon VPC CNI Best](https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html#_overview) Practices.

**Anmerkung**  
Die `WARM_IP_TARGET` Einstellungen `WARM_ENI_TARGET` und gelten für den gesamten Cluster und gelten für alle Knoten, die vom VPC-CNI verwaltet werden. Derzeit gibt es keine Möglichkeit, unterschiedliche Werte pro Knotengruppe oder Instanztyp festzulegen. Wenn Sie eine genauere Steuerung dieser Einstellungen benötigen, geben Sie uns Feedback zu [containers-roadmap](https://github.com/aws/containers-roadmap/issues/1834) issue \#1834.

## Installieren Sie den EFA-DRA-Treiber (DRANET)
<a name="efa-dra-driver"></a>

Der EFA-DRA-Treiber ist im Upstream-Projekt [DRANET](https://github.com/kubernetes-sigs/dranet) integriert, das eine cloudbasierte Netzwerkgeräteverwaltung für Kubernetes DRA ermöglicht. Der *EFA-DRA-Treiber* und *DRANET* werden in dieser Dokumentation synonym verwendet und beziehen sich auf dasselbe Tool.

Der EFA-DRA-Treiber bewirbt EFA-Geräte als `ResourceSlice` Objekte mit dem Treibernamen und dem Namen. `dra.net` `DeviceClass` `efa.networking.k8s.aws` Der EFA-DRA-Treiber wird DaemonSet auf jedem Knoten ausgeführt und erkennt automatisch EFA-Geräte.

### Voraussetzungen
<a name="_prerequisites"></a>
+ Ein Amazon EKS-Cluster, auf dem Kubernetes Version 1.34 oder höher mit von EKS verwalteten Knotengruppen oder selbstverwalteten Knotengruppen ausgeführt wird.
+ Knoten mit EFA-enabled Amazon EC2 EC2-Instance-Typen. Eine Liste der unterstützten Instance-Typen finden Sie unter [Unterstützte Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) im *Amazon EC2 EC2-Benutzerhandbuch*.
+ Knoten, auf denen Komponenten auf Host-Ebene für EFA installiert sind, finden [Sie unter Installieren der EFA-Software](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) für weitere Informationen. Die NVIDIA- und Neuron-AMIs EKS-optimized AL2023 sowie die Bottlerocket-AMIs enthalten die EFA-Komponenten auf Host-Ebene.
+ Weitere Informationen finden Sie in den [Anweisungen zur Einrichtung von Helm](helm.md).
+  `kubectl`konfiguriert für die Kommunikation mit Ihrem Cluster, weitere Informationen finden Sie unter. [Installieren oder Aktualisieren von `kubectl`](install-kubectl.md#kubectl-install-update)

### Verfahren
<a name="_procedure"></a>

**Wichtig**  
Installieren Sie den EFA-DRA-Treiber nicht auf Knoten, auf denen das EFA-Geräte-Plug-In ausgeführt wird. Die beiden Mechanismen können nicht gleichzeitig auf demselben Knoten existieren. Updates finden Sie unter Upstream-Kubernetes [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004).

1. Fügen Sie das EKS Helm-Chart-Repository hinzu.

   ```
   helm repo add eks https://aws.github.io/eks-charts
   ```

1. Aktualisieren Sie Ihr lokales Helm-Repository.

   ```
   helm repo update
   ```

1. Installieren Sie den EFA-DRA-Treiber mit Helm auf Ihrem Cluster. Der EFA-DRA-Treiber erkennt über den Instance Metadata Service (IMDS) automatisch, dass er auf EC2-Instances läuft, und ermöglicht die EFA-Geräteerkennung. Der EFA-DRA-Treiber wird standardmäßig als DaemonSet im Namespace bereitgestellt. `kube-system` Die konfigurierbaren Parameter finden Sie unter Helm values.yaml im [ GitHub EKS-Helm-Chart-Repository](https://github.com/aws/eks-charts/tree/master/stable/aws-dranet).

   ```
   helm install aws-dranet eks/aws-dranet --namespace kube-system
   ```

1. Stellen Sie sicher, dass das DRANET läuft DaemonSet .

   ```
   kubectl get daemonset -n kube-system aws-dranet
   ```

   ```
   NAME          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   aws-dranet    2         2         2       2            2           <none>          60s
   ```

1. Stellen Sie sicher, dass das erstellt `DeviceClass` wurde.

   ```
   kubectl get deviceclass
   ```

   ```
   NAME                    AGE
   efa.networking.k8s.aws  60s
   ```

1. Vergewissern Sie sich, dass `ResourceSlice` Objekte für Ihre Knoten angekündigt wurden.

   ```
   kubectl get resourceslices --field-selector spec.driver=dra.net
   ```

   Wenn bei den obigen Schritten Fehler auftreten, können Sie die Protokolle für DRANET mit dem folgenden Befehl überprüfen.

   ```
   kubectl logs -n kube-system -l app=aws-dranet
   ```

1. Um EFA-Geräte mithilfe des DRA-Treibers anzufordern, erstellen Sie ein `ResourceClaim` oder, `ResourceClaimTemplate` das auf die EFA verweist, `DeviceClass` und verweisen Sie in Ihrer Pod-Spezifikation darauf. Im folgenden Beispiel wird ein einzelnes EFA-Gerät angefordert.

   ```
   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: single-efa-claim
   spec:
     spec:
       devices:
         requests:
         - name: efa
           exactly:
             deviceClassName: efa.networking.k8s.aws
             count: 1
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: efa-workload
   spec:
     containers:
     - name: app
       ...
       resources:
         claims:
         - name: efa-device
     resourceClaims:
     - name: efa-device
       resourceClaimTemplateName: single-efa-claim
   ```

## Topology-aware EFA und Gerätezuweisung GPU/Neuron
<a name="efa-dra-topology-aware"></a>

Der EFA-DRA-Treiber unterstützt eine topologieorientierte Zuweisung, bei der EFA-Schnittstellen mit GPUs oder Neuron-Geräten auf demselben PCIe-Root kombiniert werden. Verwenden Sie die `matchAttribute` Einschränkung, um die Zuordnungen von EFA- und GPU- oder Neuron-Geräten aufeinander abzustimmen. Um diese Funktion nutzen zu können, müssen Sie auch die NVIDIA- oder Neuron DRA-Treiber verwenden. Weitere Informationen erhalten Sie unter [NVIDIA-GPU-Geräte auf Amazon EKS verwalten](device-management-nvidia.md) und [Neuron-Geräte auf Amazon EKS verwalten](device-management-neuron.md).

Im folgenden Beispiel wird eine EFA-Schnittstelle angefordert, die auf eine NVIDIA-GPU abgestimmt ist:

```
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: aligned-efa-nvidia
spec:
  spec:
    devices:
      requests:
      - name: 1-efa
        exactly:
          deviceClassName: efa.networking.k8s.aws
          count: 1
      - name: 1-gpu
        exactly:
          deviceClassName: gpu.nvidia.com
          count: 1
      constraints:
      - requests: ["1-gpu", "1-efa"]
        matchAttribute: "resource.kubernetes.io/pcieRoot"
```

Im folgenden Beispiel werden 4 EFA-Schnittstellen angefordert, die auf 4 Neuron-Geräte abgestimmt sind:

```
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: aligned-efa-neuron
spec:
  spec:
    devices:
      requests:
      - name: 4-neurons
        exactly:
          deviceClassName: neuron.aws.com
          count: 4
      - name: 4-efas
        exactly:
          deviceClassName: efa.networking.k8s.aws
          count: 4
      constraints:
      - requests: ["4-neurons", "4-efas"]
        matchAttribute: "resource.aws.com/devicegroup4_id"
```

Die Zahl im `devicegroup` Attributnamen entspricht der Anzahl der Neuron-Geräte in der verbundenen Topologiegruppe. `resource.aws.com/devicegroup1_id`Identifiziert beispielsweise ein einzelnes Neuron-Gerät, `resource.aws.com/devicegroup4_id` identifiziert eine Gruppe von 4 verbundenen Geräten `resource.aws.com/devicegroup8_id` und `resource.aws.com/devicegroup16_id` identifiziert Gruppen von 8 bzw. 16 verbundenen Geräten. Wählen Sie `matchAttribute` das Gerät aus, das dem Gerät `count` in Ihrer Anfrage entspricht, sodass die zugewiesenen Neuron-Geräte und EFA-Schnittstellen derselben verbundenen Topologiegruppe angehören. Weitere Informationen zu diesen Attributen finden Sie in der [Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/neuron-dra.html) DRA-Treiberdokumentation.

Sie können `allocationMode` damit vereinfachen, wie EFA-Geräte ausgerichteten GPU- oder Neuron-Beschleunigern zugewiesen werden. Das `allocationMode` Feld unterstützt zwei Werte: `ExactCount` (Standard) fordert eine bestimmte Anzahl von Geräten an, die von angegeben sind`count`, und `All` fordert alle passenden Geräte in einem Pool an. Auf `p5.48xlarge` Instances gibt es beispielsweise vier EFA-Geräte, die denselben PCIe-Root mit einer GPU teilen. Um diesen Gruppen von EFA-Geräten ausgerichtete GPUs zuzuweisen, können Sie Ihre `ResourceClaimTemplate` mit für die EFA-Geräte konfigurieren, auch wenn Sie die genaue EFA-GPU Gerätezuweisung und Anzahl der ausgerichteten EFA-Geräte nicht kennen. `allocationMode: All`

```
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: aligned-all-efa-one-nvidia
spec:
  spec:
    devices:
      requests:
      - name: all-efas
        exactly:
          deviceClassName: efa.networking.k8s.aws
          allocationMode: All
      - name: one-gpu
        exactly:
          deviceClassName: gpu.nvidia.com
          allocationMode: ExactCount
          count: 1
      constraints:
      - requests: ["all-efas", "one-gpu"]
        matchAttribute: "resource.kubernetes.io/pcieRoot"
```

## Teilen Sie EFA-Geräte auf mehrere Pods
<a name="efa-dra-share"></a>

Der EFA-DRA-Treiber unterstützt die gemeinsame Nutzung von EFA-Geräten zwischen mehreren Pods mithilfe von. `ResourceClaim` Im Gegensatz zu a`ResourceClaimTemplate`, das für jeden Pod einen eigenen Anspruch generiert, `ResourceClaim` handelt es sich bei a um ein benanntes Objekt, das Sie unabhängig erstellen und auf das Sie von mehreren Pods aus verweisen. Alle Pods, die auf `ResourceClaim` denselben Pods verweisen, haben gemeinsamen Zugriff auf dieselben zugewiesenen EFA-Geräte und sind für denselben Knoten geplant, auf dem diese Geräte verfügbar sind.

Um EFA-Geräte von mehreren Pods gemeinsam zu nutzen, erstellen Sie einen`ResourceClaim`, der die EFA-Geräte anfordert, und verweisen Sie dann mit dem Namen auf diesen Claim im Feld jedes Pods `resourceClaims` mit. `resourceClaimName` Der `ResourceClaim` muss im Cluster vorhanden sein, bevor die Pods erstellt werden, die darauf verweisen. Wenn ein Objekt, auf `ResourceClaim` das verwiesen wird, nicht existiert, verbleiben die Pods so lange im Status „Ausstehend“, bis der Anspruch erstellt wird.

Das folgende Beispiel erstellt einen`ResourceClaim`, der 4 EFA-Geräte anfordert, und zwei Pods, die gemeinsam auf diese Geräte zugreifen.

1. Erstellen Sie den `ResourceClaim`.

   ```
   apiVersion: resource.k8s.io/v1
   kind: ResourceClaim
   metadata:
     name: shared-efa
   spec:
     devices:
       requests:
       - name: efa
         exactly:
           deviceClassName: efa.networking.k8s.aws
           count: 4
   ```

1. Verweisen Sie auf `ResourceClaim` den Namen in jedem Pod, der Zugriff auf die EFA-Geräte benötigt. Jeder Pod wird verwendet`resourceClaimName`, um auf den vorhandenen Anspruch zu verweisen, anstatt auf`resourceClaimTemplateName`.

   ```
   apiVersion: v1
   kind: Pod
   metadata:
     name: training-worker
   spec:
     containers:
     - name: worker
       image: my-training-image
       resources:
         claims:
         - name: efa-devices
     resourceClaims:
     - name: efa-devices
       resourceClaimName: shared-efa
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: training-monitor
   spec:
     containers:
     - name: monitor
       image: my-monitor-image
       resources:
         claims:
         - name: efa-devices
     resourceClaims:
     - name: efa-devices
       resourceClaimName: shared-efa
   ```

Beide Pods verweisen auf dasselbe `shared-efa` `ResourceClaim` und sind für den Knoten geplant, dem diese EFA-Geräte zugewiesen sind. Der `ResourceClaim` Lebenszyklus ist unabhängig von den Pods — er bleibt bestehen, bis Sie ihn löschen, auch wenn alle Pods, die auf ihn verweisen, entfernt wurden.

## Installieren Sie das EFA Kubernetes-Geräte-Plugin
<a name="eks-efa-device-plugin"></a>

Das EFA Kubernetes-Geräte-Plugin bewirbt EFA-Geräte als erweiterte Ressourcen. `vpc.amazonaws.com/efa` Sie fordern EFA-Geräte in Container-Ressourcenanfragen und -limits an. Eine vollständige Anleitung zur Einrichtung von EFA mit Trainings-Workloads finden Sie unter. [Ausführung von Machine-Learning-Trainings in Amazon EKS mit Elastic Fabric Adapter](node-efa.md)

**Wichtig**  
Topology-aligned Die Zuweisung von NVIDIA-GPUs oder Neuron-Geräten mit EFA-Schnittstellen erfolgt automatisch, wenn die EKS-optimized AL2023-beschleunigten AMIs verwendet werden. Diese automatische Ausrichtung erfolgt nicht, wenn Bottlerocket-AMIs oder benutzerdefinierte AMIs EKS-optimized verwendet werden. Wenn Sie eine topologieorientierte Beschleuniger- und EFA-Gerätezuweisung mit Bottlerocket oder benutzerdefinierten AMIs benötigen, verwenden Sie den EFA-DRA-Treiber und den entsprechenden Neuron-DRA-Treiber. Der NVIDIA-DRA-Treiber wird auf Bottlerocket nicht unterstützt. Weitere Informationen finden Sie unter [Topology-aware EFA und Gerätezuweisung GPU/Neuron](#efa-dra-topology-aware).

**Wichtig**  
Ab NVIDIA `k8s-device-plugin` v0.19.0 ist das `--mofed-enabled` Flag standardmäßig auf eingestellt, was dazu führt, dass das NVIDIA-Geräte-Plugin alle Geräte in Containern mountet`true`, die GPUs anfordern. `/dev/infiniband/uverbs*` Dies steht in Konflikt mit dem EFA-Geräte-Plugin, das die Komponente sein sollte, unter der die EFA-Gerätezuweisung verwaltet wird. `/dev/infiniband` Wenn Sie von EKS verwaltete Knotengruppen oder selbstverwaltete Knoten mit dem NVIDIA-Geräte-Plugin verwenden, müssen Sie MOFED explizit deaktivieren. Detaillierte Anweisungen finden Sie unter [Installieren Sie das NVIDIA Kubernetes-Geräte-Plugin](device-management-nvidia.md#nvidia-device-plugin).  
Der automatische EKS-Modus aktiviert MOFED standardmäßig nicht und ist von diesem Problem nicht betroffen.

### Voraussetzungen
<a name="_prerequisites_2"></a>
+ Ein Amazon EKS-Cluster.
+ Knoten mit EFA-enabled Amazon EC2 EC2-Instance-Typen. Eine Liste der unterstützten Instance-Typen finden Sie unter [Unterstützte Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) im *Amazon EC2 EC2-Benutzerhandbuch*.
+ Knoten, auf denen Komponenten auf Host-Ebene für EFA installiert sind, finden [Sie unter Installieren der EFA-Software](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) für weitere Informationen. Die NVIDIA- und Neuron-AMIs EKS-optimized AL2023 sowie die Bottlerocket-AMIs enthalten die EFA-Komponenten auf Host-Ebene.
+ Weitere Informationen finden Sie in den [Anweisungen zur Einrichtung von Helm](helm.md).
+  `kubectl`konfiguriert für die Kommunikation mit Ihrem Cluster, weitere Informationen finden Sie unter. [Installieren oder Aktualisieren von `kubectl`](install-kubectl.md#kubectl-install-update)

### Verfahren
<a name="_procedure_2"></a>

1. Fügen Sie das EKS Helm-Chart-Repository hinzu.

   ```
   helm repo add eks https://aws.github.io/eks-charts
   ```

1. Aktualisieren Sie Ihr lokales Helm-Repository.

   ```
   helm repo update
   ```

1. Installieren Sie das EFA-Geräte-Plugin.

   ```
   helm install efa eks/aws-efa-k8s-device-plugin -n kube-system
   ```

1. Stellen Sie sicher, dass das EFA-Geräte-Plugin DaemonSet läuft.

   ```
   kubectl get daemonset -n kube-system efa-aws-efa-k8s-device-plugin
   ```

   ```
   NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   efa-aws-efa-k8s-device-plugin         2         2         2       2            2           <none>          60s
   ```

1. Stellen Sie sicher, dass Ihren Knoten EFA-Ressourcen zugewiesen werden können.

   ```
   kubectl get nodes "-o=custom-columns=NAME:.metadata.name,EFA:.status.allocatable.vpc\.amazonaws\.com/efa"
   ```

   ```
   NAME                                           EFA
   ip-192-168-11-225.us-west-2.compute.internal   4
   ip-192-168-24-96.us-west-2.compute.internal    4
   ```

1. Um EFA-Geräte mithilfe des Geräte-Plug-ins anzufordern, geben Sie die `vpc.amazonaws.com/efa` Ressource in Ihren Container-Ressourcenanfragen und Grenzwerten an.

   ```
   apiVersion: v1
   kind: Pod
   metadata:
     name: efa-workload
   spec:
     containers:
     - name: app
       ...
       resources:
         limits:
           vpc.amazonaws.com/efa: 4
           hugepages-2Mi: ...
         requests:
           vpc.amazonaws.com/efa: 4
           hugepages-2Mi: ...
   ```