Gérez les appareils EFA sur Amazon EKS

L'Elastic Fabric Adapter (EFA) est un périphérique réseau pour les instances Amazon EC2 qui permet une communication inter-nœuds à hautes performances et un 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 appareils EFA dans les clusters EKS : le pilote EFA Dynamic Resource Allocation (DRA) (DRANET) et le plug-in d'appareil EFA.

Il est recommandé d'utiliser le pilote EFA DRA (DRANET) pour les nouveaux déploiements sur des clusters EKS exécutant Kubernetes version 1.34 ou ultérieure avec des groupes de nœuds gérés par EKS ou des groupes de nœuds autogérés. Le pilote EFA DRA vous permet de configurer une allocation adaptée à la topologie qui associe les interfaces EFA à leurs GPU topologiquement locaux ou à leurs périphériques Neuron, et prend en charge le partage de périphériques entre les pods.

Le pilote EFA DRA n'est pas compatible avec le mode automatique Karpenter ou EKS. Utilisez le plug-in de l'appareil EFA avec Karpenter et le mode automatique EKS. Le plug-in de périphérique EFA reste également pris en charge pour les groupes de nœuds gérés par EKS et les nœuds autogérés.

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 Karpenter, des groupes de nœuds gérés par EKS ou des groupes de nœuds autogérés par EKS. Avec Karpenter, vous pouvez transmettre la configuration de chaque interface réseau via leNodeClass. Avec les groupes de nœuds gérés par EKS ou les nœuds autogérés, vous pouvez transmettre la configuration de chaque interface réseau à l'aide de modèles de lancement. La prise en charge du mode automatique EKS pour la configuration EFA par appareil et les groupes de placement sera bientôt disponible.

Lors de l'utilisation eksctlpour approvisionner des nœuds EKS avec le 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 de 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 de `eksctl pour les modèles de lancement.

Les exemples suivants montrent comment configurer NodeClass et lancer des modèles avec des interfaces EFA. Cela 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, consultez Maximiser la bande passante réseau pour les types d' EFA-enabled instance dans le guide de l'utilisateur Amazon EC2.

Karpenter

Chaque entrée de 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érençage NodeClass utilisent cette configuration, que les Pods demandent ou non des vpc.amazonaws.com/efa ressources.

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

La networkInterfaces configuration pour EC2NodeClass a été ajoutée dans Karpenter v1.11. L'exemple suivant montre une instance EC2NodeClass configurée 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 pouvez transmettre la configuration de 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, index de périphérique 0) utilise un interface type standard pour le trafic IP, tandis que les interfaces supplémentaires utilisent efa-only 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, consultez 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 accélérées EKS-optimized AL2023 (NVIDIA et Neuron) 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. 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 des adresses IP

EFA-enabled instances telles que p5.48xlarge et prenant p6-b200.48xlarge en charge de nombreuses interfaces réseau. Par défaut, le CNI Amazon VPC alloue des adresses IP à tous les ENI IP-enabled connectés, qui peuvent consommer un grand nombre d'adresses IP de votre sous-réseau même lorsque ces adresses ne sont pas activement utilisées par les Pods. Sur les instances comportant des 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 EFA-enabled les nœuds, configurez vos interfaces réseau pour qu'elles soient utilisées efa-only pour toutes les interfaces sauf l'interface 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 les adresses de votre sous-réseau. Pour des exemples de configurations, voir Karpenter 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, consultez 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 et d'ENI chaudes (préallouées). 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 grandes instances, cela peut réserver des centaines d'adresses IP inutilisées. Définissez les variables d'WARM_ENI_TARGETenvironnement WARM_IP_TARGET et sur le aws-node DaemonSet pour contrôler le nombre d'adresses IP et d'ENI de rechange gérées par le CNI. Pour plus d'informations sur ces paramètres, consultez les meilleures pratiques Amazon VPC CNI.

Installation du pilote EFA DRA (DRANET)

Le pilote EFA DRA est intégré au projet DRANET en amont, qui fournit une gestion des périphériques réseau adaptée au 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 présente les appareils EFA sous forme ResourceSlice d'objets portant le nom dra.net et le DeviceClass nom efa.networking.k8s.aws du pilote. Le pilote EFA DRA s'exécute comme un DaemonSet sur chaque nœud et découvre automatiquement les périphériques EFA.

Conditions préalables

Procédure

Topology-aware EFA et allocation GPU/Neuron d'appareils

Le pilote EFA DRA prend en charge l'allocation tenant compte de la topologie qui associe les interfaces EFA aux GPU ou aux périphériques Neuron sur la même racine PCIe. Utilisez la matchAttribute contrainte pour aligner les allocations 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érez les appareils GPU NVIDIA sur Amazon EKS et Gérez 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 sur 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 figurant dans le nom de devicegroup l'attribut correspond au nombre de dispositifs Neuron dans le groupe topologique 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 à l'appareil indiqué count dans votre demande afin que les appareils Neuron et les interfaces EFA alloués appartiennent au même groupe topologique 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 alloués aux accélérateurs GPU ou Neuron alignés. Le allocationMode champ prend en charge deux valeurs : ExactCount (par défaut) demande un nombre spécifique d'appareils spécifié parcount, et All demande tous les appareils correspondants dans 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 avec des GPU alignés, même si vous ne connaissez pas le mappage exact des EFA-GPU appareils ni le nombre d'appareils EFA alignés, vous pouvez configurer votre compte ResourceClaimTemplate avec allocationMode: All pour 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 réclamation distincte pour chaque pod, a ResourceClaim est un objet nommé que vous créez indépendamment et que vous référencez à 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 planifiés sur le même nœud où ces appareils sont disponibles.

Pour partager des appareils EFA entre des pods, créez un ResourceClaim qui demande les appareils EFA, puis référencez cette réclamation par son nom dans resourceClaims le champ de chaque pod en utilisantresourceClaimName. Le ResourceClaim doit exister dans le cluster avant que les pods qui le référencent ne 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 partageant l'accès à ces appareils.

Les deux pods font référence à la même chose shared-efa ResourceClaim et sont planifié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 les supprimiez, même si tous les pods qui y font référence sont supprimés.

Installez le plugin pour appareil EFA Kubernetes

Le plugin pour appareils EFA Kubernetes présente les appareils EFA en tant que ressources étendues. vpc.amazonaws.com/efa Vous demandez des appareils EFA dans les demandes de ressources et les limites des conteneurs. Pour une présentation complète de la configuration d'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