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, se explica cómo funciona DRA en GKE y las ventajas de usar DRA para asignar hardware, como GPUs y TPUs.

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

Antes de leer esta página, asegúrate de que conoces los siguientes recursos:

Introducción a la DRA

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 asignación de recursos de dispositivo mejora la experiencia de asignación de hardware conectado, como aceleradores, ya que permite a los proveedores de dispositivos y a los administradores de plataformas declarar clases de dispositivos que se pueden solicitar y asignar. Los operadores de aplicaciones pueden solicitar configuraciones de dispositivos específicas dentro de esas clases y, a continuación, solicitar esas configuraciones en sus cargas de trabajo. Kubernetes y GKE gestionan 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 la plataforma puede definir una clase de dispositivo que solo tenga GPUs NVIDIA A100. Los operadores de aplicaciones pueden filtrar los dispositivos de esa clase de dispositivo en función de los requisitos de la carga de trabajo, como filtrar los dispositivos que tengan un mínimo de 80 GB de memoria de GPU. Cuando el operador de la aplicación implementa una carga de trabajo que solicita la configuración filtrada, GKE coloca los pods en los nodos que cumplen los criterios seleccionados. En este ejemplo, GKE busca nodos que tengan GPUs A100 (80 GB) disponibles. El operador de la aplicación no tiene que seleccionar nodos ni configuraciones de dispositivos específicos en el manifiesto de la carga de trabajo.

Ventajas de la DRA

Sin DRA, la asignación de dispositivos de hardware en Kubernetes se basa en plugins de dispositivos. Para asociar recursos de hardware a pods mediante complementos de dispositivo, se usan etiquetas de nodo para colocar pods en nodos específicos. Además, para dedicar todos los recursos de un nodo a un solo pod, solicita el número exacto de dispositivos que estén 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 de esas clases y, a continuación, asignas los dispositivos solicitados a las cargas de trabajo. DRA proporciona una superficie significativamente más extensible para filtrar dispositivos en función de la carga de trabajo y las necesidades empresariales. El enfoque de DRA, que usa expresiones y plantillas para reclamar hardware y programar pods, tiene las siguientes ventajas:

  • 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.
  • Menor complejidad entre equipos: cuando los administradores de la plataforma aprovisionan nodos que tienen configuraciones de hardware especializadas, los operadores de aplicaciones no tienen que saber qué nodos tienen configuraciones específicas. Los administradores de la plataforma no tienen que etiquetar nodos ni comunicar información sobre nodos y dispositivos específicos a los operadores.
  • Menor complejidad para los desarrolladores: Kubernetes programa los pods en función de la configuración del dispositivo al que se hace referencia. Los operadores de aplicaciones no tienen que seleccionar nodos específicos en sus cargas de trabajo ni asegurarse de que cada pod solicite exactamente el número de dispositivos conectados a esos nodos.
  • Gestión centralizada de la infraestructura: los administradores de la plataforma pueden definir de forma centralizada configuraciones de hardware que cumplan requisitos empresariales específicos. Por ejemplo, un administrador de la plataforma podría declarar una configuración de alto rendimiento con GPUs H100 junto con una configuración de inferencia pequeña con GPUs Tesla T4.
  • Selección de hardware flexible: la API Device Restrictions te permite usar expresiones CEL para filtrar dispositivos que tengan atributos específicos. Las expresiones te permiten filtrar los dispositivos que son óptimos para cargas de trabajo específicas.

Cuándo usar DRA

Durante la vista previa, 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 e implementar la carga de trabajo en diferentes clústeres con distintos tipos de dispositivos sin tener que cambiar el manifiesto. Esta flexibilidad es ideal para casos prácticos como los siguientes:

  • Mejorar la disponibilidad de las GPUs: en el caso de las cargas de trabajo que necesitan acceder 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 amplía 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 que no hay recursos disponibles.
  • Optimizar la disponibilidad de nodos de GPU durante el escalado: el número de GPUs conectadas que requiere una carga de trabajo puede cambiar en función del tipo de GPU. Puedes usar una clase de computación de GKE para aprovisionar nodos en función de la disponibilidad, la cuota o las reservas de capacidad de las GPUs. Después, puedes usar DRA en tus cargas de trabajo para configurar los pods de forma que se ejecuten en cualquier nodo que GKE aprovisione para la clase de cálculo. Si usas DRA con clases de computación, puedes minimizar el riesgo de que se produzcan cargas de trabajo no programadas y, al mismo tiempo, asegurarte de que las cargas de trabajo se ejecuten en hardware optimizado.

Terminología

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

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

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

Por ejemplo, imagina que creas un ResourceClaim para una GPU A100 (40 GB) y, a continuación, 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 acceder a configuraciones de dispositivos similares, especialmente cuando usas un controlador de cargas de trabajo como Deployments o StatefulSets.

Los operadores de aplicaciones despliegan ResourceClaimTemplates y, a continuación, hacen referencia a las plantillas en las cargas de trabajo. Kubernetes crea ResourceClaims para cada Pod en función de 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 aplicaciones para asignar dispositivos mediante la asignación dinámica de recursos:

En este diagrama, los administradores de clústeres y los operadores de aplicaciones 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 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 práctico principal de cada tipo de reclamación es el siguiente:
    • Un ResourceClaim permite que varios pods compartan el acceso al mismo dispositivo.
    • Un ResourceClaimTemplate permite que varios pods accedan a dispositivos independientes y similares generando automáticamente ResourceClaims por pod.
  4. Los operadores de aplicaciones añaden ResourceClaimTemplates o ResourceClaims a los manifiestos de sus cargas de trabajo.
  5. Los operadores de aplicaciones despliegan la carga de trabajo.

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

  1. Si la carga de trabajo hace referencia a un ResourceClaimTemplate, Kubernetes crea un objeto ResourceClaim por cada instancia de la carga de trabajo (por ejemplo, cada réplica de un Deployment).
  2. El programador de Kubernetes usa los ResourceSlices del clúster para asignar los dispositivos disponibles y aptos a los ResourceClaims de cada Pod.
  3. El programador coloca cada Pod en un nodo que tiene acceso a los dispositivos que se han asignado al ResourceClaim del Pod.
  4. El kubelet del nodo de destino llama al controlador DRA del 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 indicar a Kubernetes que quieres dispositivos que cumplan 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 has creado el ResourceClaim o si Kubernetes lo ha creado a partir de un ResourceClaimTemplate.

Si creas un ResourceClaim y, a continuación, lo referencias en varios pods, todos esos pods podrán acceder a los dispositivos que Kubernetes asigne a ese ResourceClaim. Por ejemplo, este acceso compartido puede producirse 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 los compartan varios procesos, este acceso compartido a los dispositivos entre pods puede provocar 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 un Deployment que tiene varias réplicas, Kubernetes crea un ResourceClaim independiente para cada Pod replicado. Por lo tanto, cada Pod tiene asignado su propio dispositivo 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 eliminan 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
Gestionado por ti Gestionado por Kubernetes
Proporciona acceso a los mismos dispositivos desde varios Pods Permite acceder a los 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 los dispositivos

Comparación de la asignación dinámica de recursos con la asignación manual de dispositivos

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 mediante plugins 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:
    • Selecciona un nodo que tenga la configuración de dispositivo necesaria, como el modelo de GPU o el tipo y la topología de TPU, mediante un campo nodeSelector.
    • Especifica el número exacto de dispositivos que deben consumir los contenedores mediante 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 para saber qué nodos o grupos de nodos específicos tienen determinadas 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 en función de 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 DRA con los complementos de dispositivo:

DRA Asignación manual
Selección flexible de dispositivos mediante expresiones CEL Selección de nodos específicos mediante selectores y solicitudes de recursos
Decisiones de programación tomadas por Kubernetes Decisiones de programación tomadas por el operador mediante selectores de nodos
El filtrado de dispositivos es independiente de la creación de cargas de trabajo El filtrado de dispositivos debe realizarse en el manifiesto de la carga de trabajo
Filtrado de dispositivos centralizado y clases basadas en las necesidades, gestionadas por los administradores de la plataforma Filtrado de dispositivos aislados por operadores de aplicaciones
Los operadores de aplicaciones no necesitan saber la capacidad de los nodos, la información de las etiquetas de los nodos ni los modelos de dispositivos conectados a cada nodo. Los operadores de aplicaciones deben saber qué nodos tienen modelos y cantidades específicos de determinados dispositivos conectados.

Dispositivos GKE compatibles con DRA

Puedes usar DRA para asignar GPUs o TPUs a cargas de trabajo de GKE. Puedes asignar cualquiera de los modelos de GPU y TPU que admite GKE. Para obtener más información sobre las GPUs y las TPUs que admite GKE, consulta los siguientes recursos:

Limitaciones de DRA en GKE

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

  • No puedes usar la DRA con el aprovisionamiento automático de nodos.
  • No puedes usar DRA con las siguientes funciones de uso compartido de GPU:
    • GPUs compartidas.
    • GPUs con varias instancias.
    • Servicio multiproceso (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 ofrecen recomendaciones para administradores de plataformas u operadores de aplicaciones que quieran usar la asignación dinámica de recursos para asignar dispositivos a cargas de trabajo. DRA cambia significativamente el método por el que solicitas dispositivos conectados, tanto en GKE como en Kubernetes. Para aprovechar casos prácticos más avanzados, como la alternativa multidispositivo o el filtrado y la selección de dispositivos detallados, siga estas directrices:

Mejorar la disponibilidad de los nodos durante el escalado

Las clases de Compute en GKE te permiten definir un comportamiento de fallback basado en la prioridad que sigue GKE cuando crea nodos en clústeres. Puedes usar ComputeClasses para configurar una serie priorizada de configuraciones de nodos y dispositivos que GKE utiliza cuando crea nodos para ejecutar cargas de trabajo. Después, puedes usar DRA para asegurarte de que tu carga de trabajo se pueda ejecutar en cualquier nodo de ComputeClass sin tener que seleccionar nodos manualmente por etiqueta.

Por ejemplo, una carga de trabajo puede necesitar dos GPUs NVIDIA L4 o una GPU NVIDIA A100 (40 GB) para funcionar de forma ó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. Después, podrías usar DRA para solicitar cualquier GPU disponible para tu carga de trabajo. Cuando despliegues la carga de trabajo y selecciones ese ComputeClass, GKE creará nodos que tengan 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 el número de GPUs.

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

Siguientes pasos