Gestisci i dispositivi EFA su Amazon EKS

Elastic Fabric Adapter (EFA) è un dispositivo di rete per istanze Amazon EC2 che consente la comunicazione tra nodi ad alte prestazioni e l'RDMA (Remote Direct Memory Access) per l'intelligenza artificiale, l'apprendimento automatico e i carichi di lavoro HPC (High Performance Computing). Amazon EKS supporta due meccanismi per la gestione dei dispositivi EFA nei cluster EKS: il driver EFA Dynamic Resource Allocation (DRA) (DRANET) e il plug-in del dispositivo EFA.

Consigliamo di utilizzare i driver DRA per le nuove implementazioni con Kubernetes versioni 1.34 e successive quando si utilizza il provisioning della capacità statica in Karpenter, gruppi di nodi gestiti da EKS o nodi autogestiti. DRA non è attualmente supportato con EKS Auto Mode. Con il driver EFA DRA, è possibile configurare un'allocazione compatibile con la topologia che accoppia le interfacce EFA con le relative GPU o dispositivi Neuron topologicamente locali e condividere i dispositivi tra pod.

Driver EFA DRA e plug-in per dispositivi EFA

Creazione di nodi EKS con interfacce EFA

Quando si creano nodi EKS con interfacce EFA, le interfacce EFA vengono collegate all'istanza durante il provisioning dell'istanza. È possibile personalizzare la configurazione EFA per dispositivo e utilizzare i gruppi di posizionamento con EKS Auto Mode, Karpenter, i gruppi di nodi gestiti da EKS o i gruppi di nodi autogestiti EKS. Con EKS Auto Mode, è possibile passare la configurazione per ciascuna interfaccia di rete attraverso la sezione sottostante. NodeClass advancedNetworking.networkInterfaces Con Karpenter, si passa la configurazione per ciascuna interfaccia di rete tramite. EC2NodeClass Con i gruppi di nodi gestiti da EKS o i nodi autogestiti, si passa la configurazione per ciascuna interfaccia di rete con modelli di avvio.

Quando si utilizza eksctl per il provisioning dei nodi EKS con questa efaEnabled impostazione, tutte le interfacce vengono configurate in base al tipo di interfacciaEFA, viene creato un gruppo di EFA-specific sicurezza e il plug-in del dispositivo EFA viene installato sul cluster. Se è necessario personalizzare la configurazione EFA per dispositivo durante l'utilizzoeksctl, si consiglia di utilizzare il supporto di `eksctl per i modelli di avvio. https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html

Gli esempi seguenti mostrano come configurare NodeClass e lanciare modelli con interfacce EFA. Ciò è utile per personalizzare le interfacce utilizzate per il traffico EFA rispetto a quello standard. IP-based Per informazioni sul numero di interfacce EFA supportate da ciascun tipo di istanza e su come configurarle per la massima larghezza di banda di rete, consulta Massimizzare la larghezza di banda di rete per i tipi di EFA-enabled istanza nella Amazon EC2 User Guide.

Modalità automatica di EKS

In modalità EKS Auto, si configurano le interfacce di rete EFA utilizzando il campo in (). advancedNetworking.networkInterfaces NodeClass eks.amazonaws.com/v1 Ogni voce specifica anetworkCardIndex, deviceIndex e. interfaceType interfaceTypePossono essere interface per interfacce di rete standard o efa-only per interfacce EFA dedicate al traffico RDMA senza indirizzi IP assegnati.

Una volta networkInterfaces configurata, le istanze avviate dal NodePool referente NodeClass utilizzano questa configurazione indipendentemente dal fatto che i Pod richiedano risorse. vpc.amazonaws.com/efa EKS Auto Mode non allega IP, prefissi o ENI aggiuntivi dopo l'avvio dell'istanza per i nodi con configurazione statica dell'interfaccia di rete: solo le interfacce e gli IP configurati all'avvio sono disponibili per i Pods.

Questa funzionalità può essere utilizzata con pool di nodi a capacità statica per mantenere i nodi preriscaldati per carichi di lavoro di formazione e inferenza EFA-ready distribuiti.

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

Per l'elenco completo dei vincoli sulla configurazione dell'interfaccia di rete statica, vedere Configurazione statica dell'interfaccia di rete la documentazione. NodeClass

Karpenter

Ogni voce in networkInterfaces specifica a networkCardIndexdeviceIndex, e. interfaceType interfaceTypePuò essere interface per interfacce di rete standard o efa-only per interfacce EFA dedicate al traffico RDMA e a cui non sono assegnati indirizzi IP. Una volta networkInterfaces configurata, le istanze avviate dal NodePool referente NodeClass utilizzano questa configurazione indipendentemente dal fatto che i Pod richiedano risorse. vpc.amazonaws.com/efa

Quando si utilizza Karpenter senza networkInterfaces specificarloNodeClass, le istanze create per i Pods che richiedono vpc.amazonaws.com/efa hanno tutte le interfacce configurate con il tipo di interfaccia. EFA

La networkInterfaces configurazione per è stata aggiunta in Karpenter v1.11. EC2NodeClass L'esempio seguente mostra una EC2NodeClass configurazione per un' P6-B200 istanza con 1 interfaccia ENA e 8 interfacce. 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

Gruppi di nodi gestiti da EKS e nodi autogestiti

Con i gruppi di nodi gestiti da EKS o i nodi autogestiti, si passa alla configurazione di ciascuna interfaccia di rete con modelli di avvio.

L'esempio seguente mostra un modello di avvio configurato per un' P6-B200 istanza con 1 interfaccia ENA e 8 EFA-only interfacce. L'interfaccia di rete principale (scheda di rete 0, indice del dispositivo 0) utilizza un interface tipo standard per il traffico IP, mentre le interfacce aggiuntive vengono utilizzate efa-only per il traffico RDMA dedicato. Regola il numero di efa-only interfacce in base al tipo di istanza. Per il numero di interfacce EFA supportate da ciascun tipo di istanza, consulta Massimizzare la larghezza di banda di rete per i tipi di EFA-enabled istanza nella Amazon EC2 User Guide.

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

Utilizzo delle AMI con EFA EKS-optimized

Le AMI EKS-optimized AL2023 e tutte le AMI Bottlerocket includono i componenti a livello di host necessari per utilizzare EFA, in particolare i componenti installati da aws-efa-installer. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable Le AMI EKS AL2023 e Bottlerocket non includono il driver EFA DRA o il plug-in del dispositivo EFA e questi devono essere installati separatamente sul cluster prima di distribuire i carichi di lavoro.

Conservazione dell'allocazione degli indirizzi IP

EFA-enabled istanze come p5.48xlarge e p6-b200.48xlarge supportano molte interfacce di rete. Per impostazione predefinita, Amazon VPC CNI alloca gli indirizzi IP su tutti gli ENI IP-enabled collegati, il che può consumare un numero elevato di indirizzi IP dalla tua sottorete anche quando tali indirizzi non vengono utilizzati attivamente dai Pods. Nelle istanze con dozzine di interfacce di rete, questo può esaurire rapidamente lo spazio IP disponibile della sottorete.

Per ridurre il consumo di indirizzi IP sui EFA-enabled nodi, configura le interfacce di rete in modo che vengano utilizzate efa-only per tutte le interfacce tranne quella principale. EFA-only le interfacce sono dedicate al traffico RDMA e non hanno indirizzi IP assegnati, quindi non consumano indirizzi dalla sottorete. Ad esempio, configurazioni, vedere e. Karpenter Gruppi di nodi gestiti da EKS e nodi autogestiti Per il layout di interfaccia consigliato per ogni tipo di istanza, consulta Massimizzare la larghezza di banda di rete per i tipi di EFA-enabled istanza nella Amazon EC2 User Guide.

Oltre a utilizzare le efa-only interfacce, puoi configurare Amazon VPC CNI per limitare il numero di indirizzi IP e ENI caldi (preallocati). Per impostazione predefinita, il VPC CNI prealloca un pool caldo di ENI e indirizzi IP per velocizzare l'avvio del Pod, ma in casi di grandi dimensioni può riservare centinaia di indirizzi IP inutilizzati. Imposta le variabili di WARM_ENI_TARGET ambiente WARM_IP_TARGET e di ambiente su aws-node DaemonSet per controllare il numero di indirizzi IP e ENI di riserva che il CNI mantiene. Per ulteriori informazioni su queste impostazioni, consulta le best practice CNI di Amazon VPC.

Installa il driver EFA DRA (DRANET)

Il driver EFA DRA è integrato nel progetto DRANET upstream on, che fornisce la gestione dei dispositivi di rete basata sul cloud per GitHub Kubernetes DRA. Il driver EFA DRA e DRANET sono usati in modo intercambiabile in questa documentazione e fanno riferimento allo stesso strumento.

Il driver EFA DRA pubblicizza i dispositivi EFA come oggetti con il nome del driver e il nome. ResourceSlice dra.net DeviceClass efa.networking.k8s.aws Il driver EFA DRA viene eseguito DaemonSet su ciascun nodo e rileva automaticamente i dispositivi EFA.

Prerequisiti

Procedura

Topology-aware EFA e GPU/Neuron allocazione dei dispositivi

Il driver EFA DRA supporta l'allocazione basata sulla topologia che accoppia le interfacce EFA con GPU o dispositivi Neuron sulla stessa radice PCIe. Usa il vincolo per allineare le allocazioni dei dispositivi EFA e GPU matchAttribute o Neuron. Per utilizzare questa funzionalità, è necessario utilizzare anche i driver NVIDIA o Neuron DRA. Per ulteriori informazioni, consultare Gestisci le GPU NVIDIA su Amazon EKS e Gestisci i dispositivi Neuron su Amazon EKS.

L'esempio seguente richiede 1 interfaccia EFA allineata con 1 GPU NVIDIA:

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"

L'esempio seguente richiede 4 interfacce EFA allineate con 4 dispositivi Neuron:

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"

Il numero nel nome dell'devicegroupattributo corrisponde al numero di dispositivi Neuron nel gruppo di topologia connesso. Ad esempio, resource.aws.com/devicegroup1_id identifica un singolo dispositivo Neuron, resource.aws.com/devicegroup4_id identifica un gruppo di 4 dispositivi connessi e resource.aws.com/devicegroup16_id identifica rispettivamente gruppi di 8 resource.aws.com/devicegroup8_id e 16 dispositivi connessi. Scegli matchAttribute quello che corrisponde al dispositivo nella tua richiesta count in modo che i dispositivi Neuron allocati e le interfacce EFA appartengano allo stesso gruppo di topologia connessa. Per ulteriori informazioni su questi attributi, consultate la documentazione del driver Neuron DRA.

È possibile utilizzarlo allocationMode per semplificare il modo in cui i dispositivi EFA vengono allocati a GPU o acceleratori Neuron allineati. Il allocationMode campo supporta due valori: ExactCount (impostazione predefinita) richiede un numero specifico di dispositivi specificato da e All richiede tutti i dispositivi count corrispondenti in un pool. Ad esempio, p5.48xlarge nelle istanze ci sono quattro dispositivi EFA che condividono la stessa radice PCIe con una GPU. Per assegnare questi gruppi di dispositivi EFA a GPU allineate, anche se non si conosce l'esatta mappatura dei dispositivi e il numero di EFA-GPU dispositivi EFA allineati, è possibile configurare la configurazione con per i dispositivi EFA. ResourceClaimTemplate 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"

Condividi i dispositivi EFA tra più pod

Il driver EFA DRA supporta la condivisione di dispositivi EFA tra più Pod utilizzando un. ResourceClaim A differenza di aResourceClaimTemplate, che genera un claim separato per ogni Pod, a ResourceClaim è un oggetto denominato creato indipendentemente e a cui si fa riferimento da più Pod. Tutti i Pod che fanno riferimento allo stesso ResourceClaim condividono l'accesso agli stessi dispositivi EFA allocati e sono programmati sullo stesso nodo in cui tali dispositivi sono disponibili.

Per condividere i dispositivi EFA tra Pod, creane uno ResourceClaim che richieda i dispositivi EFA, quindi fai riferimento a quell'attestazione per nome nel campo di ciascun Pod utilizzando. resourceClaims resourceClaimName ResourceClaimDeve esistere nel cluster prima che i Pod che vi fanno riferimento vengano creati. Se un riferimento ResourceClaim non esiste, i Pod rimangono in sospeso fino alla creazione del claim.

L'esempio seguente crea un file ResourceClaim che richiede 4 dispositivi EFA e due Pod che condividono l'accesso a tali dispositivi.

Entrambi i Pod fanno riferimento allo stesso shared-efa ResourceClaim e sono programmati nel nodo in cui sono allocati i dispositivi EFA. Il ResourceClaim ciclo di vita è indipendente dai Pod: persiste finché non li elimini, anche se tutti i Pod che vi fanno riferimento vengono rimossi.

Installa il plug-in del dispositivo EFA Kubernetes

Il plug-in per dispositivi EFA Kubernetes pubblicizza i dispositivi EFA come risorse estese. vpc.amazonaws.com/efa Richiedete dispositivi EFA in container, richieste e limiti di risorse. Per una guida completa alla configurazione dell'EFA con carichi di lavoro di formazione, consulta. Esecuzione dei corsi di machine learning su Amazon EKS con Elastic Fabric Adapter

Prerequisiti

Procedura