**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# Gerenciar dispositivos EFA no Amazon EKS
O [Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) (EFA) consiste em um dispositivo de rede para instâncias do Amazon EC2 que viabiliza a comunicação de alta performance entre nós e RDMA (acesso remoto e direto a memória) para workloads de inteligência artificial, machine learning e computação de alta performance (HPC). O Amazon EKS oferece suporte a dois mecanismos para gerenciar dispositivos EFA em clusters do EKS: o *driver de alocação dinâmica de recursos (DRA) do EFA (DRANET)* e o *plug-in de dispositivo EFA*.
É recomendado usar o driver de DRA do EFA (DRANET) para novas implantações em clusters do EKS que executam a versão 1.34 ou versões posteriores do Kubernetes com grupos de nós gerenciados pelo EKS ou grupos de nós autogerenciados. O driver de DRA do EFA torna possível configurar a alocação com reconhecimento de topologia que emparelha interfaces EFA com dispositivos do Neuron ou GPUs topologicamente locais, e oferece suporte ao compartilhamento de dispositivos entre pods.
Não há suporte para o driver de DRA do EFA com o Karpenter ou para o Modo Automático do EKS. Use o [plug-in de dispositivo EFA](#eks-efa-device-plugin) com o Karpenter e o Modo Automático do EKS. Além disso, o plug-in de dispositivo EFA permanece compatível com grupos de nós gerenciados pelo EKS e com nós autogerenciados.
## Driver de DRA do EFA em comparação com o plug-in de dispositivo EFA
| Recurso | Driver de DRA do EFA | Plug-in de dispositivo do EFA |
| --- | --- | --- |
| Versão mínima do Kubernetes | 1.34 | Todas as versões do Kubernetes compatíveis com o EKS |
| Computação do EKS | Grupos de nós gerenciados e nós autogerenciados | Modo Automático do EKS, Karpenter, grupos de nós gerenciados e nós autogerenciados |
| AMIs otimizadas para o EKS | AL2023 (NVIDIA e Neuron) e Bottlerocket | AL2023 (NVIDIA e Neuron) e Bottlerocket |
| Anúncio de dispositivo | Atributos avançados via objetos `ResourceSlice`, incluindo tipo de dispositivo, topologia e localidade PCIe | Contagem de inteiros de recursos estendidos `vpc.amazonaws.com/efa` |
| Afinidade entre GPU e EFA | Reconhecimento de topologia nativo de DRA | Reconhecimento de topologia automático (apenas AMIs AL2023 otimizadas para o EKS) |
| Afinidade entre Neuron e EFA | Reconhecimento de topologia nativo de DRA | Reconhecimento de topologia automático (apenas AMIs AL2023 otimizadas para o EKS) |
| Compartilhamento de dispositivos | Vários pods podem compartilhar o mesmo dispositivo EFA por meio de referências compartilhadas de `ResourceClaim` | Sem compatibilidade. Cada dispositivo EFA é alocado exclusivamente para um pod |
## Criar nós EKS com interfaces EFA
Ao criar nós do EKS com interfaces EFA, as interfaces EFA são anexadas à instância durante o provisionamento. É possível personalizar a configuração do EFA por dispositivo e usar [grupos de posicionamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) com o Karpenter, grupos de nós gerenciados pelo EKS ou grupos de nós autogerenciados do EKS. Com o Karpenter, a configuração de cada interface de rede é definida por meio da `NodeClass`. Com os grupos de nós gerenciados ou com os nós autogerenciados do EKS, a configuração de cada interface de rede é definida por meio de [modelos de inicialização](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html). Em breve, haverá suporte ao Modo Automático do EKS para configuração EFA por dispositivo e para grupos de posicionamento.
Ao usar [`eksctl`](install-kubectl.md#eksctl-install-update) para provisionar nós do EKS com a configuração `efaEnabled`, todas as interfaces são configuradas com o tipo de interface `EFA`, um grupo de segurança específico do EFA é criado, e o plug-in de dispositivo do EFA é instalado no cluster. Se você precisar personalizar a configuração do EFA por dispositivo ao usar o `eksctl`, recomenda-se utilizar o suporte do `eksctl` para [modelos de inicialização](https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html).
Os exemplos a seguir mostram como configurar `NodeClass` e modelos de inicialização com interfaces EFA. Isso é útil para personalizar as interfaces usadas para EFA em comparação com o tráfego padrão baseado em IP. Para obter informações sobre o número de interfaces EFA compatíveis com cada tipo de instância e como configurá-las para obter a largura de banda da rede máxima, consulte [Maximizar a largura de banda da rede para tipos de instância habilitados para EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) no *Guia do usuário do Amazon EC2*.
## Karpenter
Cada entrada em `networkInterfaces` especifica um `networkCardIndex`, um `deviceIndex` e um `interfaceType`. O `interfaceType` aceita dois valores: `interface` para interfaces de rede padrão ou `efa-only` para interfaces EFA dedicadas ao tráfego de RDMA e sem endereços IP atribuídos. Quando a opção `networkInterfaces` está configurada, as instâncias iniciadas pelo `NodePool` que referenciam essa `NodeClass` adotam essa configuração obrigatoriamente, mesmo que os pods não solicitem recursos do tipo `vpc.amazonaws.com/efa`.
Ao usar o Karpenter sem especificar `networkInterfaces` na `NodeClass`, as instâncias criadas para pods que solicitam `vpc.amazonaws.com/efa` têm todas as interfaces configuradas com o tipo de interface `EFA`.
A configuração `networkInterfaces` para `EC2NodeClass` foi adicionada no Karpenter v1.11. O exemplo a seguir mostra uma `EC2NodeClass` configurada para uma instância P6-B200 que apresenta uma interface ENA e oito interfaces somente EFA.
### Configuração do Karpenter EC2NodeClass com interfaces somente EFA para instâncias 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 nós gerenciados pelo EKS e nós autogerenciados
Com os grupos de nós gerenciados ou com os nós autogerenciados do EKS, a configuração de cada interface de rede é definida por meio de [modelos de inicialização](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html).
O exemplo a seguir mostra um modelo de inicialização configurado para uma instância P6-B200 que apresenta uma interface ENA e oito interfaces somente EFA. A interface de rede principal (placa de rede 0 e índice do dispositivo 0) usa um tipo de `interface` padrão para tráfego IP, enquanto as interfaces adicionais usam `efa-only` para tráfego de RDMA dedicado. Ajuste o número de interfaces `efa-only` com base no tipo de instância. Para obter o número de interfaces EFA compatíveis com cada tipo de instância, consulte [Maximizar a largura de banda da rede para tipos de instância habilitados para EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) no *Guia do usuário do Amazon EC2*.
### Exemplo de modelo de inicialização com interfaces somente EFA para instâncias P6-B200
Substitua ` security-group-id ` pelo seus valores. O grupo de segurança deve permitir todo o tráfego de entrada e saída direcionado a si mesmo para habilitar a funcionalidade de desvio do sistema operacional do EFA. Para saber mais, consulte [Etapa 1: preparar um grupo de segurança habilitado para EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) no *Guia do usuário do Amazon EC2*.
**Importante**
Não especifique o `SubnetId` no modelo de inicialização ao usar grupos de nós gerenciados pelo EKS. O EKS requer que todas as sub-redes sejam especificadas por meio da API `CreateNodegroup` e rejeita modelos de inicialização que incluam configuração de sub-rede.
```
{
"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"]
}
]
}
}
```
## Usar AMIs otimizadas para o EKS com o EFA
As AMIs aceleradas do AL2023 otimizadas para o EKS (NVIDIA e Neuron) e todas as AMIs do Bottlerocket incluem os componentes a nível de host necessários para a utilização do EFA, especificamente os componentes instalados pelo [aws-efa-installer](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable). As AMIs do AL2023 e do Bottlerocket para o EKS **não contam** com o driver de DRA do EFA ou com o plug-in de dispositivo EFA; por isso, eles precisam ser instalados separadamente no cluster antes da implantação de workloads.
## Conservação da alocação de endereços IP
Instâncias compatíveis com EFA, como a `p5.48xlarge` e a `p6-b200.48xlarge`, oferecem suporte a várias interfaces de rede. Por padrão, a CNI da Amazon VPC aloca endereços IP em todas as ENIs anexadas e habilitadas para IP. Isso pode consumir uma quantidade significativa de endereços IP da sub-rede, mesmo que estes endereços não estejam sendo usados ativamente por pods. No caso de instâncias com dezenas de interfaces de rede, esse comportamento pode esgotar rapidamente o espaço de endereços IP disponível na sub-rede.
Para reduzir o consumo de endereços IP em nós compatíveis com EFA, configure as interfaces de rede para o uso de `efa-only` em todas elas, com exceção da interface primária. As interfaces configuradas como “somente EFA” são dedicadas ao tráfego de RDMA e não têm endereços IP atribuídos, evitando o consumo de endereços da sub-rede. Para obter configurações de exemplo, consulte [Karpenter](#eks-efa-auto-karpenter) e [Grupos de nós gerenciados pelo EKS e nós autogerenciados](#eks-efa-mng-self-managed). Para conferir o layout de interface recomendado para cada tipo de instância, consulte [Maximizar a largura de banda da rede para tipos de instância habilitados para EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html) no *Guia do usuário do Amazon EC2*.
Além de usar interfaces `efa-only`, é possível configurar a CNI da Amazon VPC para limitar a quantidade de ENIs e de endereços IP ativos (alocados previamente). Por padrão, a CNI da VPC mantém um grupo ativo de ENIs e endereços IP alocados previamente para acelerar a inicialização dos pods. No entanto, em instâncias de grande porte, isso pode resultar na reserva de centenas de endereços IP não utilizados. Defina as variáveis de ambiente `WARM_IP_TARGET` e `WARM_ENI_TARGET` no DaemonSet `aws-node` para controlar quantos endereços IP e ENIs sobressalentes a CNI mantém ativos. Para mais informações sobre essas configurações, consulte as práticas recomendadas para a [CNI da Amazon VPC](https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html#_overview).
**nota**
As configurações `WARM_ENI_TARGET` e `WARM_IP_TARGET` são válidas para todo o cluster e se aplicam a todos os nós gerenciados pela CNI da VPC. No momento, não é possível definir valores distintos por tipo de instância ou grupo de nós. Caso precise de um controle mais detalhado dessas definições, contribua com o seu feedback na página [containers-roadmap issue \#1834](https://github.com/aws/containers-roadmap/issues/1834).
## Instalação do driver de DRA do EFA (DRANET)
O driver de DRA do EFA é desenvolvido diretamente no projeto [DRANET](https://github.com/kubernetes-sigs/dranet), que fornece gerenciamento de dispositivos de rede compatíveis com a nuvem para a DRA do Kubernetes. Os termos *driver de DRA do EFA* e *DRANET* são usados como sinônimos ao longo desta documentação e fazem referência à mesma ferramenta.
O driver de DRA do EFA publica os dispositivos EFA como objetos `ResourceSlice` com o nome de driver `dra.net` e o nome de `DeviceClass` `efa.networking.k8s.aws`. O driver de DRA do EFA é executado como um DaemonSet em cada nó e realiza a descoberta automática dos dispositivos EFA.
### Pré-requisitos
+ Um cluster do Amazon EKS que executa a versão 1.34 ou versões posteriores do Kubernetes com grupos de nós gerenciados pelo EKS ou com grupos de nós autogerenciados.
+ Nós com tipos de instância do Amazon EC2 compatíveis com EFA. Para obter uma lista dos tipos de instância compatíveis, consulte [Tipos de instância compatíveis](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) no *Guia do usuário do Amazon EC2*.
+ Nós com componentes a nível de host instalados para o EFA; consulte [Instalar o software EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) para obter mais informações. Os componentes a nível de host do EFA já estão inclusos nas AMIs do AL2023 otimizadas para o EKS (versões NVIDIA e Neuron) e também nas AMIs do Bottlerocket.
+ O Helm instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do Helm](helm.md) para obter mais informações.
+ `kubectl` configurado para se comunicar com o seu cluster; consulte [Instalar ou atualizar o `kubectl`](install-kubectl.md#kubectl-install-update) para obter mais informações.
### Procedimento
**Importante**
Não instale o driver de DRA do EFA em nós nos quais o plug-in do dispositivo EFA esteja em execução. Os dois mecanismos não podem coexistir no mesmo nó. Consulte o [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004) do Kubernetes para obter atualizações.
1. Adicione o repositório do chart do Helm do EKS.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Atualize seu repositório Helm local.
```
helm repo update
```
1. Instale o driver de DRA do EFA no cluster usando o Helm. O driver de DRA do EFA detecta automaticamente que está sendo executado em instâncias do EC2 por meio do serviço de metadados de instância (IMDS) e ativa a descoberta de dispositivos EFA. Por padrão, o driver de DRA do EFA é implantado como um DaemonSet no namespace `kube-system`. Consulte o arquivo values.yaml do Helm no [repositório do GitHub dedicado ao chart do Helm do EKS](https://github.com/aws/eks-charts/tree/master/stable/aws-dranet) para obter os parâmetros configuráveis.
```
helm install aws-dranet eks/aws-dranet --namespace kube-system
```
1. Verifique se o DaemonSet do DRANET está em execução.
```
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. Verifique se `DeviceClass` foi criado.
```
kubectl get deviceclass
```
```
NAME AGE
efa.networking.k8s.aws 60s
```
1. Verifique se objetos `ResourceSlice` estão sendo anunciados para seus nós.
```
kubectl get resourceslices --field-selector spec.driver=dra.net
```
Caso ocorram erros nas etapas anteriores, você pode consultar os logs do DRANET com o comando abaixo.
```
kubectl logs -n kube-system -l app=aws-dranet
```
1. Para solicitar dispositivos EFA usando o driver de DRA, crie um `ResourceClaim` ou um `ResourceClaimTemplate` que faça referência à `DeviceClass` do EFA e faça a referência correspondente na especificação do pod. O exemplo apresentado a seguir solicita um ú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
```
## Alocação de dispositivos EFA com GPU e dispositivos do Neuron com reconhecimento de topologia
O driver de DRA do EFA oferece suporte à alocação baseada em reconhecimento de topologia, permitindo o emparelhamento de interfaces EFA com GPUs ou dispositivos Neuron na mesma raiz PCIe. Use a restrição `matchAttribute` para alinhar a alocação do EFA com a de GPUs ou dispositivos do Neuron. Para usar essa funcionalidade, você também deve usar os drivers de DRA da NVIDIA ou do Neuron. Para obter mais informações, consulte [Gerenciar dispositivos de GPU NVIDIA no Amazon EKS](device-management-nvidia.md) e [Gerenciar dispositivos Neuron no Amazon EKS](device-management-neuron.md).
O exemplo abaixo demonstra como solicitar uma interface EFA alinhada com uma GPU da 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"
```
O exemplo abaixo demonstra como solicitar 4 interfaces EFA alinhadas com 4 dispositivos do 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"
```
O número contido no nome do atributo `devicegroup` representa a quantidade de dispositivos do Neuron presentes no grupo de topologia conectado. Por exemplo, o atributo `resource.aws.com/devicegroup1_id` identifica apenas um dispositivo do Neuron, enquanto `resource.aws.com/devicegroup4_id` identifica um grupo de 4 dispositivos interconectados. Da mesma forma, `resource.aws.com/devicegroup8_id` e `resource.aws.com/devicegroup16_id` identificam, respectivamente, grupos de 8 e 16 dispositivos conectados. Escolha o `matchAttribute` que corresponda à `count` de dispositivos solicitada, garantindo que as interfaces EFA e os dispositivos do Neuron alocados pertençam ao mesmo grupo de topologia conectado. Para obter mais informações sobre esses atributos, consulte a [documentação do driver de DRA do Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/neuron-dra.html).
É possível usar o `allocationMode` para simplificar a alocação de dispositivos EFA em alinhamento com os aceleradores de GPU ou do Neuron. O campo `allocationMode` aceita dois valores: `ExactCount` (o padrão), que solicita um número específico de dispositivos especificado por `count`, e `All`, que solicita todos os dispositivos correspondentes em um grupo. Por exemplo, em instâncias `p5.48xlarge`, existem quatro dispositivos EFA que compartilham a mesma raiz PCIe com uma GPU. Para alocar esses grupos de dispositivos EFA com GPUs alinhadas, mesmo que você não conheça o mapeamento exato entre dispositivos EFA e GPU e a contagem de dispositivos EFA alinhados, você pode configurar o `ResourceClaimTemplate` com `allocationMode: All` para os 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"
```
## Compartilhamento de dispositivos EFA entre diversos pods
O driver de DRA do EFA oferece suporte ao compartilhamento de dispositivos EFA entre diversos pods por meio do uso de um `ResourceClaim`. Ao contrário de um `ResourceClaimTemplate`, que gera uma solicitação separada para cada pod, um `ResourceClaim` é um objeto nomeado que você cria de forma independente e faz referência usando diversos pods. Assim, todos os Pods que referenciam o mesmo `ResourceClaim` compartilham o acesso aos mesmos dispositivos EFA alocados e são obrigatoriamente agendados no mesmo nó em que esses dispositivos estão disponíveis.
Para compartilhar dispositivos EFA entre pods, crie um `ResourceClaim` que solicite os dispositivos EFA e, em seguida, faça referência a essa solicitação pelo nome no campo `resourceClaims` de cada pod usando `resourceClaimName`. É necessário que o `ResourceClaim` já exista no cluster antes da criação dos pods que o referenciam. Se um `ResourceClaim` referenciado não existir, os pods permanecerão em um estado pendente até que a solicitação seja criada.
O exemplo abaixo demonstra a criação de um `ResourceClaim` para solicitar quatro dispositivos EFA, além de dois pods que compartilham o acesso a eles.
1. Criar a `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. Referencie o `ResourceClaim` pelo nome em todos os pods que necessitarem de acesso aos dispositivos EFA. Para isso, cada pod deve usar o campo `resourceClaimName` para referenciar a solicitação existente em vez de empregar `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 os pods referenciam o mesmo `shared-efa` `ResourceClaim` e são agendados para o nó em que esses dispositivos EFA estão alocados. O ciclo de vida do `ResourceClaim` é independente dos pods. Dessa forma, ele continuará existindo até que seja excluído manualmente, mesmo que todos os Pods que o referenciam sejam removidos.
## Instale o plug-in de dispositivo EFA para Kubernetes
O plug-in de dispositivos EFA para Kubernetes disponibiliza os dispositivos EFA como recursos estendidos `vpc.amazonaws.com/efa`. Você solicita dispositivos EFA nas solicitações e limites de recursos de contêineres. Para obter um guia passo a passo completo sobre como configurar o EFA com workloads de treinamento, consulte [Execute o treinamento de machine learning no Amazon EKS com o Elastic Fabric Adapter](node-efa.md).
**Importante**
A alocação com alinhamento de topologia entre as interfaces EFA e as GPUs da NVIDIA ou os dispositivos do Neuron ocorre de forma automática quando você usa as AMIs aceleradas do AL2023 otimizadas para o EKS. Este alinhamento automático não ocorre ao usar AMIs otimizadas para o EKS do Bottlerocket ou AMIs personalizadas. Caso você precise do alinhamento de topologia na alocação de aceleradores e dispositivos EFA usando o Bottlerocket ou as AMIs personalizadas, será necessário adotar o driver de DRA do EFA e o respectivo driver de DRA do Neuron. O driver de DRA da NVIDIA não é compatível com o Bottlerocket. Para obter mais informações, consulte [Alocação de dispositivos EFA com GPU e dispositivos do Neuron com reconhecimento de topologia](#efa-dra-topology-aware).
**Importante**
A partir da versão v0.19.0 do `k8s-device-plugin` da NVIDIA, o sinalizador `--mofed-enabled` assume o valor `true` como padrão. Isso faz com que o plug-in de dispositivos da NVIDIA monte automaticamente todos os dispositivos `/dev/infiniband/uverbs*` dentro dos contêineres que solicitam GPUs. Isso gera um conflito com o plug-in de dispositivos EFA, que é o componente responsável por gerenciar a alocação dos dispositivos EFA em `/dev/infiniband`. Se você estiver usando grupos de nós gerenciados pelo EKS ou nós autogerenciados com o plug-in de dispositivo da NVIDIA, é necessário desativar explicitamente o MOFED. Para instruções, consulte [Instalar o plug-in de dispositivo NVIDIA para Kubernetes](device-management-nvidia.md#nvidia-device-plugin).
O Modo Automático do EKS não habilita o MOFED por padrão e não é afetado por esse problema.
### Pré-requisitos
+ Um cluster do Amazon EKS.
+ Nós com tipos de instância do Amazon EC2 compatíveis com EFA. Para obter uma lista dos tipos de instância compatíveis, consulte [Tipos de instância compatíveis](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) no *Guia do usuário do Amazon EC2*.
+ Nós com componentes a nível de host instalados para o EFA; consulte [Instalar o software EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) para obter mais informações. Os componentes a nível de host do EFA já estão inclusos nas AMIs do AL2023 otimizadas para o EKS (versões NVIDIA e Neuron) e também nas AMIs do Bottlerocket.
+ O Helm instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do Helm](helm.md) para obter mais informações.
+ `kubectl` configurado para se comunicar com o seu cluster; consulte [Instalar ou atualizar o `kubectl`](install-kubectl.md#kubectl-install-update) para obter mais informações.
### Procedimento
1. Adicione o repositório do chart do Helm do EKS.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Atualize seu repositório Helm local.
```
helm repo update
```
1. Instalação do plug-in de dispositivo do EFA.
```
helm install efa eks/aws-efa-k8s-device-plugin -n kube-system
```
1. Verifique se o DaemonSet do plug-in do dispositivo EFA está em execução.
```
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. Verifique se os seus nós possuem recursos EFA alocáveis.
```
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 dispositivos EFA usando o plug-in de dispositivo, especifique o recurso `vpc.amazonaws.com/efa` em suas solicitações e limites de recursos do contêiner.
```
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: ...
```