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

Cette page explique comment découvrir et résoudre les problèmes liés à l'autoscaler de cluster qui ne met pas à l'échelle les nœuds de 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 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 ne peut plus être planifié lorsque le planificateur Kubernetes ne peut pas le placer sur un nœud existant en raison de ressources insuffisantes, de contraintes de nœud ou de non-respect des exigences du pod.

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 Filtrer de , saisissez unschedulable, puis appuyez sur Entrée.

    Si des pods sont listés, cela signifie qu'ils ne peuvent pas être planifiés. 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 de passer à l'échelle supérieure. 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'être mis à l'échelle et fonctionne comme prévu.

Vérifier si vous aviez auparavant des pods non planifiables

Si vous recherchez la cause de l'échec de l'autoscaler de cluster par le passé, recherchez les pods qui n'étaient pas programmables auparavant:

  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 de 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 planifiables au cours de la période 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 d'ajustement 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 se met pas à l'échelle.

Scénario: Depuis une heure, un pod est marqué comme non planifiable. 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 des é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 la page 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 liés aux événements scaleUp possibles.

  5. Comme vous ne trouvez aucun événement scaleUp, vous continuez à rechercher des événements noScaleUp et examinez 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 trouvez un événement noScaleUp pour votre pod, et tous les MIG du champ 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 ce 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.

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 dépannage pour la 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 du dépassement du délai avant expiration. ID des MIG défaillants. Ce message devrait être temporaire. Si le problème persiste, contactez l'assistance Cloud Customer Care pour une analyse 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 se sont trouvées à 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 dans la section Pas assez d'espace d'adresses IP libre pour les pods.
"scale.up.error.service.account.deleted" Impossible d'effectuer un scaling à la hausse, 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 approfondie.

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 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 n'a eu lieu, car cette opération est dans une période d'interruption (il est temporairement bloqué). Ce message 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 au bout de 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 être effectué, 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, car un prédicat de planification est défaillant pour les pods en attente. Nom du prédicat défaillant et raisons de l'échec. Examiner 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 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.

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 au 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 considéré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 considéré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, 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 s'adapte pas au nœud

L'autoscaler de cluster ne planifie un pod sur un nœud que s'il existe un nœud disposant de ressources suffisantes (GPU, mémoire et espace de 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 capacité, comparez les demandes de ressources aux ressources fournies.

L'exemple suivant montre comment vérifier les ressources de processeur, mais les mêmes étapes s'appliquent aux GPU, à la mémoire et aux ressources 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 existe plusieurs pods, commencez par le premier et répétez le processus suivant 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 dans le pod pour connaître le total des demandes de ressources. Par exemple, dans la configuration de pod suivante, le pod a besoin de deux vCPU:

    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 associé au 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 indiquée dans la colonne Type de machine. Par exemple, n1-standard-1.

  9. Comparez la requête de ressources aux vCPU fournis par le type de machine. Par exemple, si un pod demande deux processeurs virtuels, mais que les nœuds disponibles ont 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éclencherait pas de scaling à la hausse, car même s'il ajoutait un nouveau nœud, ce pod ne pourrait pas y tenir. 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 ce paramètre, consultez la section Ressources allouables par nœud.

Pour résoudre ce problème, déterminez si les demandes de ressources définies pour la charge de travail sont adaptées à 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 qu'il puisse s'adapter aux nœuds.

Problème: des clusters non opérationnels empêchent l'ajustement à la hausse

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

Si c'est la raison pour laquelle votre autoscaler de cluster ne s'effectue pas, un événement de type Warning est présent dans le 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, réduisez le nombre de nœuds défaillants.

Il est également possible que certains des 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 un nœud comme étant NotReady tant que cette altération est présente.

Si le comportement est causé par la présence d'une corruption ignore-taint.cluster-autoscaler.kubernetes.io/.*, supprimez-la.

Étape suivante