Administración de los dispositivos EFA en Amazon EKS

Elastic Fabric Adapter (EFA) es un dispositivo de red para instancias de Amazon EC2 que permite una comunicación entre nodos de alto rendimiento y RDMA (acceso directo a memoria remota) para inteligencia artificial, machine learning y cargas de trabajo de computación de alto rendimiento (HPC). Amazon EKS admite dos mecanismos para administrar los dispositivos EFA en los clústeres de EKS: el controlador de asignación dinámica de recursos de EFA (DRA) (DRANET) y el complemento para dispositivos de EFA.

Se recomienda utilizar el controlador de DRA de EFA (DRANET) para las nuevas implementaciones en los clústeres de EKS que ejecuten la versión 1.34 o posterior de Kubernetes con grupos de nodos administrados o grupos de nodos autoadministrados de EKS. El controlador de DRA de EFA permite configurar una asignación basada en la topología que empareja las interfaces de EFA con sus GPU topológicamente locales o sus dispositivos Neuron, y permite compartir dispositivos entre los pods.

El controlador de DRA de Karpenter no es compatible con el modo automático de EKS o Karpenter. Utilice el complemento de dispositivo EFA con Karpenter y el modo automático de EKS. El complemento para dispositivos EFA también sigue siendo compatible con los grupos de nodos administrados y los nodos autoadministrados de EKS.

Controlador de DRA de EFA frente al complemento para dispositivos EFA

Creación de nodos de EKS con interfaces EFA

Al crear nodos de EKS con interfaces EFA, las interfaces EFA se conectan a la instancia durante el aprovisionamiento de la instancia. Puede personalizar la configuración de EFA por dispositivo y utilizar grupos de ubicación con Karpenter, grupos de nodos administrados de EKS o grupos de nodos autoadministrados de EKS. Con Karpenter, la configuración de cada interfaz de red se transfiere a través de NodeClass. Con los grupos de nodos administrados o los nodos autoadministrados de EKS, se transfiere la configuración de cada interfaz de red con plantillas de lanzamiento. Próximamente, se incorporará el modo automático de EKS para grupos de configuración y ubicación de EFA por dispositivo.

Cuando se utiliza eksctl para aprovisionar nodos de EKS con la configuración efaEnabled, todas las interfaces se configuran según el tipo de interfaz EFA, se crea un grupo de seguridad específico de EFA y el complemento para dispositivos EFA se instala en el clúster. Si necesita personalizar la configuración de EFA por dispositivo al utilizar eksctl, se recomienda utilizar el soporte de eksctl para las plantillas de lanzamiento.

En los siguientes ejemplos se muestra cómo configurar NodeClass e iniciar plantillas con interfaces EFA. Esto resulta útil para personalizar las interfaces utilizadas para EFA en comparación con el tráfico estándar basado en IP. Para obtener información sobre la cantidad de interfaces EFA compatibles con cada tipo de instancia y cómo configurarlas para un ancho de banda de la red máximo, consulte Maximizar el ancho de banda de la red para los tipos de instancias habilitadas para EFA en la Guía del usuario de Amazon EC2.

Karpenter

Cada entrada networkInterfaces especifica networkCardIndex, deviceIndex y interfaceType. interfaceType puede ser interface para interfaces de red estándar o efa-only para interfaces EFA que están dedicadas al tráfico RDMA y no tienen direcciones IP asignadas. Cuando se configura networkInterfaces, las instancias iniciadas por la entidad NodePool que hace referencia a NodeClass utilizan esta configuración independientemente de si los pods solicitan recursos de vpc.amazonaws.com/efa.

Cuando se utiliza Karpenter sin especificar networkInterfaces en NodeClass, las instancias creadas para los pods que solicitan vpc.amazonaws.com/efa tienen todas las interfaces configuradas según el tipo de interfaz EFA.

La configuración de networkInterfaces para EC2NodeClass se agregó en Karpenter v1.11. En el siguiente ejemplo, se muestra una EC2NodeClass configurada para una P6-B200 con 1 interfaz ENA y 8 interfaces de solo EFA.

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

Grupos de nodos administrados y nodos autoadministrados de EKS

Con los grupos de nodos administrados o los nodos autoadministrados de EKS, se transfiere la configuración de cada interfaz de red con plantillas de lanzamiento.

En el siguiente ejemplo se muestra una plantilla de lanzamiento configurada para una instancia P6-B200 con 1 interfaz ENA y 8 interfaces de solo EFA. La interfaz de red principal (tarjeta de red 0, índice de dispositivos 0) utiliza un tipo de interface estándar para el tráfico IP, mientras que las interfaces adicionales utilizan efa-only para el tráfico de RDMA dedicado. Ajuste la cantidad de interfaces de efa-only en función del tipo de instancia. Para conocer la cantidad de interfaces EFA compatibles con cada tipo de instancia, consulte Maximizar el ancho de banda de la red para los tipos de instancias habilitadas para EFA en la Guía del usuario de 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"]
      }
    ]
  }
}

Uso de AMI optimizadas para EKS con EFA

Las AMI aceleradas de AL2023 optimizadas para EKS (NVIDIA y Neuron) y todas las AMI de Bottlerocket incluyen los componentes de nivel de host necesarios para usar EFA, en concreto los componentes instalados por aws-efa-installer. Las AMI de Bottlerocket y EKS AL2023 no incluyen el controlador de DRA de EFA ni el complemento para dispositivos EFA, y el complemento para dispositivos debe instalarse por separado en el clúster antes de implementar cargas de trabajo.

Conservación de la asignación de direcciones IP

Las instancias habilitadas para EFA, como p5.48xlarge y p6-b200.48xlarge, son compatibles con muchas interfaces de red. De forma predeterminada, la CNI de Amazon VPC asigna direcciones IP a todos los ENI conectados habilitados para IP, que pueden consumir una gran cantidad de direcciones IP de la subred, incluso cuando los pods no las utilizan activamente. En instancias con docenas de interfaces de red, esto puede agotar rápidamente el espacio de IP disponible de la subred.

Para reducir el consumo de direcciones IP en los nodos habilitados para EFA, configure las interfaces de red para que utilicen efa-only en todas las interfaces, excepto en la principal. Las interfaces exclusivas de EFA están dedicadas al tráfico RDMA y no tienen direcciones IP asignadas, por lo que no consumen direcciones de la subred. Para ver configuraciones de ejemplo, consulte Karpenter y Grupos de nodos administrados y nodos autoadministrados de EKS. Para conocer el diseño de interfaz recomendado para cada tipo de instancia, consulte Maximizar el ancho de banda de la red para los tipos de instancias habilitadas para EFA en la Guía del usuario de Amazon EC2.

Además de utilizar interfaces de efa-only, puede configurar la CNI de Amazon VPC para limitar la cantidad de direcciones IP calientes (preasignadas) y ENI. De forma predeterminada, la CNI de la VPC preasigna un conjunto caliente de ENI y direcciones IP para acelerar el inicio del pod, pero en instancias grandes puede reservar cientos de direcciones IP no utilizadas. Configure las variables de entorno WARM_IP_TARGET y WARM_ENI_TARGET en el DaemonSet aws-node para controlar el número de direcciones IP y ENI de reserva que mantiene el CNI. Para obtener más información sobre estos ajustes, consulte Prácticas recomendadas de CNI de Amazon VPC.

Instalación del controlador de DRA de EFA (DRANET)

El controlador de DRA de EFA está integrado en el proyecto DRANET ascendente, que proporciona una administración de dispositivos de red basada en la nube para Kubernetes DRA. El controlador de DRA de EFA y DRANET se utilizan indistintamente en esta documentación y hacen referencia a la misma herramienta.

El controlador de DRA de EFA anuncia los dispositivos EFA como objetos ResourceSlice con el nombre del controlador dra.net y el nombre de DeviceClass efa.networking.k8s.aws. El controlador de DRA de EFA se ejecuta como un DaemOnset en cada nodo y detecta automáticamente los dispositivos EFA.

Requisitos previos

Procedimiento

Asignación de dispositivos GPU/Neuron y EFA según la topología

El controlador de DRA de EFA admite la asignación compatible con la topología que empareja las interfaces de EFA con las GPU o los dispositivos Neuron en la misma raíz PCIe. Usa la restricción matchAttribute para alinear las asignaciones de dispositivos EFA y GPU o Neuron. Para utilizar esta capacidad, también debe utilizar los controladores DRA de NVIDIA o Neuron. Para obtener más información, consulte Administración de dispositivos GPU NVIDIA en Amazon EKS y Administración de los dispositivos Neuron en Amazon EKS.

En el siguiente ejemplo se solicita 1 interfaz EFA alineada 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"

En el siguiente ejemplo se solicitan 4 interfaces EFA alineadas con 4 dispositivos 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"

El número del nombre del atributo devicegroup corresponde al número de dispositivos Neuron del grupo de topología conectado. Por ejemplo, resource.aws.com/devicegroup1_id identifica un único dispositivo Neuron, resource.aws.com/devicegroup4_id identifica un grupo de 4 dispositivos conectados y resource.aws.com/devicegroup8_id y resource.aws.com/devicegroup16_id identifican grupos de 8 y 16 dispositivos conectados, respectivamente. Elija el matchAttribute que coincida con el dispositivo count de su solicitud para que los dispositivos Neuron y las interfaces EFA asignados pertenezcan al mismo grupo de topología conectado. Para obtener más información sobre estos atributos, consulte la documentación de DRA de Neuron.

Se puede utilizar allocationMode para simplificar la asignación de los dispositivos EFA a los aceleradores de GPU o Neuron alineados. El campo allocationMode admite dos valores: ExactCount (el valor predeterminado) solicita un número específico de dispositivos especificado por count y All solicita todos los dispositivos coincidentes de un grupo. Por ejemplo, en las instancias p5.48xlarge hay cuatro dispositivos EFA que comparten la misma raíz PCIe con una GPU. Para asignar estos grupos de dispositivos EFA a las GPU alineadas, aunque no conozca la asignación exacta de los dispositivos EFA-GPU ni el número exacto de dispositivos EFA alineados, puede configurar sus ResourceClaimTemplate con allocationMode: All para los dispositivos 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"

Uso compartido de los dispositivos EFA entre varios pods

El controlador de DRA de EFA permite compartir dispositivos EFA entre varios pods mediante un ResourceClaim. A diferencia de ResourceClaimTemplate, que genera una reclamación independiente para cada pod, ResourceClaim es un objeto con nombre que se crea de forma independiente y al que se hace referencia desde varios pods. Todos los pods que hacen referencia a la misma ResourceClaim comparten el acceso a los mismos dispositivos EFA asignados y están programados en el mismo nodo en el que están disponibles esos dispositivos.

Para compartir dispositivos EFA entre los pods, cree una ResourceClaim que solicite los dispositivos EFA y, a continuación, haga referencia a esa reclamación por su nombre en el campo resourceClaims de cada Pod mediante resourceClaimName. ResourceClaim debe existir en el clúster antes de crear los pods que hacen referencia a él. Si no existe una ResourceClaim a la que se hace referencia, los pods permanecen en estado pendiente hasta que se cree la reclamación.

En el siguiente ejemplo, se crea una ResourceClaim que solicita 4 dispositivos EFA y dos pods que comparten el acceso a esos dispositivos.

Ambos pods hacen referencia a la misma shared-efa ResourceClaim y están programados para el nodo en el que están asignados esos dispositivos EFA. El ciclo de vida de ResourceClaim es independiente de los pods: persiste hasta que lo elimine, incluso si se eliminan todos los pods que hacen referencia a ella.

Instalación del complemento para dispositivos de Kubernetes de EFA

El complemento para dispositivos EFA de Kubernetes anuncia los dispositivos EFA como recursos ampliados de vpc.amazonaws.com/efa. Los dispositivos EFA se solicitan en límites y solicitudes de recursos de contenedores. Para ver un recorrido completo sobre cómo configurar EFA con cargas de trabajo de formación, consulte Impartición de formación en machine learning en Amazon EKS con Elastic Fabric Adapter.

Requisitos previos

Procedimiento