À 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 fondamentaux de la DRA, comment l'utiliser dans GKE et ses avantages.

Ce document est destiné aux rôles suivants :

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

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 de matériel associé, tel que des accélérateurs, en permettant aux fournisseurs d'appareils et aux administrateurs de plate-forme de déclarer des classes d'appareils qui peuvent être demandées et allouées. Les opérateurs d'applications peuvent demander des configurations d'appareils spécifiques dans ces classes, puis les demander dans leurs charges de travail. Kubernetes et GKE gèrent la planification des pods, les affectations 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 en fonction des exigences de la charge de travail, par exemple en filtrant pour un minimum de 80 Go de mémoire GPU. Lorsque l'opérateur d'applications déploie une charge de travail qui demande la configuration filtrée, GKE place les pods sur des nœuds qui répondent aux critères sélectionnés. Dans cet exemple, GKE trouve des nœuds qui disposent de GPU A100 (80 Go) disponibles. L'opérateur d'applications n'a pas besoin de sélectionner des nœuds ou des configurations d'appareils spécifiques dans le fichier manifeste de la charge de travail.

Avantages de la DRA

Sans la DRA, l'allocation d'appareils matériels dans Kubernetes repose sur des plug-ins d'appareils. Pour associer des ressources matérielles à des pods à l'aide de plug-ins d'appareils, vous utilisez des libellés de nœuds 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 demandez le nombre exact d'appareils associés aux nœuds.

Avec la 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 aux charges de travail. La DRA offre une surface beaucoup plus extensible pour filtrer les appareils en fonction des besoins de l'entreprise et de la charge de travail. L'approche de la 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 d'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é réduite entre les équipes : 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 connaître quels nœuds ont des configurations spécifiques. Les administrateurs de plate-forme n'ont pas besoin de libeller 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 et n'ont pas besoin de s'assurer que chaque pod demande exactement le nombre d'appareils associé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 spécifiques de l'entreprise. Par exemple, un administrateur de plate-forme peut déclarer une configuration hautes performances 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 offre la possibilité de filtrer les appareils qui sont optimaux pour des charges de travail spécifiques.

Quand utiliser la DRA

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éliorer la disponibilité des GPU : pour les charges de travail qui ont besoin d'accéder au matériel GPU, vous pouvez utiliser la 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 requise par une charge de travail peut varier en fonction de facteurs tels que le type d' appareil et ses capacités. Vous pouvez utiliser les ComputeClasses GKE pour placer des 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 de n'importe quel nœud sur lequel GKE les place.

    L'utilisation de la DRA avec les 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

Kubernetes Open Source et les fournisseurs Kubernetes gérés tels que GKE utilisent les types d'API DRA principaux suivants :

ResourceSlice
Une ResourceSlice répertorie un ou plusieurs appareils matériels du cluster auxquels les nœuds peuvent accéder. Par exemple, dans un nœud qui peut accéder à un seul GPU, la ResourceSlice répertorie le GPU et le nom du nœud. Les pilotes d'appareils DRA de chaque nœud créent des ResourceSlices. Le planificateur Kubernetes utilise les ResourceSlices pour décider des appareils à allouer afin de répondre aux requêtes de charge de travail.
DeviceClass
Une DeviceClass définit une catégorie d'appareils, tels que des GPU, qui peuvent être demandés pour les charges de travail. Certains pilotes d'appareils fournissent des DeviceClasses intégrées, telles que 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'appareils 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 référence une ResourceClaim, Kubernetes attribue à cette ResourceClaim les appareils qui correspondent aux paramètres spécifiés.

Prenons l'exemple d'un scénario dans lequel vous créez une ResourceClaim pour un GPU A100 (40 Go), puis déployez une charge de travail qui sélectionne cette ResourceClaim. Kubernetes attribue un GPU A100 (40 Go) disponible à la ResourceClaim et planifie votre pod sur un nœud qui peut 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 doivent 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'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 correspondantes.

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

Fonctionnement de la DRA

L'utilisation de la DRA dans vos clusters et charges de travail est un processus semblable à celui qui consiste à utiliser des StorageClasses, des PersistentVolumeClaims et des PersistentVolumes pour provisionner dynamiquement des volumes pour les pods.

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

Dans ce schéma, les administrateurs de cluster et les opérateurs d'applications 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 répondant à des exigences spécifiques, telles que 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'appareils. Le cas d'utilisation principal pour chaque type de revendication est le suivant :
    • 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'applications ajoutent les ResourceClaimTemplates ou les ResourceClaims à leurs fichiers manifestes de charge de travail.
  5. Les opérateurs d'applications déploient la charge de travail.

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

  1. Si la charge de travail référence un ResourceClaimTemplate, Kubernetes crée un objet ResourceClaim pour chaque instance de la charge de travail (par exemple, chaque instance répliquée dans un déploiement).
  2. Le planificateur Kubernetes utilise les ResourceSlices du cluster pour allouer des appareils disponibles et éligibles à la ResourceClaim de chaque pod.
  3. Le planificateur place chaque pod sur un nœud qui a accès aux appareils alloués à la ResourceClaim du pod.
  4. Le kubelet du 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 des ResourceClaims et des ResourceClaimTemplates

Vous pouvez utiliser des ResourceClaims ou des 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 une ResourceClaim, puis la référencez dans plusieurs pods, tous ces pods peuvent accéder aux appareils que Kubernetes alloue pour cette ResourceClaim. Par exemple, cet accès partagé peut se produire si vous référencez une ResourceClaim spécifique dans un fichier manifeste de déploiement comportant plusieurs instances répliquées. Toutefois, si les appareils alloué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 allouer des appareils distincts aux pods, vous pouvez utiliser un ResourceClaimTemplate, qui est un modèle que Kubernetes utilise pour créer automatiquement des ResourceClaims individuelles. Par exemple, si vous référencez un ResourceClaimTemplate dans un déploiement comportant plusieurs instances répliquées, Kubernetes crée une ResourceClaim distincte pour chaque pod répliqué. Par conséquent, chaque pod reçoit son propre appareil alloué au lieu de partager l'accès à l'appareil avec d'autres pods. Ces ResourceClaims générées automatiquement sont liées à la durée de vie du pod correspondant et sont supprimées lorsque le pod s'arrête. Si vous disposez de pods indépendants qui doivent 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 des ResourceClaims et des ResourceClaimTemplates
ResourceClaims créées manuellement ResourceClaims créées 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 qui ont besoin d'un accès indépendant aux appareils

Comparaison de la DRA avec l'allocation manuelle d'appareils

La DRA rend l'allocation d'appareils associés semblable au provisionnement dynamique de PersistentVolumes. Kubernetes est également compatible avec l'allocation d'appareils à l'aide de plug-ins d'appareils. Cette méthode comporte les étapes suivantes :

  1. Un administrateur de cluster crée des nœuds auxquels des appareils sont associés, comme des GPU.
  2. L'administrateur de 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 qui possè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 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'applications et les administrateurs de cluster communiquent sur les nœuds ou les pools de nœuds spécifiques qui possèdent 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 de leurs attributs, et ne nécessite pas que les opérateurs de charge de travail connaissent la configuration exacte des nœuds du cluster.

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

Tableau 2. Comparaison de la DRA et de l'allocation manuelle d'appareils
DRA Allocation 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 requêtes 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 plate-forme Filtrage isolé des appareils par les opérateurs d'applications
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 possèdent des modèles et des quantités spécifiques de certains appareils associés.

DRA et autoscaling de l'infrastructure

Pour ajuster automatiquement le nombre de nœuds dans un pool de nœuds en mode Standard, vous utilisez l' autoscaler de cluster. Vous pouvez activer l'autoscaler de cluster dans n'importe quel pool de nœuds créé manuellement, y compris les pools de nœuds qui comportent des pilotes DRA.

Pour les pools de nœuds qui utilisent la 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 une 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 la DRA

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

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

Limites

Les limites suivantes s'appliquent lorsque vous utilisez la DRA :

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

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

  • GPU:

  • Interfaces réseau: consultez la section 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 nécessite que vos pools de nœuds comportent au moins un nœud. Pour éviter que les pools de nœuds qui utilisent des pilotes tiers ne soient réduits à zéro nœud, définissez le nombre minimal de nœuds sur au moins 1.
    • L'autoscaler de cluster peut ne pas fonctionner 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 avec autoscaling qui utilisent une ResourceClaim statique pour partager l'accès aux appareils entre les pods, l'autoscaling est compatible avec un maximum de 128 pods DaemonSet. Pour contourner cette limitation, effectuez l'une des opérations suivantes :
      • Empêchez le pool de nœuds de passer à plus de 128 nœuds en définissant le nombre maximal de nœuds.
      • Utilisez le adminAccess champ (bêta), dans la ResourceClaim, qui permet au DaemonSet d'accéder aux appareils qui sont en cours d'utilisation.
    • Si vos pods référencent des ResourceClaims et disposent d'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 la section PriorityClass sans préemption.

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 aux charges de travail. La 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, tenez compte des conseils suivants :

Étape suivante