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 à l'état Pending et que de nouveaux nœuds ne sont pas ajoutés, cela indique souvent un problème avec la fonctionnalité de scaling à la hausse de l'autoscaler de cluster. Ce problème peut empêcher vos applications d'évoluer pour répondre à la demande, retarder les déploiements et affecter la disponibilité du service.

Cette page vous permet de diagnostiquer et de résoudre les problèmes courants qui empêchent l'autoscaler de cluster d'ajouter des nœuds. La résolution de ces problèmes permet au programmeur 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 planifient et s'exécutent 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 de charge 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 programmables. Un pod devient non programmable lorsque le programmeur Kubernetes ne peut le placer sur aucun 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 programmeur Kubernetes peut alors planifier le pod sur le nœud nouvellement provisionné.

Vérifier si vous avez des pods non programmables

Pour déterminer si votre cluster doit faire l'objet d'un scaling à la hausse, recherchez les pods non programmé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 liés aux pods non programmables, consultez Erreur : Pod non programmable. La résolution de 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 de scaling à la hausse et fonctionne comme prévu.

Vérifier si vous aviez des pods non programmables

Si vous recherchez la cause de l'échec de l'autoscaler de cluster par le passé, recherchez les pods qui n'étaient pas 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 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 sont listés, cela signifie que vous aviez des pods non programmables au cours de la période spécifiée.

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

Après avoir confirmé que vous disposez de 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.

Analyser les métriques Cloud Monitoring pour détecter les problèmes de scaling à la hausse

L'autoscaler de cluster GKE expose des métriques à Cloud Monitoring qui fournissent des insights sur ses décisions, en particulier en ce qui concerne les ComputeClasses. Ces métriques sont disponibles sur GKE 1.37 et versions ultérieures, et incluent les éléments suivants.

  • Pods en attente : kubernetes.io/autoscaler/cluster_pending_pods_per_ccc affiche les pods que l'autoscaler tente de planifier.
  • Tentatives de provisionnement : kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc suit la fréquence à laquelle l'autoscaler tente d'ajouter des nœuds.
  • Échecs de provisionnement : kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc indique les tentatives de création de nœuds ayant échoué et les raisons de ces échecs.

Ces métriques utilisent le type de ressource k8s_entity, où la valeur du champ resource.labels.entity_type est ComputeClass. La valeur du champ resource.labels.entity_name indique le nom de la ComputeClass. Si le champ entity_name contient une chaîne vide ("") comme valeur, la métrique concerne les décisions de l'autoscaler de cluster qui ne sont pas liées à une ComputeClass.

Utilisez l'Explorateur de métriques pour filtrer et regrouper les résultats par champ entity_name. Par exemple, utilisez la chaîne resource.labels.entity_name = "" pour afficher les activités qui ne sont pas liées aux ComputeClasses, et les libellés de métriques (comme reason) pour déterminer si les problèmes de scaling à la hausse sont spécifiques à une ComputeClass.

Pour obtenir des exemples de requêtes, consultez Surveiller le provisionnement des nœuds et Surveiller l'état des pods en attente.

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 n'augmente pas de taille.

Scénario : Un pod a été marqué comme non programmable au cours de la dernière heure. 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 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'aviez fait, vous pourriez essayer de trouver 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 scaleUp possibles.

  5. Comme vous n'avez trouvé aucun événement scaleUp, vous continuez à rechercher des é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 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 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œ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 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 à la hausse 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 scaling à la hausse é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 d'intervalle exponentiel entre les tentatives du système, qui peut durer jusqu'à 30 minutes. Pour en savoir plus, consultez Périodes d'intervalle exponentiel entre les tentatives.

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 de problèmes 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 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 la section Rechercher une instance dont l'enregistrement des nœuds a échoué. Pour d'autres causes, consultez Les instances MIG n'ont pas pu apparaître à temps. Cette erreur est généralement temporaire. Si l'erreur persiste, contactez 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 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 échoue, 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 des pods non programmables se trouvent dans le cluster et que l'autoscaler de cluster ne peut pas effectuer de 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.

Message Détails Atténuation
"no.scale.up.in.backoff" Pas de scaling à la hausse, car le scaling à la hausse 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 après 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. Raisons pour lesquelles 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 le scaling à la hausse d'un pool de nœuds en raison de l'échec d'un prédicat de planification pour les pods en attente. Nom du prédicat défaillant et motifs 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és 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 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, 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 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 qui ne sont pas associées à un message d'événement de l'autoscaler de cluster.

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 n'effectue pas de 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) pour un pod en attente. Si les demandes 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 réservent une partie de ces ressources. 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 demandes 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 existe 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, cliquez sur l'onglet YAML.

  5. Notez les demandes de ressources de chaque conteneur du pod pour trouver 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"

  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 processeurs virtuels 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 telle configuration, 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 ressources demandées : créez un pool de nœuds avec un type de machine pouvant accepter 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 instances du MIG n'ont pas pu apparaître à temps

Symptômes :

Un des messages d'erreur suivants s'affiche :

  • Dans la console Google Cloud , le cluster affiche la notification suivante :

    Can't scale up because instances in managed instance groups hosting node pools failed to appear in time

  • Dans Logging, l'événement eventResult pour le scaling à la hausse contient le message d'erreur suivant :

    scale.up.error.waiting.for.instances.timeout

Cause :

Compute Engine ne peut pas créer de nœuds dans le MIG, ou les nouveaux nœuds ne parviennent pas à s'enregistrer auprès du plan de contrôle avant l'expiration de l'opération de scaling à la hausse. Ce problème peut survenir pour l'une des raisons suivantes :

  • Échec de l'enregistrement des nœuds : Compute Engine crée les nœuds, mais ils ne s'enregistrent pas auprès du plan de contrôle en raison d'une ou de plusieurs règles de pare-feu, d'une modification récente de l'accès aux services privés ou de l'appairage de réseaux VPC, ou d'un compte de service Identity and Access Management (IAM) manquant.
  • Dépassement des quotas du projet : les nouvelles instances du MIG n'apparaissent pas, car votre projet dépasse un quota de processeurs, d'adresses IP ou d'une autre ressource.
  • Adresses IP indisponibles : le sous-réseau ne dispose pas de suffisamment d'adresses IP libres pour créer des nœuds.
  • Modèle d'instance non valide : le MIG utilise un modèle d'instance non valide, tel qu'un modèle avec une image manquante, ce qui empêche le scaling à la hausse.
  • Ressources insuffisantes : la zone ne dispose pas de suffisamment de ressources Compute Engine, telles que des GPU ou des processeurs, pour créer un nœud.
  • API inaccessibles : une API requise, telle que compute.googleapis.com, n'est pas accessible en raison d'une règle de pare-feu ou d'un périmètre VPC Service Controls.
  • Latence du réseau : une latence importante du réseau retarde la création ou l'utilisation d'un nouveau nœud.

Solution :

  1. Pour identifier la cause du délai avant expiration, listez les erreurs d'instance dans le MIG, puis vérifiez le résultat :

    • Le MIG ne liste pas les erreurs au moment de l'échec : Compute Engine a créé les nœuds, mais ceux-ci ne se sont pas enregistrés auprès du plan de contrôle avant l'expiration du délai. À l'étape suivante, commencez par Échec de l'enregistrement des nœuds. Si les nœuds se sont enregistrés, mais que l'opération a pris trop de temps, consultez Latence du réseau.

    • Le MIG liste les erreurs survenues au moment de l'échec : Compute Engine n'a pas pu créer les nœuds. Utilisez le code d'erreur et le message d'erreur pour trouver la cause à l'étape suivante. Voici quelques codes d'erreur courants :

      • QUOTA_EXCEEDED : quotas de projet dépassés
      • IP_SPACE_EXHAUSTED : adresses IP non disponibles
      • ZONE_RESOURCE_POOL_EXHAUSTED : ressources insuffisantes

      Certains codes d'erreur ont un suffixe _WITH_DETAILS et incluent plus d'informations dans le message d'erreur. Si le message d'erreur signale une ressource qui n'existe pas, telle qu'une image source, consultez la section Modèle d'instance non valide.

  2. Utilisez la résolution qui correspond à la cause de votre problème :

    • Échec de l'enregistrement des nœuds : suivez les étapes de la section Rechercher une instance dont l'enregistrement des nœuds a échoué. Vous pouvez également vérifier les modifications de configuration récentes :

      • Règles de pare-feu : pour vérifier si une règle de pare-feu a été récemment créée, mise à jour ou supprimée, exécutez la requête suivante dans l'explorateur de journaux :

        resource.type="gce_firewall_rule"
log_id("cloudaudit.googleapis.com/activity")

        Si une modification bloque le trafic entre les nœuds et le plan de contrôle ou vers les API Google, mettez à jour ou remplacez la règle de pare-feu. Pour en savoir plus sur la connectivité requise, consultez Conditions préalables à l'enregistrement des nœuds.

      • Compte de service IAM : pour un compte de service manquant, consultez la ligne scale.up.error.service.account.deleted dans le tableau Erreurs de scaling à la hausse.

      • Accès aux services privés : pour vérifier les modifications récentes dans les journaux d'audit, consultez Journalisation d'audit de l'accès aux services privés.

      • Appairage de réseaux VPC : pour vérifier si l'appairage a été récemment ajouté, mis à jour ou supprimé, exécutez la requête suivante dans l'explorateur de journaux pour chaque projet appairé :

        log_id("cloudaudit.googleapis.com/activity")
resource.type="gce_network"
protoPayload.methodName:("compute.networks.addPeering" OR
"compute.networks.updatePeering" OR
"compute.networks.removePeering")

        Si une modification de l'appairage a perturbé la connectivité au plan de contrôle, mettez à jour la connexion d'appairage. Si la connexion a été supprimée, consultez La connexion d'appairage de réseaux VPC est accidentellement supprimée.

    • Quotas de projet dépassés : consultez la ligne scale.up.error.quota.exceeded dans le tableau Erreurs de scaling à la hausse.

    • Adresses IP non disponibles : consultez la ligne scale.up.error.ip.space.exhausted dans le tableau Erreurs de scaling à la hausse.

    • Modèle d'instance non valide : consultez la section Le modèle d'instance n'est pas valide dans la documentation Compute Engine.

    • Ressources insuffisantes : consultez la ligne scale.up.error.out.of.resources dans le tableau Erreurs liées au scaling à la hausse.

    • API inaccessibles : dans l'explorateur de journaux, exécutez une requête pour vérifier l'activité liée aux règles de pare-feu ou aux périmètres VPC Service Controls :

      • Pour vérifier si une règle de pare-feu a été récemment modifiée, exécutez la requête de journal d'audit dans la section Règles de pare-feu de Échec de l'enregistrement du nœud. Si vous avez activé la journalisation des règles de pare-feu pour vos règles, vous pouvez également afficher les connexions refusées par vos règles en exécutant la requête suivante :

        resource.type="gce_subnetwork"
log_id("compute.googleapis.com/firewall")
jsonPayload.disposition="DENIED"

        Si les journaux affichent une règle de pare-feu qui bloque le trafic vers les API Google requises, mettez à jour ou remplacez la règle de pare-feu pour autoriser le trafic. Pour en savoir plus sur les exigences de mise en réseau, consultez Conditions préalables à la connexion réseau aux API et services Google.

      • Si vous utilisez VPC Service Controls, sélectionnez votre organisation dans la console Google Cloud et exécutez la requête suivante dans l'explorateur de journaux pour vérifier si un périmètre a été récemment ajouté ou modifié :

        logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName="accesscontextmanager.googleapis.com"

        Remplacez ORGANIZATION_ID par l'ID de votre organisation.

        Vous pouvez également ajouter les filtres suivants pour rechercher la mise à jour ou la création d'un périmètre VPC Service Controls :

        severity=NOTICE
protoPayload.methodName=("google.identity.accesscontextmanager.v1.AccessContextManager.CreateServicePerimeter"
OR "google.identity.accesscontextmanager.v1.AccessContextManager.UpdateServicePerimeter")

        Si un périmètre nouveau ou modifié bloque l'accès aux API Google requises, récupérez les erreurs VPC Service Controls à partir des journaux d'audit pour identifier le service bloqué et mettez à jour le périmètre de service pour autoriser l'accès. Pour en savoir plus sur l'utilisation de l'autoscaler de cluster dans un périmètre, consultez L'autoscaler ne fonctionne pas dans les périmètres où les services accessibles et les services restreints sont activés.

    • Latence du réseau : la latence réseau temporaire se résout généralement lors des tentatives de scaling à la hausse ultérieures. Pour résoudre les problèmes de latence persistante, consultez Résoudre les problèmes de mise en réseau courants dans la documentation Compute Engine.

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 opérationnel. 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 ne sont pas opérationnels ou ne sont pas 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 non opérationnels en effectuant l'une des actions suivantes ou les deux :

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

Étapes suivantes