À propos de l'allocation dynamique des ressources dans GKE

Cette page fournit des informations sur l'allocation dynamique des ressources (DRA) dans Google Kubernetes Engine (GKE). Sur cette page, vous découvrirez les principes de base de la DRA, son fonctionnement dans GKE et les avantages de l'utiliser pour allouer du matériel tel que des GPU et des TPU.

Cette page est destinée aux rôles suivants:

Avant de lire cette page, assurez-vous de connaître les ressources suivantes:

Présentation de la DRA

La DRA est une fonctionnalité Kubernetes intégrée qui vous permet de demander, d'allouer et de partager de manière flexible du matériel dans votre cluster entre les pods et les conteneurs. La DRA améliore l'expérience d'allocation du matériel connecté, tel que les accélérateurs, en permettant aux fournisseurs d'appareils et aux administrateurs de plate-forme de déclarer des classes d'appareils pouvant être demandés et alloués. Les opérateurs d'applications peuvent demander des configurations d'appareils spécifiques dans ces classes, puis demander ces configurations dans leurs charges de travail. Kubernetes et GKE gèrent la planification des pods, l'attribution de nœuds et l'allocation d'appareils en fonction des requêtes de charge de travail.

Par exemple, un administrateur de plate-forme peut définir une classe d'appareils qui ne comporte que des GPU NVIDIA A100. Les opérateurs d'applications peuvent ensuite filtrer les appareils de cette classe d'appareils en fonction des exigences de charge de travail, par exemple en filtrant pour un minimum de 80 Go de mémoire GPU. Lorsque l'opérateur de l'application déploie une charge de travail qui demande la configuration filtrée, GKE place les pods sur les nœuds qui répondent aux critères sélectionnés. Dans cet exemple, GKE recherche les nœuds disposant de GPU A100 (80 Go) disponibles. L'opérateur de l'application n'a pas besoin de sélectionner des nœuds ou des configurations d'appareil spécifiques dans le fichier manifeste de la charge de travail.

Avantages de la DRA

Sans DRA, l'allocation d'appareils matériels dans Kubernetes repose sur des plug-ins d'appareil. Pour associer des ressources matérielles à des pods à l'aide de plug-ins d'appareil, vous devez utiliser des libellés de nœud pour placer les pods sur des nœuds spécifiques. De plus, pour consacrer les ressources d'un nœud entier à un seul pod, vous devez demander le nombre exact d'appareils connectés aux nœuds.

Avec le stockage DRA, l'allocation d'appareils à des pods est semblable à l'allocation de volumes pour le stockage. Vous définissez des classes d'appareils, demandez des appareils dans ces classes, puis attribuez ces appareils demandés à des charges de travail. La DRA offre une surface beaucoup plus extensible pour filtrer les appareils en fonction de la charge de travail et des besoins de l'entreprise. L'approche DRA consistant à utiliser des expressions et des modèles pour revendiquer du matériel et planifier des pods présente les avantages suivants:

  • Allocation d'appareils déclarative: les administrateurs de la plate-forme peuvent définir des configurations d'appareils pour des types de charges de travail ou d'équipes spécifiques.
  • Réduction de la complexité inter-équipes: lorsque les administrateurs de la plate-forme provisionnent des nœuds dotés de configurations matérielles spécialisées, les opérateurs d'applications n'ont pas besoin de savoir quels nœuds ont des configurations spécifiques. Les administrateurs de la plate-forme n'ont pas besoin d'étiqueter les nœuds ni de communiquer des informations sur des nœuds et des appareils spécifiques aux opérateurs.
  • Simplicité réduite pour les développeurs: Kubernetes planifie les pods en fonction de la configuration de l'appareil référencé. Les opérateurs d'applications n'ont pas besoin de sélectionner des nœuds spécifiques dans leurs charges de travail et ne doivent pas s'assurer que chaque pod demande exactement le nombre d'appareils connectés à ces nœuds.
  • Gestion centralisée de l'infrastructure: les administrateurs de la plate-forme peuvent définir de manière centralisée des configurations matérielles qui répondent à des exigences métier spécifiques. Par exemple, un administrateur de plate-forme peut déclarer une configuration hautes performances avec des GPU H100 et une petite configuration d'inférence avec des GPU Tesla T4.
  • Sélection flexible du matériel: la DRA vous permet d'utiliser des expressions CEL pour filtrer les appareils qui présentent des attributs spécifiques. L'utilisation d'expressions permet de filtrer les appareils qui sont optimaux pour des charges de travail spécifiques.

Quand utiliser DRA ?

Pendant la phase Preview, la principale raison d'utiliser la DRA dans GKE est la flexibilité avec laquelle vous pouvez demander des appareils pour les charges de travail. Vous pouvez écrire un fichier manifeste une seule fois et déployer la charge de travail sur différents clusters avec différents types d'appareils sans avoir à modifier le fichier manifeste. Cette flexibilité est idéale pour les cas d'utilisation suivants:

  • Amélioration de la disponibilité des GPU: pour les charges de travail qui ont besoin d'accéder au matériel de GPU, vous pouvez utiliser la DRA pour demander n'importe quel GPU disponible dans le cluster au lieu de spécifier un modèle de GPU. Si ces charges de travail ont des exigences spécifiques en termes de mémoire GPU (VRAM), vous pouvez demander n'importe quel GPU du cluster disposant d'une quantité minimale de mémoire. Ce type de requête flexible élargit l'ensemble de nœuds GPU sur lesquels une charge de travail peut s'exécuter, ce qui réduit le risque que la charge de travail ne soit pas planifiée en raison de ressources indisponibles.
  • Optimisez la disponibilité des nœuds GPU lors de l'ajustement de l'échelle: le nombre de GPU associés requis par une charge de travail peut varier en fonction du type de GPU. Vous pouvez utiliser une classe de calcul GKE pour provisionner des nœuds en fonction de la disponibilité des GPU, des quotas ou des réservations de capacité. Vous pouvez ensuite utiliser la DRA dans vos charges de travail pour configurer les pods afin qu'ils s'exécutent sur n'importe quel nœud que GKE provisionne pour la classe de calcul. L'utilisation de la DRA avec des classes de calcul vous permet de minimiser le risque de charges de travail non planifiées, tout en vous assurant qu'elles s'exécutent sur du matériel optimisé.

Terminologie

Les fournisseurs Kubernetes Open Source et Kubernetes gérés tels que GKE utilisent les termes de DRA suivants:

ResourceSlice
Un ResourceSlice liste un ou plusieurs appareils matériels du cluster auxquels les nœuds peuvent accéder. Par exemple, dans un nœud pouvant accéder à un seul GPU, ResourceSlice liste le GPU et le nom du nœud. Les pilotes d'appareil DRA sur chaque nœud créent des ResourceSlices. Le planificateur Kubernetes utilise des ResourceSlices pour décider des appareils à allouer pour répondre aux demandes de charge de travail.
DeviceClass
Un DeviceClass définit une catégorie d'appareils, tels que les GPU, que vous pouvez demander pour vos charges de travail. Certains pilotes d'appareils fournissent des DeviceClasses intégrés, tels que la DeviceClass gpu.nvidia.com pour les GPU NVIDIA. Les administrateurs de la plate-forme peuvent également créer des DeviceClasses personnalisées qui définissent des configurations d'appareils spécifiques.
ResourceClaim

Un ResourceClaim permet à un pod ou à un utilisateur de demander des ressources matérielles en filtrant certains paramètres dans un DeviceClass. Lorsqu'une charge de travail fait référence à un ResourceClaim, Kubernetes lui attribue les appareils correspondant aux paramètres spécifiés.

Par exemple, imaginons que vous créiez un ResourceClaim pour un GPU A100 (40 Go), puis déployiez une charge de travail qui sélectionne ce ResourceClaim. Kubernetes attribue un GPU A100 (40 Go) disponible à ResourceClaim et planifie votre pod sur un nœud pouvant accéder à ce GPU.

ResourceClaimTemplate

Un ResourceClaimTemplate définit un modèle que les pods peuvent utiliser pour créer automatiquement des ResourceClaims par pod. Les ResourceClaimTemplates sont utiles lorsque plusieurs charges de travail ont besoin d'accéder à des configurations d'appareils similaires, en particulier lorsque vous utilisez un contrôleur de charge de travail tel que des déploiements ou des StatefulSets.

Les opérateurs d'application déploient des ResourceClaimTemplates, puis les référencent dans les charges de travail. Kubernetes crée des ResourceClaims pour chaque pod en fonction du modèle spécifié, alloue des appareils et planifie les pods. Lorsque les pods s'arrêtent, Kubernetes nettoie les ResourceClaims correspondants.

Fonctionnement de la DRA

L'utilisation de DRA dans vos clusters et charges de travail est semblable à l'utilisation de StorageClasses, PersistentVolumeClaims et PersistentVolumes pour provisionner dynamiquement des volumes pour les pods.

Le schéma suivant montre les étapes suivies par les administrateurs de cluster et les opérateurs d'applications pour allouer des appareils à l'aide de la DRA:

Dans ce schéma, les administrateurs de cluster et les opérateurs d'application effectuent les opérations suivantes:

  1. Les administrateurs de cluster installent des pilotes d'appareils compatibles avec la DRA dans les nœuds.
  2. Les administrateurs de cluster créent des DeviceClasses qui filtrent le matériel qui répond à des exigences spécifiques, telles que tous les GPU disposant de plus de 40 Go de mémoire. Certains appareils peuvent également inclure des DeviceClasses intégrés.
  3. Les opérateurs d'applications créent des ResourceClaimTemplates ou des ResourceClaims qui demandent des configurations d'appareils. Voici le cas d'utilisation principal pour chaque type de revendication :
    • Un ResourceClaim permet à plusieurs pods de partager l'accès à un même appareil.
    • Un ResourceClaimTemplate permet à plusieurs pods d'accéder à des appareils distincts et similaires en générant automatiquement des ResourceClaims par pod.
  4. Les opérateurs d'application ajoutent les ResourceClaimTemplates ou ResourceClaims à leurs fichiers manifestes de charge de travail.
  5. Les opérateurs d'application déploient la charge de travail.

Lorsque vous déployez une charge de travail qui fait référence à un ResourceClaimTemplate ou à un ResourceClaim, Kubernetes effectue les étapes de planification suivantes:

  1. Si la charge de travail fait référence à un ResourceClaimTemplate, Kubernetes crée un nouvel objet ResourceClaim pour chaque instance de la charge de travail (par exemple, chaque réplica dans un déploiement).
  2. Le planificateur Kubernetes utilise les ResourceSlices du cluster pour allouer les appareils disponibles et éligibles au ResourceClaim de chaque pod.
  3. Le planificateur place chaque pod sur un nœud ayant accès aux appareils qui ont été alloués à ResourceClaim du pod.
  4. Le kubelet sur le nœud de destination appelle le pilote DRA sur le nœud pour associer le matériel alloué au pod afin de répondre à sa requête de ressources.

Quand utiliser ResourceClaims et ResourceClaimTemplates

ResourceClaims et ResourceClaimTemplates vous permettent d'indiquer à Kubernetes que vous souhaitez des appareils qui répondent à des exigences spécifiques. Lorsqu'un ResourceClaim est référencé dans un pod, Kubernetes alloue des appareils à la ressource API ResourceClaim correspondante sur le serveur d'API Kubernetes. Cette allocation se produit que vous ayez créé le ResourceClaim ou que Kubernetes l'ait créé à partir d'un ResourceClaimTemplate.

Si vous créez un ResourceClaim, puis le référencez dans plusieurs pods, tous ces pods peuvent accéder aux appareils que Kubernetes alloue pour ce ResourceClaim. Par exemple, cet accès partagé peut se produire si vous référencez un ResourceClaim spécifique dans un fichier manifeste de déploiement qui comporte plusieurs réplicas. Cependant, si les appareils alloués ne sont pas configurés pour être partagés par plusieurs processus, cet accès aux appareils partagés entre les pods peut entraîner un comportement involontaire.

Un ResourceClaimTemplate vous permet de définir des modèles que Kubernetes utilise pour créer automatiquement des ResourceClaims individuels pour les pods. Par exemple, si vous faites référence à un ResourceClaimTemplate dans un déploiement qui comporte plusieurs réplicas, Kubernetes crée un ResourceClaim distinct pour chaque pod cloné. Par conséquent, chaque pod dispose de son propre appareil alloué au lieu de partager l'accès à l'appareil avec d'autres pods. Ces ResourceClaims générés automatiquement sont liés à la durée de vie du pod correspondant et sont supprimés lorsque le pod se termine. Si vous avez des pods indépendants qui ont besoin d'accéder à des configurations d'appareils similaires, utilisez un ResourceClaimTemplate pour allouer des appareils à chaque pod séparément.

Le tableau suivant décrit certaines différences entre la création manuelle de ResourceClaims et le fait de laisser Kubernetes créer des ResourceClaims à partir d'un ResourceClaimTemplate:

ResourceClaims créés manuellement ResourceClaims créés automatiquement
Géré par vous Gérés par Kubernetes
Fournit un accès aux mêmes appareils à partir de plusieurs pods Fournit un accès aux appareils à partir d'un seul pod
Existe dans le cluster indépendamment des pods Lié au cycle de vie du pod correspondant
Idéal pour plusieurs charges de travail qui doivent partager un appareil spécifique Idéal pour plusieurs charges de travail nécessitant un accès indépendant aux appareils

Comparaison de la DRA avec l'allocation manuelle des appareils

La DRA permet d'allouer des appareils connectés de manière similaire au provisionnement dynamique des PersistentVolumes. Kubernetes permet également d'allouer des appareils à l'aide de plug-ins d'appareil. Cette méthode comprend les étapes suivantes:

  1. Un administrateur de cluster crée des nœuds auxquels sont associés des appareils, tels que des GPU.
  2. L'administrateur du cluster communique des informations sur des nœuds spécifiques et leurs appareils associés aux opérateurs de charge de travail.
  3. Un opérateur de charge de travail demande des appareils dans le fichier manifeste de la charge de travail comme suit :
    • Sélectionnez un nœud disposant de la configuration d'appareil requise, comme le modèle de GPU ou le type et la topologie de TPU, à l'aide d'un champ nodeSelector.
    • Spécifiez le nombre exact d'appareils que les conteneurs doivent consommer à l'aide du champ resources dans la spécification du pod.

Cette méthode d'allocation manuelle nécessite que les opérateurs d'application et les administrateurs de cluster communiquent sur les nœuds ou pools de nœuds spécifiques qui disposent de certaines configurations d'appareils. Ils doivent coordonner les requêtes de charge de travail pour qu'elles correspondent aux appareils des nœuds, sinon le déploiement échoue. En comparaison, la DRA vous permet d'utiliser des expressions pour filtrer de manière flexible les appareils en fonction des attributs, et les opérateurs de charge de travail n'ont pas besoin de connaître la configuration exacte des nœuds du cluster.

Le tableau suivant compare la DRA aux plug-ins d'appareil:

DRA Attribution manuelle
Sélection flexible des appareils à l'aide d'expressions CEL Sélection de nœuds spécifiques à l'aide de sélecteurs et de demandes de ressources
Décisions de planification prises par Kubernetes Décisions de planification prises par l'opérateur à l'aide de sélecteurs de nœuds
Le filtrage des appareils est distinct de la création de la charge de travail. Le filtrage des appareils doit être effectué dans le fichier manifeste de la charge de travail.
Filtrage centralisé des appareils et classes basées sur les besoins, gérés par les administrateurs de la plate-forme Filtrage des appareils isolés par les opérateurs d'application
Les opérateurs d'applications n'ont pas besoin de connaître la capacité des nœuds, les informations sur les libellés des nœuds ni les modèles d'appareils connectés pour chaque nœud. Les opérateurs d'applications doivent savoir quels nœuds sont associés à des modèles et à des quantités spécifiques d'appareils.

Appareils GKE compatibles avec la DRA

Vous pouvez utiliser la DRA pour allouer des GPU ou des TPU à des charges de travail GKE. Vous pouvez allouer n'importe quel modèle de GPU et de TPU compatible avec GKE. Pour en savoir plus sur les GPU et TPU compatibles avec GKE, consultez les ressources suivantes:

Limites de la DRA dans GKE

La DRA présente les limites suivantes dans les clusters GKE:

  • Vous ne pouvez pas utiliser le stockage DRA avec le provisionnement automatique des nœuds.
  • Vous ne pouvez pas utiliser le stockage DRA avec les fonctionnalités de partage de GPU suivantes :
    • GPU à temps partagé
    • GPU multi-instances
    • Service multiprocessus (MPS)
  • Vous ne pouvez pas utiliser la DRA dans les clusters Autopilot.
  • Vous devez utiliser GKE version 1.32.1-gke.1489001 ou ultérieure.

Cette section fournit des recommandations aux administrateurs de plate-forme ou aux opérateurs d'applications qui souhaitent utiliser la DRA pour allouer des appareils à des charges de travail. La DRA modifie considérablement la méthode par laquelle vous demandez des appareils connectés, à la fois dans GKE et dans Kubernetes. Pour bénéficier de cas d'utilisation plus avancés, tels que le remplacement inter-appareils ou le filtrage et la sélection précis des appareils, suivez les conseils suivants:

Améliorer la disponibilité des nœuds lors du scaling

Les ComputeClasses de GKE vous permettent de définir le comportement de remplacement basé sur la priorité que GKE suit lorsqu'il crée des nœuds dans des clusters. Vous pouvez utiliser ComputeClasses pour configurer une série de configurations de nœuds et d'appareils prioritaires que GKE utilise lorsqu'il crée des nœuds pour exécuter des charges de travail. Vous pouvez ensuite utiliser la DRA pour vous assurer que votre charge de travail peut s'exécuter sur n'importe quel nœud de la classe de calcul sans avoir à sélectionner manuellement les nœuds par libellé.

Par exemple, une charge de travail peut nécessiter deux GPU NVIDIA L4 ou un GPU NVIDIA A100 (40 Go) pour fonctionner de manière optimale. Vous pouvez créer une classe de calcul qui donne la priorité à la création de nœuds avec un GPU A100 (40 Go), mais qui peut passer à la création de nœuds avec deux GPU L4 par nœud. Vous pouvez ensuite utiliser la DRA pour demander n'importe quel GPU disponible pour votre charge de travail. Lorsque vous déployez la charge de travail et sélectionnez cette classe de calcul, GKE crée des nœuds disposant de l'une des configurations de GPU spécifiées. Avec DRA, GKE peut placer la charge de travail sur le premier nœud disponible, quel que soit le modèle de GPU, le libellé du nœud ou le nombre de GPU.

Pour en savoir plus, consultez les ressources suivantes :

Étape suivante