À propos des classes de calcul personnalisées

Autopilot Standard

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. 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 provisionner des nœuds qui répondent 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 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.

Limites

Vous ne pouvez pas utiliser de classes de calcul personnalisées avec les réservations de capacité Compute Engine en mode Autopilot ou dans les pools de nœuds en mode Standard provisionnés automatiquement. Les pools de nœuds en mode Standard créés manuellement sont compatibles avec les réservations de capacité.

Fonctionnement des classes de calcul personnalisées

Les classes de calcul personnalisées sont des ressources personnalisées Kubernetes qui provisionnent l'infrastructure Google 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. Lorsque vous déployez une charge de travail qui demande la classe de calcul, GKE tente de placer les pods sur les nœuds qui répondent aux exigences de la classe de calcul.

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 définition de ressource personnalisée (CRD) complète de la ressource personnalisée ComputeClass, exécutez la commande suivante :

kubectl describe crd computeclasses.cloud.google.com

La sortie affiche l'intégralité du CRD, y compris tous les champs compatibles et les relations entre ces champs. Pour mieux comprendre les classes de calcul personnalisées, reportez-vous à cette définition pendant que vous lisez ce document.

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 :

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.
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.
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.
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.
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.

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.

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.

Selon le type de règle de priorité, vous pouvez spécifier des propriétés de machine supplémentaires, telles que des VM Spot ou une capacité de processeur minimale, pour que GKE les utilise lors du provisionnement des nœuds. Le champ priorities accepte les types de règles de priorité suivants :

machineFamily : définit des nœuds à l'aide d'une série de machines Compute Engine, comme n2 ou c3.
machineType : définit des nœuds à l'aide d'un type de machine Compute Engine prédéfini, tel que n2-standard-4.
nodepools : 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.

Type de règle 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 les champs suivants en plus du type de règle machineFamily :

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.

L'exemple suivant montre la règle de priorité machineFamily :

priorities:
- machineFamily: n2
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

Type de règle machineType

Le champ machineType accepte un type de machine prédéfini Compute Engine, tel que n2-standard-32. Le type de machine doit être compatible avec tous les GPU que vous spécifiez.

Vous pouvez utiliser les champs suivants en plus du type de règle machineType :

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.
gpu : configurer des GPU.
- gpu.type : type de GPU, tel que nvidia-l4. Pour en savoir plus, consultez la page Déployer des charges de travail GPU dans Autopilot.
- gpu.count : nombre de GPU à associer. Pour connaître les quantités compatibles par type de GPU, consultez la section Quantités de GPU compatibles.

L'exemple suivant montre une règle machineType pour les 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

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

priorities:
- machineType: g2-standard-16
  spot: false
  gpu:
    type: nvidia-l4
    count: 1

Type de règle nodepools

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 spécifier d'autres propriétés de machine avec ce champ dans le même élément de règle de priorité. 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 :

GKE place les pods sur tous les nœuds existants associés à cette classe de calcul.
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.
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.
Si aucune VM Spot N2 n'est disponible dans la région, GKE provisionne de nouvelles VM N2 à la demande.
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.

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, la commande suivante met à jour un pool de nœuds existant et l'associe à 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" \
    --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 :

Assurez-vous que le provisionnement automatique des nœuds est activé dans votre cluster.
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 :

Créer des nœuds dans le pool de nœuds manually-created-pool
Provisionner des nœuds N2, soit dans des pools de nœuds N2 existants, soit en créant un pool de nœuds
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. Il s'agit du comportement par défaut.
- 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.

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 :

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".

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.

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

Découvrez d'autres recommandations de déploiement de charges de travail dans GKE Autopilot.