À propos des classes de calcul personnalisées

Cette page explique comment utiliser des classes de calcul personnalisées pour contrôler les propriétés des nœuds que Google Kubernetes Engine (GKE) provisionne lors de l'autoscaling de votre cluster. Ce document s'adresse aux administrateurs de plate-forme qui souhaitent définir de manière déclarative des profils d'autoscaling pour les nœuds, afin que des charges de travail spécifiques s'exécutent sur du matériel répondant à leurs exigences.

Présentation des classes de calcul

Dans GKE, une classe de calcul est un profil constitué d'un ensemble d'attributs de nœud que GKE utilise pour provisionner les nœuds qui exécutent vos charges de travail lors des événements d'autoscaling. Les classes de calcul peuvent cibler des optimisations spécifiques, comme le provisionnement de nœuds hautes performances ou la priorité accordée aux configurations optimisées pour les coûts afin de réduire les coûts d'exécution. Les classes de calcul personnalisées vous permettent de définir des profils que GKE utilise ensuite pour mettre à l'échelle automatique des nœuds afin de répondre précisément aux exigences de charges de travail spécifiques.

Les classes de calcul personnalisées sont disponibles en mode Autopilot et Standard GKE dans la version 1.30.3-gke.1451000 et ultérieures. Elles offrent une approche déclarative pour définir les attributs de nœud et les priorités d'autoscaling. Les classes de calcul personnalisées peuvent être configurées et utilisées par défaut dans tous les clusters GKE éligibles.

Avantages des classes de calcul personnalisées

Les classes de calcul personnalisées offrent les avantages suivants :

  • Priorités de calcul de remplacement : définissez une hiérarchie de configurations des nœuds dans chaque classe de calcul pour que GKE puisse les hiérarchiser. Si la configuration la plus appropriée n'est pas disponible, GKE choisit automatiquement la configuration suivante dans la hiérarchie. Ce modèle de remplacement garantit que même lorsque les ressources de calcul ne sont pas disponibles, vos charges de travail s'exécutent toujours sur du matériel optimisé avec des délais de planification minimes.
  • Contrôle granulaire de l'autoscaling : définissez les configurations de nœuds les mieux adaptées à des charges de travail spécifiques. GKE donne la priorité à ces configurations lors de la création de nœuds pendant le scaling.
  • Configuration déclarative de l'infrastructure : adoptez une approche déclarative de la gestion de l'infrastructure afin que GKE crée automatiquement des nœuds qui répondent aux exigences de vos charges de travail spécifiques.
  • Migration active : si des ressources de calcul pour une configuration de machine plus appropriée deviennent disponibles dans votre emplacement, GKE migre automatiquement vos charges de travail vers de nouveaux nœuds qui utilisent la configuration de votre choix.
  • Optimisation des coûts : privilégiez les types de nœuds économiques, tels que les VM Spot, pour réduire les dépenses liées à votre cluster.
  • Classes de calcul par défaut pour les espaces de noms : définissez une classe de calcul par défaut dans chaque espace de noms Kubernetes afin que les charges de travail de cet espace de noms s'exécutent sur un matériel optimisé, même si elles ne demandent pas de classe de calcul spécifique.
  • Seuils de consolidation de nœuds personnalisés : définissez des seuils d'utilisation de ressources personnalisées pour les nœuds. Si l'utilisation des ressources d'un nœud spécifique est inférieure à votre seuil, GKE tente de regrouper les charges de travail sur un nœud disponible semblable et réduit la capacité du nœud sous-utilisé.

Cas d'utilisation des classes de calcul personnalisées

Envisagez d'utiliser des classes de calcul personnalisées dans les scénarios suivants :

  • Vous souhaitez exécuter vos charges de travail d'IA/ML sur des configurations de GPU ou de TPU spécifiques.
  • Vous souhaitez définir des configurations matérielles par défaut pour les charges de travail exécutées par des équipes spécifiques, en évitant les frais généraux des opérateurs d'applications.
  • Vous exécutez des charges de travail qui fonctionnent de manière optimale sur des configurations matérielles ou des séries de machines Compute Engine spécifiques.
  • Vous souhaitez déclarer des configurations matérielles qui répondent à des exigences commerciales spécifiques, telles que les performances élevées, l'optimisation des coûts ou la haute disponibilité.
  • Vous souhaitez que GKE effectue un remplacement hiérarchique vers des configurations matérielles spécifiques en cas d'indisponibilité des ressources de calcul, afin que vos charges de travail s'exécutent toujours sur des machines adaptées à leurs exigences.
  • Vous souhaitez définir de manière centralisée les configurations optimales pour le parc de votre entreprise, afin que vos coûts soient plus prévisibles et que vos charges de travail s'exécutent de manière plus fiable.
  • Vous souhaitez spécifier de manière centralisée les réservations de capacité Compute Engine que GKE doit utiliser pour provisionner de nouveaux nœuds pour des charges de travail spécifiques.

Fonctionnement des classes de calcul personnalisées

Les classes de calcul personnalisées sont des ressources personnalisées Kubernetes qui provisionnent l'infrastructureGoogle Cloud . Vous définissez un objet ComputeClass dans le cluster, puis vous demandez cette classe de calcul dans les charges de travail ou vous la définissez comme valeur par défaut pour un espace de noms Kubernetes. Lorsqu'une charge de travail correspondante nécessite une nouvelle infrastructure, GKE provisionne de nouveaux nœuds conformément aux priorités que vous définissez dans la définition de votre classe de calcul.

Les attributs que vous définissez dans vos classes de calcul déterminent la façon dont GKE configure les nouveaux nœuds pour exécuter des charges de travail. Lorsque vous modifiez une classe de calcul existante, tous les futurs nœuds que GKE crée pour cette classe de calcul utilisent la configuration modifiée. GKE ne modifie pas rétroactivement la configuration des nœuds existants pour qu'elle corresponde à vos modifications.

Pour vous assurer que vos classes de calcul personnalisées sont optimisées pour votre parc, tenez compte des consignes suivantes :

  • Comprenez les exigences de calcul de votre parc, y compris les exigences matérielles spécifiques à l'application.
  • Définissez un thème qui guide la conception de chaque classe de calcul. Par exemple, une classe de calcul optimisée pour les performances peut avoir une stratégie de remplacement qui n'utilise que des types de machines à haute capacité de processeur.
  • Déterminez la famille et la série de machines Compute Engine qui correspondent le mieux à vos charges de travail. Pour en savoir plus, consultez le Guide des ressources de familles de machines et guide comparatif.
  • Planifiez une stratégie de remplacement dans chaque classe de calcul afin que les charges de travail s'exécutent toujours sur des nœuds qui utilisent des configurations de machine similaires. Par exemple, si la série de machines N4 n'est pas disponible, vous pouvez utiliser des machines N2.

Afficher la définition complète de ressource personnalisée

Pour afficher la dernière définition de ressource personnalisée (CRD) de la ressource personnalisée ComputeClass, y compris tous les champs et leurs relations, consultez la documentation de référence sur ComputeClass.

Vous pouvez également afficher le CRD dans votre cluster en exécutant la commande suivante:

kubectl describe crd computeclasses.cloud.google.com

Planifier une classe de calcul personnalisée

Pour planifier, déployer et utiliser efficacement une classe de calcul personnalisée dans votre cluster, procédez comme suit :

  1. Choisissez vos priorités de calcul de remplacement : définissez une série de règles qui régissent les propriétés des nœuds créés par GKE pour la classe de calcul.
  2. Configurez des pools de nœuds et des classes de calcul GKE Standard : pour les clusters en mode Standard, suivez les étapes de configuration requises afin d'utiliser la classe de calcul avec vos pools de nœuds.
  3. Définissez le comportement de scaling lorsqu'aucune règle de priorité ne s'applique : vous pouvez indiquer à GKE ce qu'il doit faire si les nœuds qui respectent vos règles de priorité ne peuvent pas être provisionnés.
  4. Définissez les paramètres d'autoscaling pour la consolidation des nœuds : indiquez à GKE quand consolider les charges de travail et supprimer les nœuds sous-utilisés.
  5. Configurez la migration active vers des nœuds de priorité supérieure : vous pouvez indiquer à GKE de déplacer les charges de travail vers des nœuds préférés à mesure que le matériel devient disponible.
  6. Consommer des réservations Compute Engine: vous pouvez demander à GKE de consommer les réservations zonales Compute Engine existantes lorsque vous créez des nœuds.

Choisir vos priorités de calcul de remplacement

Le principal avantage de l'utilisation d'une classe de calcul personnalisée est de pouvoir contrôler la stratégie de remplacement lorsque vos nœuds préférés ne sont pas disponibles en raison de facteurs tels que l'épuisement des ressources et les limites de quota.

Pour créer une stratégie de remplacement, définissez une liste de règles de priorité dans votre classe de calcul personnalisée. Lorsqu'un cluster doit effectuer un scaling à la hausse, GKE donne la priorité à la création de nœuds correspondant à la première règle de priorité. Si GKE ne peut pas créer ces nœuds, il revient à la règle de priorité suivante, en répétant ce processus jusqu'à ce que GKE ait réussi à effectuer le scaling à la hausse du cluster ou à épuiser toutes les règles. Si toutes les règles sont épuisées, GKE crée des nœuds en fonction du comportement par défaut ou spécifié décrit dans la section Définissez le comportement de scaling lorsqu'aucune règle de priorité ne s'applique.

Les différentes séries de machines Compute Engine sont compatibles avec différentes technologies et fonctionnalités. Les générations antérieures d'une série de machines peuvent ne pas être compatibles avec les mêmes types de stockage que les générations plus récentes. Si vous exécutez des charges de travail avec état qui reposent sur des données persistantes, évitez d'utiliser une classe de calcul couvrant plusieurs générations d'une série de machines. Les charges de travail ne pourront peut-être pas accéder aux données persistantes si GKE les place sur un type de machine qui n'est pas compatible avec ce type de stockage. Pour en savoir plus, filtrez le tableau de comparaison des séries de machines en fonction de types de stockage spécifiques.

Règles de priorité

Vous définissez des règles de priorité dans le champ spec.priorities de la ressource personnalisée ComputeClass. Chaque règle du champ priorities décrit les propriétés des nœuds à provisionner. GKE traite le champ priorities dans l'ordre, ce qui signifie que le premier élément du champ est la priorité la plus élevée pour le provisionnement de nœuds.

Il existe deux types de règles de priorité:

  • Types de règles déclaratives: utilisez les caractéristiques des nœuds pour décrire les nœuds que vous souhaitez provisionner.

  • Type de règle de pool de nœuds: dans les clusters GKE Standard, fournit la liste des pools de nœuds créés manuellement et associés à la classe de calcul dans laquelle GKE doit provisionner des nœuds.

Règles de priorité déclaratives

Avec les règles de priorité déclaratives, vous pouvez spécifier des propriétés de machine (famille ou type de machine, VM Spot, options d'accélérateur, options de stockage, réservations et exigences minimales en termes de ressources) que GKE utilisera lors du provisionnement des nœuds. Pour obtenir la liste complète des champs compatibles, consultez la documentation de référence sur le CRD ComputeClass.

Configurations machineFamily

Le champ machineFamily accepte une série de machines Compute Engine telle que n2 ou c3. Si non spécifiée, la valeur par défaut est e2.

Vous pouvez utiliser d'autres champs spec.priorities avec le champ machineFamily pour définir de manière déclarative vos exigences de calcul, par exemple:

  • spot : VM Spot. La valeur par défaut est false.
  • minCores : nombre minimal de vCPU par nœud. La valeur par défaut est 0.
  • minMemoryGb : mémoire minimale par nœud. La valeur par défaut est 0.
  • storage.bootDiskKMSKey : chemin d'accès à la clé Cloud Key Management Service à utiliser pour le chiffrement du disque de démarrage.
  • storage.secondaryBootDisks: disques persistants utilisés pour précharger des données dans les nœuds GKE, comme un modèle de machine learning (ML) ou une image de conteneur. Nécessite la version 1.31.2-gke.1105000 de GKE ou une version ultérieure. Pour configurer un disque de démarrage secondaire à utiliser par votre cluster, consultez la section Configurer des disques de démarrage secondaires.
    • storage.secondaryBootDisks.diskImageName: nom de l'image disque à précharger.
    • storage.secondaryBootDisks.project: nom du projet auquel appartient l'image disque. Si cette valeur n'est pas spécifiée, votre projet de cluster est utilisé par défaut.
    • storage.secondaryBootDisks.mode: mode dans lequel le disque de démarrage secondaire doit être utilisé. Si cette valeur est définie sur CONTAINER_IMAGE_CACHE, le disque de démarrage secondaire est utilisé comme cache d'image de conteneur. La valeur doit être égale à CONTAINER_IMAGE_CACHE ou MODE_UNSPECIFIED. Si cette valeur n'est pas spécifiée, la valeur par défaut est MODE_UNSPECIFIED.

L'exemple suivant montre une règle de priorité qui utilise machineFamily:

priorities:
- machineFamily: n2
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset
Configurations machineType

Le champ machineType accepte un type de machine prédéfini Compute Engine, tel que n2-standard-32.

Vous pouvez spécifier d'autres champs spec.priorities à côté du champ machineType pour définir de manière déclarative vos exigences de calcul, par exemple:

  • spot : utiliser des VM Spot. La valeur par défaut est false.
  • storage : configurer le stockage de nœuds.
    • storage.bootDiskType : type de disque de démarrage.
    • storage.bootDiskKMSKey : chemin d'accès à la clé Cloud KMS à utiliser pour le chiffrement du disque de démarrage.
    • storage.bootDiskSize : taille en Go du disque de démarrage du nœud.
    • storage.localSSDCount : nombre de SSD locaux à associer au nœud. Si elle est spécifiée, la valeur doit être supérieure ou égale à 1.

L'exemple suivant montre une règle de priorité qui utilise machineType pour provisionner des types de machines n2-standard-32:

priorities:
- machineType: n2-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
Configuration du GPU

Pour sélectionner des GPU dans vos règles de priorité, spécifiez le type, le nombre et la version du pilote (facultatif) du GPU dans le champ gpu d'une règle de priorité. Les champs suivants sont acceptés:

Vous pouvez également spécifier d'autres champs spec.priorities tels que les VM Spot, les options de stockage et les réservations en combinaison avec les champs gpu.

L'exemple suivant montre une règle pour les GPU:

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true
Configuration du TPU

Nécessite la version 1.31.2-gke.1518000 de GKE ou une version ultérieure

Pour sélectionner des TPU dans vos règles de priorité, spécifiez le type, le nombre et la topologie du TPU dans le champ tpu d'une règle de priorité. Les champs suivants sont obligatoires :

Vous pouvez également spécifier d'autres champs spec.priorities avec le champ tpu dans votre règle de priorité, par exemple:

  • spot : utiliser des VM Spot. La valeur par défaut est false.
  • storage : configurer le stockage de nœuds.
    • storage.bootDiskType : type de disque de démarrage.
    • storage.bootDiskKMSKey: chemin d'accès à la clé Cloud KMS à utiliser pour le chiffrement du disque de démarrage.
    • storage.bootDiskSize : taille en Go du disque de démarrage du nœud.
  • reservations: utilisez une réservation Compute Engine. Pour en savoir plus, consultez la section Consommer des réservations Compute Engine.

L'exemple suivant montre une règle pour les TPU:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

Cet exemple définit le comportement de remplacement suivant:

  1. GKE tente de provisionner une tranche TPU v5p multi-hôte de 16 nœuds en consommant une réservation Compute Engine partagée appelée tpu-reservation à partir du projet reservation-project.
  2. Si aucun TPU n'est disponible pour la réservation, GKE tente de provisionner une tranche TPU v5p multi-hôte à 16 nœuds exécutée sur des VM Spot.
  3. Si aucune des règles précédentes ne peut être appliquée, GKE suit la logique décrite dans la section Définissez le comportement de scaling lorsqu'aucune règle de priorité ne s'applique.

Après avoir déployé une classe de calcul personnalisée TPU sur votre cluster, sélectionnez-la dans votre charge de travail:

Spécifications des accélérateurs et de la forme de la machine

Les configurations d'accélérateur déclaratives ne nécessitent pas de spécifier explicitement le champ machineType ou machineFamily, sauf si vous les utilisez en combinaison avec des réservations.

Règles de priorité des pools de nœuds

Le champ nodepools contient une liste de pools de nœuds existants sur lesquels GKE tente de créer des pods en attente. GKE ne traite pas les valeurs de ce champ dans l'ordre. Vous ne pouvez pas utiliser d'autres champs spec.priorities avec le champ nodepools dans le même élément de règle de priorité, car les règles avec le champ nodepools ne sont pas de nature déclarative. Ce champ n'est compatible qu'avec le mode GKE Standard. Pour en savoir plus sur l'utilisation, consultez la section Ciblez des pools de nœuds spécifiques dans une définition de classe de calcul.

Comment GKE crée-t-il des nœuds à l'aide de règles de priorité ?

Lorsque vous déployez une charge de travail qui demande une classe de calcul et qu'un nouveau nœud est nécessaire, GKE traite la liste des règles dans le champ priorities de la spécification ComputeClass dans l'ordre.

Prenons l'exemple de la spécification suivante :

spec:
  ...
  priorities:
  - machineFamily: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false

Lorsque vous déployez une charge de travail qui demande une classe de calcul avec ces règles de priorité, GKE associe les nœuds comme suit :

  1. GKE place les pods sur tous les nœuds existants associés à cette classe de calcul.
  2. Si les nœuds existants ne peuvent pas accueillir les pods, GKE provisionne de nouveaux nœuds qui utilisent la série de machines N2, sont des VM Spot et disposent d'au moins 64 vCPU.
  3. Si des VM Spot N2 avec au moins 64 vCPU ne sont pas disponibles dans la région, GKE provisionne de nouveaux nœuds qui utilisent des VM Spot N2 pouvant accueillir les pods, quel que soit le nombre de cœurs.
  4. Si aucune VM Spot N2 n'est disponible dans la région, GKE provisionne de nouvelles VM N2 à la demande.
  5. Si aucune des règles précédentes ne peut être appliquée, GKE suit la logique décrite dans la section Définissez le comportement de scaling lorsqu'aucune règle de priorité ne s'applique.

Valeurs par défaut pour les règles de priorité

Vous pouvez définir des valeurs par défaut pour certains des champs des règles de priorité de votre spécification ComputeClass. Ces valeurs par défaut s'appliquent si les champs correspondants d'une règle spécifique sont omis. Vous pouvez définir ces valeurs par défaut à l'aide du champ priorityDefaults dans la spécification ComputeClass.

Le champ priorityDefaults présente les limites suivantes:

  • Nécessite la version 1.32.1-gke.1729000 de GKE ou une version ultérieure.
  • N'est pas compatible avec la règle de priorité nodepools, qui ne contient aucun champ.

Pour en savoir plus sur les types de valeurs par défaut que vous pouvez définir, consultez la section priorityDefaults dans la CustomResourceDefinition ComputeClass.

Pools de nœuds et classes de calcul GKE Standard

Si vous utilisez le mode Standard de GKE, vous devrez peut-être effectuer une configuration manuelle pour vous assurer que les pods de votre classe de calcul sont planifiés comme prévu.

  • Pools de nœuds gérés par provisionnement automatique des nœuds : aucune configuration manuelle n'est requise. Le provisionnement automatique des nœuds effectue automatiquement les étapes de configuration de la classe de calcul à votre place. Pour en savoir plus, consultez la section Provisionnement automatique des nœuds et des classes de calcul.
  • Pools de nœuds créés manuellement : une configuration manuelle est requise. Vous devez ajouter des étiquettes de nœuds et des rejets de nœuds à vos pools de nœuds créés manuellement pour associer les nœuds à une classe de calcul spécifique. Pour en savoir plus, consultez la page Configurer des pools de nœuds créés manuellement pour une classe de calcul.

Configurer des pools de nœuds créés manuellement pour une classe de calcul

Si vos clusters GKE Standard comportent des pools de nœuds que vous avez créés manuellement sans provisionnement automatique des nœuds, vous devez configurer ces pools de nœuds pour les associer à des classes de calcul spécifiques. GKE planifie uniquement les pods qui demandent une classe de calcul spécifique sur les nœuds des pools de nœuds que vous associez à cette classe de calcul. Les pools de nœuds en mode Autopilot et en mode Standard GKE créés par le provisionnement automatique effectuent automatiquement cette configuration pour vous.

Pour associer un pool de nœuds créé manuellement à une classe de calcul, vous devez ajouter des étiquettes de nœuds et des rejets de nœuds au pool de nœuds lors de sa création ou de sa mise à jour en spécifiant les options --node-labels et --node-taints, comme suit :

  • Étiquette de nœud : cloud.google.com/compute-class=COMPUTE_CLASS
  • Rejet : cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

Dans ces attributs, COMPUTE_CLASS est le nom de votre classe de calcul personnalisée.

Par exemple, les commandes suivantes mettent à jour un pool de nœuds existant et l'associent à la classe de calcul dev-class:

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class"

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

Vous pouvez associer chaque pool de nœuds de votre cluster à une classe de calcul personnalisée. Les pods que GKE planifie sur ces pools de nœuds créés manuellement ne déclenchent la création de nœuds que dans ces pools de nœuds lors des événements d'autoscaling.

Provisionnement automatique des nœuds et des classes de calcul

Vous pouvez utiliser le provisionnement automatique des nœuds avec une classe de calcul personnalisée pour permettre à GKE de créer et de supprimer automatiquement des pools de nœuds en fonction de vos règles de priorité.

Pour utiliser le provisionnement automatique des nœuds avec une classe de calcul, procédez comme suit :

  1. Assurez-vous que le provisionnement automatique des nœuds est activé dans votre cluster.
  2. Ajoutez le champ nodePoolAutoCreation avec la valeur enabled: true à votre spécification ComputeClass.

GKE peut ensuite placer des pods qui utilisent des classes de calcul qui configurent le provisionnement automatique des nœuds sur de nouveaux pools de nœuds. GKE décide d'effectuer un scaling à la hausse d'un pool de nœuds existant ou d'en créer un en fonction de facteurs tels que la taille des clusters et les exigences des pods. Les pods dont les classes de calcul ne configurent pas le provisionnement automatique des nœuds continuent d'effectuer le scaling à la hausse des pools de nœuds existants.

Vous pouvez utiliser des classes de calcul qui interagissent avec le provisionnement automatique des nœuds en même temps que des classes de calcul qui interagissent avec des pools de nœuds créés manuellement dans le même cluster.

Considérons les interactions suivantes avec le provisionnement automatique des nœuds :

  • Vous ne pouvez pas utiliser les sélecteurs de nœuds famille de machines ou VM Spot, car ils sont en conflit avec le comportement de la classe de calcul. GKE rejette tous les pods qui demandent une classe de calcul et des VM Spot ou des séries de machines spécifiques.
  • Vous pouvez configurer le provisionnement automatique des nœuds pour les classes de calcul qui utilisent le champ nodepools pour référencer les pools de nœuds existants. Le provisionnement automatique des nœuds traite les priorités dans l'ordre et tente d'effectuer un scaling à la hausse des pools de nœuds existants pour y placer vos pods.

Prenons l'exemple suivant d'un cluster qui comporte à la fois des pools de nœuds créés manuellement et le provisionnement automatique des nœuds :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n2
  - machineFamily: n2d
  nodePoolAutoCreation:
    enabled: true

Dans cet exemple, GKE tente d'effectuer les opérations suivantes :

  1. Créer des nœuds dans le pool de nœuds manually-created-pool
  2. Provisionner des nœuds N2, soit dans des pools de nœuds N2 existants, soit en créant un pool de nœuds
  3. Si GKE ne peut pas créer de nœuds N2, il tente d'augmenter la taille des pools de nœuds N2D existants ou de créer des pools de nœuds N2D

Cibler des pools de nœuds spécifiques dans une définition de classe de calcul

Le champ priorities.nodepools vous permet de spécifier une liste de pools de nœuds créés manuellement sur lesquels GKE tente de planifier des pods sans ordre spécifique dans les clusters GKE Standard qui utilisent l'autoscaling de cluster. Ce champ n'accepte qu'une liste de pools de nœuds. Vous ne pouvez pas spécifier de propriétés de machine supplémentaires, comme la série de machines, dans la même règle de priorité. Lorsque vous déployez une charge de travail qui demande une classe de calcul avec des pools de nœuds nommés, GKE tente de planifier les pods en attente dans ces pools de nœuds. GKE peut créer des nœuds dans ces pools de nœuds pour y placer les pods.

Les pools de nœuds que vous spécifiez dans le champ priorities.nodepools doivent être associés à cette classe de calcul à l'aide d'étiquettes de nœuds et de rejets de nœuds, comme décrit dans la section Configurer des pools de nœuds créés manuellement pour les classes de calcul.

La liste des pools de nœuds que vous spécifiez dans le champ nodepools n'a pas de priorité. Pour configurer une commande de remplacement pour les pools de nœuds nommés, vous devez spécifier plusieurs éléments priorities.nodepools distincts. Prenons l'exemple de la spécification suivante :

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

Dans cet exemple, GKE tente d'abord de placer les pods en attente qui demandent cette classe de calcul sur des nœuds existants dans des pools de nœuds étiquetés avec la classe de calcul. Si les nœuds existants ne sont pas disponibles, GKE tente de provisionner de nouveaux nœuds dans pool1 ou pool2. Si GKE ne peut pas provisionner de nouveaux nœuds dans ces pools de nœuds, il tente de provisionner de nouveaux pods dans pool3.

Définir le comportement de scaling lorsqu'aucune règle de priorité ne s'applique

La ressource personnalisée ComputeClass vous permet de spécifier ce que GKE doit faire s'il n'existe aucun nœud capable de respecter l'une des règles de priorité. Le champ whenUnsatisfiable de la spécification accepte les valeurs suivantes.

  • ScaleUpAnyway : créer un nœud qui utilise la configuration de machine par défaut du cluster. Dans les versions de GKE antérieures à la version 1.33, il s'agit du comportement par défaut si vous omettez ce champ.

    GKE effectue l'une des actions suivantes:

    • Dans les clusters Autopilot, GKE place le pod sur un nœud nouveau ou existant, quelle que soit la configuration de la machine de nœud.
    • Dans les clusters Standard qui n'utilisent pas le provisionnement automatique des nœuds, GKE tente d'effectuer un scaling à la hausse de tout pool de nœuds créé manuellement qui définit une étiquette et un rejet correspondant à une classe de calcul donnée.
    • Dans les clusters Standard qui utilisent le provisionnement automatique des nœuds, GKE peut créer un pool de nœuds qui utilise la série de machines E2 par défaut pour placer le pod.

  • DoNotScaleUp : laisser le pod à l'état Pending jusqu'à ce qu'un nœud répondant aux exigences de la classe de calcul soit disponible. Dans GKE 1.33 et versions ultérieures, il s'agit du comportement par défaut si vous omettez ce champ.

Définir les paramètres d'autoscaling pour la consolidation des nœuds

Par défaut, GKE supprime les nœuds sous-utilisés en exécutant des charges de travail, les consolidant sur d'autres nœuds disposant de la capacité nécessaire. Pour toutes les classes de calcul, il s'agit du comportement par défaut, car tous les clusters qui utilisent des classes de calcul doivent utiliser l'autoscaler de cluster ou sont des clusters Autopilot. Lors d'une consolidation de nœuds, GKE draine un nœud sous-utilisé, recrée les charges de travail sur un autre nœud, puis supprime le nœud drainé.

Le moment et les critères de suppression des nœuds dépendent du profil d'autoscaling. Vous pouvez ajuster les seuils de sous-utilisation des ressources qui déclenchent la suppression des nœuds et la consolidation des charges de travail à l'aide de la section autoscalingPolicy de votre définition de classe de calcul personnalisée. Vous pouvez ajuster les paramètres suivants :

  • consolidationDelayMinutes : nombre de minutes après lesquelles GKE supprime les nœuds sous-utilisés
  • consolidationThreshold : seuil d'utilisation du processeur et de la mémoire en pourcentage des ressources disponibles du nœud. GKE ne prend en compte les nœuds pour la suppression que si l'utilisation des ressources est inférieure à ce seuil.
  • gpuConsolidationThreshold : seuil d'utilisation du GPU exprimé en pourcentage des ressources disponibles du nœud. GKE ne prend en compte les nœuds pour la suppression que si l'utilisation des ressources est inférieure à ce seuil. Envisagez de définir cette valeur sur 100 ou 0 afin que GKE consolide tous les nœuds dont l'utilisation des GPU associés n'est pas de 100 %.

Prenons l'exemple suivant :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

Dans cette configuration, GKE supprime les nœuds inutilisés au bout de cinq minutes. Les nœuds ne deviennent candidats à la consolidation que si leur utilisation du processeur et de la mémoire est inférieure à 70 %.

Configurer la migration active vers des nœuds de priorité supérieure

La migration active est une fonctionnalité d'autoscaling facultative dans les classes de calcul personnalisées qui remplace automatiquement les nœuds existants qui se trouvent plus bas dans une liste de priorité de remplacement de classe de calcul par de nouveaux nœuds situés plus haut dans cette liste. Cela garantit que tous vos pods opérationnels s'exécutent finalement sur vos nœuds préférés pour cette classe de calcul, même si GKE devait initialement exécuter ces pods sur des nœuds avec un classement inférieur.

Lorsqu'une migration active se produit, GKE crée des nœuds en fonction des règles de priorité de la classe de calcul, puis vide et supprime les nœuds obsolètes de priorité inférieure. La migration se fait progressivement pour minimiser les interruptions de la charge de travail. La migration active présente les considérations suivantes :

  • La migration active ne migre pas les données stockées dans un espace de stockage persistant, comme les disques persistants Compute Engine. Pour minimiser le risque de perte de données, ne pas activer la migration active dans les classes de calcul utilisées par les charges de travail avec état.
  • Si vous avez activé le provisionnement automatique des nœuds sur vos clusters Standard, la migration active peut déclencher la création de pools de nœuds si les pools de nœuds existants ne répondent pas aux critères de priorité supérieure définis dans votre classe de calcul personnalisée.
  • Pour éviter toute interruption de charge de travail critique, la migration active ne déplace pas les pods suivants :
    • Pods qui définissent un PodDisruptionBudget, si le déplacement dépasse le PodDisruptionBudget.
    • Pods comportant l'annotation cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • Les charges de travail utilisant des volumes persistants avec des ressources zonales telles que Hyperdisk peuvent ne pas fonctionner correctement avec la migration active. Les restrictions zonales et les restrictions de type de machine de certains produits Hyperdisk peuvent réduire l'efficacité de la migration active. De plus, certaines charges de travail avec état peuvent ne pas tolérer la perturbation causée par la migration active.

Prenons l'exemple de spécification de classe de calcul suivante, qui donne la priorité aux nœuds N2 par rapport aux nœuds N2D :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  activeMigration:
    optimizeRulePriority: true

Si les nœuds N2 n'avaient pas été disponibles lorsque vous avez déployé un pod avec cette classe de calcul, GKE aurait utilisé des nœuds N2D comme option de remplacement. Si des nœuds N2 deviennent disponibles pour le provisionnement ultérieurement, par exemple si votre quota augmente ou si des VM N2 deviennent disponibles dans votre zone géographique, GKE crée un nœud N2 et migre progressivement le pod du nœud N2D existant vers le nouveau nœud N2. GKE supprime ensuite le nœud N2D obsolète.

Utiliser des réservations Compute Engine

Disponible dans GKE version 1.31.1-gke.2105000 et versions ultérieures

Si vous utilisez des réservations de capacité Compute Engine pour obtenir un niveau de garantie plus élevé de la disponibilité du matériel dans des zonesGoogle Cloud spécifiques, vous pouvez configurer chaque priorité de remplacement dans votre classe de calcul personnalisée afin que GKE consomme les réservations lors de la création de nouveaux nœuds.

La consommation de réservations dans des classes de calcul personnalisées s'accompagne des exigences suivantes:

  • Les clusters en mode standard doivent utiliser le provisionnement automatique des nœuds pour que GKE puisse utiliser des réservations pour créer des nœuds. Pour en savoir plus, consultez la section Provisionnement automatique des nœuds et des classes de calcul. Vous pouvez également continuer à utiliser les réservations lorsque vous créez manuellement des pools de nœuds dans votre cluster.
  • Les réservations autres que TPU ne peuvent être utilisées que lorsque machineType ou machineFamily est défini.
  • Les classes de calcul qui configurent des SSD locaux doivent utiliser la règle de priorité machineType, et non machineFamily. Pour en savoir plus, consultez la section Type de règle machineType.
  • Les classes de calcul qui spécifient des réservations pour un machineType auquel sont associés des SSD locaux doivent inclure explicitement un champ localSSDCount:.

Prenons l'exemple de spécification de classe de calcul suivante, qui donne la priorité à une réservation partagée spécifique à utiliser lors du provisionnement d'instances a3-highgpu-1g. Si les types d'instances prioritaires ne sont pas disponibles, GKE utilise les réservations correspondantes de la spécification:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

Si vous déployez un pod qui utilise la classe de calcul accelerator-reservations, GKE tente d'abord d'utiliser la réservation a3-shared-reservation lors de la création d'instances a3-highgpu-1g pour exécuter le pod. Si cette réservation spécifique n'a pas de capacité disponible, GKE tente d'augmenter la taille des instances a3-highgpu-1g à l'aide de toute réservation correspondante. Si aucune réservation n'est accessible, GKE utilise des VM Spot a3-highgpu-1g. Enfin, si aucune VM Spot n'est disponible, l'opération d'ajustement échoue.

Dans cet exemple, les deux règles de priorité avec des références de réservation nécessitent explicitement le champ localSSDCount:, car la forme de machine a3-highgpu-1g inclut des SSD locaux.

L'exemple suivant montre une réservation spécifique partagée, qui est remplacée par des VM Spot, puis par des VM à la demande:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n2
    reservations:
      specific:
      - name: n2-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n2
    spot: true
  - machineFamily: n2
  whenUnsatisfiable: DoNotScaleUp

Vous pouvez utiliser les types de réservations suivants:

  • Réservations spécifiques à un seul projet: configurez les champs suivants:

    • reservations.specific.name: nom de la réservation.
    • reservations.affinity: doit être Specific.

  • Réservations partagées spécifiques: configurez les champs suivants:

    • reservations.specific.name: nom de la réservation.
    • reservations.specific.project: ID du projet propriétaire de la réservation.
    • reservations.affinity: doit être Specific.

  • Toutes les réservations correspondantes: configurez les champs suivants:

    • reservations.affinity: doit être AnyBestEffort.
    • Ne définissez pas de nom de réservation ni de projet.

Les réservations TPU nécessitent une affinité spécifique. reservations.affinity: AnyBestEffort n'est pas compatible.

Si GKE ne trouve pas de capacité disponible dans une réservation, le comportement qui en résulte dépend du type de réservation sélectionné dans la règle de priorité de la classe de calcul, comme suit:

  • Réservations spécifiques: GKE essaie la règle de priorité suivante dans la classe de calcul.
  • Toutes les réservations correspondantes: GKE tente de provisionner un nœud à la demande qui répond aux exigences de cette règle de priorité. Si GKE ne peut pas provisionner de nœud à la demande, il tente d'appliquer la règle de priorité suivante de la classe de calcul.

Si GKE ne peut pas respecter les exigences de l'une des règles de priorité pour la classe de calcul, le comportement lorsque aucune règle ne s'applique se produit.

Consommer des blocs de réservation spécifiques

À partir de la version 1.31.4-gke.1072000 de GKE, vous pouvez cibler un bloc de réservation spécifique dans une réservation basée sur le matériel. Cette fonctionnalité est disponible pour les types de machines A3 Ultra et A4.

Pour utiliser un bloc de réservation spécifique, configurez votre ressource ComputeClass comme indiqué dans cet exemple:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

Remplacez RESERVATION_BLOCK_NAME par le nom du bloc de réservation cible.

Lorsque vous utilisez cette fonctionnalité, tenez compte des points suivants:

  • Cette fonctionnalité ne s'applique qu'aux réservations spécifiques d'un projet unique ou partagé.

Personnaliser la configuration du système de nœud

Vous pouvez personnaliser certains paramètres dans le kubelet et le noyau Linux à l'aide du champ nodeSystemConfig dans la spécification ComputeClass. Vous pouvez spécifier ce champ dans n'importe quelle règle de priorité qui définit une série ou un type de machine Compute Engine. Vous pouvez également définir des valeurs globales par défaut pour tous les champs de configuration système de nœuds qui sont omis dans les règles de priorité en ajoutant le champ nodeSystemConfig au champ priorityDefaults de votre classe de calcul.

Cette fonctionnalité est disponible dans GKE version 1.32.1-gke.1729000 et ultérieure.

Pour en savoir plus, consultez les pages suivantes :

Demander des classes de calcul dans les charges de travail

Pour utiliser une classe de calcul personnalisée une fois que vous avez terminé de la concevoir, votre pod doit la demander explicitement dans la spécification du pod. Vous pouvez également définir une classe de calcul par défaut dans un espace de noms Kubernetes spécifique. Dans ce cas, les pods de cet espace de noms utiliseront cette classe de calcul, sauf si les pods demandent une classe de calcul différente.

Pour savoir comment demander et utiliser des classes de calcul dans GKE, consultez la section Contrôler les attributs de nœud avec autoscaling à l'aide de classes de calcul personnalisées.

Étape suivante