Résoudre les problèmes liés aux ComputeClass personnalisées

Ce document vous aide à résoudre les problèmes liés à l'échec de la planification des charges de travail GKE sur des nœuds définis par une ComputeClass personnalisée ou lorsque l'autoscaler de cluster ne provisionne pas les types de machines attendus.

Ce document s'adresse aux développeurs d'applications, ainsi qu'aux administrateurs et opérateurs de plate-forme qui utilisent des ComputeClasses personnalisées pour gérer la planification des charges de travail et la création automatique de pools de nœuds dans GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Concepts clés

Pour vous aider à résoudre les problèmes, assurez-vous de connaître les composants et mécanismes GKE suivants :

  • ComputeClass personnalisée : ressource spécifique à GKE qui vous permet de définir une liste priorisée de configurations de nœuds pour l'autoscaling. Pour en savoir plus, consultez À propos des ComputeClasses personnalisées.

  • Autoscaler de cluster : composant qui ajoute ou supprime automatiquement des nœuds dans votre cluster en fonction de la demande de charge de travail. Pour en savoir plus, consultez À propos de l'autoscaling des clusters GKE.

  • Création automatique de pools de nœuds : l'autoscaler de cluster GKE crée et gère automatiquement les pools de nœuds en fonction des exigences des charges de travail. Pour en savoir plus, consultez À propos de la création automatique de pools de nœuds.

  • Logique de secours : mécanisme par lequel l'autoscaler de cluster tente d'abord de provisionner les nœuds correspondant à votre règle de priorité la plus élevée. Pour en savoir plus, consultez Choisir vos priorités de calcul de remplacement.

Résoudre les problèmes par symptômes

Ce document organise les étapes de dépannage de manière séquentielle, des vérifications de base aux configurations plus avancées. Pour un diagnostic plus complet, nous vous recommandons de suivre ces étapes dans l'ordre. Si vous rencontrez des problèmes spécifiques, consultez les liens correspondants dans le tableau suivant :

Problème constaté Procédure de dépannage
Un pod demandant une ComputeClass personnalisée est bloqué à l'état Pending
L'autoscaler de cluster ne crée pas de nœuds correspondant à la classe de calcul personnalisée
L'autoscaler de cluster crée des types de machines par défaut au lieu de types spécialisés Analyser le comportement de repli de l'autoscaler
Le résultat de la commande kubectl describe computeclass indique un état non opérationnel Vérifier les configurations ComputeClass personnalisées
Les charges de travail ne migrent pas vers des nœuds de priorité supérieure Vérifier l'état général de l'autoscaler de cluster
Les charges de travail des VM GPU ou Spot présentent des problèmes de planification

Problèmes hors champ d'application

Ce document ne traite pas des problèmes suivants :

  • Problèmes généraux de mise en réseau GKE, tels que la connectivité entre les pods ou l'équilibrage de charge de service.
  • Problèmes liés à l'autoscaler horizontal de pods (AHP) ou à l'autoscaler vertical de pods (VPA).
  • Problèmes non liés au mécanisme ComputeClass personnalisé, tels que les erreurs au niveau de l'application ou les problèmes PersistentVolume qui ne sont pas liés aux contraintes de planification.
  • Problèmes de quota ou d'indisponibilité des ressources qui ne sont pas directement liés à la logique de secours ComputeClass.

Identifier les variables d'espace réservé

Pour personnaliser les commandes de ce document, saisissez vos valeurs spécifiques dans la colonne Variable. Les valeurs modifiées sont automatiquement synchronisées dans tous les blocs de code et toutes les commandes.

Variable Description
PROJECT_ID ID de votre projet Google Cloud .
LOCATION Région ou zone Compute Engine dans laquelle se trouve le cluster.
CLUSTER_NAME Nom de votre cluster.
NODE_POOL_NAME Nom du pool de nœuds à inspecter (le cas échéant pour les clusters Standard).
CUSTOM_COMPUTECLASS_NAME Nom de la ComputeClass personnalisée demandée par le pod.
NAMESPACE Espace de noms du pod dont la planification a échoué.
POD_NAME Nom du pod dont la planification a échoué.

Avant de commencer

Pour obtenir les autorisations nécessaires pour effectuer les tâches décrites dans ce document, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet Google Cloud  :

  • Pour accéder aux clusters GKE : Lecteur de cluster Kubernetes Engine (roles/container.viewer).
  • Pour afficher les journaux : Lecteur de journaux (roles/logging.viewer).
  • Pour gérer les clusters GKE : Administrateur Kubernetes Engine (roles/container.admin).

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Pour configurer kubectl afin qu'il communique avec le cluster, exécutez la commande suivante :

  gcloud container clusters get-credentials CLUSTER_NAME
      --location LOCATION
      --project PROJECT_ID

Effectuer des vérifications de diagnostic de base

Vérifiez que les composants principaux sont correctement configurés et que le cluster est compatible avec les ComputeClasses personnalisées.

Vérifier l'état et le sélecteur du pod

Vérifiez que le pod est à l'état Pending et qu'il demande correctement la ComputeClass personnalisée.

  1. Répertoriez les pods à l'état Pending :

    kubectl get pods --all-namespaces -o wide | grep Pending

  2. Inspectez la spécification du pod pour le champ nodeSelector :

    kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.nodeSelector}'

Évaluer le résultat

  • Le résultat affiche le libellé : le champ nodeSelector est correctement configuré avec le libellé cloud.google.com/compute-class.
  • Le résultat n'affiche pas le libellé :
    • Interprétation : il est possible que le champ nodeSelector soit incorrect ou manquant pour le libellé cloud.google.com/compute-class dans la configuration du déploiement de votre charge de travail.
    • Résolution : modifiez le fichier YAML de votre charge de travail, tel qu'un déploiement ou un job, pour inclure le champ nodeSelector dans la section spec.template.spec.

Vérifier la compatibilité de la version du cluster

Les ComputeClasses personnalisées nécessitent GKE version 1.30.3-gke.1451000 ou ultérieure. Vérifiez que votre cluster exécute une version compatible avec les ComputeClasses personnalisées.

Vérifiez la version de votre cluster :

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(currentMasterVersion)"

Évaluer le résultat

  • Version 1.30.3-gke.1451000 ou ultérieure : la version de votre cluster est compatible avec les ComputeClasses personnalisées.
  • Version antérieure à 1.30.3-gke.1451000 :
    • Interprétation : votre cluster n'a pas été mis à niveau vers une version compatible avec les ComputeClasses personnalisées.
    • Solution : vous devez mettre à niveau votre cluster pour utiliser des ComputeClasses personnalisées.

Vérifier les configurations ComputeClass personnalisées

Des erreurs de configuration dans la ressource ComputeClass personnalisée peuvent empêcher la planification des pods ou le provisionnement correct des nœuds par GKE.

Vérifier l'état et le statut de ComputeClass

Vérifiez que GKE signale que la ComputeClass personnalisée est opérationnelle.

  1. Répertoriez toutes les ressources ComputeClass :

    kubectl get computeclass

  2. Décrivez la ressource ComputeClass spécifique :

    kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

Évaluer le résultat

  • L'état de santé indique True : la classe de calcul personnalisée est opérationnelle. Voici un exemple de ComputeClass personnalisé opérationnel :

    Status:
  Conditions:
    Last Transition Time:  2024-01-19T17:18:48Z
    Message:               CCC is healthy.
    Reason:                Health
    Status:                True
    Type:                  Health

  • L'état de fonctionnement indique False :

    • Interprétation : la classe de calcul personnalisée n'est pas opérationnelle. Examinez les champs Message et Reason dans le résultat pour identifier le problème.
    • Résolution : effectuez l'action correspondant au champ Reason dans le résultat :
      • NodePoolNotExist : assurez-vous que le pool de nœuds référencé existe ou mettez à jour la ComputeClass pour référencer un pool de nœuds existant.
      • ReservationUnusable : vérifiez la configuration et l'utilisation de la réservation référencée.
      • Invalid machine type : mettez à jour la ComputeClass pour utiliser un type de machine compatible avec la région ou la zone du cluster.

Valider la règle unsatisfiable

Le champ whenUnsatisfiable détermine le comportement lorsque aucune règle de priorité ne peut être respectée.

Vérifiez le règlement :

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Inspectez le champ spec.whenUnsatisfiable dans le résultat. Ce champ peut présenter l'une des valeurs suivantes :

  • DoNotScaleUp : les pods restent à l'état Pending si aucun nœud préféré ne peut être créé.
  • ScaleUpAnyway : les pods peuvent s'exécuter sur des types de nœuds par défaut (comme la série E2) si les nœuds préférés ne sont pas disponibles.

Évaluer le résultat

L'effet de la règle whenUnsatisfiable dépend de sa valeur :

  • Si la valeur est DoNotScaleUp :
    • Interprétation : ce comportement est normal lorsqu'aucune règle de priorité ne peut être appliquée, peut-être en raison de l'indisponibilité des ressources ou des limites de quota. Si les pods doivent attendre un matériel spécifique, cette valeur est correcte.
    • Résolution : si l'exécution de la charge de travail est plus importante que l'exécution sur un matériel spécifique, définissez la règle sur ScaleUpAnyway.
  • Si la valeur est ScaleUpAnyway :
    • Interprétation : ce comportement est normal. GKE revient aux types de nœuds par défaut, car les nœuds préférés ne sont pas disponibles.
    • Solution : si les pods ne doivent pas s'exécuter sur les types de nœuds par défaut, définissez la règle sur DoNotScaleUp.
  • Comportement par défaut : si vous n'avez pas spécifié de valeur pour le champ whenUnsatisfiable et que vous utilisez une version de GKE antérieure à 1.33, la règle est définie par défaut sur ScaleUpAnyway.

L'exemple suivant montre comment mettre à jour la règle en modifiant le champ whenUnsatisfiable dans le fichier manifeste ComputeClass :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: CUSTOM_COMPUTECLASS_NAME
spec:
  # ... other fields
  whenUnsatisfiable: DoNotScaleUp # or ScaleUpAnyway

Vérifier les contraintes de planification des pods

Assurez-vous que la spécification de votre pod est compatible avec les attributs des nœuds provisionnés par la ComputeClass personnalisée.

Vérifier les demandes de ressources des pods

Vérifiez si les demandes de processeur, de mémoire et de GPU du pod peuvent être satisfaites par au moins l'un des types de machines définis dans le champ priorities de la ComputeClass personnalisée.

  1. Obtenir les demandes de ressources des pods :

    kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.containers[*].resources.requests}'

    Inspectez la sortie pour les demandes cpu, memory et de GPU, telles que nvidia.com/gpu.

  2. Comparez ces demandes avec les types de machines définis dans le champ priorities de la classe Compute personnalisée :

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
    -o jsonpath='{.spec.priorities}'

    Inspectez le résultat pour trouver les champs machineType ou machineFamily. Pour chaque type de machine de la ComputeClass personnalisée, vérifiez ses spécifications dans la documentation sur les types de machines et assurez-vous que ses ressources allouables sont supérieures aux demandes du pod.

Évaluer le résultat

  • Ressources compatibles : les demandes de ressources du pod sont inférieures ou égales aux ressources pouvant être allouées d'au moins un type de machine dans la classe de calcul.

  • Les ressources dépassent la capacité :

    • Interprétation : le pod ne peut pas être planifié, car aucun type de machine dans ComputeClass ne fournit suffisamment de processeur, de mémoire ou de GPU. Cela peut également se produire si le champ nodePoolAutoCreation est défini sur true et que la demande de mémoire du pod dépasse les limites des pools de nœuds créés automatiquement.
    • Résolution : ajustez les requêtes de ressources du pod ou les types de machines de la classe de calcul personnalisée :
      • Réduisez les demandes de ressources des pods : si les demandes de ressources sont élevées, diminuez les valeurs cpu, memory ou gpu dans le fichier YAML de la charge de travail.
      • Passez à des types de machines plus grands : si les requêtes du pod sont justifiées, modifiez le champ spec.priorities dans votre fichier manifeste ComputeClass personnalisé pour inclure des options machineType ou machineFamily plus grandes qui peuvent répondre aux exigences du pod. Exemple :
    spec:
  priorities:
  - machineType: n2d-highmem-96 # A larger machine type
    spot: true
  # ... other priorities

Vérifier les rejets et tolérances en conflit

Les nœuds créés pour une ComputeClass personnalisée sont associés au taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule. GKE ajoute automatiquement cette tolérance aux pods.

Toutefois, le matériel spécialisé tel que les GPU comporte des taints supplémentaires, comme le taint nvidia.com/gpu=present:NoSchedule. Si votre ComputeClass utilise des nœuds avec du matériel spécialisé, les pods doivent avoir une tolérance pour ces rejets afin de pouvoir être planifiés sur ces nœuds.

Vérifiez le champ tolerations du pod :

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.tolerations}'

Évaluer le résultat

  • Tolérances correctes : les contaminations et les tolérances sont correctement configurées.

  • Tolérances manquantes :

    • Interprétation : l'absence de tolérances empêche le pod de se programmer sur des nœuds avec des rejets de matériel spécialisé. Par exemple, si la ComputeClass utilise des nœuds GPU, il se peut que le pod ne dispose pas de la tolérance nvidia.com/gpu=present:NoSchedule. Pour connaître les exigences spécifiques aux GPU, consultez Vérifier la configuration des GPU.

    • Résolution : dans le champ tolerations de la spécification de votre pod, ajoutez les tolérances nécessaires pour correspondre aux rejets sur les nœuds définis par la ComputeClass. Par exemple, pour les nœuds GPU, ajoutez une tolérance pour le rejet nvidia.com/gpu=present:NoSchedule comme suit :

      spec:
template:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
# ... other tolerations and Pod spec

Configuration du pool de nœuds (clusters standards)

Dans les clusters GKE Standard, les pools de nœuds créés manuellement doivent être étiquetés et marqués pour fonctionner avec une ComputeClass personnalisée.

Vérifier les libellés et les rejets de pool de nœuds

  1. Identifiez les pools de nœuds dans votre ComputeClass personnalisée. Si la ComputeClass personnalisée utilise le champ nodePools, notez les noms des pools de nœuds listés :

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

  2. Pour chaque pool de nœuds que vous avez identifié, vérifiez sa configuration :

    gcloud container node-pools describe NODE_POOL_NAME
    --cluster CLUSTER_NAME
    --location LOCATION
    --format="yaml(config.labels, config.taints)"

Évaluer le résultat

  • Pool de nœuds correctement configuré : le pool de nœuds possède le libellé cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME et le taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule.

  • Pool de nœuds mal configuré :

    • Interprétation : le pool de nœuds n'a pas été configuré avec l'étiquette et le rejet requis pour l'associer à la ComputeClass personnalisée.

    • Solution : mettez à jour le pool de nœuds pour ajouter le libellé et le rejet :

      1. Ajoutez ou modifiez un libellé de nœud :

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-labels=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

      2. Ajoutez ou mettez à jour un taint de nœud :

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-taints=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule

Vérifier la configuration de la création automatique de pools de nœuds

Pour les clusters Autopilot et Standard avec nodePoolAutoCreation défini sur true, la création automatique de pools de nœuds doit être correctement configurée.

Vérifier que la création automatique de pools de nœuds est activée

  1. Vérifiez si le champ nodePoolAutoCreation.enabled de la ComputeClass personnalisée est défini sur true :

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

  2. Vérifiez si la création automatique de pools de nœuds est activée sur le cluster :

    gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(autoscaling.enableNodeAutoprovisioning)"

Si l'une ou l'autre de ces options est désactivée, la création automatique de pools de nœuds ne créera pas de pools de nœuds pour votre ComputeClass personnalisée.

Évaluer le résultat

  • Création automatique de pools de nœuds activée : dans ComputeClass, le champ nodePoolAutoCreation.enabled est défini sur true et le provisionnement automatique des nœuds est activé au niveau du cluster.

  • Création automatique de pools de nœuds désactivée :

    • Interprétation : la création automatique de pools de nœuds est désactivée si la valeur du champ nodePoolAutoCreation.enabled est false ou manquante dans ComputeClass, ou si le provisionnement automatique de nœuds au niveau du cluster est désactivé.

    • Résolution : activez la création automatique de pools de nœuds :

      1. Modifiez le fichier YAML ComputeClass personnalisé pour inclure nodePoolAutoCreation: enabled: true :

        spec:
  # ... priorities
  nodePoolAutoCreation:
    enabled: true

      2. Activez la création automatique de pools de nœuds au niveau du cluster et configurez les limites de ressources :

        gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --enable-autoprovisioning \
  --autoprovisioning-min-cpu=MIN_CPU \
  --autoprovisioning-max-cpu=MAX_CPU \
  --autoprovisioning-min-memory=MIN_MEMORY \
  --autoprovisioning-max-memory=MAX_MEMORY

Vérifier les limites de ressources pour la création automatique de pools de nœuds

La création automatique de pools de nœuds est soumise à des limites de processeur et de mémoire à l'échelle du cluster. Si l'utilisation actuelle du cluster plus les ressources d'un nouveau nœud dépassent ces limites, la création automatique de pool de nœuds ne provisionne pas de nouveaux nœuds.

  1. Affichez les limites de ressources :

    gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
--format="value(autoscaling.resourceLimits)"

    La sortie liste les champs resourceType, minimum et maximum pour le processeur et la mémoire (en Go).

  2. Examinez les types de machines dans les priorités de votre ComputeClass personnalisée. Vérifiez les spécifications du processeur et de la mémoire dans la documentation sur les types de machines.

  3. Déterminez la capacité totale actuelle du processeur et de la mémoire de tous les nœuds du cluster. La somme de la capacité actuelle et des ressources d'un nouveau nœud potentiel ne doit pas dépasser la limite maximale pour la création automatique de pools de nœuds.

Évaluer le résultat

  • Capacité suffisante : le cluster dispose d'une capacité de processeur et de mémoire suffisante dans les limites de ressources pour que la création automatique de pool de nœuds provisionne un nouveau nœud.

  • Limites dépassées :

    • Interprétation : la création automatique de pools de nœuds ne peut pas provisionner de nouveaux nœuds, car le cluster a atteint les limites de processeur ou de mémoire, ou les limites ont été définies trop bas pour les types de machines de la ComputeClass.

    • Solution : augmentez les limites de ressources pour la création automatique de pools de nœuds :

      1. Déterminez de nouvelles limites maximales qui tiennent compte de l'utilisation actuelle et de la croissance future, y compris les types de machines les plus volumineux de la classe de calcul personnalisée.

      2. Mettre à jour les limites de ressources pour la création automatique de pools de nœuds Vous pouvez définir plusieurs ressources dans une seule commande :

        gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --set-nap-resource-limits resourceType=cpu,maximum=NEW_MAX_CPU \
  --set-nap-resource-limits resourceType=memory,maximum=NEW_MAX_GB

Analyser le comportement de repli de l'autoscaler

Cette section vous aide à examiner les facteurs externes pour comprendre pourquoi l'autoscaler de cluster peut ignorer les options préférées et utiliser des options de remplacement, ou ne pas effectuer le scaling à la hausse.

Les ComputeClasses personnalisées utilisent une logique de remplacement prioritaire. Si un pod n'est pas planifié sur des nœuds correspondant à la règle de priorité la plus élevée, cela est souvent dû à des contraintes telles que l'indisponibilité des ressources ou les quotas de projet. Lorsque GKE ne peut pas provisionner de nœuds correspondant à une règle de priorité spécifique, par exemple en raison d'une erreur ZONE_RESOURCE_POOL_EXHAUSTED ou QUOTA_EXCEEDED de Compute Engine, l'autoscaler de cluster essaie immédiatement la règle suivante dans la liste priorities. Il n'y a pas de période d'attente avant que GKE ne passe à la priorité suivante, sauf lorsque vous utilisez des TPU ou le modèle de provisionnement Flex Start, qui prennent en charge un délai configurable.

Vérifier l'indisponibilité des ressources

Vérifiez si les ressources sont indisponibles dans la zone spécifiée en consultant les journaux de l'autoscaler de cluster ou les erreurs du groupe d'instances géré (MIG) Compute Engine.

Option 1 : Vérifier les événements de visibilité de l'autoscaler de cluster

Dans la console Google Cloud , accédez à Cloud Logging > Explorateur de journaux, puis exécutez la requête suivante pour trouver les événements de scaling automatique qui peuvent indiquer une indisponibilité des ressources :

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.resource.exhausted"

Option 2 : Vérifier les erreurs du MIG

Vous pouvez rechercher les erreurs MIG dans la console Google Cloud ou à l'aide d'une requête Cloud Logging.

  • Utiliser la console Google Cloud  :

    1. Dans la console Google Cloud , accédez à Compute Engine > Groupes d'instances.
    2. Recherchez le MIG correspondant au pool de nœuds qui ne parvient pas à évoluer à la hausse.
    3. Cliquez sur le nom du MIG, puis accédez à l'onglet Erreurs. Recherchez les messages indiquant une pénurie de ressources.

  • Utiliser une requête Cloud Logging :

    1. Dans la console Google Cloud , accédez à Cloud Logging > Explorateur de journaux.
    2. Exécutez la requête suivante pour vérifier si le MIG a généré des erreurs d'épuisement des ressources :
    resource.type="gce_instance"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.status.message:("ZONE_RESOURCE_POOL_EXHAUSTED" OR "does not have enough resources available to fulfill the request" OR "resource pool exhausted" OR "does not exist in zone")

Évaluer le résultat

  • Les ressources sont disponibles : si les journaux n'affichent pas les messages ZONE_RESOURCE_POOL_EXHAUSTED, il est peu probable que l'indisponibilité des ressources soit la cause de l'échec du scale-up.

  • Les ressources ne sont pas disponibles :

    • Interprétation : le provisionnement des nœuds échoue en raison d'une forte demande temporaire pour un type de machine spécifique (en particulier les VM Spot ou les GPU) dans cette zone, ou parce qu'un pod est limité par l'affinité PersistentVolume à une zone où les ressources sont indisponibles.

    • Résolution : L'indisponibilité des ressources est temporaire, mais vous pouvez améliorer la résilience en ajoutant de la flexibilité à votre configuration :

      • Diversifier les types de machines : assurez-vous que le champ spec.priorities de la ComputeClass personnalisée contient plusieurs types ou familles de machines en tant que solutions de secours :

        spec:
  priorities:
  - machineFamily: c3  # Highest priority
  - machineFamily: n2d # Fallback option
  - machineFamily: e2  # Lowest priority

      • Utilisez des clusters régionaux : si le cluster est zonal, il est vulnérable à l'indisponibilité des ressources dans cette zone unique. L'utilisation de clusters régionaux permet à l'autoscaler de cluster de tenter de provisionner des nœuds dans d'autres zones de la région où des capacités peuvent être disponibles.

      • Utiliser les réservations Compute Engine : pour les charges de travail critiques qui ne peuvent pas tolérer de retard, créez des réservations Compute Engine pour vous assurer d'avoir la capacité nécessaire pour des types de machines spécifiques.

Vérifier les quotas de projet

Vérifiez que votre projet dispose d'un quota suffisant pour les ressources requises par les nouveaux nœuds, telles que les processeurs, les GPU et les adresses IP.

  1. Recherchez les erreurs de quota dans les journaux de l'autoscaler. Utilisez Cloud Logging pour rechercher les messages d'erreur liés aux quotas dans les événements de visibilité de l'autoscaler :

    resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.quota.exceeded"

    Vous pouvez également utiliser la requête Cloud Logging suivante pour vérifier les journaux d'erreurs liées aux quotas provenant du MIG :

    resource.type="gce_instance"
protoPayload.methodName:"compute.instances.insert"
protoPayload.status.message:"QUOTA_EXCEEDED"
severity=ERROR

  2. Consultez les quotas dans la console Google Cloud  :

    1. Dans la console Google Cloud , accédez à IAM et administration > Quotas.
    2. Filtrez sur le service API Compute Engine.
    3. Vérifiez l'utilisation des métriques pertinentes, comme les processeurs, les GPU (tous types) et les adresses IP utilisées pour la région dans laquelle se trouve votre cluster GKE. Vérifiez que l'utilisation actuelle n'a pas atteint la limite.

Évaluer le résultat

  • Quota inférieur aux limites : si l'utilisation du quota est inférieure aux limites de quota et qu'aucune erreur QUOTA_EXCEEDED n'est détectée dans les journaux, les limites de quota n'empêcheront pas le scale-up.
  • Quota dépassé :
    • Interprétation : le provisionnement des nœuds échoue en raison d'un quota insuffisant pour des ressources telles que les processeurs, les GPU, les adresses IP ou les MIG.
    • Solution : Si votre projet a atteint une limite de quota, demandez une augmentation de quota.

Configurations avancées

Les configurations telles que les GPU, les Spot VM et les réservations Compute Engine ont leurs propres exigences spécifiques et points de défaillance potentiels à vérifier.

Vérifier la configuration du GPU

Pour les ComputeClasses personnalisées qui provisionnent des nœuds GPU, validez la configuration GPU dans la ComputeClass personnalisée et assurez-vous que le pod dispose de la tolérance nvidia.com/gpu obligatoire.

  1. Vérifiez le fichier YAML de la ComputeClass personnalisée pour trouver un bloc gpu dans une règle de priorité :

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

    Le bloc gpu doit spécifier un champ type et un champ count, par exemple :

    priorities:
- machineType: a2-highgpu-1g
  gpu:
    type: nvidia-tesla-a100
    count: 1

  2. Inspectez le pod pour vérifier la tolérance du GPU. Tout pod qui doit être planifié sur un nœud GPU doit avoir la tolérance nvidia.com/gpu, même s'il ne demande pas de GPU lui-même.

    kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'

    Recherchez la tolérance dans le champ spec.tolerations.

Évaluer le résultat

  • GPU correctement configuré : si ComputeClass définit les GPU type et count, et que les pods incluent la tolérance nvidia.com/gpu, la configuration du GPU est correcte. Vous trouverez ci-dessous la tolérance requise :

    tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"

  • GPU mal configuré :

    • Interprétation : il est possible que le pod ne dispose pas de la tolérance nvidia.com/gpu requise, que la ComputeClass ne soit pas saine en raison d'incohérences dans le champ GPU ou que la version GKE ne gère pas correctement la configuration du GPU.
    • Résolution : effectuez l'une des actions suivantes :
      • Modifiez le fichier YAML de la charge de travail pour inclure la tolérance GPU obligatoire, puis réappliquez le fichier YAML.
      • Mettez à niveau le cluster GKE. Si la ComputeClass personnalisée n'est pas saine et que le problème est lié aux champs GPU, recherchez les problèmes connus et passez à une version corrigée de GKE, par exemple 1.31.8-gke.1045000 ou ultérieure.

Vérifier la configuration des VM Spot

Si vous utilisez des VM Spot, assurez-vous que le paramètre spot: true se trouve dans les règles de priorité appropriées de votre fichier manifeste ComputeClass. Assurez-vous également de comprendre la logique de tarification de l'autoscaler de cluster.

Examinez le fichier manifeste ComputeClass :

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Dans le résultat, recherchez spot: true dans le champ spec.priorities, par exemple :

priorities:
- machineFamily: n2d
  spot: true

L'autoscaler de cluster peut utiliser les données tarifaires de us-central1 comme référence lorsqu'il compare le coût de différents types de VM Spot, ce qui peut entraîner des choix apparemment non optimaux dans d'autres régions. Il s'agit d'un comportement connu.

Évaluer le résultat

  • VM Spot correctement configurées : si le champ spot: true est spécifié et que l'autoscaler de cluster provisionne des VM Spot, la configuration fonctionne comme prévu.

  • Échec de la planification des VM Spot :

    • Interprétation : il est possible que les pods nécessitant des VM Spot ne puissent pas être planifiés sur des VM Spot en raison de l'indisponibilité des ressources dans la zone cible ou parce que l'autoscaler de cluster peut choisir un autre type de VM en fonction de son modèle de tarification us-central1.

    • Solution :

      • Si vous pensez qu'une ressource n'est pas disponible, consultez Vérifier l'indisponibilité d'une ressource.

      • Pour contrôler la sélection des VM Spot, listez explicitement les entrées machineType dans votre champ priorities, de la moins chère à la plus chère pour votre région. Cette approche vous permet de contrôler directement l'ordre de secours. Exemple :

        spec:
  priorities:
  - machineType: t2d-standard-48 # Cheapest in this region
    spot: true
  - machineType: n2d-standard-48 # Fallback Spot option
    spot: true
  - machineType: n2d-standard-48 # On-demand fallback
    spot: false

État général de l'autoscaler de cluster

Cette section vous aide à rechercher les problèmes qui ne sont pas directement liés à la configuration personnalisée de ComputeClass, mais qui peuvent affecter son fonctionnement.

Vérifier les opérations simultanées

Vérifiez qu'aucune autre opération de cluster ou de pool de nœuds n'est en cours en même temps. GKE n'autorise généralement qu'une seule opération à la fois, ce qui peut bloquer l'autoscaling.

Répertoriez les opérations en cours qui ne sont pas à l'état DONE :

gcloud container operations list \
    --location=LOCATION \
    --filter='targetLink~"/clusters/CLUSTER_NAME" AND status!=DONE'

Si la commande renvoie des opérations, cela signifie qu'une action telle que la mise à niveau d'un cluster, la création d'un pool de nœuds ou une autre modification est peut-être en cours. Les événements d'autoscaling peuvent être bloqués jusqu'à la fin de cette opération.

Évaluer le résultat

  • Aucune opération simultanée : si la commande list renvoie une liste vide, l'autoscaler de cluster n'est bloqué par aucune opération.

  • Opérations simultanées détectées :

    • Interprétation : si la commande liste des opérations avec l'état RUNNING ou PENDING, une opération simultanée, telle qu'une mise à niveau du cluster ou une modification du pool de nœuds, peut être en cours et bloquer l'autoscaling.

    • Résolution : Attendez que l'opération en cours se termine. Vous pouvez surveiller l'état à l'aide d'un ID d'opération en utilisant :

      gcloud container operations wait OPERATION_ID --location LOCATION

      Remplacez OPERATION_ID par l'ID du résultat de la commande list. Une fois l'opération de blocage terminée, l'autoscaler de cluster devrait reprendre son fonctionnement normal.

Examiner la migration active

Si vous constatez que des charges de travail restent sur des nœuds de priorité inférieure alors que des nœuds de priorité supérieure sont disponibles, vérifiez si la migration active est activée. Si le champ activeMigration.optimizeRulePriority est défini sur false ou omis dans votre ComputeClass, GKE ne déplacera pas automatiquement les charges de travail vers des nœuds de priorité supérieure lorsqu'ils deviendront disponibles.

  1. Pour vérifier les tolérances des pods, consultez le champ spec.tolerations. Si le pod présente des tolérances correspondant à des taints sur plusieurs pools de nœuds de priorités différentes, le planificateur peut le placer sur un nœud de priorité inférieure s'il est disponible en premier.

    kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'

  2. Pour vérifier si la migration active est activée, examinez le champ spec.activeMigration.optimizeRulePriority dans le fichier manifeste ComputeClass.

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Évaluer le résultat

  • Migration active activée : si le champ activeMigration.optimizeRulePriority est défini sur true, GKE tente de déplacer les charges de travail vers des nœuds de priorité supérieure lorsqu'ils deviennent disponibles.

  • Migration active désactivée ou inefficace :

    • Interprétation : si le champ activeMigration.optimizeRulePriority est défini sur false ou omis, ou si les tolérances du pod sont trop larges, les charges de travail restent sur les nœuds de priorité inférieure lorsque des nœuds de priorité supérieure sont disponibles. Cette approche permet de planifier les charges de travail sur les nœuds de priorité inférieure qui deviennent disponibles en premier.

    • Résolution : si vous souhaitez que les charges de travail soient déplacées vers des nœuds de priorité plus élevée, effectuez l'une des actions suivantes :

      • Utilisez des contraintes de planification plus spécifiques, comme nodeAffinity, pour privilégier les pools de nœuds de priorité plus élevée.

      • Modifiez le fichier manifeste ComputeClass pour définir activeMigration.optimizeRulePriority: true et appliquer le fichier YAML :

        spec:
  activeMigration:
    optimizeRulePriority: true

Obtenir de l'aide

Étapes suivantes