**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Administración de los dispositivos EFA en Amazon EKS
[Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) (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](#eks-efa-device-plugin) 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
| Característica | Controlador de DRA de EFA | Complemento para dispositivos de EFA |
| --- | --- | --- |
| Versión mínima de Kubernetes | 1.34 | Todas las versiones de Kubernetes compatible con EKS |
| Computación de EKS | Grupos de nodos administrados, nodos autoadministrados | Modo automático de EKS, Karpenter, grupos de nodos administrados, nodos autoadministrados |
| AMI optimizadas para EKS | AL2023 (NVIDIA, Neuron), Bottlerocket | AL2023 (NVIDIA, Neuron), Bottlerocket |
| Anuncio de dispositivo | Atributos enriquecidos a través de objetos `ResourceSlice`, como el tipo de dispositivo, la topología y la localidad de PCIe | Recuento de enteros de recursos ampliados de `vpc.amazonaws.com/efa` |
| Afinidad GPU-EFA | Reconocimiento de la topología nativa de DRA | Reconocimiento automático de la topología (solo AMI AL2023 optimizadas para EKS) |
| Afinidad Neuron-EFA | Reconocimiento de la topología nativa de DRA | Reconocimiento automático de la topología (solo AMI AL2023 optimizadas para EKS) |
| Uso compartido de dispositivos | Varios pods pueden compartir el mismo dispositivo EFA a través de referencias `ResourceClaim` compartidas | No admitido. Cada dispositivo EFA se asigna exclusivamente a un pod. |
## 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html). 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`](install-kubectl.md#eksctl-install-update) 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](https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html).
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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) 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.
### Ejemplo: EC2NodeClass de Karpenter con interfaces de solo EFA para P6-B200
```
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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html).
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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) en la *Guía del usuario de Amazon EC2*.
### Ejemplo de plantilla de lanzamiento con interfaces de solo EFA para P6-B200
Reemplace ` security-group-id ` por sus valores. El grupo de seguridad debe permitir todo el tráfico entrante y saliente hacia y desde sí mismo para habilitar la funcionalidad de omisión del sistema operativo de EFA. Para más información, consulte [Paso 1: preparar un grupo de seguridad compatibles con EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) en la *Guía del usuario de Amazon EC2*.
**importante**
No especifique `SubnetId` en la plantilla de lanzamiento cuando utilice grupos de nodos administrados de EKS. EKS exige que todas las subredes se especifiquen a través de la API `CreateNodegroup` y rechaza las plantillas de lanzamiento que incluyen la configuración de subredes.
```
{
"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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable). 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](#eks-efa-auto-karpenter) y [Grupos de nodos administrados y nodos autoadministrados de EKS](#eks-efa-mng-self-managed). 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) 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](https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html#_overview).
**nota**
Las configuraciones `WARM_ENI_TARGET` y `WARM_IP_TARGET` abarcan todo el clúster y se aplican a todos los nodos administrados por la CNI de VPC. Actualmente, no hay forma de establecer valores diferentes por grupo de nodos o tipo de instancia. Si necesita un control más detallado de estos ajustes, envíenos sus comentarios sobre el [problema n.º 1834 de containers-roadmap](https://github.com/aws/containers-roadmap/issues/1834).
## Instalación del controlador de DRA de EFA (DRANET)
El controlador de DRA de EFA está integrado en el proyecto [DRANET](https://github.com/kubernetes-sigs/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
+ Un clúster de Amazon EKS que ejecuta la versión 1.34 o posterior de Kubernetes o grupos de nodos administrados o grupos de nodos autoadministrados de EKS.
+ Nodos con tipos de instancias de Amazon EC2 habilitadas para EFA. Para obtener una lista de los tipos de instancia compatibles, consulte [Tipos de instancias compatibles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) en la *Guía del usuario de Amazon EC2*.
+ Nodos con componentes de nivel de host instalados para EFA; consulte [Instalación del software EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) para obtener más información. Las AMI aceleradas de NVIDIA y Neuron de AL2023 optimizadas para EKS y las AMI de Bottlerocket incluyen los componentes de nivel de host de EFA.
+ Si tiene Helm instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de Helm](helm.md) para obtener más información.
+ `kubectl` configurado para comunicarse con su clúster. Consulte [Instalación o actualización de `kubectl`](install-kubectl.md#kubectl-install-update) para obtener más información.
### Procedimiento
**importante**
No instale el controlador de DRA de EFA en los nodos en los que se esté ejecutando el complemento para dispositivos EFA. Los dos mecanismos no pueden coexistir en el mismo nodo. Consulte [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004) de Kubernetes ascendente para ver las actualizaciones.
1. Agregue el repositorio de gráficos de Helm de EKS.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Actualice el repositorio de Helm local.
```
helm repo update
```
1. Instale el controlador de DRA de EFA en su clúster con Helm. El controlador de DRA de EFA detecta automáticamente que se está ejecutando en instancias de EC2 a través del servicio de metadatos de instancias (IMDS) y permite la detección de dispositivos EFA. El controlador de DRA de EFA se implementa como un DaemOnset en el espacio de nombres `kube-system` de forma predeterminada. Consulte los valores de Helm en el [repositorio de GitHub del gráfico de Helm de EKS](https://github.com/aws/eks-charts/tree/master/stable/aws-dranet) para ver los parámetros configurables.
```
helm install aws-dranet eks/aws-dranet --namespace kube-system
```
1. Compruebe que el DaemOnset de DRANET esté funcionando.
```
kubectl get daemonset -n kube-system aws-dranet
```
```
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
aws-dranet 2 2 2 2 2 60s
```
1. Compruebe que `DeviceClass` se haya creado.
```
kubectl get deviceclass
```
```
NAME AGE
efa.networking.k8s.aws 60s
```
1. Compruebe que los objetos `ResourceSlice` estén anunciados para sus nodos.
```
kubectl get resourceslices --field-selector spec.driver=dra.net
```
Si observa errores al realizar los pasos anteriores, puede comprobar los registros de DRANET con el siguiente comando.
```
kubectl logs -n kube-system -l app=aws-dranet
```
1. Para solicitar dispositivos EFA mediante el controlador de DRA, cree un `ResourceClaim` o `ResourceClaimTemplate` que haga referencia al `DeviceClass` y haga referencia a él en la especificación del pod. En el siguiente ejemplo, se solicita un único dispositivo EFA.
```
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: single-efa-claim
spec:
spec:
devices:
requests:
- name: efa
exactly:
deviceClassName: efa.networking.k8s.aws
count: 1
---
apiVersion: v1
kind: Pod
metadata:
name: efa-workload
spec:
containers:
- name: app
...
resources:
claims:
- name: efa-device
resourceClaims:
- name: efa-device
resourceClaimTemplateName: single-efa-claim
```
## 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](device-management-nvidia.md) y [Administración de los dispositivos Neuron en Amazon EKS](device-management-neuron.md).
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](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/neuron-dra.html).
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.
1. Creación del `ResourceClaim`.
```
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: shared-efa
spec:
devices:
requests:
- name: efa
exactly:
deviceClassName: efa.networking.k8s.aws
count: 4
```
1. Haga referencia a `ResourceClaim` por el nombre de cada pod que necesite acceso a los dispositivos EFA. Cada pod utiliza `resourceClaimName` para hacer referencia a la reclamación existente en lugar de `resourceClaimTemplateName`.
```
apiVersion: v1
kind: Pod
metadata:
name: training-worker
spec:
containers:
- name: worker
image: my-training-image
resources:
claims:
- name: efa-devices
resourceClaims:
- name: efa-devices
resourceClaimName: shared-efa
---
apiVersion: v1
kind: Pod
metadata:
name: training-monitor
spec:
containers:
- name: monitor
image: my-monitor-image
resources:
claims:
- name: efa-devices
resourceClaims:
- name: efa-devices
resourceClaimName: shared-efa
```
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](node-efa.md).
**importante**
La asignación alineada con la topología de las GPU NVIDIA o los dispositivos Neuron con interfaces EFA se realiza automáticamente cuando se utilizan las AMI aceleradas AL2023 optimizadas para EKS. Esta alineación automática no se produce cuando se utilizan AMI optimizadas para EKS de Bottlerocket o AMI personalizadas. Si necesita una asignación de dispositivos EFA y aceleradores alineados con la topología con Bottlerocket o AMI personalizadas, utilice el controlador de DRA de EFA y el controlador de DRA de Neuron correspondiente. Actualmente, no se admite el uso del controlador de DRA de NVIDIA en Bottlerocket. Para obtener más información, consulte [Asignación de dispositivos GPU/Neuron y EFA según la topología](#efa-dra-topology-aware).
**importante**
A partir de la versión `k8s-device-plugin` v0.19.0 de NVIDIA, el indicador `--mofed-enabled` se establece de forma predeterminada en `true`, lo que hace que el complemento para dispositivos de NVIDIA monte todos los dispositivos `/dev/infiniband/uverbs*` en contenedores que solicitan GPU. Esto entra en conflicto con el complemento de dispositivo EFA, que debería ser el componente que gestione la asignación de dispositivos EFA en `/dev/infiniband`. Si utiliza grupos de nodos administrados o nodos autoadministrados de EKS con el complemento para dispositivos NVIDIA, debe deshabilitar MOFED de forma explícita. Para obtener instrucciones, consulte [Instalación del complemento para dispositivos de Kubernetes de NVIDIA](device-management-nvidia.md#nvidia-device-plugin).
El modo automático de EKS no habilita MOFED de forma predeterminada y no se ve afectado por este problema.
### Requisitos previos
+ Un clúster de Amazon EKS.
+ Nodos con tipos de instancias de Amazon EC2 habilitadas para EFA. Para obtener una lista de los tipos de instancia compatibles, consulte [Tipos de instancias compatibles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) en la *Guía del usuario de Amazon EC2*.
+ Nodos con componentes de nivel de host instalados para EFA; consulte [Instalación del software EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) para obtener más información. Las AMI aceleradas de NVIDIA y Neuron de AL2023 optimizadas para EKS y las AMI de Bottlerocket incluyen los componentes de nivel de host de EFA.
+ Si tiene Helm instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de Helm](helm.md) para obtener más información.
+ `kubectl` configurado para comunicarse con su clúster. Consulte [Instalación o actualización de `kubectl`](install-kubectl.md#kubectl-install-update) para obtener más información.
### Procedimiento
1. Agregue el repositorio de gráficos de Helm de EKS.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Actualice el repositorio de Helm local.
```
helm repo update
```
1. Instale el complemento para dispositivos EFA.
```
helm install efa eks/aws-efa-k8s-device-plugin -n kube-system
```
1. Compruebe que el DaemonSet del complemento para dispositivos EFA esté en ejecución.
```
kubectl get daemonset -n kube-system efa-aws-efa-k8s-device-plugin
```
```
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
efa-aws-efa-k8s-device-plugin 2 2 2 2 2 60s
```
1. Compruebe que los nodos tengan recursos de EFA asignables.
```
kubectl get nodes "-o=custom-columns=NAME:.metadata.name,EFA:.status.allocatable.vpc\.amazonaws\.com/efa"
```
```
NAME EFA
ip-192-168-11-225.us-west-2.compute.internal 4
ip-192-168-24-96.us-west-2.compute.internal 4
```
1. Para solicitar que los dispositivos EFA use el complemento para dispositivos, especifique el recurso `vpc.amazonaws.com/efa` en los límites y solicitudes de recursos del contenedor.
```
apiVersion: v1
kind: Pod
metadata:
name: efa-workload
spec:
containers:
- name: app
...
resources:
limits:
vpc.amazonaws.com/efa: 4
hugepages-2Mi: ...
requests:
vpc.amazonaws.com/efa: 4
hugepages-2Mi: ...
```