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 dinámica de recursos (DRA) en Google Kubernetes Engine (GKE). En esta página, aprenderás sobre los conceptos básicos de la DRA, cómo funciona en GKE y los beneficios de usar la DRA para asignar hardware, como GPUs y TPUs.

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 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 adjunto, 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 carga 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 la app pueden filtrar los dispositivos de esa clase según los requisitos de carga de trabajo, por ejemplo, filtrar para obtener 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 adjuntar recursos de hardware a los Pods con complementos de dispositivos, usa etiquetas de nodos para colocar los Pods en nodos específicos. Además, para dedicar todos los recursos de un nodo a un solo Pod, debes solicitar la cantidad exacta de dispositivos conectados a los nodos.

Con DRA, la experiencia de asignar dispositivos a los Pods es similar a la de asignar volúmenes para el almacenamiento. Defines clases de dispositivos, solicitas dispositivos dentro de esas clases y, luego, asignas los 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 comerciales. El enfoque de DRA que usa expresiones y plantillas para reclamar hardware y programar Pods tiene los siguientes beneficios:

  • Asignación declarativa de dispositivos: Los administradores de la plataforma pueden definir configuraciones de dispositivos para tipos específicos de cargas de trabajo o equipos.
  • Menor complejidad entre equipos: Cuando los administradores de la plataforma aprovisionan nodos que tienen parámetros de configuración de hardware especializados, los operadores de la app no necesitan saber qué nodos tienen parámetros de configuración específicos. Los administradores de la plataforma no necesitan etiquetar nodos ni comunicar información sobre nodos y dispositivos específicos a los operadores.
  • Menor complejidad para los desarrolladores: Kubernetes programa los 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 la plataforma pueden definir de forma centralizada las configuraciones de hardware que satisfacen requisitos comerciales específicos. Por ejemplo, un administrador de la plataforma podría declarar una configuración de alto rendimiento que tenga GPU H100 junto con una pequeña configuración de inferencia que tenga GPU Tesla T4.
  • Selección de hardware flexible: La DRA te permite usar expresiones CEL para filtrar dispositivos que tienen atributos específicos. El uso de expresiones proporciona la flexibilidad necesaria para filtrar los dispositivos que son óptimos para cargas de trabajo específicas.

Cuándo usar la DRA

Durante la versión preliminar, el motivo principal para usar DRA en GKE es la flexibilidad con la que puedes solicitar dispositivos para las 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 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 la carga de trabajo debido a la falta de recursos.
  • Optimiza la disponibilidad de nodos de GPU durante el ajuste de escala: 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, la cuota o las reservas de capacidad de la GPU. Luego, puedes usar DRA en tus cargas de trabajo para configurar los Pods de modo 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 las cargas de trabajo se ejecuten en hardware optimizado.

Terminología

Los proveedores de Kubernetes de código abierto y Kubernetes administrado, 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 de 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 las GPUs, que están disponibles para solicitar cargas de trabajo. Algunos controladores de dispositivos proporcionan DeviceClasses integradas, como gpu.nvidia.comDeviceClass para las 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 soliciten recursos de hardware filtrando ciertos parámetros dentro de un 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, 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 pueda 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 la app 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.

Cómo funciona la DRA

Usar DRA en tus clústeres y cargas de trabajo es similar a usar StorageClasses, PersistentVolumeClaims y PersistentVolumes para aprovisionar volúmenes de forma dinámica para los 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 del clúster y los operadores de la app hacen lo siguiente:

  1. Los administradores del clúster 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 reclamo es el siguiente:
    • Un objeto ResourceClaim permite que varios Pods compartan el acceso al mismo dispositivo.
    • Un ResourceClaimTemplate permite que varios Pods accedan a dispositivos separados y similares generando automáticamente ResourceClaims por Pod.
  4. Los operadores de aplicaciones agregan los objetos 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 a 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 del clúster para asignar dispositivos disponibles y aptos a cada ResourceClaim del 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 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 la API de 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 un ResourceClaimTemplate.

Si creas un objeto ResourceClaim y, luego, haces referencia a él en varios Pods, todos esos Pods podrán acceder a los dispositivos que Kubernetes asigne para ese objeto 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 ser compartidos por varios procesos, este acceso compartido a los dispositivos en los Pods podría generar un comportamiento no deseado.

Un ResourceClaimTemplate te permite definir plantillas que Kubernetes usa para crear automáticamente ResourceClaims individuales para los Pods. Por ejemplo, si haces referencia a un 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 ciclo de vida del Pod correspondiente y se borran cuando finaliza el Pod. Si tienes Pods independientes que necesitan acceder 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:

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 de forma independiente de los Pods. Está vinculado al ciclo de vida del Pod correspondiente.
Ideal para varias cargas de trabajo que necesitan compartir un dispositivo específico Ideal para múltiples 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 a través de complementos de dispositivos. Este método implica los siguientes pasos:

  1. Un administrador del clúster crea nodos que tienen dispositivos adjuntos, como GPUs.
  2. El administrador del clúster comunica información sobre nodos específicos y sus dispositivos adjuntos a los operadores de cargas de trabajo.
  3. Un operador de carga de trabajo solicita dispositivos en el manifiesto de carga de trabajo de la siguiente manera:
    • Selecciona un nodo que tenga la configuración del dispositivo requerida, como el modelo de GPU o el tipo y la topología de TPU, 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 la aplicación 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. De lo contrario, la implementación fallará. En comparación, 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 del clúster.

En la siguiente tabla, se compara la DRA con los complementos para 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 Decisiones de programación 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 las necesidades, administrados 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 adjuntos para cada nodo. Los operadores de la app deben saber qué nodos tienen modelos específicos y qué cantidades de ciertos dispositivos están conectados.

Dispositivos de GKE compatibles con DRA

Puedes usar DRA para asignar GPU 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 GPU y TPU que admite GKE, consulta los siguientes recursos:

Limitaciones de la DRA en GKE

El 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:
    • GPU 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 los administradores de plataformas o los operadores de apps que deseen usar DRA para asignar dispositivos a cargas de trabajo. La DRA cambia significativamente el método por el que solicitas dispositivos conectados, tanto en GKE como en Kubernetes. Para aprovechar casos de uso más avanzados, como la resiliencia multidispositivo o el filtrado y la selección detallados de dispositivos, ten en cuenta las siguientes recomendaciones:

Mejora la disponibilidad de los nodos durante el escalamiento

Las ComputeClasses en GKE te permiten definir un comportamiento de resguardo basado en la prioridad que GKE sigue cuando crea nodos nuevos en los 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 necesidad de seleccionar nodos de forma manual por etiqueta.

Por ejemplo, una carga de trabajo podría necesitar dos GPUs NVIDIA L4 o una GPU NVIDIA A100 (40 GB) para ejecutarse de manera óptima. Podrías 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 GPU L4 por nodo. Luego, podrías 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 DRA, GKE puede colocar la carga de trabajo en el primer nodo disponible, independientemente del modelo de GPU, la etiqueta del nodo o la cantidad de GPU.

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

¿Qué sigue?