À propos de l'allocation dynamique des ressources dans GKE

Vous pouvez utiliser l'allocation dynamique de ressources (DRA) pour allouer des GPU à vos charges de travail Google Kubernetes Engine (GKE). Ce document explique les principes de base de DRA, comment l'utiliser dans GKE et les avantages de son utilisation.

Ce document est destiné aux rôles suivants :

Vous devez déjà connaître les éléments suivants :

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ées et allouées. 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 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 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'allocation d'appareils aux 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. 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 consiste à utiliser 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 métier 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 : vous pouvez utiliser des expressions CEL pour filtrer les appareils qui possèdent des attributs spécifiques. L'utilisation d'expressions permet de filtrer de manière flexible les appareils qui sont optimaux pour des charges de travail spécifiques.

Quand utiliser DRA ?

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 matière 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 lors du scaling : la quantité d'appareils dont une charge de travail a besoin peut varier en fonction de facteurs tels que le type d'appareil et ses capacités. Vous pouvez utiliser les ComputeClasses GKE pour placer les pods accélérés sur des pools de nœuds spécifiques en fonction de la disponibilité des appareils. Vous pouvez ensuite configurer vos pods pour qu'ils revendiquent les appareils dans n'importe quel nœud sur lequel GKE place les pods.

    L'utilisation de DRA avec ComputeClasses vous permet de minimiser le risque de charges de travail non planifiées tout en vous aidant à exécuter des charges de travail sur du matériel optimisé.

Terminologie

Les fournisseurs Kubernetes Open Source et Kubernetes gérés tels que GKE utilisent les types d'API DRA principaux 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 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 tel que Deployments ou StatefulSets.

Les opérateurs d'applications déploient des ResourceClaimTemplates, puis font référence aux modèles 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.

Pour en savoir plus sur les types d'API DRA, consultez Terminologie DRA.

Fonctionnement de DRA

L'utilisation de DRA dans vos clusters et charges de travail est un processus similaire à 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 des 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 les principaux 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

Vous pouvez utiliser ResourceClaims ou ResourceClaimTemplates pour 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éé la ResourceClaim ou que Kubernetes l'ait créée à 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.

Pour attribuer des appareils distincts aux pods, vous pouvez utiliser un ResourceClaimTemplate, qui est un modèle que Kubernetes utilise pour créer automatiquement des ResourceClaims individuels. 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é. Chaque pod obtient ainsi 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 disposez de 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 la création de ResourceClaims par Kubernetes à partir d'un ResourceClaimTemplate :

Tableau 1. Comparaison entre ResourceClaims et ResourceClaimTemplates
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 Permet d'accéder 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 plusieurs charges de travail 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, à l'aide d'un champ nodeSelector.
    • Spécifiez le nombre exact d'appareils que les conteneurs doivent utiliser 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, et n'oblige pas les opérateurs de charge de travail à connaître la configuration exacte des nœuds du cluster.

Le tableau suivant compare DRA aux plug-ins de périphériques :

Tableau 2. Comparaison de l'allocation d'appareils manuelle et avec DRA
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.

DRA et autoscaling de l'infrastructure

Pour ajuster automatiquement le nombre de nœuds dans un pool de nœuds en mode Standard, vous devez utiliser l'autoscaler de cluster. Vous pouvez activer l'autoscaler de cluster dans tous les pools de nœuds créés manuellement, y compris ceux qui disposent de pilotes DRA.

Pour les pools de nœuds qui utilisent DRA, l'utilisation des appareils affecte la façon dont l'autoscaler de cluster ajoute et supprime des nœuds dans un pool de nœuds. Pour calculer l'utilisation des appareils dans un pool de nœuds, l'autoscaler de cluster prend en compte les facteurs suivants :

  • Tous les appareils d'un pool de ressources doivent être locaux à un nœud spécifique. Si un ResourceSlice comporte un pool d'appareils associés à plusieurs nœuds, l'autoscaler de cluster ignore ces appareils.
  • Tous les appareils du pool de nœuds sont aussi importants et identiques.
  • Les appareils DRA sont prioritaires par rapport au processeur ou à la mémoire. Dans les pools de nœuds DRA, l'autoscaler de cluster ignore l'utilisation du processeur et de la mémoire.

Ces facteurs peuvent entraîner un comportement de scaling à la baisse différent dans les pools de nœuds DRA par rapport aux autres pools de nœuds.

Appareils GKE compatibles avec DRA

Le tableau suivant décrit les appareils que vous pouvez attribuer aux charges de travail avec DRA dans GKE :

Tableau 3. Appareils compatibles avec DRA dans GKE
Appareils compatibles avec DRA
GPU Tout type de GPU disponible dans votre région. Pour en savoir plus, consultez Emplacements des GPU.
Interfaces réseau Plusieurs types d'interfaces réseau, telles que les interfaces compatibles RDMA, en installant le pilote DRANET géré. Pour en savoir plus, consultez Allouer des ressources réseau à l'aide de DRANET géré par GKE.

Limites

Les limites suivantes s'appliquent lorsque vous utilisez DRA :

  • Mode de fonctionnement : DRA n'est disponible que dans les clusters en mode standard.

  • Type d'accélérateur : pendant la preview, DRA dans GKE n'est compatible qu'avec les GPU.

  • GPU :

    • Vous ne pouvez pas utiliser de GPU à temps partagé, de GPU multi-instances ni de service multiprocessus (MPS).
    • Pour les nœuds qui utilisent les pilotes GPU DRA, vous ne pouvez pas utiliser le package de métriques DCGM (NVIDIA Data Center GPU Manager) géré pour envoyer des métriques DCGM à Cloud Monitoring.
    • Le pilote de GPU pour DRA appartient à NVIDIA, et non à GKE. Pour en savoir plus, consultez la documentation NVIDIA.

  • Interfaces réseau (aperçu) : consultez les limites dans "Allouer des ressources réseau à l'aide de DRANET géré par GKE".

  • Autoscaling :

    • Pour les pilotes DRA tiers que vous installez, l'autoscaler de cluster exige que vos pools de nœuds comportent au moins un nœud. Pour empêcher les pools de nœuds qui utilisent des pilotes tiers de passer à zéro nœud, définissez le nombre minimal de nœuds sur au moins 1.
    • Il est possible que l'autoscaler de cluster ne fonctionne pas correctement avec les pilotes DRA tiers. Si vous utilisez des pilotes tiers, vérifiez qu'ils ne publient des informations que pour les appareils locaux à des nœuds spécifiques.
    • Pour les DaemonSets dans les pools de nœuds à autoscaling qui utilisent un ResourceClaim statique pour partager l'accès aux appareils entre les pods, l'autoscaling est compatible avec un maximum de 128 pods DaemonSet. Pour éviter cette limitation, effectuez l'une des opérations suivantes :
    • Si vos pods font référence à des ResourceClaims et ont une PriorityClass qui définit la règle de préemption sur PreemptLowerPriority, la latence de l'autoscaling peut augmenter. PreemptLowerPriority est la règle de préemption par défaut pour PriorityClass. Assurez-vous donc que vos PriorityClasses définissent explicitement le champ preemptionPolicy sur Never. Pour en savoir plus, consultez Non-preempting PriorityClass.

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 :

Étapes suivantes