Gérer les appareils EFA sur Amazon EKS

Elastic Fabric Adapter (EFA) est un périphérique réseau pour les instances Amazon EC2 qui permet des communications inter-nœuds hautes performances et un accès RDMA (Remote Direct Memory Access) pour les charges de travail liées à l'intelligence artificielle, à l'apprentissage automatique et au calcul haute performance (HPC). Amazon EKS prend en charge deux mécanismes pour gérer les périphériques EFA dans les clusters EKS : le pilote EFA Dynamic Resource Allocation (DRA) (DRANET) et le plug-in de périphérique EFA.

Nous vous recommandons d'utiliser des pilotes DRA pour les nouveaux déploiements avec les versions 1.34 et ultérieures de Kubernetes lorsque vous utilisez le provisionnement de capacité statique dans Karpenter, des groupes de nœuds gérés par EKS ou des nœuds autogérés. Le DRA n'est actuellement pas pris en charge avec le mode automatique EKS. Avec le pilote EFA DRA, vous pouvez configurer une allocation tenant compte de la topologie qui associe les interfaces EFA à leurs GPU topologiquement locaux ou à leurs périphériques Neuron, et partager des périphériques entre les Pods.

Pilote EFA DRA ou plug-in de périphérique EFA

Création de nœuds EKS avec des interfaces EFA

Lorsque vous créez des nœuds EKS avec des interfaces EFA, les interfaces EFA sont attachées à l'instance lors du provisionnement de l'instance. Vous pouvez personnaliser la configuration EFA par appareil et utiliser des groupes de placement avec EKS Auto Mode, Karpenter, des groupes de nœuds gérés EKS ou des groupes de nœuds autogérés EKS. Avec le mode automatique EKS, vous passez la configuration de chaque interface réseau par le biais du NodeClass dessousadvancedNetworking.networkInterfaces. Avec Karpenter, vous transmettez la configuration de chaque interface réseau via leEC2NodeClass. Avec les groupes de nœuds gérés par EKS ou les nœuds autogérés, vous transmettez la configuration pour chaque interface réseau à l'aide de modèles de lancement.

Lors de l'utilisation eksctl pour le provisionnement de nœuds EKS avec ce efaEnabled paramètre, toutes les interfaces sont configurées avec le type d'interfaceEFA, un groupe de EFA-specific sécurité est créé et le plug-in du périphérique EFA est installé sur le cluster. Si vous devez personnaliser la configuration EFA par appareil lors de l'utilisationeksctl, il est recommandé d'utiliser le support d'eksctl pour les modèles de lancement. https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html

Les exemples suivants montrent comment configurer NodeClass et lancer des modèles avec des interfaces EFA. Ceci est utile pour personnaliser les interfaces utilisées pour le trafic EFA par rapport au IP-based trafic standard. Pour plus d'informations sur le nombre d'interfaces EFA prises en charge par chaque type d'instance et sur la manière de les configurer pour une bande passante réseau maximale, voir Maximiser la bande passante réseau pour les types d' EFA-enabled instance dans le guide de l'utilisateur Amazon EC2.

Mode automatique EKS

En mode EKS Auto, vous configurez les interfaces réseau EFA à l'aide du advancedNetworking.networkInterfaces champ du NodeClass (eks.amazonaws.com/v1). Chaque entrée spécifie un networkCardIndexdeviceIndex, etinterfaceType. Il interfaceType peut s'agir interface d'interfaces réseau standard ou efa-only d'interfaces EFA dédiées au trafic RDMA sans adresse IP attribuée.

Lorsqu'elle networkInterfaces est configurée, les instances lancées par le NodePool référencement NodeClass utilisent cette configuration, que les Pods demandent des vpc.amazonaws.com/efa ressources ou non. Le mode EKS Auto n'associe pas d'adresses IP, de préfixes ou d'ENI supplémentaires après le lancement de l'instance pour les nœuds dotés d'une configuration d'interface réseau statique. Seules les interfaces et les adresses IP configurées au lancement sont disponibles pour les Pods.

Cette fonctionnalité peut être utilisée avec des pools de nœuds à capacité statique afin de maintenir des EFA-ready nœuds préchauffés pour les charges de travail d'entraînement et d'inférence distribuées.

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

Pour obtenir la liste complète des contraintes relatives à la configuration de l'interface réseau statique, consultez Configuration de l'interface réseau statique la NodeClass documentation.

Karpenter

Chaque entrée dans networkInterfaces spécifie un networkCardIndexdeviceIndex, etinterfaceType. Il interfaceType peut s'agir interface d'interfaces réseau standard ou efa-only d'interfaces EFA dédiées au trafic RDMA et auxquelles aucune adresse IP n'est attribuée. Lorsqu'elle networkInterfaces est configurée, les instances lancées par le NodePool référencement NodeClass utilisent cette configuration, que les Pods demandent des vpc.amazonaws.com/efa ressources ou non.

Lorsque vous utilisez Karpenter sans le spécifier networkInterfaces dans votreNodeClass, les instances créées pour les demandes de Pods vpc.amazonaws.com/efa ont toutes les interfaces configurées avec le type EFA d'interface.

La networkInterfaces configuration de EC2NodeClass a été ajoutée dans Karpenter v1.11. L'exemple suivant montre une EC2NodeClass configuration pour une P6-B200 instance avec 1 interface ENA et 8 EFA-only interfaces.

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

Groupes de nœuds gérés par EKS et nœuds autogérés

Avec les groupes de nœuds gérés par EKS ou les nœuds autogérés, vous transmettez la configuration pour chaque interface réseau à l'aide de modèles de lancement.

L'exemple suivant montre un modèle de lancement configuré pour une P6-B200 instance avec 1 interface ENA et 8 EFA-only interfaces. L'interface réseau principale (carte réseau 0, indice de périphérique 0) utilise un interface type standard pour le trafic IP, tandis que les interfaces supplémentaires l'utilisent efa-only pour le trafic RDMA dédié. Ajustez le nombre d'efa-onlyinterfaces en fonction de votre type d'instance. Pour connaître le nombre d'interfaces EFA prises en charge par chaque type d'instance, voir Maximiser la bande passante réseau pour les types d' EFA-enabled instances dans le guide de l'utilisateur Amazon EC2.

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

Utilisation d' EKS-optimized AMI avec EFA

Les AMI EKS-optimized AL2023 et toutes les AMI Bottlerocket incluent les composants au niveau de l'hôte requis pour utiliser EFA, en particulier les composants installés par l'installateur aws-efa. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable Les AMI EKS AL2023 et Bottlerocket n'incluent pas le pilote EFA DRA ni le plug-in de périphérique EFA, et ceux-ci doivent être installés séparément sur votre cluster avant de déployer des charges de travail.

Conservation de l'allocation d'adresses IP

EFA-enabled instances telles que p5.48xlarge et p6-b200.48xlarge prennent en charge de nombreuses interfaces réseau. Par défaut, Amazon VPC CNI attribue des adresses IP à tous les ENI IP-enabled connectés, ce qui peut consommer un grand nombre d'adresses IP provenant de votre sous-réseau même lorsque ces adresses ne sont pas utilisées activement par les Pods. Sur les instances dotées de dizaines d'interfaces réseau, cela peut rapidement épuiser l'espace IP disponible de votre sous-réseau.

Pour réduire la consommation d'adresses IP sur les EFA-enabled nœuds, configurez vos interfaces réseau afin qu'elles soient utilisées efa-only pour toutes les interfaces, à l'exception de la principale. EFA-only les interfaces sont dédiées au trafic RDMA et n'ont pas d'adresse IP attribuée, elles ne consomment donc pas d'adresses provenant de votre sous-réseau. Pour des exemples de configurations, reportez-vous Karpenter aux sections etGroupes de nœuds gérés par EKS et nœuds autogérés. Pour connaître la disposition d'interface recommandée pour chaque type d'instance, voir Maximiser la bande passante réseau pour les types d' EFA-enabled instances dans le guide de l'utilisateur Amazon EC2.

Outre l'utilisation d'efa-onlyinterfaces, vous pouvez configurer le CNI Amazon VPC pour limiter le nombre d'adresses IP chaudes (pré-allouées) et d'ENI. Par défaut, le VPC CNI préalloue un pool chaud d'ENI et d'adresses IP pour accélérer le démarrage du Pod, mais sur les instances volumineuses, cela peut réserver des centaines d'adresses IP inutilisées. Définissez les variables WARM_IP_TARGET et d'WARM_ENI_TARGETenvironnement sur le aws-node DaemonSet pour contrôler le nombre d'adresses IP et d'ENI disponibles que le CNI gère. Pour plus d'informations sur ces paramètres, consultez les meilleures pratiques CNI d'Amazon VPC.

Installez le pilote EFA DRA (DRANET)

Le pilote EFA DRA est intégré au projet DRANET en amont sur GitHub, qui fournit une gestion des périphériques réseau compatible avec le cloud pour Kubernetes DRA. Le pilote EFA DRA et DRANET sont utilisés de manière interchangeable dans cette documentation et font référence au même outil.

Le pilote EFA DRA annonce les périphériques EFA en tant qu'ResourceSliceobjets portant le nom du pilote dra.net et le DeviceClass nomefa.networking.k8s.aws. Le pilote EFA DRA s'exécute DaemonSet sur chaque nœud et découvre automatiquement les périphériques EFA.

Conditions préalables

Procédure

Topology-aware EFA et attribution des GPU/Neuron appareils

Le pilote EFA DRA prend en charge l'allocation tenant compte de la topologie qui associe les interfaces EFA à des GPU ou à des périphériques Neuron sur la même racine PCIe. Utilisez la matchAttribute contrainte pour aligner les allocations d'appareils EFA et GPU ou Neuron. Pour utiliser cette fonctionnalité, vous devez également utiliser les pilotes NVIDIA ou Neuron DRA. Pour plus d’informations, consultez Gérer les GPU NVIDIA sur Amazon EKS et Gérer les appareils Neuron sur Amazon EKS.

L'exemple suivant demande 1 interface EFA alignée sur 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'exemple suivant demande 4 interfaces EFA alignées avec 4 appareils 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"

Le numéro indiqué dans le nom de devicegroup l'attribut correspond au nombre de périphériques Neuron dans le groupe de topologie connecté. Par exemple, resource.aws.com/devicegroup1_id identifie un seul appareil Neuron, resource.aws.com/devicegroup4_id identifie un groupe de 4 appareils connectés resource.aws.com/devicegroup8_id et resource.aws.com/devicegroup16_id identifie des groupes de 8 et 16 appareils connectés respectivement. Choisissez matchAttribute celui qui correspond au périphérique count de votre demande afin que les appareils Neuron et les interfaces EFA alloués appartiennent au même groupe de topologie connecté. Pour plus d'informations sur ces attributs, consultez la documentation du pilote Neuron DRA.

Vous pouvez l'utiliser allocationMode pour simplifier la façon dont les appareils EFA sont attribués aux accélérateurs GPU ou Neuron alignés. Le allocationMode champ prend en charge deux valeurs : ExactCount (valeur par défaut) demande un nombre spécifique d'appareils spécifié par count et All demande tous les appareils correspondants d'un pool. Par exemple, sur les p5.48xlarge instances, quatre périphériques EFA partagent la même racine PCIe avec un seul GPU. Pour attribuer à ces groupes d'appareils EFA des GPU alignés, même si vous ne connaissez pas le mappage exact des EFA-GPU appareils et le nombre d'appareils EFA alignés, vous pouvez configurer votre option allocationMode: All pour ResourceClaimTemplate les appareils EFA.

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"

Partagez des appareils EFA entre plusieurs Pods

Le pilote EFA DRA prend en charge le partage de périphériques EFA entre plusieurs Pods à l'aide d'unResourceClaim. Contrairement à aResourceClaimTemplate, qui génère une revendication distincte pour chaque Pod, a ResourceClaim est un objet nommé que vous créez indépendamment et que vous faites référence à partir de plusieurs Pods. Tous les Pods qui font référence au même accès ResourceClaim partagent l'accès aux mêmes appareils EFA alloués et sont programmés sur le même nœud que celui où ces appareils sont disponibles.

Pour partager des appareils EFA entre des Pods, créez un ResourceClaim qui demande les appareils EFA, puis faites référence à cette réclamation par son nom dans resourceClaims le champ de chaque Pod en utilisantresourceClaimName. Ils ResourceClaim doivent exister dans le cluster pour que les pods qui le référencent soient créés. Si ResourceClaim aucune référence n'existe, les Pods restent en attente jusqu'à ce que la réclamation soit créée.

L'exemple suivant crée un ResourceClaim qui demande 4 appareils EFA et deux Pods qui partagent l'accès à ces appareils.

Les deux pods font référence à la même chose shared-efa ResourceClaim et sont programmés sur le nœud où ces appareils EFA sont alloués. Le ResourceClaim cycle de vie est indépendant des Pods : il persiste jusqu'à ce que vous le supprimiez, même si tous les Pods qui y font référence sont supprimés.

Installez le plug-in de périphérique EFA Kubernetes

Le plug-in EFA Kubernetes présente les appareils EFA en tant que ressources étendues. vpc.amazonaws.com/efa Vous demandez des appareils EFA dans les demandes et les limites de ressources du conteneur. Pour une présentation complète de la configuration de l'EFA avec des charges de travail de formation, voir. Exécuter un entraînement de machine learning sur Amazon EKS avec Elastic Fabric Adapter

Conditions préalables

Procédure