EFA-Geräte auf Amazon EKS verwalten

Elastic Fabric Adapter (EFA) ist ein Netzwerkgerät für Amazon EC2-Instances, das leistungsstarke Kommunikation zwischen Knoten und RDMA (Remote Direct Memory Access) für Workloads in den Bereichen künstliche Intelligenz, maschinelles Lernen und High Performance Computing (HPC) 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-Plug-In.

Wir empfehlen, DRA-Treiber für neue Bereitstellungen mit Kubernetes-Versionen 1.34 und höher zu verwenden, wenn die statische Kapazitätsbereitstellung in Karpenter, von EKS verwaltete Knotengruppen oder selbstverwaltete Knoten verwendet wird. DRA wird derzeit im EKS-Automatikmodus nicht unterstützt. 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 Geräte zwischen Pods gemeinsam nutzt.

EFA-DRA-Treiber im Vergleich zum EFA-Geräte-Plugin

EKS-Knoten mit EFA-Schnittstellen erstellen

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 EKS Auto Mode, Karpenter, EKS-verwalteten Knotengruppen oder selbstverwalteten EKS-Knotengruppen verwenden. Im EKS-Automatikmodus leiten Sie die Konfiguration für jede Netzwerkschnittstelle durch das Unterfenster weiter. NodeClass advancedNetworking.networkInterfaces Mit Karpenter übergeben Sie die Konfiguration für jede Netzwerkschnittstelle über den. EC2NodeClass Bei EKS-verwalteten Knotengruppen oder selbstverwalteten Knoten übergeben Sie die Konfiguration für jede Netzwerkschnittstelle mit Startvorlagen.

Wenn Sie die efaEnabled Einstellung eksctl für die Bereitstellung von EKS-Knoten verwenden, werden alle Schnittstellen mit dem Schnittstellentyp konfiguriertEFA, eine EFA-specific Sicherheitsgruppe wird erstellt und das EFA-Geräte-Plug-In wird auf dem Cluster installiert. Wenn Sie die EFA-Konfiguration pro Gerät bei der Verwendung anpassen müssen, wird empfohleneksctl, 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 anzupassen, die für EFA-Verkehr im Vergleich zu IP-based Standardverkehr verwendet werden. 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 im Amazon EC2-Benutzerhandbuch.

EKS Auto Mode

Im EKS-Automatikmodus konfigurieren Sie die EFA-Netzwerkschnittstellen mithilfe des advancedNetworking.networkInterfaces Felds im NodeClass (). eks.amazonaws.com/v1 Jeder Eintrag gibt ein networkCardIndexdeviceIndex, und interfaceType an. Dies interfaceType kann interface für Standard-Netzwerkschnittstellen oder efa-only für EFA-Schnittstellen verwendet werden, die für RDMA-Verkehr ohne zugewiesene IP-Adressen vorgesehen sind.

Wenn konfiguriert networkInterfaces ist, NodeClass verwenden Instances, die vom NodePool referenzierenden Server gestartet werden, diese Konfiguration, unabhängig davon, ob Pods Ressourcen anfordern. vpc.amazonaws.com/efa EKS Auto Mode fügt nach dem Start der Instance für Knoten mit statischer Netzwerkschnittstellenkonfiguration keine zusätzlichen IPs, Präfixe oder ENIs hinzu — nur die beim Start konfigurierten Schnittstellen und IPs sind für Pods verfügbar.

Diese Funktion kann mit Node-Pools mit statischer Kapazität verwendet werden, um vorgewärmte EFA-ready Knoten für verteilte Trainings- und Inferenz-Workloads aufrechtzuerhalten.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: efa-node-class
spec:
  role: MyNodeRole
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
  securityGroupSelectorTerms:
    - tags:
        Name: "efa-security-group"
  placementGroupSelector:
    name: "ml-training-pg"
  advancedNetworking:
    networkInterfaces:
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 1
    - 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

Eine vollständige Liste der Einschränkungen bei der Konfiguration statischer Netzwerkschnittstellen finden Sie Konfiguration der statischen Netzwerkschnittstelle in der NodeClass Dokumentation.

Karpenter

Jeder Eintrag in networkInterfaces gibt ein networkCardIndexdeviceIndex, und aninterfaceType. Das interfaceType kann interface für Standard-Netzwerkschnittstellen oder efa-only für EFA-Schnittstellen verwendet werden, die für RDMA-Verkehr vorgesehen sind und denen keine IP-Adressen zugewiesen sind. Wenn konfiguriert networkInterfaces ist, NodeClass verwenden Instances, die vom NodePool referenzierenden Host gestartet werden, diese Konfiguration, unabhängig davon, ob Pods Ressourcen anfordern. vpc.amazonaws.com/efa

Wenn Sie Karpenter verwenden, ohne networkInterfaces in Ihrem angegeben zu vpc.amazonaws.com/efa haben, sind bei InstanzenNodeClass, die für Pods erstellt wurden, 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

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

EKS-verwaltete Knotengruppen und selbstverwaltete Knoten

Bei EKS-verwalteten Knotengruppen oder selbstverwalteten Knoten übergeben Sie die Konfiguration für jede Netzwerkschnittstelle mit Startvorlagen.

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 den IP-Verkehr, während zusätzliche Schnittstellen den dedizierten RDMA-Verkehr verwendenefa-only. Passen Sie die Anzahl der efa-only Schnittstellen an Ihren Instance-Typ an. Die Anzahl der EFA-Schnittstellen, die von jedem Instance-Typ unterstützt werden, finden Sie im Amazon EC2-Benutzerhandbuch unter Maximieren der Netzwerkbandbreite für EFA-enabled Instance-Typen.

{
  "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"]
      }
    ]
  }
}

Verwenden von AMIs mit EFA EKS-optimized

Die EKS-optimized AL2023-AMIs 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 werden. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable Die EKS-AL2023- und Bottlerocket-AMIs enthalten weder den EFA-DRA-Treiber noch das EFA-Geräte-Plug-In, und diese müssen separat auf Ihrem Cluster installiert werden, bevor Sie Workloads bereitstellen.

Beibehaltung der IP-Adresszuweisung

EFA-enabled Instanzen wie p5.48xlarge und p6-b200.48xlarge unterstützen viele Netzwerkschnittstellen. Standardmäßig weist das Amazon VPC CNI allen IP-enabled angeschlossenen ENIs IP-Adressen zu, wodurch eine große Anzahl von IP-Adressen aus Ihrem Subnetz abgerufen 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 Verbrauch von IP-Adressen 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 den RDMA-Verkehr vorgesehen und ihnen sind keine IP-Adressen zugewiesen, sodass sie keine Adressen aus Ihrem Subnetz verwenden. Beispiele für Konfigurationen finden Sie unter Karpenter und. EKS-verwaltete Knotengruppen und selbstverwaltete Knoten Das empfohlene Schnittstellenlayout für jeden Instance-Typ finden Sie unter Maximieren der Netzwerkbandbreite für EFA-enabled Instance-Typen im Amazon 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 von ungenutzten IP-Adressen reserviert werden. Legen Sie die Umgebungsvariablen WARM_IP_TARGET und die WARM_ENI_TARGET Umgebungsvariablen auf dem fest aws-node DaemonSet , um zu steuern, wie viele Ersatz-IP-Adressen und ENIs das CNI verwaltet. Weitere Informationen zu diesen Einstellungen finden Sie unter Best Practices für Amazon VPC CNI.

Installieren Sie den EFA-DRA-Treiber (DRANET)

Der EFA-DRA-Treiber ist im https://github.com/kubernetes-sigs/dranet Upstream-DRANET-Projekt integriert GitHub, das eine Cloud-fähige 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 kündigt EFA-Geräte als ResourceSlice Objekte mit dem Treibernamen und dem Namen an. dra.net DeviceClass efa.networking.k8s.aws Der EFA-DRA-Treiber läuft DaemonSet auf jedem Knoten als und erkennt automatisch EFA-Geräte.

Voraussetzungen

Verfahren

Topology-aware EFA und Gerätezuweisung GPU/Neuron

Der EFA-DRA-Treiber unterstützt die topologiebewusste Zuweisung, bei der EFA-Schnittstellen mit GPUs oder Neuron-Geräten auf demselben PCIe-Root gekoppelt werden. Verwenden Sie die matchAttribute Einschränkung, um die Zuweisungen 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-GPUs auf Amazon EKS verwalten und Neuron-Geräte auf Amazon EKS verwalten.

Im folgenden Beispiel wird eine EFA-Schnittstelle angefordert, die einer NVIDIA-GPU zugeordnet 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"

Das folgende Beispiel fordert 4 EFA-Schnittstellen an, 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_idIdentifiziert 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, 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-DRA-Treiberdokumentation.

Sie können allocationMode es verwenden, um zu vereinfachen, wie EFA-Geräte ausgerichteten GPU- oder Neuron-Beschleunigern zugewiesen werden. Das allocationMode Feld unterstützt zwei Werte: ExactCount (Standardeinstellung) fordert eine bestimmte Anzahl von Geräten an, die von angegeben wirdcount, 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 abgestimmte GPUs zuzuweisen, können Sie Ihre ResourceClaimTemplate Konfiguration für die EFA-Geräte konfigurieren, auch wenn Sie die genaue EFA-GPU Gerätezuordnung und die Anzahl der abgeglichenen 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 mit mehreren Pods

Der EFA-DRA-Treiber unterstützt die gemeinsame Nutzung von EFA-Geräten zwischen mehreren Pods mithilfe eines. ResourceClaim Im Gegensatz zu aResourceClaimTemplate, das für jeden Pod einen eigenen Anspruch generiert, ResourceClaim ist a ein benanntes Objekt, das Sie unabhängig erstellen und von mehreren Pods aus referenzieren. Alle Pods, die auf denselben Pods verweisen, haben ResourceClaim gemeinsam 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 einenResourceClaim, der die EFA-Geräte anfordert, und verweisen Sie dann namentlich in den Feldern der einzelnen Pods resourceClaims auf diesen Anspruch. resourceClaimName Das ResourceClaim muss im Cluster existieren, bevor die Pods, die es referenzieren, erstellt werden. ResourceClaimExistiert kein Objekt, auf das verwiesen wird, verbleiben die Pods im Status „Ausstehend“, bis der Anspruch geltend gemacht wird.

Das folgende Beispiel erstellt einenResourceClaim, der 4 EFA-Geräte anfordert, und zwei Pods, die den Zugriff auf diese Geräte gemeinsam nutzen.

Beide Pods verweisen auf dasselbe shared-efa ResourceClaim und sind für den Knoten vorgesehen, 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 werden.

Installieren Sie das EFA Kubernetes-Geräte-Plugin

Das EFA Kubernetes-Geräte-Plugin bewirbt EFA-Geräte als erweiterte Ressourcen. vpc.amazonaws.com/efa Sie fordern EFA-Geräte in Container-Ressourcenanforderungen 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

Voraussetzungen

Verfahren