À 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 DRA, son fonctionnement dans GKE et les avantages de l'utilisation de DRA 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 DRA

DRA est une fonctionnalité Kubernetes intégrée qui vous permet de demander, d'allouer et de partager du matériel de manière flexible dans votre cluster entre les pods et les conteneurs. DRA améliore l'expérience d'allocation du matériel associé, 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 au sein de ces classes, puis demander ces configurations dans leurs charges de travail. Kubernetes et GKE gèrent la planification des pods, l'attribution des nœuds et l'allocation des appareils en fonction des demandes 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 en fonction des exigences de charge de travail, par exemple en filtrant pour une mémoire GPU d'au moins 80 Go. Lorsque l'opérateur d'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 qui disposent de GPU A100 (80 Go) disponibles. L'opérateur d'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 DRA

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

Avec DRA, l'expérience d'attribution d'appareils à des pods est semblable à celle de l'attribution 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. 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 qui utilise des expressions et des modèles pour revendiquer du matériel et planifier des pods présente les avantages suivants :

  • Allocation déclarative des appareils : les administrateurs de plate-forme peuvent définir des configurations d'appareils pour des types de charges de travail ou des équipes spécifiques.
  • Complexité inter-équipes réduite : lorsque les administrateurs de 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 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.
  • Complexité 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 ni de 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 plate-forme peuvent définir de manière centralisée des configurations matérielles qui répondent à des exigences commerciales spécifiques. Par exemple, un administrateur de plate-forme peut déclarer une configuration haute performance avec des GPU H100, ainsi qu'une petite configuration d'inférence avec des GPU Tesla T4.
  • Sélection flexible du matériel : DRA vous permet d'utiliser des expressions CEL pour filtrer les appareils qui possèdent 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 version Preview, la principale raison d'utiliser 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éliorer la disponibilité des GPU : pour les charges de travail qui ont besoin d'accéder au matériel GPU, vous pouvez utiliser DRA pour demander n'importe quel GPU disponible dans le cluster au lieu d'avoir à 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 des 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.
  • Optimiser la disponibilité des nœuds GPU lors du scaling : 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 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 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 DRA suivants :

ResourceSlice
Un ResourceSlice liste un ou plusieurs périphériques 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 de périphérique DRA sur chaque nœud créent des ResourceSlices. Le planificateur Kubernetes utilise des ResourceSlices pour décider des appareils à allouer afin de répondre aux demandes de charge de travail.
DeviceClass
Une DeviceClass définit une catégorie d'appareils, tels que les GPU, qui peuvent être demandés pour les charges de travail. Certains pilotes d'appareils fournissent des DeviceClasses intégrées, comme la DeviceClass gpu.nvidia.com pour les GPU NVIDIA. Les administrateurs de plate-forme peuvent également créer des DeviceClasses personnalisées qui définissent des configurations d'appareil spécifiques.
ResourceClaim

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

Par exemple, imaginons que vous créez un ResourceClaim pour un GPU A100 (40 Go), puis que vous déployez 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 vous avez plusieurs charges de travail qui ont besoin d'accéder à des configurations d'appareils similaires, en particulier lorsque vous utilisez un contrôleur de charge de travail comme Deployments ou StatefulSets.

Les opérateurs d'applications 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 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 illustre les étapes suivies par les administrateurs de cluster et les opérateurs d'application pour allouer des appareils à l'aide de 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 les pilotes de périphériques compatibles avec DRA dans les nœuds.
  2. Les administrateurs de cluster créent des DeviceClasses qui filtrent le matériel répondant à des exigences spécifiques, comme tous les GPU avec plus de 40 Go de mémoire. Certains appareils peuvent également inclure des DeviceClasses intégrées.
  3. Les opérateurs d'applications créent des ResourceClaimTemplates ou des ResourceClaims qui demandent des configurations d'appareil. Voici le principal cas d'utilisation pour chaque type de revendication :
    • Une ResourceClaim permet à plusieurs pods de partager l'accès au 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 aux fichiers manifestes de leurs charges 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 objet ResourceClaim pour chaque instance de la charge de travail (par exemple, chaque réplica d'un déploiement).
  2. Le planificateur Kubernetes utilise les ResourceSlices du cluster pour allouer les appareils disponibles et éligibles à la ResourceClaim de chaque pod.
  3. Le planificateur place chaque pod sur un nœud ayant accès aux appareils qui ont été attribués à la 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 demande de ressources.

Quand utiliser ResourceClaims et ResourceClaimTemplates

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

Si vous créez un ResourceClaim et que vous y faites référence 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 comportant plusieurs répliques. Toutefois, si les appareils attribués ne sont pas configurés pour être partagés par plusieurs processus, cet accès partagé aux appareils entre les pods peut entraîner un comportement inattendu.

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 référencez un ResourceClaimTemplate dans un déploiement comportant plusieurs répliques, Kubernetes crée un ResourceClaim distinct pour chaque pod répliqué. Par conséquent, chaque pod reçoit son propre appareil 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'appareil 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 la création de ResourceClaims par Kubernetes à partir d'un ResourceClaimTemplate :

ResourceClaims créés manuellement ResourceClaims créés automatiquement
Géré par vous Gérés par Kubernetes
Permet d'accéder aux mêmes appareils depuis plusieurs pods Fournit l'accès aux appareils depuis 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 les charges de travail multiples nécessitant un accès indépendant aux appareils

Comparaison de DRA avec l'attribution manuelle des appareils

DRA permet d'allouer des appareils associés de manière similaire au provisionnement dynamique de 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, comme 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 doté 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 en utilisant le 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'appareil. Ils doivent coordonner les demandes de charge de travail pour qu'elles correspondent aux appareils des nœuds, sinon le déploiement échoue. En comparaison, DRA vous permet d'utiliser des expressions pour filtrer de manière flexible les appareils en fonction des attributs. 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 DRA aux plug-ins de périphériques :

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 charges 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 plate-forme Filtrage des appareils isolés par 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 associé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 de certains appareils.

Appareils GKE compatibles avec DRA

Vous pouvez utiliser DRA pour allouer des GPU ou des TPU aux 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 les TPU compatibles avec GKE, consultez les ressources suivantes :

Limites de DRA dans GKE

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

  • Vous ne pouvez pas utiliser DRA avec le provisionnement automatique des nœuds.
  • Vous ne pouvez pas utiliser DRA avec les fonctionnalités de partage de GPU suivantes :
    • GPU à temps partagé.
    • GPU multi-instances.
    • Multi-Process Service (MPS).
  • Vous ne pouvez pas utiliser 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 DRA pour allouer des appareils à des charges de travail. DRA modifie considérablement la méthode de demande d'appareils associés, à la fois dans GKE et dans Kubernetes. Pour bénéficier de cas d'utilisation plus avancés, tels que le basculement 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 dans GKE vous permettent de définir un comportement de remplacement basé sur la priorité que GKE suit lorsqu'il crée des nœuds dans les clusters. Vous pouvez utiliser ComputeClasses pour configurer une série prioritaire de configurations de nœuds et d'appareils que GKE utilise lorsqu'il crée des nœuds pour exécuter des charges de travail. Vous pouvez ensuite utiliser 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 s'exécuter de manière optimale. Vous pouvez créer une ComputeClass qui privilégie la création de nœuds avec un GPU A100 (40 Go), mais qui peut revenir à la création de nœuds avec deux GPU L4 par nœud. Vous pouvez ensuite utiliser 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 ComputeClass, 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, quels que soient le modèle de GPU, le libellé du nœud ou le nombre de GPU.

Pour en savoir plus, consultez les ressources suivantes :

Étapes suivantes