**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 de hardware en Amazon EKS Amazon EKS admite dos mecanismos de Kubernetes para administrar dispositivos de hardware especializados en clústeres de EKS: *asignación dinámica de recursos (DRA)* y *complementos para dispositivos*. Ambos mecanismos permiten que las cargas de trabajo accedan a aceleradores de hardware, como las GPU NVIDIA y los chips de AWS Trainium, y a dispositivos de red de alto rendimiento, como Elastic Fabric Adapter (EFA). Se recomienda utilizar los controladores de DRA para las nuevas implementaciones con las versiones 1.34 y posteriores de Kubernetes con grupos de nodos administrados o nodos autoadministrados de EKS, ya que DRA ofrece una selección de dispositivos más completa, una programación con reconocimiento de topología y funciones de uso compartido de dispositivos que no son posibles con los complementos para dispositivos. Consulte la documentación de Kubernetes sobre la [asignación dinámica de recursos](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) y los [complementos para dispositivos](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) para obtener información general sobre estas dos características de Kubernetes. ## La asignación dinámica de recursos frente a los complementos para dispositivos Los complementos para dispositivos de Kubernetes han sido el principal mecanismo para exponer el hardware especializado a las cargas de trabajo de Kubernetes. Los complementos para dispositivos anuncian los dispositivos como recursos ampliados (por ejemplo, `nvidia.com/gpu` o `aws.amazon.com/neuroncore`) que se solicitan en límites y solicitudes de recursos de contenedores. Si bien los complementos para dispositivos son ampliamente compatibles y utilizados, tienen limitaciones: + Los dispositivos se solicitan mediante recuentos de enteros opacos sin filtrado basado en atributos. + No se admite el uso compartido de dispositivos entre contenedores o pods. + No hay una asignación con reconocimiento de topología expresiva entre los tipos de dispositivos. + A menudo, se requieren extensiones de programador personalizadas para una ubicación inteligente. La asignación dinámica de recursos (DRA) es una característica de Kubernetes que está disponible de forma general en la versión 1.34 de Kubernetes y que aborda estas limitaciones. Con la DRA, los controladores de dispositivos publican una gran cantidad de atributos de los dispositivos en el programador de Kubernetes mediante objetos `ResourceSlice`. Solicita dispositivos mediante objetos `ResourceClaim` y `ResourceClaimTemplate` que hacen referencia a categorías `DeviceClass`. DRA permite: + La selección de dispositivos basada en atributos mediante expresiones del [lenguaje de expresión común (CEL)](https://kubernetes.io/docs/reference/using-api/cel/). + Asignación con reconocimiento de topología que garantiza que los dispositivos estén ubicados en el mismo conmutador PCIe o dominio NUMA. + Uso compartido de dispositivos entre varios contenedores o pods mediante referencias de `ResourceClaim` compartidas. + Programación basada en restricciones que alinea diferentes tipos de dispositivos ## Controladores DRA para Amazon EKS Los siguientes controladores de DRA se utilizan habitualmente para administrar dispositivos de hardware especializados en los clústeres de Amazon EKS. Controlador de DRA de EFA El controlador de DRA de EFA ([DRANET](https://github.com/kubernetes-sigs/dranet)) administra la asignación de dispositivos de Elastic Fabric Adapter (EFA) con la programación con reconocimiento de topología que empareja las interfaces EFA con sus GPU o dispositivos Neuron topológicamente locales y permite compartir dispositivos entre pods. Para obtener más información, consulte [Administración de los dispositivos EFA en Amazon EKS](device-management-efa.md). Controlador de DRA de Neuron El controlador de DRA de Neuron administra la asignación de dispositivos AWS Trainium y AWS Inferentia2 con programación con reconocimiento de topología, asignación de subconjuntos de dispositivos conectados y configuración lógica de NeuronCore (LNC) sin necesidad de extensiones de programador personalizadas. Controlador de DRA de NVIDIA El [controlador de DRA de NVIDIA para las GPU](https://github.com/kubernetes-sigs/nvidia-dra-driver-gpu) permite una asignación flexible y una reconfiguración dinámica de las GPU de NVIDIA, además de admitir recursos `ComputeDomain` para cargas de trabajo NVLink (MNNVL) de varios nodos en instancias Grace-Blackwell de EC2. Para obtener más información sobre el uso de `ComputeDomains` con instancias Grace-Blackwell de EC2, consulte [Uso de UltraServers P6e-GB200 con Amazon EKS](ml-eks-nvidia-ultraserver.md). ## Complementos para dispositivos para Amazon EKS Los siguientes complementos para dispositivos se utilizan habitualmente para administrar dispositivos de hardware especializados en los clústeres de Amazon EKS. Complemento para dispositivos de EFA El complemento para dispositivos EFA detecta todos los dispositivos EFA disponibles en cada nodo y los anuncia como recursos ampliados de `vpc.amazonaws.com/efa`. Complemento para dispositivos Neuron El [complemento para dispositivos Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/tutorials/k8s-setup.html) expone el hardware de Neuron como recursos ampliados de `aws.amazon.com/neuroncore` y `aws.amazon.com/neuron`. Detecta los dispositivos Neuron disponibles en cada nodo, los anuncia como recursos asignables y administra su ciclo de vida. Complemento para dispositivos de NVIDIA El [complemento para dispositivos de NVIDIA](https://github.com/NVIDIA/k8s-device-plugin) promociona las GPU NVIDIA como recursos ampliados de `nvidia.com/gpu` y hace un seguimiento del estado de las GPU. ## Consideraciones Antes de usar los controladores de DRA en Amazon EKS, tenga en cuenta lo siguiente: + DRA está disponible en Amazon EKS con la versión 1.33 y posteriores de Kubernetes, pero se recomienda para las versiones 1.34 y posteriores de Kubernetes debido a un [problema de Kubernetes](https://github.com/kubernetes/kubernetes/issues/133920) ascendente. El plano de control del clúster y los nodos deben ejecutar una versión de Kubernetes que sea compatible con DRA. + Actualmente, DRA no es compatible con la computación aprovisionada del modo automático de EKS o Karpenter. Debe utilizar grupos de nodos administrados por EKS o nodos autoadministrados con controladores de DRA. + Los controladores de DRA y los complementos para dispositivos para el mismo tipo de dispositivo no **deben** ejecutarse simultáneamente en el mismo nodo. Desinstale el complemento para dispositivos antes de instalar el controlador de DRA correspondiente o impleméntelo en nodos independientes. Consulte el [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004) de Kubernetes para obtener actualizaciones sobre la compatibilidad del controlador de DRA y los complementos para dispositivos. + DRA utiliza recursos de API de Kubernetes (`ResourceClaim`, `ResourceClaimTemplate`, `DeviceClass`) distintos a los complementos para dispositivos (`resource.limits`, `resource.requests`). La migración de los complementos para dispositivos a DRA requiere actualizar las especificaciones de la carga de trabajo. + Los complementos para dispositivos siguen siendo totalmente compatibles con todas las versiones de Kubernetes. Si su clúster ejecuta una versión de Kubernetes anterior a la 1.34 o si utiliza Karpenter o el modo automático de EKS, siga usando los complementos para dispositivos. El controlador de DRA de NVIDIA no es compatible con Bottlerocket; usa el complemento de dispositivo NVIDIA en los nodos de Bottlerocket. Los controladores de DRA de EFA y Neuron son compatibles con Bottlerocket. ## ResourceClaim frente a ResourceClaimTemplate de DRA Cuando se utiliza DRA, se solicitan dispositivos a través de objetos `ResourceClaim` o `ResourceClaimTemplate`. Estos dos tipos de recursos tienen diferentes propósitos y tienen comportamientos de ciclo de vida diferentes. ResourceClaim Una `ResourceClaim` es un objeto de Kubernetes con nombre que se crea independientemente de cualquier pod. Se hace referencia a ella en una especificación de Pod por su nombre mediante el campo `resourceClaimName`. Una `ResourceClaim` tiene las siguientes características: + Debe existir en el clúster antes de crear los pods que hacen referencia a ella. Si la reclamación no existe, el pod permanece en estado pendiente. + Persiste hasta que lo elimine de forma explícita, independientemente de si algún pod hace referencia a ella. + Varios pods pueden hacer referencia a la misma `ResourceClaim`, lo que permite compartir dispositivos. Todos los pods que hacen referencia a la misma reclamación comparten el acceso a los mismos dispositivos asignados y están programados en el mismo nodo. Use una `ResourceClaim` cuando necesite varios pods para compartir el acceso a los mismos dispositivos o cuando necesite una reclamación que exista más allá de la vida útil de un solo pod. ResourceClaimTemplate Una `ResourceClaimTemplate` define una plantilla que Kubernetes utiliza para generar automáticamente una `ResourceClaim` única para cada pod. Se hace referencia a ella en una especificación de Pod mediante el campo `resourceClaimTemplateName`. La plantilla `ResourceClaimTemplate` en sí misma no está vinculada a ningún pod: es una plantilla reutilizable que permanece de forma independiente. Una `ResourceClaimTemplate` tiene las siguientes características: + Kubernetes crea una nueva `ResourceClaim` para cada pod que hace referencia a la plantilla. Cada pod tiene su propio conjunto de dispositivos independiente. + Cada `ResourceClaim` generada está vinculada al ciclo de vida del pod que desencadenó su creación. Cuando se elimina el pod, también se elimina la `ResourceClaim` generada asociada. La `ResourceClaimTemplate` en sí no se ve afectada y sigue generando nuevas reclamaciones para los pods futuros. Use una `ResourceClaimTemplate` cuando cada pod de una carga de trabajo necesite sus propios dispositivos dedicados con configuraciones similares. Por ejemplo, use una `ResourceClaimTemplate` para pods en un trabajo que utilice la ejecución paralela, donde cada pod necesite su propia GPU o dispositivos EFA. En la tabla siguiente se resumen las diferencias entre `ResourceClaim` y `ResourceClaimTemplate`. | Comportamiento | ResourceClaim | ResourceClaimTemplate | | --- | --- | --- | | Creación | La crea manualmente antes de que los pods hagan referencia a ella. | Kubernetes genera automáticamente una reclamación por pod. | | Ciclo de vida | Persiste hasta que la elimina. | La plantilla persiste hasta que la elimina. Cada `ResourceClaim` generada está vinculada al pod que desencadenó su creación. | | Uso compartido de dispositivos entre los pods | Soportado. Varios pods pueden hacer referencia a la misma reclamación. | No admitido. Cada pod recibe una reclamación diferente. | | Campo de especificación de pod | `resourceClaimName` | `resourceClaimTemplateName` | Para ver ejemplos del uso de objetos `ResourceClaim` para compartir dispositivos EFA entre pods, consulte [Uso compartido de los dispositivos EFA entre varios pods](device-management-efa.md#efa-dra-share). Para ver ejemplos del uso de objetos `ResourceClaimTemplate` con una asignación compatible con la topología, consulte [Asignación de dispositivos GPU/Neuron y EFA según la topología](device-management-efa.md#efa-dra-topology-aware). ## Temas + [Administración de los dispositivos EFA en Amazon EKS](device-management-efa.md) + [Administración de los dispositivos Neuron en Amazon EKS](device-management-neuron.md) + [Administración de dispositivos GPU NVIDIA en Amazon EKS](device-management-nvidia.md)