Résoudre les problèmes d'autoscaler de cluster qui n'effectue pas de scaling à la hausse

Lorsque vos pods dans Google Kubernetes Engine (GKE) sont bloqués dans un état Pending et que de nouveaux nœuds ne sont pas ajoutés, cela indique souvent un problème avec la fonctionnalité de scale-up de l'autoscaler de cluster. Ce problème peut empêcher vos applications de s'adapter à la demande, retarder les déploiements et affecter la disponibilité des services.

Utilisez cette page pour diagnostiquer et résoudre les problèmes courants qui empêchent l'autoscaler de cluster d'ajouter de nouveaux nœuds. Résoudre ces problèmes permet au planificateur Kubernetes de placer rapidement vos charges de travail et aide votre cluster à s'adapter à l'augmentation de la charge.

Ces informations sont importantes pour les développeurs d'applications, qui ont besoin que leurs applications et services soient planifiés et exécutés de manière fiable, ainsi que pour les administrateurs et opérateurs de plate-forme, qui sont chargés de s'assurer que le cluster peut provisionner dynamiquement des ressources pour répondre aux exigences des charges de travail et maintenir les niveaux de service. 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.

Comprendre quand l'autoscaler de cluster augmente vos nœuds

Avant de procéder au dépannage, il peut être utile de comprendre quand l'autoscaler de cluster tente d'augmenter la capacité de vos nœuds. L'autoscaler de cluster n'ajoute des nœuds que lorsque les ressources existantes sont insuffisantes.

Toutes les 10 secondes, l'autoscaler de cluster vérifie s'il existe des pods non planifiables. Un pod devient non planifiable lorsque le programmeur Kubernetes ne peut pas le placer sur un nœud existant en raison de ressources insuffisantes, de contraintes de nœud ou d'exigences de pod non satisfaites.

Lorsque l'autoscaler de cluster détecte des pods non programmables, il évalue si l'ajout d'un nœud permettrait de programmer le pod. Si l'ajout d'un nœud permet de planifier un pod, l'autoscaler de cluster ajoute un nœud au groupe d'instances géré (MIG). Le planificateur Kubernetes peut ensuite planifier le pod sur le nœud nouvellement provisionné.

Vérifier si vous avez des pods non planifiables

Pour déterminer si votre cluster doit être mis à l'échelle, recherchez les pods non planifiés :

  1. Dans la console Google Cloud , accédez à la page Charges de travail.

    Accéder à la page Charges de travail

  2. Dans le champ Filtre, saisissez unschedulable, puis appuyez sur Entrée.

    Si des pods sont listés, cela signifie que vous avez des pods non programmables. Pour résoudre les problèmes de pods non programmables, consultez Erreur : Pod non programmable. Résoudre la cause sous-jacente des pods non planifiables peut souvent permettre à l'autoscaler de cluster d'effectuer un scaling à la hausse. Pour identifier et résoudre les erreurs spécifiques à l'autoscaler de cluster, consultez les sections suivantes.

    Si aucun pod n'est listé, l'autoscaler de cluster n'a pas besoin d'effectuer un scaling à la hausse et fonctionne comme prévu.

Vérifier si vous aviez déjà des pods non planifiables

Si vous cherchez à comprendre pourquoi l'autoscaler de cluster a échoué par le passé, vérifiez s'il y avait des pods non planifiables :

  1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Spécifiez une période pour les entrées de journal que vous souhaitez afficher.

  3. Dans le volet "Requête", saisissez la requête suivante :

    logName="projects/PROJECT_ID/logs/events"
jsonPayload.source.component="default-scheduler"
jsonPayload.reason="FailedScheduling"

    Remplacez PROJECT_ID par l'ID du projet.

  4. Cliquez sur Exécuter la requête.

    Si des résultats s'affichent, cela signifie que vous aviez des pods non programmables dans la plage de temps que vous avez spécifiée.

Vérifier si le problème est dû à une limitation

Une fois que vous avez confirmé que vous avez des pods non planifiés, assurez-vous que votre problème avec l'autoscaler de cluster n'est pas dû à l'une des limites de l'autoscaler de cluster.

Afficher les erreurs

Vous pouvez souvent diagnostiquer la cause des problèmes de scaling à la hausse en consultant les messages d'erreur :

Afficher les erreurs dans les notifications

Si le problème que vous avez observé s'est produit il y a moins de 72 heures, consultez les notifications d'erreur dans la console Google Cloud . Ces notifications fournissent des informations précieuses sur les raisons pour lesquelles l'autoscaler de cluster n'a pas effectué de scaling à la hausse, et proposent des conseils pour résoudre l'erreur et afficher les journaux pertinents pour une enquête plus approfondie.

Pour afficher les notifications dans la console Google Cloud , procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Consultez la colonne Notifications. Les notifications suivantes sont associées à des problèmes de scaling à la hausse :

    • Can't scale up
    • Can't scale up pods
    • Can't scale up a node pool

  3. Cliquez sur la notification concernée pour afficher un volet contenant des informations sur la cause du problème et les actions recommandées pour le résoudre.

  4. Facultatif: Pour afficher les journaux de cet événement, cliquez sur Journaux. Cette action vous redirige vers l'explorateur de journaux avec une requête préremplie pour vous aider à enquêter plus en détail sur l'événement de mise à l'échelle. Pour en savoir plus sur le fonctionnement des événements de scaling à la hausse, consultez Afficher les événements d'autoscaler de cluster.

Si le problème persiste après avoir lu les conseils de la notification, consultez les tables des messages d'erreur pour obtenir de l'aide.

Afficher les erreurs dans les événements

Si le problème que vous avez observé s'est produit il y a plus de 72 heures, consultez les événements dans Cloud Logging. En cas d'erreur, celle-ci est souvent enregistrée dans un événement.

Pour afficher les journaux de l'autoscaler de cluster dans la console Google Cloud , procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Sélectionnez le nom du cluster que vous souhaitez examiner pour afficher la page Détails du cluster.

  3. Sur la page Détails du cluster, cliquez sur l'onglet Journaux.

  4. Dans l'onglet Journaux, cliquez sur l'onglet Journaux de l'autoscaler pour afficher les journaux.

  5. Facultatif : Pour appliquer des filtres plus avancés afin d'affiner les résultats, cliquez sur le bouton situé à droite de la page pour afficher les journaux dans l'explorateur de journaux.

Pour en savoir plus sur le fonctionnement des événements de scaling à la hausse, consultez Afficher les événements d'autoscaler de cluster. Pour découvrir comment utiliser Cloud Logging, consultez l'exemple de dépannage suivant.

Exemple: Résoudre un problème datant de plus de 72 heures

L'exemple suivant montre comment vous pouvez examiner et résoudre un problème de cluster qui ne s'adapte pas à la hausse.

Scénario : Au cours de la dernière heure, un pod a été marqué comme non programmable. L'autoscaler de cluster n'a provisionné aucun nouveau nœud pour planifier le pod.

Solution :

  1. Comme le problème s'est produit il y a plus de 72 heures, vous examinez le problème à l'aide de Cloud Logging au lieu de consulter les messages de notification.
  2. Dans Cloud Logging, vous trouverez les détails de journalisation des événements de l'autoscaler de cluster, comme décrit dans Afficher les erreurs dans les événements.

  3. Vous recherchez les événements scaleUp contenant le pod que vous étudiez dans le champ triggeringPods. Vous pouvez filtrer les entrées de journal, y compris en fonction d'une valeur de champ JSON particulière. Pour en savoir plus, consultez Requêtes de journaux avancées.

  4. Vous ne trouvez aucun événement de scaling à la hausse. Toutefois, si vous l'avez fait, vous pouvez essayer de trouver un EventResult contenant le même eventId que l'événement scaleUp. Vous pouvez ensuite examiner le champ errorMsg et consulter la liste des messages d'erreur scaleUp possibles.

  5. Comme vous n'avez trouvé aucun événement scaleUp, vous continuez à rechercher les événements noScaleUp et à examiner les champs suivants :

    • unhandledPodGroups : contient des informations sur le pod (ou sur son contrôleur).
    • reason : fournit des motifs globaux indiquant que le scaling à la hausse pourrait être bloqué.
    • skippedMigs : fournit des motifs pour lesquels certains MIG peuvent être ignorés.

  6. Vous avez identifié un événement noScaleUp pour votre pod, et tous les MIG rejectedMigs ont le même ID de message de motif "no.scale.up.mig.failing.predicate" avec deux paramètres, "NodeAffinity" et "node(s) did not match node selector".

Solution :

Après avoir consulté la liste des messages d'erreur, vous constatez que l'autoscaler de cluster ne peut pas effectuer de scaling à la hausse d'un pool de nœuds en raison d'un échec du prédicat de planification pour les pods en attente. Les paramètres sont le nom du prédicat défaillant et le motif de l'échec.

Pour résoudre le problème, vous examinez le fichier manifeste du pod et découvrez qu'il comporte un sélecteur de nœuds qui ne correspond à aucune MIG du cluster. Supprimez le sélecteur du fichier manifeste du pod et recréez le pod. L'autoscaler de cluster ajoute un nœud et le pod est planifié.

Résoudre les erreurs de scaling à la hausse

Si vous utilisez des ComputeClasses personnalisées et que les problèmes de scaling sont liés aux configurations de nœuds spécifiques définies dans votre ComputeClass, consultez Résoudre les problèmes liés aux ComputeClasses personnalisées.

Une fois que vous avez identifié l'erreur, utilisez les tableaux suivants pour comprendre sa cause et la résoudre.

Erreurs liées aux événements scaleUp

Les messages d'erreur concernant les événements scaleUp se trouvent dans l'événement eventResult correspondant, dans le champ resultInfo.results[].errorMsg.

Lorsqu'une opération de scale-up échoue, car elle dépasse un quota, il s'agit d'une erreur de création de nœud qui déclenche une période de backoff du système, qui peut durer jusqu'à 30 minutes. Pour en savoir plus, consultez Périodes de backoff.

Message Détails Paramètres Atténuation
"scale.up.error.out.of.resources" Des erreurs de ressources se produisent lorsque vous tentez de demander de nouvelles ressources dans une zone qui ne peut pas traiter votre requête du fait de l'indisponibilité actuelle d'une ressource Compute Engine, telle que les GPU ou les processeurs. ID des MIG défaillants. Suivez la procédure de résolution des problèmes de disponibilité des ressources dans la documentation Compute Engine.
"scale.up.error.quota.exceeded" L'événement scaleUp a échoué, car certains MIG n'ont pas pu être augmentés en raison d'un dépassement de quota Compute Engine. ID des MIG défaillants. Consultez l'onglet Erreurs du MIG dans la console Google Cloud pour voir quel quota est dépassé. Une fois que vous savez quel quota est dépassé, suivez les instructions pour demander une augmentation de quota.
"scale.up.error.waiting.for.instances.timeout" Échec du scaling à la hausse du groupe d'instances géré en raison de l'expiration du délai. ID des MIG défaillants. Si les instances démarrent, mais ne s'enregistrent pas auprès du plan de contrôle, suivez les étapes de dépannage de l'enregistrement des instances. Ce message devrait être temporaire. Si le problème persiste, contactez l'assistance Cloud Customer Care pour une analyse plus approfondie.
"scale.up.error.ip.space.exhausted" Impossible d'effectuer un scaling à la hausse, car les instances de certains groupes d'instances gérés sont à court d'adresses IP. Cela signifie que le cluster ne dispose pas de suffisamment d'espace d'adresses IP non alloué à utiliser pour ajouter de nouveaux nœuds ou pods. ID des MIG défaillants. Suivez la procédure de dépannage décrite dans Pas assez d'espace d'adresses IP libre pour les pods.
"scale.up.error.service.account.deleted" Impossible de faire évoluer le service, car le compte de service a été supprimé. ID des MIG défaillants. Essayez d'annuler la suppression du compte de service. Si cette procédure ne fonctionne pas, contactez l'assistance Cloud Customer Care pour une analyse plus approfondie.

Motifs de survenue d'un événement noScaleUp

Un événement noScaleUp est émis régulièrement lorsqu'il existe des pods non planifiables dans le cluster et que l'autoscaler de cluster ne peut pas effectuer de scaling à la hausse du cluster pour planifier les pods. Les événements noScaleUp reposent sur le principe du "meilleur effort" et ne couvrent pas tous les cas possibles.

Motifs de premier niveau pour les événements noScaleUp

Les messages de motif de premier niveau pour les événements noScaleUp s'affichent dans le champ noDecisionStatus.noScaleUp.reason. Le message contient un motif de premier niveau pour lequel l'autoscaler de cluster ne peut pas effectuer de scaling à la hausse du cluster.

Message Détails Atténuation
"no.scale.up.in.backoff" Aucun scaling à la hausse, car cette opération est dans une période d'interruption (temporairement bloquée). Il s'agit d'un message qui peut survenir lors des événements de scaling à la hausse comportant un grand nombre de pods. Ce message devrait être temporaire. Vérifiez cette erreur dans quelques minutes. Si ce message persiste, contactez l'assistance Cloud Customer Care pour une analyse plus approfondie.

Motifs de premier niveau liés au provisionnement automatique des nœuds pour les événements noScaleUp

Les messages de motif de premier niveau lié au provisionnement automatique des nœuds pour les événements noScaleUp s'affichent dans le champ noDecisionStatus.noScaleUp.napFailureReason. Le message contient un motif de premier niveau pour lequel l'autoscaler de cluster ne peut pas provisionner de nouveaux pools de nœuds.

Message Détails Atténuation
"no.scale.up.nap.disabled"

Le provisionnement automatique des nœuds n'a pas pu effectuer de scaling à la hausse, car il n'est pas activé au niveau du cluster.

Si le provisionnement automatique des nœuds est désactivé, les nouveaux nœuds ne sont pas provisionnés automatiquement si le pod en attente présente des exigences qui ne peuvent pas être satisfaites par des pools de nœuds existants.

 Vérifiez la configuration du cluster et envisagez d'activer le provisionnement automatique des nœuds.

Motifs de niveau MIG pour les événements noScaleUp

Les messages de motif de niveau MIG pour les événements noScaleUp s'affichent dans les champs noDecisionStatus.noScaleUp.skippedMigs[].reason et noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. Le message contient un motif pour lequel l'autoscaler de cluster ne peut pas augmenter la taille d'un MIG particulier.

Message Détails Paramètres Atténuation
"no.scale.up.mig.skipped" Impossible d'effectuer un scaling à la hausse d'un MIG, car il a été ignoré lors de la simulation. Motifs pour lesquels le MIG a été ignoré (par exemple, absence d'une exigence de pod). Examinez les paramètres inclus dans le message d'erreur et indiquez la raison pour laquelle le MIG a été ignoré.
"no.scale.up.mig.failing.predicate" Impossible d'effectuer un scaling à la hausse d'un pool de nœuds en raison d'un échec du prédicat de planification pour les pods en attente. Nom du prédicat défaillant et motifs de l'échec. Examinez les exigences du pod, telles que les règles d'affinité, les rejets ou les tolérances, ainsi que les besoins en ressources.

Motifs de niveau groupe de pods liés au provisionnement automatique des nœuds pour les événements noScaleUp

Les messages de motif de provisionnement automatique des nœuds au niveau du groupe de pods pour les événements noScaleUp s'affichent dans le champ noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. Le message contient un motif pour lequel l'autoscaler de cluster ne peut pas provisionner de pool de nœuds pour planifier un groupe de pods particulier.

Message Détails Paramètres Atténuation
"no.scale.up.nap.pod.gpu.no.limit.defined" Le provisionnement automatique des nœuds n'a pas pu provisionner de groupe de nœuds, car un pod en attente reçoit une requête de GPU, mais les limites de ressources des GPU ne sont pas définies au niveau du cluster. Type de GPU demandé. Examinez la requête de GPU du pod en attente et mettez à jour la configuration du provisionnement automatique des nœuds au niveau du cluster pour les limites de GPU.
"no.scale.up.nap.pod.gpu.type.not.supported" Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod, car il reçoit des requêtes pour un type de GPU inconnu. Type de GPU demandé. Vérifiez la configuration du pod en attente pour le type de GPU afin de vous assurer qu'il correspond à un type de GPU compatible.
"no.scale.up.nap.pod.zonal.resources.exceeded" Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod dans cette zone, car cela enfreindrait les limites de ressources maximales à l'échelle du cluster, cela dépasserait les ressources disponibles dans la zone, ou il n'y a aucun type de machine adapté à la requête. Nom de la zone concernée. Examinez et mettez à jour les limites maximales de ressources à l'échelle du cluster, les demandes de ressources de pod ou les zones disponibles pour le provisionnement automatique des nœuds.
"no.scale.up.nap.pod.zonal.failing.predicates" Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod dans cette zone en raison de prédicats défaillants. Nom de la zone concernée et motifs pour lesquels les prédicats sont défaillants. Examiner les exigences du pod en attente, telles que les règles d'affinité, les rejets, les tolérances ou les besoins en ressources.

Effectuer d'autres investigations

Les sections suivantes expliquent comment utiliser l'explorateur de journaux et gcpdiag pour obtenir des informations supplémentaires sur vos erreurs.

Analyser les erreurs dans l'explorateur de journaux

Si vous souhaitez examiner plus en détail votre message d'erreur, consultez les journaux spécifiques à votre erreur :

  1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Dans le volet Requête, saisissez la requête suivante :

    resource.type="k8s_cluster"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"

    Remplacez ERROR_MESSAGE par le message que vous souhaitez examiner. Exemple :scale.up.error.out.of.resources

  3. Cliquez sur Exécuter la requête.

Déboguer certaines erreurs avec gcpdiag

gcpdiag est un outil Open Source créé avec l'aide d'ingénieurs techniques Google Cloud. Il ne s'agit pas d'un produit Google Cloud officiellement pris en charge.

Si l'un des messages d'erreur suivants s'affiche, vous pouvez utiliser gcpdiag pour résoudre le problème:

  • scale.up.error.out.of.resources
  • scale.up.error.quota.exceeded
  • scale.up.error.waiting.for.instances.timeout
  • scale.up.error.ip.space.exhausted
  • scale.up.error.service.account.deleted

Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.

Résoudre les erreurs de scaling à la hausse complexes

Les sections suivantes vous aident à résoudre les erreurs qui nécessitent plusieurs étapes ou auxquelles aucun message d'événement de l'autoscaler de cluster n'est associé.

Le pod ne tient pas sur le nœud

Symptômes :

Vos pods restent à l'état Pending avec le message d'erreur PodUnschedulable, ou votre cluster affiche le message d'erreur Pods unschedulable et l'autoscaler de cluster ne procède pas au scaling à la hausse pour ajouter des nœuds.

Cause :

L'autoscaler de cluster n'ajoute des nœuds à un pool de nœuds que si le type de machine fournit suffisamment de ressources (processeurs, GPU, mémoire et stockage, par exemple) pour un pod en attente. Si les requêtes de ressources d'un pod dépassent les ressources d'un seul nœud, l'autoscaler de cluster n'effectue pas de scaling à la hausse, car le pod ne peut toujours pas tenir sur un nouveau nœud.

De plus, les ressources pouvant être allouées à un nœud sont inférieures à ses ressources totales, car les composants système en réservent une partie. Pour en savoir plus sur la façon dont GKE calcule les ressources pouvant être allouées, consultez Ressources pouvant être allouées aux nœuds.

Solution :

Pour vérifier si les requêtes de ressources d'un pod dépassent les ressources fournies par vos nœuds et résoudre le problème, procédez comme suit. Cet exemple vérifie les ressources de processeur, mais les mêmes étapes s'appliquent aux ressources de GPU, de mémoire et de stockage :

  1. Dans la console Google Cloud , accédez à la page Charges de travail.

    Accéder à la page Charges de travail

  2. Cliquez sur le message d'erreur PodUnschedulable.

  3. Dans le volet Détails, cliquez sur le nom du pod. S'il y a plusieurs pods, commencez par le premier et répétez le processus suivant pour chaque pod.

  4. Sur la page Détails du pod, cliquez sur l'onglet YAML.

  5. Notez les requêtes de ressources de chaque conteneur du pod pour trouver le total des requêtes de ressources. Par exemple, dans la configuration de pod suivante, le pod a besoin de deux processeurs virtuels :

    resources:
  limits:
    cpu: "3"
  requests:
    cpu: "2"

  6. Affichez les détails du pool de nœuds du cluster avec le pod non planifié :

    1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

      Accéder à la page "Clusters Kubernetes"

    2. Cliquez sur le nom du cluster qui affiche le message d'erreur Pods unschedulable.

    3. Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.

    4. Dans la section Pools de nœuds, notez la valeur de la colonne Type de machine (par exemple, n1-standard-1).

  7. Comparez la requête de ressource avec les vCPU fournis par le type de machine. Par exemple, si un pod demande deux processeurs virtuels, mais que les nœuds disponibles utilisent le type de machine n1-standard-1, les nœuds ne disposent que d'un seul processeur virtuel. Avec une configuration comme celle-ci, l'autoscaler de cluster ne déclenche pas de scaling à la hausse, car le pod ne peut toujours pas s'adapter à un nouveau nœud. Pour en savoir plus sur les types de machines disponibles, consultez le Guide des ressources de familles de machines et guide comparatif dans la documentation Compute Engine.

  8. Résolvez l'incohérence en fonction des besoins de votre charge de travail :

    • Si le pod nécessite les requêtes de ressources demandées : créez un pool de nœuds avec un type de machine pouvant prendre en charge les requêtes de ressources du pod.
    • Si les requêtes de ressources du pod ne sont pas exactes : mettez à jour la définition du pod afin qu'il puisse s'adapter aux nœuds existants.

Les clusters non opérationnels empêchent le scaling à la hausse

Symptômes :

L'autoscaler de cluster interrompt toutes les opérations de scaling, et le ConfigMap cluster-autoscaler-status contient un événement de type Warning avec ClusterUnhealthy comme motif.

Pour afficher le ConfigMap cluster-autoscaler-status, exécutez la commande suivante :

kubectl describe configmap cluster-autoscaler-status -n kube-system

Cause :

L'autoscaler de cluster n'effectue pas de scaling à la hausse s'il considère qu'un cluster n'est pas sain. L'autoscaler de cluster détermine l'état du cluster en fonction du ratio de nœuds opérationnels et prêts, et non de l'état du plan de contrôle. Si 45% des nœuds d'un cluster sont défectueux ou non prêts, l'autoscaler de cluster interrompt toutes les opérations.

L'autoscaler de cluster considère également qu'un nœud prêt est NotReady lorsque le nœud présente un rejet avec le préfixe ignore-taint.cluster-autoscaler.kubernetes.io/. L'autoscaler de cluster traite le nœud comme NotReady tant que ce rejet est présent.

Solution :

Pour résoudre ce problème, réduisez le nombre de nœuds défectueux en effectuant l'une des actions suivantes, ou les deux :

  • Examinez et réparez les nœuds NotReady ou non opérationnels afin que moins de 45 % des nœuds du cluster soient non opérationnels.
  • Si les nœuds prêts présentent un taint avec le préfixe ignore-taint.cluster-autoscaler.kubernetes.io/, supprimez-le.

Étapes suivantes