Acerca de la asignación dinámica de recursos en GKE

Puedes usar la asignación dinámica de recursos (DRA) para asignar GPUs a tus cargas de trabajo de Google Kubernetes Engine (GKE). En este documento, se explican los aspectos fundamentales de la DRA, cómo usarla en GKE y los beneficios de usarla.

Este documento está destinado a los siguientes roles:

Ya debes estar familiarizado con lo siguiente:

Introducción a la DRA

La DRA es una función integrada de Kubernetes que te permite solicitar, asignar y compartir hardware de forma flexible en tu clúster entre Pods y contenedores. La DRA mejora la experiencia de asignar hardware conectado, como aceleradores, ya que permite que los proveedores de dispositivos y los administradores de plataformas declaren clases de dispositivos que se pueden solicitar y asignar. Los operadores de apps pueden solicitar configuraciones de dispositivos específicas dentro de esas clases y, luego, solicitar esas configuraciones en sus cargas de trabajo. Kubernetes y GKE administran la programación de Pods, las asignaciones de nodos y la asignación de dispositivos en función de las solicitudes de carga de trabajo.

Por ejemplo, un administrador de plataformas puede definir una clase de dispositivo que solo tenga GPUs NVIDIA A100. Luego, los operadores de apps pueden filtrar los dispositivos en esa clase de dispositivo según los requisitos de la carga de trabajo, como filtrar un mínimo de 80 GB de memoria de GPU. Cuando el operador de la app implementa una carga de trabajo que solicita la configuración filtrada, GKE coloca los Pods en nodos que cumplen con los criterios seleccionados. En este ejemplo, GKE encuentra nodos que tienen GPUs A100 (80 GB) disponibles. El operador de la app no necesita seleccionar nodos específicos ni configuraciones de dispositivos en el manifiesto de la carga de trabajo.

Beneficios de la DRA

Sin la DRA, la asignación de dispositivos de hardware en Kubernetes depende de los complementos de dispositivos. Para conectar recursos de hardware a Pods con complementos de dispositivos, usa etiquetas de nodo para colocar Pods en nodos específicos. Además, para dedicar los recursos de un nodo completo a un solo Pod, solicita la cantidad exacta de dispositivos conectados a los nodos.

Con la DRA, la asignación de dispositivos a Pods es similar a la asignación de volúmenes para el almacenamiento. Defines clases de dispositivos, solicitas dispositivos dentro de esas clases y, luego, asignas esos dispositivos solicitados a las cargas de trabajo. La DRA proporciona una superficie mucho más extensible para filtrar dispositivos según las necesidades de la carga de trabajo y la empresa. El enfoque de la DRA de usar expresiones y plantillas para reclamar hardware y programar Pods tiene los siguientes beneficios:

  • Asignación declarativa de dispositivos: Los administradores de plataformas pueden definir configuraciones de dispositivos para tipos específicos de cargas de trabajo o equipos.
  • Reducción de la complejidad entre equipos: Cuando los administradores de plataformas aprovisionan nodos que tienen configuraciones de hardware especializadas, los operadores de apps no necesitan saber qué nodos tienen configuraciones específicas. Los administradores de plataformas no necesitan etiquetar nodos ni comunicar información sobre nodos y dispositivos específicos a los operadores.
  • Reducción de la complejidad para desarrolladores: Kubernetes programa Pods según la configuración del dispositivo al que se hace referencia. Los operadores de apps no necesitan seleccionar nodos específicos en sus cargas de trabajo ni asegurarse de que cada Pod solicite exactamente la cantidad de dispositivos conectados a esos nodos.
  • Administración centralizada de la infraestructura: Los administradores de plataformas pueden definir de forma centralizada configuraciones de hardware que satisfagan requisitos empresariales específicos. Por ejemplo, un administrador de plataformas podría declarar una configuración de alto rendimiento que tenga GPUs H100 junto con una pequeña configuración de inferencia que tenga GPUs Tesla T4.
  • Selección de hardware flexible: Puedes usar expresiones CEL para filtrar dispositivos que tengan atributos específicos. El uso de expresiones proporciona la flexibilidad para filtrar dispositivos que son óptimos para cargas de trabajo específicas.

Cuándo usar la DRA

El motivo principal para usar la DRA en GKE es la flexibilidad con la que puedes solicitar dispositivos para cargas de trabajo. Puedes escribir un manifiesto una vez y, luego, implementar la carga de trabajo en diferentes clústeres con diferentes tipos de dispositivos sin necesidad de cambiar el manifiesto. Esta flexibilidad es ideal para casos de uso como los siguientes:

  • Mejora la disponibilidad de la GPU: Para las cargas de trabajo que necesitan acceso al hardware de la GPU, puedes usar la DRA para solicitar cualquier GPU disponible en el clúster en lugar de tener que especificar un modelo de GPU. Si esas cargas de trabajo tienen requisitos específicos de memoria de GPU (VRAM), puedes solicitar cualquier GPU en el clúster que tenga una cantidad mínima de memoria. Este tipo de solicitud flexible expande el conjunto de nodos de GPU en los que se puede ejecutar una carga de trabajo, lo que reduce el riesgo de que la carga de trabajo no se programe debido a recursos no disponibles.

  • Optimiza la disponibilidad de nodos durante el escalamiento: la cantidad de dispositivos que requiere una carga de trabajo puede cambiar según factores como el tipo de dispositivo y sus capacidades. Puedes usar GKE ComputeClasses de GKE para colocar Pods acelerados en grupos de nodos específicos según la disponibilidad del dispositivo. Luego, puedes configurar tus Pods para que reclamen los dispositivos en cualquier nodo en el que GKE coloque los Pods.

    El uso de la DRA con ComputeClasses te permite minimizar el riesgo de cargas de trabajo no programadas y, al mismo tiempo, te ayuda a ejecutar cargas de trabajo en hardware optimizado.

Terminología

Kubernetes de código abierto y los proveedores de Kubernetes administrados, como GKE, usan los siguientes tipos de API de DRA principales:

ResourceSlice
Un ResourceSlice enumera uno o más dispositivos de hardware en el clúster a los que pueden acceder los nodos. Por ejemplo, en un nodo que puede acceder a una sola GPU, el ResourceSlice enumera la GPU y el nombre del nodo. Los controladores de dispositivos DRA en cada nodo crean ResourceSlices. El programador de Kubernetes usa ResourceSlices para decidir qué dispositivos asignar para satisfacer las solicitudes de carga de trabajo.
DeviceClass
Un DeviceClass define una categoría de dispositivos, como GPUs, que están disponibles para solicitar cargas de trabajo. Algunos controladores de dispositivos proporcionan DeviceClasses integrados, como el DeviceClass gpu.nvidia.com para GPUs NVIDIA. Los administradores de plataformas también pueden crear DeviceClasses personalizados que definan configuraciones de dispositivos específicas.
ResourceClaim

Un ResourceClaim permite que un Pod o un usuario soliciten recursos de hardware mediante el filtrado de ciertos parámetros dentro de un DeviceClass. Cuando una carga de trabajo hace referencia a un ResourceClaim, Kubernetes asigna dispositivos que coinciden con los parámetros especificados a ese ResourceClaim.

Por ejemplo, considera una situación en la que creas un ResourceClaim para una GPU A100 (40 GB) y, luego, implementas una carga de trabajo que selecciona ese ResourceClaim. Kubernetes asigna una GPU A100 (40 GB) disponible al ResourceClaim y programa tu Pod en un nodo que puede acceder a esa GPU.

ResourceClaimTemplate

Un ResourceClaimTemplate define una plantilla que los Pods pueden usar para crear automáticamente nuevos ResourceClaims por Pod. Los ResourceClaimTemplates son útiles cuando tienes varias cargas de trabajo que necesitan acceso a configuraciones de dispositivos similares, en especial cuando usas un controlador de carga de trabajo como Deployments o StatefulSets.

Los operadores de apps implementan ResourceClaimTemplates y, luego, hacen referencia a las plantillas en las cargas de trabajo. Kubernetes crea ResourceClaims para cada Pod según la plantilla especificada, asigna dispositivos y programa los Pods. Cuando finalizan los Pods, Kubernetes limpia los ResourceClaims correspondientes.

Para obtener más información sobre los tipos de API de DRA, consulta la terminología de DRA.

Cómo funciona la DRA

El uso de la DRA en tus clústeres y cargas de trabajo es un proceso similar a usar StorageClasses, PersistentVolumeClaims y PersistentVolumes para aprovisionar de forma dinámica volúmenes para Pods.

En el siguiente diagrama, se muestran los pasos que siguen los administradores de clústeres y los operadores de apps para asignar dispositivos con la DRA:

En este diagrama, los administradores de clústeres y los operadores de apps hacen lo siguiente:

  1. Los administradores de clústeres instalan controladores de dispositivos que admiten la DRA en los nodos.
  2. Los administradores de clústeres crean DeviceClasses que filtran el hardware que cumple con requisitos específicos, como todas las GPUs con más de 40 GB de memoria. Algunos dispositivos también pueden incluir DeviceClasses integrados.
  3. Los operadores de aplicaciones crean ResourceClaimTemplates o ResourceClaims que solicitan configuraciones de dispositivos. El caso de uso principal para cada tipo de reclamo es el siguiente:
    • Un ResourceClaim permite que varios Pods compartan el acceso al mismo dispositivo.
    • Un ResourceClaimTemplate permite que varios Pods accedan a dispositivos separados y similares mediante la generación automática de ResourceClaims por Pod.
  4. Los operadores de aplicaciones agregan los ResourceClaimTemplates o ResourceClaims a sus manifiestos de carga de trabajo.
  5. Los operadores de aplicaciones implementan la carga de trabajo.

Cuando implementas una carga de trabajo que hace referencia a un ResourceClaimTemplate o un ResourceClaim, Kubernetes realiza los siguientes pasos de programación:

  1. Si la carga de trabajo hace referencia a un ResourceClaimTemplate, Kubernetes crea un objeto ResourceClaim nuevo para cada instancia de la carga de trabajo (por ejemplo, cada réplica en una Deployment).
  2. El programador de Kubernetes usa los ResourceSlices en el clúster para asignar dispositivos disponibles y aptos al ResourceClaim de cada Pod.
  3. El programador coloca cada Pod en un nodo que tiene acceso a los dispositivos que se asignaron al ResourceClaim del Pod.
  4. El kubelet en el nodo de destino llama al controlador DRA en el nodo para conectar el hardware asignado al Pod y satisfacer su solicitud de recursos.

Cuándo usar ResourceClaims y ResourceClaimTemplates

Puedes usar ResourceClaims o ResourceClaimTemplates para indicarle a Kubernetes que deseas dispositivos que cumplan con requisitos específicos. Cuando se hace referencia a un ResourceClaim en un Pod, Kubernetes asigna dispositivos al recurso de API ResourceClaim correspondiente en el servidor de la API de Kubernetes. Esta asignación ocurre independientemente de si creaste el ResourceClaim o si Kubernetes lo creó a partir de un ResourceClaimTemplate.

Si creas un ResourceClaim y, luego, haces referencia a él en varios Pods, todos esos Pods pueden acceder a los dispositivos que Kubernetes asigna para ese ResourceClaim. Por ejemplo, este acceso compartido puede ocurrir si haces referencia a un ResourceClaim específico en un manifiesto de Deployment que tiene varias réplicas. Sin embargo, si los dispositivos asignados no están configurados para que varios procesos los compartan, este acceso a dispositivos compartidos entre Pods puede generar un comportamiento no deseado.

Para asignar dispositivos separados a Pods, puedes usar un ResourceClaimTemplate, que es una plantilla que Kubernetes usa para crear automáticamente ResourceClaims individuales. Por ejemplo, si haces referencia a un ResourceClaimTemplate en una Deployment que tiene varias réplicas, Kubernetes crea un ResourceClaim separado para cada Pod replicado. Como resultado, cada Pod obtiene su propio dispositivo asignado en lugar de compartir el acceso al dispositivo con otros Pods. Estos ResourceClaims generados automáticamente están vinculados a la vida útil del Pod correspondiente y se borran cuando finaliza el Pod. Si tienes Pods independientes que necesitan acceso a configuraciones de dispositivos similares, usa un ResourceClaimTemplate para asignar dispositivos a cada Pod por separado.

En la siguiente tabla, se describen algunas diferencias entre la creación manual de ResourceClaims y la creación de ResourceClaims por parte de Kubernetes a partir de un ResourceClaimTemplate:

Tabla 1. Comparación de ResourceClaims y ResourceClaimTemplates
ResourceClaims creados manualmente ResourceClaims creados automáticamente
Administrados por ti Administrados por Kubernetes
Proporciona acceso a los mismos dispositivos desde varios Pods Proporciona acceso a dispositivos desde un solo Pod
Existe en el clúster independientemente de los Pods Vinculado al ciclo de vida del Pod correspondiente
Ideal para varias cargas de trabajo que necesitan compartir un dispositivo específico Ideal para varias cargas de trabajo que necesitan acceso independiente a dispositivos

Comparación de la DRA con la asignación manual de dispositivos

La DRA hace que la asignación de dispositivos conectados sea una experiencia similar al aprovisionamiento dinámico de PersistentVolumes. Kubernetes también admite la asignación de dispositivos con complementos de dispositivos. Este método incluye los siguientes pasos:

  1. Un administrador de clústeres crea nodos que tienen dispositivos conectados, como GPUs.
  2. El administrador del clúster comunica información sobre nodos específicos y sus dispositivos conectados a los operadores de cargas de trabajo.
  3. Un operador de carga de trabajo solicita dispositivos en el manifiesto de la carga de trabajo de la siguiente manera:
    • Selecciona un nodo que tenga la configuración de dispositivo requerida, como el modelo de GPU, con un campo nodeSelector.
    • Especifica la cantidad exacta de dispositivos que consumirán los contenedores con el campo resources en la especificación del Pod.

Este método de asignación manual requiere que los operadores de aplicaciones y los administradores de clústeres se comuniquen sobre qué nodos o grupos de nodos específicos tienen ciertas configuraciones de dispositivos. Deben coordinar las solicitudes de carga de trabajo para que coincidan con los dispositivos de los nodos o la implementación fallará. En comparación, la DRA te permite usar expresiones para filtrar de forma flexible los dispositivos según los atributos y no requiere que los operadores de cargas de trabajo conozcan la configuración exacta de los nodos en el clúster.

En la siguiente tabla, se compara la DRA con los complementos de dispositivos:

Tabla 2. Comparación de la DRA y la asignación manual de dispositivos
DRA Asignación manual
Selección flexible de dispositivos con expresiones CEL Selección de nodos específicos con selectores y solicitudes de recursos
Decisiones de programación tomadas por Kubernetes Decisiones de programación tomadas por el operador con selectores de nodos
El filtrado de dispositivos está separado de la creación de cargas de trabajo El filtrado de dispositivos debe realizarse en el manifiesto de la carga de trabajo
Filtrado centralizado de dispositivos y clases basadas en necesidades, administradas por administradores de plataformas Filtrado aislado de dispositivos por operadores de aplicaciones
Los operadores de apps no necesitan conocer la capacidad del nodo, la información de la etiqueta del nodo, o los modelos de dispositivos conectados para cada nodo Los operadores de apps deben saber qué nodos tienen modelos y cantidades específicos de ciertos dispositivos conectados.

DRA y ajuste de escala automático de la infraestructura

Para ajustar automáticamente la cantidad de nodos dentro de un grupo de nodos en modo Estándar, usa el escalador automático del clú1ster. Puedes habilitar el escalador automático del clúster en cualquier grupo de nodos creado de forma manual, incluidos los grupos de nodos que tienen controladores DRA.

Para los grupos de nodos que usan la DRA, la utilización del dispositivo afecta la forma en que el escalador automático del clúster agrega y quita nodos en un grupo de nodos. Para calcular la utilización del dispositivo en un grupo de nodos, el escalador automático del clúster considera los siguientes factores:

  • Todos los dispositivos de un grupo de recursos deben ser locales para un nodo específico. Si un ResourceSlice tiene un grupo de dispositivos conectados a varios nodos, el escalador automático del clúster ignora esos dispositivos.
  • Todos los dispositivos del grupo de nodos son igualmente importantes y son idénticos.
  • Los dispositivos DRA tienen mayor prioridad que la CPU o la memoria. En los grupos de nodos DRA, el escalador automático del clúster ignora el uso de la CPU y la memoria.

Estos factores pueden significar que notes un comportamiento de reducción de escala diferente en los grupos de nodos DRA que en otros grupos de nodos.

Dispositivos de GKE compatibles con la DRA

En la siguiente tabla, se describen los dispositivos que puedes asignar a las cargas de trabajo con la DRA en GKE:

Tabla 3. Dispositivos compatibles con la DRA en GKE
Dispositivos compatibles con la DRA
GPU Cualquier tipo de GPU que esté disponible en tu ubicación. Para obtener más información, consulta Ubicaciones de GPU.
Interfaces de red Varios tipos de interfaces de red, como interfaces compatibles con RDMA, mediante la instalación del controlador DRANET administrado. Para obtener más información, consulta Asigna recursos de red con DRANET administrado por GKE.

Limitaciones

Se aplican las siguientes limitaciones cuando usas la DRA:

  • Modo de operación: La DRA solo está disponible en clústeres en modo Estándar.

  • Tipo de acelerador: La DRA en GKE solo admite GPUs.

  • GPUs:

  • Interfaces de red: consulta Limitaciones en "Asigna recursos de red con DRANET administrado por GKE".

  • Ajuste de escala automático:

    • Para los controladores DRA de terceros que instalas, el escalador automático del clúster requiere que tus grupos de nodos tengan al menos un nodo. Para evitar que los grupos de nodos que usan controladores de terceros se escalen a cero nodos, establece la cantidad mínima de nodos en al menos 1.
    • Es posible que el escalador automático del clúster no funcione correctamente con los controladores DRA de terceros. Si usas controladores de terceros, verifica que los controladores publiquen información solo para los dispositivos que son locales para nodos específicos.
    • Para los DaemonSets en grupos de nodos con ajuste de escala automático que usan un ResourceClaim estático para compartir el acceso a dispositivos entre Pods, el ajuste de escala automático admite hasta 128 Pods de DaemonSet. Para evitar esta limitación, haz una de las siguientes acciones:
    • Si tus Pods hacen referencia a ResourceClaims y tienen una PriorityClass que establece la política de interrupción en PreemptLowerPriority, es posible que aumente la latencia del ajuste de escala automático. PreemptLowerPriority es la política de interrupción predeterminada para PriorityClass, por lo que debes asegurarte de que tus PriorityClasses establezcan de forma explícita el campo preemptionPolicy en Never. Para obtener más información, consulta PriorityClass sin interrupción.

En esta sección, se proporcionan recomendaciones para administradores de plataformas o operadores de apps que desean usar la DRA para asignar dispositivos a cargas de trabajo. La DRA cambia significativamente el método con el que solicitas dispositivos conectados, tanto en GKE como en Kubernetes. Para aprovechar casos de uso más avanzados, como la conmutación por error entre dispositivos o el filtrado y la selección detallados de dispositivos, considera las siguientes instrucciones:

¿Qué sigue?