Información acerca de la asignación dinámica de recursos en GKE

En esta página, se proporciona información sobre la asignación de recursos dinámica (DRA) en Google Kubernetes Engine (GKE). En esta página, obtendrás información sobre los aspectos básicos de la DRA, cómo funciona en GKE y los beneficios de usar la DRA para asignar hardware, como GPUs y TPU.

Esta página está destinada a los siguientes roles:

Antes de leer esta página, asegúrate de estar familiarizado con los siguientes recursos:

Introducción a 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 asignación de 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 según las solicitudes de cargas de trabajo.

Por ejemplo, un administrador de la plataforma podría definir una clase de dispositivo que solo tenga GPU NVIDIA A100. Luego, los operadores de apps pueden filtrar los dispositivos de esa clase según los requisitos de la carga de trabajo, como filtrar para un mínimo de 80 GB de memoria de la GPU. Cuando el operador de la app implementa una carga de trabajo que solicita la configuración filtrada, GKE coloca los Pods en los 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 ni configuraciones de dispositivos específicos en el manifiesto de la carga de trabajo.

Beneficios de la DRA

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

Con DRA, la experiencia de asignar dispositivos a pods es similar a asignar volúmenes para el almacenamiento. Define clases de dispositivos, solicita dispositivos dentro de esas clases y, luego, asígnales esos dispositivos solicitados a las cargas de trabajo. La DRA proporciona una superficie mucho más extensible para filtrar dispositivos según la carga de trabajo y las necesidades empresariales. El enfoque de DRA de usar expresiones y plantillas para reclamar hardware y programar Pods tiene los siguientes beneficios:

  • Asignación de dispositivos declarativa: Los administradores de la plataforma 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 la plataforma aprovisionan nodos que tienen configuraciones de hardware especializadas, los operadores de apps no necesitan saber qué nodos tienen configuraciones específicas. Los administradores de la plataforma no necesitan etiquetar nodos ni comunicar información sobre nodos y dispositivos específicos a los operadores.
  • Reducción de la complejidad para los desarrolladores: Kubernetes programa pods según la configuración del dispositivo a la 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 de infraestructura centralizada: Los administradores de la plataforma pueden definir de forma centralizada las configuraciones de hardware que cumplen con requisitos empresariales específicos. Por ejemplo, un administrador de la plataforma podría declarar una configuración de alto rendimiento que tenga GPUs H100 junto con una configuración de inferencia pequeña que tenga GPUs Tesla T4.
  • Selección de hardware flexible: La DRA te permite 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 DRA

Durante la versión preliminar, el motivo principal para usar 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 obtención de GPU: Para las cargas de trabajo que necesitan acceso al hardware de GPU, puedes usar 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 del 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 no se programe debido a recursos no disponibles.
  • Optimiza la disponibilidad de los nodos de GPU durante el escalamiento: La cantidad de GPUs adjuntas que requiere una carga de trabajo puede cambiar según el tipo de GPU. Puedes usar una clase de procesamiento de GKE para aprovisionar nodos según la disponibilidad de GPU, la cuota o las reservas de capacidad. Luego, puedes usar DRA en tus cargas de trabajo para configurar los Pods para que se ejecuten en cualquier nodo que GKE aprovisione para la clase de procesamiento. El uso de DRA con clases de procesamiento te permite minimizar el riesgo de cargas de trabajo no programadas y, al mismo tiempo, garantizar que se ejecuten en hardware optimizado.

Terminología

Los proveedores de Kubernetes de código abierto y Kubernetes administrados, como GKE, usan los siguientes términos de DRA:

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, 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 cargas de trabajo.
DeviceClass
Una DeviceClass define una categoría de dispositivos, como las GPUs, que están disponibles para solicitar cargas de trabajo. Algunos controladores de dispositivos proporcionan DeviceClasses integradas, como gpu.nvidia.comDeviceClass para GPUs de NVIDIA. Los administradores de la plataforma también pueden crear DeviceClasses personalizadas que definan parámetros de configuración específicos del dispositivo.
ResourceClaim

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

Por ejemplo, imagina 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 a ResourceClaim y programa tu Pod en un nodo que pueda acceder a esa GPU.

ResourceClaimTemplate

Un ResourceClaimTemplate define una plantilla que los Pods pueden usar para crear automáticamente nuevos ResourceClaims por Pod. ResourceClaimTemplates son útiles cuando tienes varias cargas de trabajo que necesitan acceso a configuraciones de dispositivos similares, en especial cuando se usa un controlador de cargas de trabajo, como implementaciones 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 se finalizan los Pods, Kubernetes limpia los ResourceClaims correspondientes.

Cómo funciona la DRA

El uso de DRA en tus clústeres y cargas de trabajo es una experiencia similar al uso de StorageClasses, PersistentVolumeClaims y PersistentVolumes para aprovisionar volúmenes de forma dinámica 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 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 integradas.
  3. Los operadores de aplicaciones crean ResourceClaimTemplates o ResourceClaims que solicitan configuraciones de dispositivos. El caso de uso principal para cada tipo de declaración es el siguiente:
    • Un ResourceClaim permite que varios Pods compartan el acceso al mismo dispositivo.
    • Una ResourceClaimTemplate permite que varios Pods accedan a dispositivos separados y similares generando automáticamente ResourceClaims por Pod.
  4. Los operadores de aplicaciones agregan 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 una ResourceClaimTemplate o a un ResourceClaim, Kubernetes realiza los siguientes pasos de programación:

  1. Si la carga de trabajo hace referencia a una 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 a cada ResourceClaim de Pod.
  3. El programador coloca cada pod en un nodo que tiene acceso a los dispositivos que se asignaron a ResourceClaim del pod.
  4. El kubelet en el nodo de destino llama al controlador de DRA en el nodo para adjuntar el hardware asignado al Pod y satisfacer su solicitud de recursos.

Cuándo usar ResourceClaims y ResourceClaimTemplates

Tanto ResourceClaims como ResourceClaimTemplates te permiten 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 se produce independientemente de si creaste el ResourceClaim o si Kubernetes lo creó a partir de una ResourceClaimTemplate.

Si creas un ResourceClaim y, luego, lo usas como referencia 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 podría generar un comportamiento no deseado.

Un ResourceClaimTemplate te permite definir plantillas que Kubernetes usa para crear automáticamente ResourceClaims individuales para Pods. Por ejemplo, si haces referencia a una ResourceClaimTemplate en una Deployment que tiene varias réplicas, Kubernetes crea un ResourceClaim independiente 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 al tiempo de vida del Pod correspondiente y se borran cuando este finaliza. Si tienes Pods independientes que necesitan acceso a configuraciones de dispositivos similares, usa una ResourceClaimTemplate para asignar dispositivos a cada Pod por separado.

En la siguiente tabla, se describen algunas diferencias entre crear ResourceClaims de forma manual y permitir que Kubernetes cree ResourceClaims a partir de una ResourceClaimTemplate:

ResourceClaims creados de forma manual 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 de forma independiente de los pods. Se vinculan 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 los 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 implica 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:
    • Usa un campo nodeSelector para seleccionar un nodo que tenga la configuración de dispositivo requerida, como el modelo de GPU o el tipo y la topología de TPU.
    • Especifica la cantidad exacta de dispositivos que los contenedores deben consumir 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 del clúster 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 dispositivos de forma flexible en función de atributos y no requiere que los operadores de cargas de trabajo conozcan la configuración exacta de los nodos del clúster.

En la siguiente tabla, se compara la DRA con los complementos 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 que toma Kubernetes Programación de decisiones que toma el operador con selectores de nodos
El filtrado de dispositivos es independiente de la creación de cargas de trabajo. El filtrado de dispositivos se debe realizar en el manifiesto de la carga de trabajo.
Filtrado de dispositivos centralizado y clases basadas en necesidades, administradas por los administradores de la plataforma Filtrado de dispositivos aislados por operadores de aplicaciones
Los operadores de apps no necesitan conocer la capacidad del nodo, la información de la etiqueta del nodo ni 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.

Dispositivos de GKE compatibles con la DRA

Puedes usar DRA para asignar GPUs o TPU a cargas de trabajo de GKE. Puedes asignar cualquiera de los modelos de GPU y TPU que admite GKE. Para obtener detalles sobre las GPUs y las TPU que admite GKE, consulta los siguientes recursos:

Limitaciones de la DRA en GKE

DRA tiene las siguientes limitaciones en los clústeres de GKE:

  • No puedes usar DRA con el aprovisionamiento automático de nodos.
  • No puedes usar DRA con las siguientes funciones de uso compartido de GPU:
    • GPUs de tiempo compartido
    • GPUs de varias instancias
    • Servicio de varios procesos (MPS).
  • No puedes usar DRA en clústeres de Autopilot.
  • Debes usar la versión 1.32.1-gke.1489001 de GKE o una posterior.

En esta sección, se proporcionan recomendaciones para administradores de plataformas o operadores de apps que deseen usar la DRA para asignar dispositivos a cargas de trabajo. DRA cambia de forma significativa el método con el que solicitas dispositivos conectados, tanto en GKE como en Kubernetes. Para beneficiarte de casos de uso más avanzados, como el resguardo multidispositivo o el filtrado y la selección de dispositivos detallados, ten en cuenta la siguiente guía:

Mejora la disponibilidad de los nodos durante el escalamiento

ComputeClasses en GKE te permiten definir el comportamiento de resguardo basado en la prioridad que sigue GKE cuando crea nodos nuevos en clústeres. Puedes usar ComputeClasses para configurar una serie priorizada de configuraciones de nodos y dispositivos que GKE usa cuando crea nodos para ejecutar cargas de trabajo. Luego, puedes usar DRA para asegurarte de que tu carga de trabajo se pueda ejecutar en cualquier nodo dentro de ComputeClass sin tener que seleccionar manualmente los nodos por etiqueta.

Por ejemplo, una carga de trabajo puede necesitar dos GPU NVIDIA L4 o una GPU NVIDIA A100 (40 GB) para ejecutarse de manera óptima. Puedes crear una ComputeClass que priorice la creación de nodos con una GPU A100 (40 GB), pero que pueda recurrir a la creación de nodos con dos GPUs L4 por nodo. Luego, puedes usar DRA para solicitar cualquier GPU disponible para tu carga de trabajo. Cuando implementas la carga de trabajo y seleccionas esa ComputeClass, GKE crea nodos que tienen una de las configuraciones de GPU especificadas. Con la DRA, GKE puede colocar la carga de trabajo en el primer nodo disponible, independientemente del modelo de GPU, la etiqueta del nodo o el recuento de GPU.

Para obtener más información, consulta las siguientes páginas:

¿Qué sigue?