**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 de hardware no Amazon EKS O Amazon EKS oferece suporte a dois mecanismos do Kubernetes para gerenciar dispositivos de hardware especializados em clusters do EKS: *Alocação dinâmica de recursos (DRA)* e *plug-ins de dispositivos*. Ambos os mecanismos permitem que as workloads acessem aceleradores de hardware, como GPUs NVIDIA e chips AWS Trainium, e dispositivos de rede de alta performance, como o Elastic Fabric Adapter (EFA). É recomendado usar drivers de DRA para novas implantações com as versões 1.34 e versões posteriores do Kubernetes ao usar grupos de nós gerenciados pelo EKS ou de nós gerenciados pelo usuário, pois a DRA fornece seleção de dispositivos mais robusta, agendamento com reconhecimento de topologia e recursos de compartilhamento de dispositivos que não estão disponíveis por meio de plug-ins de dispositivos. Consulte a documentação do Kubernetes sobre [Alocação dinâmica de recursos](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) e [plug-ins de dispositivos](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) para obter informações gerais sobre esses dois recursos do Kubernetes. ## Alocação dinâmica de recursos x plug-ins de dispositivos Os plug-ins de dispositivos do Kubernetes têm sido o principal mecanismo para integrar hardware especializado às workloads do Kubernetes. Os plug-ins de dispositivos anunciam os dispositivos como recursos estendidos (por exemplo, `nvidia.com/gpu` ou `aws.amazon.com/neuroncore`) que você solicita nas solicitações e limites de recursos do contêiner. Embora os plug-ins de dispositivos sejam amplamente compatíveis e utilizados, eles apresentam algumas limitações: + Os dispositivos são solicitados como contagens inteiras opacas, sem filtragem baseada em atributos. + Não há suporte para o compartilhamento de dispositivos entre contêineres ou Pods. + Não há alocação expressiva que leve em conta a topologia entre os diferentes tipos de dispositivos. + Extensões personalizadas do agendador são frequentemente necessárias para uma colocação inteligente. A Alocação dinâmica de recursos (DRA) é um recurso do Kubernetes disponibilizado para o público em geral na versão 1.34 do Kubernetes, que resolve essas limitações. Com o DRA, os drivers de dispositivos publicam atributos detalhados dos dispositivos para o agendador do Kubernetes por meio de objetos `ResourceSlice`. Você solicita dispositivos usando objetos `ResourceClaim` e `ResourceClaimTemplate` que fazem referência a categorias `DeviceClass`. O DRA permite: + Seleção de dispositivos com base em atributos utilizando expressões [Common Expression Language (CEL)](https://kubernetes.io/docs/reference/using-api/cel/). + Alocação sensível à topologia que garante que os dispositivos fiquem localizados no mesmo switch PCIe ou domínio NUMA. + Compartilhamento de dispositivos entre vários contêineres ou Pods por meio de referências `ResourceClaim` compartilhadas. + Programação baseada em restrições que coordena diferentes tipos de dispositivos ## Drivers DRA para o Amazon EKS Os seguintes drivers DRA são comumente usados para gerenciar dispositivos de hardware especializados em clusters do Amazon EKS. Driver de DRA do EFA O driver de DRA do EFA ([DRANET](https://github.com/kubernetes-sigs/dranet)) gerencia a alocação de dispositivos Elastic Fabric Adapter (EFA) com agendamento com reconhecimento de topologia que emparelha interfaces EFA com GPUs ou com dispositivos do Neuron topologicamente locais, e fornece suporte para o compartilhamento de dispositivos entre pods. Para obter mais informações, consulte [Gerenciar dispositivos EFA no Amazon EKS](device-management-efa.md). Driver Neuron DRA O driver Neuron DRA gerencia a alocação de dispositivos AWS Trainium e AWS Inferentia2 por meio do agendamento com reconhecimento de topologia, alocação de subconjuntos de dispositivos conectados e configuração do NeuronCore lógico (LNC), sem a necessidade de extensões personalizadas do agendador. Driver de DRA da NVIDIA O [driver NVIDIA DRA para GPUs](https://github.com/kubernetes-sigs/nvidia-dra-driver-gpu) permite a alocação flexível e a reconfiguração dinâmica das GPUs NVIDIA, incluindo suporte a recursos `ComputeDomain` para workloads Multi-Node NVLink (MNNVL) em instâncias Grace-Blackwell do EC2. Para obter mais informações sobre como usar `ComputeDomains` com instâncias Grace-Blackwell do EC2, consulte [Uso do P6e-GB200 UltraServers com o Amazon EKS](ml-eks-nvidia-ultraserver.md). ## Plug-ins de dispositivos para o Amazon EKS Os seguintes plug-ins de dispositivo são comumente usados para gerenciar dispositivos de hardware especializados em clusters do Amazon EKS. Plug-in de dispositivo do EFA O plug-in do dispositivo EFA detecta todos os dispositivos EFA disponíveis em cada nó e os anuncia como recursos estendidos `vpc.amazonaws.com/efa`. Plug-in do dispositivo Neuron O [plug-in do dispositivo Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/tutorials/k8s-setup.html) expõe o hardware Neuron como recursos estendidos `aws.amazon.com/neuroncore` e `aws.amazon.com/neuron`. Ele detecta os dispositivos Neuron disponíveis em cada nó, os anuncia como recursos alocáveis e gerencia seu ciclo de vida. Plug-in de dispositivo NVIDIA O [plug-in de dispositivo da NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) apresenta as GPUs da NVIDIA como recursos estendidos `nvidia.com/gpu` e monitora a integridade das GPUs. ## Considerações Antes de usar drivers DRA no Amazon EKS, analise as seguintes considerações: + O DRA está disponível no Amazon EKS com o Kubernetes versão 1.33 e superior, mas é recomendado para as versões 1.34 e posteriores do Kubernetes devido a um [problema no Kubernetes original](https://github.com/kubernetes/kubernetes/issues/133920). O ambiente de gerenciamento e os nós do seu cluster devem estar executando uma versão do Kubernetes compatível com o DRA. + Atualmente, o DRA não é compatível com o Karpenter nem com os recursos de computação provisionados pelo Modo Automático do EKS. Você deve usar grupos de nós gerenciados pelo EKS ou nós autogerenciados com drivers DRA. + Os drivers DRA e os plug-ins de dispositivo para o mesmo tipo de dispositivo não **devem** ser executados simultaneamente no mesmo nó. Desinstale o plug-in do dispositivo antes de instalar o driver DRA correspondente ou realize a implantação em nós separados. Consulte o [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004) do Kubernetes para obter atualizações sobre a compatibilidade do driver DRA e do plug-in de dispositivo. + O DRA utiliza diferentes recursos da API do Kubernetes (`ResourceClaim`, `ResourceClaimTemplate`, `DeviceClass`) em vez de plug-ins de dispositivos (`resource.limits`, `resource.requests`). A migração de plug-ins de dispositivo para o DRA é necessária para a atualização das especificações da sua workload. + Os plug-ins de dispositivos continuam sendo totalmente compatíveis com todas as versões do Kubernetes. Se o cluster executar uma versão do Kubernetes anterior à 1.34, ou se você usar o Karpenter ou o Modo Automático do EKS, continue usando os plug-ins de dispositivo. Não há suporte para o driver de DRA da NVIDIA no Bottlerocket; use o plug-in de dispositivo da NVIDIA em nós do Bottlerocket. Há suporte para os drivers de DRA do EFA e do Neuron no Bottlerocket. ## Comparação entre ResourceClaim e ResourceClaimTemplate na DRA Ao usar a DRA, a solicitação de dispositivos é feita por meio dos objetos `ResourceClaim` ou `ResourceClaimTemplate`. Esses dois tipos de recursos atendem a finalidades distintas e têm comportamentos de ciclo de vida diferentes. ResourceClaim O `ResourceClaim` é um objeto nomeado do Kubernetes criado de forma independente de qualquer pod. Você o referencia em uma especificação de pod pelo nome usando o campo `resourceClaimName`. Um `ResourceClaim` tem as seguintes características: + Ele deve existir no cluster antes da criação de qualquer pod que o referencie. Caso a solicitação não exista, o pod permanecerá em um estado pendente. + O objeto permanece ativo até ser explicitamente excluído por você, independentemente de estar sendo referenciado por algum pod. + Vários pods podem referenciar o mesmo `ResourceClaim`, viabilizando o compartilhamento de dispositivos. Todos os pods que referenciam a mesma solicitação compartilham o acesso aos mesmos dispositivos alocados e são obrigatoriamente agendados no mesmo nó. Use um `ResourceClaim` quando você precisar que diversos pods compartilhem o acesso aos mesmos dispositivos ou quando a solicitação precisar persistir além do ciclo de vida de um único pod. ResourceClaimTemplate O `ResourceClaimTemplate` define um modelo que o Kubernetes usa para gerar automaticamente um `ResourceClaim` exclusivo para cada pod. Você o referencia em uma especificação de pod usando o campo `resourceClaimTemplateName`. O `ResourceClaimTemplate` em si não está vinculado a nenhum pod. Ele é um modelo reutilizável que persiste de forma independente. Um `ResourceClaimTemplate` tem as seguintes características: + O Kubernetes cria um novo `ResourceClaim` para cada pod que faça referência ao modelo. Isso garante que cada pod receba o próprio conjunto de dispositivos dedicados. + Cada `ResourceClaim` gerado fica vinculado ao ciclo de vida do pod que deu origem à sua criação. Com a exclusão do pod, o `ResourceClaim` gerado e associado também é excluído. O `ResourceClaimTemplate` em si não é afetado e continua a gerar novas solicitações para pods futuros. Use um `ResourceClaimTemplate` em situações nas quais cada pod em uma workload precisa de dispositivos dedicados com configurações semelhantes. Por exemplo, use um `ResourceClaimTemplate` para pods em um trabalho de execução paralela no qual cada pod necessita dos próprios dispositivos de GPU ou de EFA. A tabela a seguir resume as diferenças entre o `ResourceClaim` e o `ResourceClaimTemplate`. | Comportamento | ResourceClaim | ResourceClaimTemplate | | --- | --- | --- | | Criação | Você o cria manualmente antes que os pods o referenciem | O Kubernetes gera uma solicitação automaticamente por pod | | Ciclo de vida | Persiste até que você o exclua | O modelo persiste até que você o exclua. Cada `ResourceClaim` gerado fica vinculado ao pod que deu origem à sua criação. | | Compartilhamento de dispositivos entre pods | Compatível. Diversos pods podem referenciar a mesma solicitação | Sem compatibilidade. Cada pod recebe uma solicitação separada | | Campo de especificação do pod | `resourceClaimName` | `resourceClaimTemplateName` | Para obter exemplos de uso de objetos `ResourceClaim` com a finalidade de compartilhamento de dispositivos EFA entre pods, consulte [Compartilhamento de dispositivos EFA entre diversos pods](device-management-efa.md#efa-dra-share). Para obter exemplos de uso de objetos `ResourceClaimTemplate` com alocação com reconhecimento de topologia, consulte [Alocação de dispositivos EFA com GPU e dispositivos do Neuron com reconhecimento de topologia](device-management-efa.md#efa-dra-topology-aware). ## Tópicos + [Gerenciar dispositivos EFA no Amazon EKS](device-management-efa.md) + [Gerenciar dispositivos Neuron no Amazon EKS](device-management-neuron.md) + [Gerenciar dispositivos de GPU NVIDIA no Amazon EKS](device-management-nvidia.md)