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

Cette page explique comment identifier et résoudre les problèmes liés à l'autoscaler de cluster qui n'augmente pas le nombre de nœuds dans vos clusters Google Kubernetes Engine (GKE).

Cette page s'adresse aux développeurs d'applications qui souhaitent résoudre une situation inattendue ou négative avec leur application ou leur service, ainsi qu'aux administrateurs et opérateurs de plate-forme qui souhaitent éviter toute interruption de la livraison de produits et de services.

Comprendre quand l'autoscaler de cluster augmente le nombre de 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 programmables. Un pod devient non programmable 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 programmateur 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 Filtrer filter_list, 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 liés aux pods non programmables, consultez Erreur : Pod non programmable. Résoudre la cause sous-jacente des pods non programmables 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 précédemment 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 programmables :

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 sont listés, cela signifie que vous aviez des pods non planifiables dans la plage de temps que vous avez spécifiée.

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

Après avoir confirmé que vous avez des pods non programmé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 en consultant les messages d'erreur :

• Si vous avez déjà reçu un message d'erreur, consultez le tableau des messages d'erreur pour obtenir des conseils sur la résolution de l'erreur.

• Si vous n'avez pas encore reçu de message, utilisez l'une des options suivantes:

  • Problèmes datant de moins de 72 heures : affichez les notifications d'erreur dans la console Google Cloud .
  • Problèmes datant de plus de 72 heures : afficher les erreurs dans les événements de Cloud Logging

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'étend pas.

Scénario : Un pod est marqué comme non planifiable depuis une heure. L'autoscaler de cluster n'a pas provisionné de nouveaux nœuds 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 en avez trouvé un, vous pouvez essayer de rechercher un événement EventResult contenant la même valeur eventId que l'événement scaleUp. Vous pouvez ensuite examiner le champ errorMsg et consulter la liste des messages d'erreur liés aux événements 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, car un prédicat de planification est défaillant 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 dispose d'un sélecteur de nœud qui ne correspond à aucun MIG du cluster. Vous supprimez le sélecteur du fichier manifeste du pod et recréez le pod. L'autoscaler de cluster ajoute un nouveau nœud, et le pod est programmé.

Résoudre les erreurs de scaling à la hausse

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.

Motifs de survenue d'un événement noScaleUp

Un événement noScaleUp est émis régulièrement lorsque le cluster comporte des pods non programmables et que l'autoscaler de cluster ne peut pas effectuer un scaling à la hausse du cluster pour programmer 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.

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.

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.

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

Les messages de motif de niveau groupe de pods lié au provisionnement automatique des nœuds 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 un nouveau pool de nœuds pour planifier un groupe de pods particulier.

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, affichez 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 compatible.

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 fournissent des conseils pour résoudre les erreurs impliquant plusieurs étapes et les erreurs auxquelles aucun message d'événement de l'autoscaler de cluster n'est associé.

Problème : le pod ne tient pas sur le nœud

L'autoscaler de cluster ne planifie un pod sur un nœud que si ce nœud dispose de ressources suffisantes (GPU, mémoire et stockage, par exemple) pour répondre aux exigences du pod. Pour déterminer si c'est la raison pour laquelle l'autoscaler de cluster n'a pas augmenté la taille du cluster, comparez les demandes de ressources avec les ressources fournies.

L'exemple suivant montre comment vérifier les ressources de processeur, mais les mêmes étapes s'appliquent aux ressources de GPU, de mémoire et de stockage. Pour comparer les demandes de processeur aux processeurs provisionnés, procédez comme suit :

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 la procédure suivante pour chaque pod.

4. Sur la page "Détails du pod", accédez à l'onglet Événements.

5. Dans l'onglet Événements, accédez à l'onglet YAML.

6. Notez les demandes de ressources de chaque conteneur du pod pour connaître le total des demandes 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"
   

7. 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, accédez à l'onglet Nœuds.

8. Dans la section Pools de nœuds, notez la valeur de la colonne Type de machine. Par exemple, n1-standard-1.

9. Comparez la demande de ressources avec les processeurs virtuels fournis par le type de machine. Par exemple, si un pod demande deux processeurs virtuels, mais que les nœuds disponibles sont de type de machine n1-standard-1, les nœuds ne disposent que d'un processeur virtuel. Avec une configuration comme celle-ci, l'autoscaler de cluster ne déclencherait pas de scaling à la hausse, car même s'il ajoutait un nouveau nœud, ce pod ne pourrait pas y être placé. 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.

N'oubliez pas non plus que les ressources allouables d'un nœud sont inférieures aux ressources totales, car une partie est nécessaire pour exécuter les composants système. Pour en savoir plus sur le calcul de cette valeur, consultez Ressources allouables des nœuds.

Pour résoudre ce problème, déterminez si les demandes de ressources définies pour la charge de travail répondent à vos besoins. Si le type de machine ne doit pas être modifié, créez un pool de nœuds avec un type de machine compatible avec la requête provenant du pod. Si les demandes de ressources du pod ne sont pas exactes, mettez à jour la définition du pod afin que les pods puissent s'adapter aux nœuds.

Problème : des clusters non opérationnels empêchent le scaling à la hausse

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

Si c'est la raison pour laquelle votre autoscaler de cluster n'effectue pas de scaling à la hausse, un événement de type Warning est disponible dans la ConfigMap de l'autoscaler de cluster, avec ClusterUnhealthy comme motif.

Pour afficher le ConfigMap, exécutez la commande suivante :

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

Pour résoudre ce problème, diminuez le nombre de nœuds non opérationnels.

Il est également possible que certains nœuds soient prêts, mais qu'ils ne soient pas considérés comme tels par l'autoscaler de cluster. Cela se produit lorsqu'un rejet avec le préfixe ignore-taint.cluster-autoscaler.kubernetes.io/ est présent sur un nœud. L'autoscaler de cluster considère qu'un nœud est NotReady tant que cette contamination est présente.

Si le comportement est dû à la présence d'un taint ignore-taint.cluster-autoscaler.kubernetes.io/.*, supprimez-le.

Étapes suivantes

• Consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes.

• Regardez une vidéo YouTube sur le dépannage et la résolution des problèmes de scaling.

• Si vous ne trouvez pas de solution à votre problème dans la documentation, consultez Obtenir de l'aide pour obtenir une assistance supplémentaire, y compris des conseils sur les sujets suivants :

  • Ouvrez une demande d'assistance en contactant le service client Google Cloud.
  • Obtenir de l'aide de la communauté en posant des questions sur Stack Overflow et en utilisant le tag google-kubernetes-engine pour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack #kubernetes-engine pour obtenir de l'aide auprès de la communauté.
  • Signaler des bugs ou demander des fonctionnalités à l'aide de l'outil public de suivi des problèmes.