Afficher les événements de l'autoscaler de cluster

Cette page décrit les décisions prises par l'autoscaler de cluster Google Kubernetes Engine (GKE) concernant l'autoscaling.

L'autoscaler de cluster GKE émet des événements de visibilité, disponibles sous forme d'entrées de journal dans Cloud Logging.

Les événements décrits dans ce guide sont distincts des événements Kubernetes produits par l'autoscaler de cluster.

Conditions de disponibilité

Il est possible d'afficher les événements journalisés pour l'autoscaler de cluster dans les versions de cluster suivantes :

Type d'événement Version du cluster
status, scaleUp, scaleDown, eventResult 1.15.4-gke.7 et versions ultérieures
nodePoolCreated, nodePoolDeleted. 1.15.4-gke.18 et versions ultérieures
noScaleUp 1.16.6-gke.3 et versions ultérieures
noScaleDown 1.16.8-gke.2 et versions ultérieures

Pour afficher les événements de l'autoscaler, vous devez activer Cloud Logging dans votre cluster. Les événements ne seront pas générés si la journalisation est désactivée.

Afficher des événements

Les événements de visibilité de l'autoscaler de cluster sont stockés dans un journal Cloud Logging, dans le même projet que celui où se trouve votre cluster GKE. Vous pouvez également consulter ces événements à partir des notifications sur la page Google Kubernetes Engine de la console Google Cloud.

Afficher les journaux d'événements de visibilité

Pour afficher les journaux, procédez comme suit :

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

    Accéder à la page Clusters Kubernetes

  2. Sélectionnez le nom de votre cluster 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.

Afficher les notifications d'événements de visibilité

Pour afficher les notifications d'événements de visibilité sur la page Google Kubernetes Engine, procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans la console Google Cloud :

    Accéder à Google Kubernetes Engine

  2. Recherchez les notifications spécifiques au scaling dans la colonne Notifications pour des clusters spécifiques.

  3. Cliquez sur la notification pour obtenir des informations détaillées, des actions recommandées et pour accéder aux journaux de cet événement.

Types d'événements

Tous les événements journalisés sont au format JSON et se trouvent dans le champ jsonPayload d'une entrée de journal. Tous les horodatages des événements sont des horodatages UNIX exprimés en secondes.

Voici un résumé des types d'événements émis par l'autoscaler de cluster :

Type d'événement Description
status Se produit régulièrement et décrit la taille de tous les pools de nœuds avec autoscaling ainsi que leur taille cible, telles qu'observées par l'autoscaler de cluster.
scaleUp Se produit lorsque l'autoscaler de cluster effectue un scaling à la hausse du cluster.
scaleDown Se produit lorsque l'autoscaler de cluster effectue un scaling à la baisse du cluster.
eventResult Se produit lorsqu'un événement scaleUp ou scaleDown aboutit ou échoue.
nodePoolCreated Se produit lorsque l'autoscaler de cluster sur lequel le provisionnement automatique des nœuds est activé crée un pool de nœuds.
nodePoolDeleted Se produit lorsque l'autoscaler de cluster sur lequel le provisionnement automatique des nœuds est activé supprime un pool de nœuds.
noScaleUp Se produit 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 l'adapter aux pods.
noScaleDown Se produit lorsque certains nœuds ne peuvent pas être supprimés par l'autoscaler de cluster.

Événement de type Status

Un événement status est émis régulièrement et décrit la taille réelle de tous les pools de nœuds avec autoscaling ainsi que leur taille cible, telles qu'observées par l'autoscaler de cluster.

Exemple

L'exemple de journal suivant montre un événement status :

{
  "status": {
    "autoscaledNodesCount": 4,
    "autoscaledNodesTarget": 4,
    "measureTime": "1582898536"
  }
}

Événement de type scaleUp

Un événement scaleUp est émis lorsque l'autoscaler de cluster effectue un scaling à la hausse du cluster. L'autoscaler augmente la taille des pools de nœuds du cluster en effectuant un scaling à la hausse des groupes d'instances gérés (MIG) sous-jacents des pools de nœuds. Pour en savoir plus sur le fonctionnement du scaling à la hausse, consultez la page Fonctionnement du scaling à la hausse dans les questions fréquentes sur l'autoscaler de cluster Kubernetes.

L'événement contient des informations sur les MIG soumis à un scaling à la hausse, par nombre de nœuds, et sur les pods non programmables ayant déclenché l'événement.

La liste des pods déclencheurs est tronquée à 50 entrées arbitraires. Le nombre réel de pods déclencheurs est indiqué dans le champ triggeringPodsTotalCount.

Exemple

L'exemple de journal suivant montre un événement scaleUp :

{
  "decision": {
    "decideTime": "1582124907",
    "eventId": "ed5cb16d-b06f-457c-a46d-f75dcca1f1ee",
    "scaleUp": {
      "increasedMigs": [
        {
          "mig": {
            "name": "test-cluster-default-pool-a0c72690-grp",
            "nodepool": "default-pool",
            "zone": "us-central1-c"
          },
          "requestedNodes": 1
        }
      ],
      "triggeringPods": [
        {
          "controller": {
            "apiVersion": "apps/v1",
            "kind": "ReplicaSet",
            "name": "test-85958b848b"
          },
          "name": "test-85958b848b-ptc7n",
          "namespace": "default"
        }
      ],
      "triggeringPodsTotalCount": 1
    }
  }
}

Événement de type scaleDown

Un événement scaleDown est émis lorsque l'autoscaler de cluster effectue un scaling à la baisse du cluster. Pour en savoir plus sur le fonctionnement du scaling à la baisse, consultez la page Fonctionnement du scaling à la baisse dans les questions fréquentes sur l'autoscaler de cluster Kubernetes.

Les champs cpuRatio et memRatio décrivent l'utilisation du processeur et de la mémoire du nœud, sous forme de pourcentage. Cette utilisation correspond à la somme des requêtes de pods divisée par la quantité allouable sur le nœud, et non à l'utilisation réelle.

La liste des pods évincés est tronquée à 50 entrées arbitraires. Le nombre réel de pods évincés est indiqué dans le champ evictedPodsTotalCount.

Utilisez la requête suivante pour vérifier si l'autoscaler de cluster a effectué un scaling à la baisse des nœuds :

resource.type="k8s_cluster" \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
log_id("container.googleapis.com/cluster-autoscaler-visibility") \
( "decision" NOT "noDecisionStatus" )

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster.

  • COMPUTE_REGION : région Compute Engine du cluster, telle que us-central1.

Exemple

L'exemple de journal suivant montre un événement scaleDown :

{
  "decision": {
    "decideTime": "1580594665",
    "eventId": "340dac18-8152-46ff-b79a-747f70854c81",
    "scaleDown": {
      "nodesToBeRemoved": [
        {
          "evictedPods": [
            {
              "controller": {
                "apiVersion": "apps/v1",
                "kind": "ReplicaSet",
                "name": "kube-dns-5c44c7b6b6"
              },
              "name": "kube-dns-5c44c7b6b6-xvpbk"
            }
          ],
          "evictedPodsTotalCount": 1,
          "node": {
            "cpuRatio": 23,
            "memRatio": 5,
            "mig": {
              "name": "test-cluster-default-pool-c47ef39f-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-f"
            },
            "name": "test-cluster-default-pool-c47ef39f-p395"
          }
        }
      ]
    }
  }
}

Vous pouvez également afficher l'événement scale-down sur les nœuds sans charge de travail en cours d'exécution (généralement uniquement les pods système créés par des DaemonSets). Utilisez la requête suivante pour afficher les journaux des événements :

resource.type="k8s_cluster" \
resource.labels.project_id=PROJECT_ID \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
severity>=DEFAULT \
logName="projects/PROJECT_ID/logs/events" \
("Scale-down: removing empty node")

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet.

  • CLUSTER_NAME : nom du cluster.

  • COMPUTE_REGION : région Compute Engine du cluster, telle que us-central1.

Événement de type EventResult

Un événement eventResult est émis lorsqu'un événement scaleUp ou scaleDown aboutit ou échoue. Cet événement contient une liste d'ID d'événement (du champ eventId dans les événements scaleUp ou scaleDown), ainsi que des messages d'erreur. Un message d'erreur vide indique que l'événement a abouti. Une liste d'événements eventResult est agrégée dans le champ results.

Pour diagnostiquer les erreurs, consultez les sections Erreurs liées aux événements scaleUp et Erreurs liées aux événements scaleDown.

Exemple

L'exemple de journal suivant montre un événement eventResult :

{
  "resultInfo": {
    "measureTime": "1582878896",
    "results": [
      {
        "eventId": "2fca91cd-7345-47fc-9770-838e05e28b17"
      },
      {
        "errorMsg": {
          "messageId": "scale.down.error.failed.to.delete.node.min.size.reached",
          "parameters": [
            "test-cluster-default-pool-5c90f485-nk80"
          ]
        },
        "eventId": "ea2e964c-49b8-4cd7-8fa9-fefb0827f9a6"
      }
    ]
  }
}

Événement de type NodePoolCreated

Un événement nodePoolCreated est émis lorsque l'autoscaler de cluster sur lequel le provisionnement automatique des nœuds est activé crée un pool de nœuds. Cet événement contient le nom du pool de nœuds créé et une liste de ses MIG sous-jacents. Si le pool de nœuds a été créé en raison d'un événement scaleUp, la valeur eventId de l'événement scaleUp correspondant est incluse dans le champ triggeringScaleUpId.

Exemple

L'exemple de journal suivant montre un événement nodePoolCreated :

{
  "decision": {
    "decideTime": "1585838544",
    "eventId": "822d272c-f4f3-44cf-9326-9cad79c58718",
    "nodePoolCreated": {
      "nodePools": [
        {
          "migs": [
            {
              "name": "test-cluster-nap-n1-standard--b4fcc348-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-f"
            },
            {
              "name": "test-cluster-nap-n1-standard--jfla8215-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-c"
            }
          ],
          "name": "nap-n1-standard-1-1kwag2qv"
        }
      ],
      "triggeringScaleUpId": "d25e0e6e-25e3-4755-98eb-49b38e54a728"
    }
  }
}

Événement de type NodePoolDeleted

Un événement nodePoolDeleted est émis lorsque l'autoscaler de cluster sur lequel le provisionnement automatique des nœuds est activé supprime un pool de nœuds.

Exemple

L'exemple de journal suivant montre un événement nodePoolDeleted :

{
  "decision": {
    "decideTime": "1585830461",
    "eventId": "68b0d1c7-b684-4542-bc19-f030922fb820",
    "nodePoolDeleted": {
      "nodePoolNames": [
        "nap-n1-highcpu-8-ydj4ewil"
      ]
    }
  }
}

Événement de type 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 l'adapter aux pods.

  • Les événements noScaleUp reposent sur le principe du "meilleur effort", c'est-à-dire qu'ils ne couvrent pas tous les motifs possibles pour lesquels l'autoscaler de cluster ne peut pas effectuer un scaling à la hausse.
  • Les événements noScaleUp sont limités afin de restreindre le volume de journaux produit. Chaque motif persistant n'est émis que toutes les deux minutes.
  • Tous les motifs peuvent être répartis de manière arbitraire entre plusieurs événements. Par exemple, il n'y a aucune garantie que tous les motifs de rejet des MIG pour un seul groupe de pods apparaissent dans le même événement.
  • La liste des groupes de pods non gérés est tronquée à 50 entrées arbitraires. Le nombre réel de groupes de pods non gérés est indiqué dans le champ unhandledPodGroupsTotalCount.

Champs de motif

Les champs suivants expliquent pourquoi le scaling à la hausse n'a pas eu lieu :

  • reason : fournit un motif global pour lequel l'autoscaler de cluster ne peut pas effectuer de scaling à la hausse. Pour en savoir plus, consultez la section Motifs de premier niveau pour les événements noScaleUp.
  • napFailureReason : fournit un motif global empêchant l'autoscaler de cluster de provisionner des pools de nœuds supplémentaires (par exemple, le provisionnement automatique des nœuds est désactivé). Pour en savoir plus, consultez la section Motifs de premier niveau liés au provisionnement automatique des nœuds pour les événements noScaleUp.
  • skippedMigs[].reason : fournit des informations sur le motif pour lequel un MIG spécifique a été ignoré. L'autoscaler de cluster ignore certains MIG d'un pod lors d'une tentative de scaling à la hausse (car l'ajout d'un autre nœud entraînerait le dépassement des limites de ressources à l'échelle du cluster, par exemple). Pour en savoir plus, consultez la section Motifs de niveau MIG pour les événements noScaleUp.
  • unhandledPodGroups : contient des informations sur le motif pour lequel un groupe particulier de pods non programmables ne déclenche pas le scaling à la hausse. Les pods sont regroupés par leur contrôleur immédiat. Les pods sans contrôleur assurent eux-mêmes leur regroupement. Chaque groupe de pods contient un exemple de pod arbitraire et le nombre de pods du groupe, ainsi que les motifs suivants :

Exemple

L'exemple de journal suivant montre un événement noScaleUp :

{
  "noDecisionStatus": {
    "measureTime": "1582523362",
    "noScaleUp": {
      "skippedMigs": [
        {
          "mig": {
            "name": "test-cluster-nap-n1-highmem-4-fbdca585-grp",
            "nodepool": "nap-n1-highmem-4-1cywzhvf",
            "zone": "us-central1-f"
          },
          "reason": {
            "messageId": "no.scale.up.mig.skipped",
            "parameters": [
              "max cluster cpu limit reached"
            ]
          }
        }
      ],
      "unhandledPodGroups": [
        {
          "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              "parameters": [
                "us-central1-f"
              ]
            }
          ],
          "podGroup": {
            "samplePod": {
              "controller": {
                "apiVersion": "v1",
                "kind": "ReplicationController",
                "name": "memory-reservation2"
              },
              "name": "memory-reservation2-6zg8m",
              "namespace": "autoscaling-1661"
            },
            "totalPodCount": 1
          },
          "rejectedMigs": [
            {
              "mig": {
                "name": "test-cluster-default-pool-b1808ff9-grp",
                "nodepool": "default-pool",
                "zone": "us-central1-f"
              },
              "reason": {
                "messageId": "no.scale.up.mig.failing.predicate",
                "parameters": [
                  "NodeResourcesFit",
                  "Insufficient memory"
                ]
              }
            }
          ]
        }
      ],
      "unhandledPodGroupsTotalCount": 1
    }
  }
}

Événement de type noScaleDown

Un événement noScaleDown est émis régulièrement lorsque des nœuds ne peuvent pas être supprimés par l'autoscaler de cluster.

  • Les nœuds qui ne peuvent pas être supprimés, car leur utilisation est élevée, ne sont pas inclus dans les événements noScaleDown.
  • Les événements noScaleDown reposent sur le principe du "meilleur effort", c'est-à-dire qu'ils ne couvrent pas tous les motifs possibles pour lesquels l'autoscaler de cluster ne peut pas effectuer un scaling à la baisse.
  • Les événements noScaleDown sont limités afin de restreindre le volume de journaux produit. Chaque motif persistant n'est émis que toutes les deux minutes.
  • La liste des nœuds est tronquée à 50 entrées arbitraires. Le nombre réel de nœuds est indiqué dans le champ nodesTotalCount.

Champs de motif

Les champs suivants expliquent pourquoi le scaling à la baisse n'a pas eu lieu :

  • reason : fournit un motif global pour lequel l'autoscaler de cluster ne peut pas effectuer de scaling à la baisse (par exemple, une période d'interruption après l'exécution récente d'un scaling à la hausse). Pour en savoir plus, consultez la section Motifs de premier niveau pour les événements noScaleDown.
  • nodes[].reason : fournit des motifs de niveau nœud pour lesquels l'autoscaler de cluster ne peut pas supprimer un nœud particulier (par exemple, il n'y a pas d'emplacement où déplacer les pods du nœud). Pour en savoir plus, consultez la section Motifs de niveau nœud pour les événements noScaleDown.

Exemple

L'exemple de journal suivant montre un événement noScaleDown :

{
  "noDecisionStatus": {
    "measureTime": "1582858723",
    "noScaleDown": {
      "nodes": [
        {
          "node": {
            "cpuRatio": 42,
            "mig": {
              "name": "test-cluster-default-pool-f74c1617-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-c"
            },
            "name": "test-cluster-default-pool-f74c1617-fbhk"
          },
          "reason": {
            "messageId": "no.scale.down.node.no.place.to.move.pods"
          }
        }
      ],
      "nodesTotalCount": 1,
      "reason": {
        "messageId": "no.scale.down.in.backoff"
      }
    }
  }
}

Résoudre les problèmes de scaling

Cette section explique comment résoudre des problèmes liés à des événements de scaling.

Impossible d'effectuer un scaling à la hausse du cluster

Scénario : J'ai créé un pod dans mon cluster, mais il est resté bloqué à l'état En attente au cours de la dernière heure. L'autoscaler de cluster n'a pas provisionné de nouveaux nœuds pour adapter le cluster au pod.

Solution :

  1. Dans l'explorateur de journaux, recherchez les détails de journalisation liés aux événements de l'autoscaler de cluster, comme décrit dans la section Afficher des événements.

  2. Recherchez les événements scaleUp contenant le pod souhaité 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.

    1. Recherchez un événement EventResult contenant la même valeur eventId que l'événement scaleUp.
    2. Examinez le champ errorMsg et consultez la liste des messages d'erreur liés aux événements scaleUp possibles.

    Exemple d'erreur liée à un événement scaleUp : Pour un événement scaleUp, vous constatez que l'erreur est "scale.up.error.quota.exceeded", ce qui indique que "un événement scaleUp a échoué, car certains MIG n'ont pas pu être augmentés en raison d'un dépassement de quota". Pour résoudre le problème, vous examinez vos paramètres de quota et augmentez ceux qui sont sur le point d'être dépassés. L'autoscaler de cluster ajoute un nouveau nœud, et le pod est programmé.

  3. Sinon, recherchez les é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.

  4. Reportez-vous aux sections suivantes pour connaître les motifs possibles de survenue des événements noScaleUp :

    Exemple d'événement noScaleUp : 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". Après avoir consulté la liste des messages d'erreur, vous constatez que "vous ne pouvez pas procéder au scaling à la hausse d'un MIG, car un prédicat a échoué pour ce MIG". 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 la spécification 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 de la spécification du pod et recréez le pod. L'autoscaler de cluster ajoute un nouveau nœud, et le pod est programmé.

  5. S'il n'y a pas d'événement noScaleUp, utilisez d'autres méthodes de débogage pour résoudre le problème.

Impossible d'effectuer un scaling à la baisse du cluster

Scénario : J'ai créé un nœud dans mon cluster qui n'a utilisé que 10 % de son processeur et de sa mémoire au cours des derniers jours. Malgré cette faible utilisation, l'autoscaler de cluster n'a pas supprimé le nœud comme prévu.

Solution :

  1. Dans l'explorateur de journaux, recherchez les détails de journalisation liés aux événements de l'autoscaler de cluster, comme décrit dans la section Afficher des événements.
  2. Recherchez les événements scaleDown contenant le nœud souhaité dans le champ nodesToBeRemoved. 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.
    1. Dans l'événement scaleDown, recherchez un événement EventResult contenant la valeur eventId associée.
    2. Examinez le champ errorMsg et consultez la liste des messages d'erreur liés aux événements scaleDown possibles.
  3. Sinon, recherchez les événements noScaleDown qui ont le nœud souhaité dans le champ nodes. Recherchez dans le champ reason des motifs globaux indiquant que le scaling à la baisse pourrait être bloqué.

  4. Reportez-vous aux sections suivantes pour connaître les motifs possibles de survenue des événements noScaleDown :

    Exemple d'événement noScaleDown : Vous avez identifié un événement noScaleDown contenant un motif de niveau nœud pour votre nœud. L'ID du message est "no.scale.down.node.pod.has.local.storage", et il n'existe qu'un seul paramètre : "test-single-pod". Après avoir consulté la liste des messages d'erreur, vous constatez que cela signifie que "le pod bloque le scaling à la baisse, car il demande un stockage en local". Vous consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes et découvrez que la solution consiste à ajouter une annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" au pod. Une fois l'annotation appliquée, l'autoscaler de cluster effectue correctement le scaling à la baisse du cluster.

  5. S'il n'y a pas d'événement noScaleDown, utilisez d'autres méthodes de débogage pour résoudre le problème.

Messages

Les événements émis par l'autoscaler de cluster utilisent des messages paramétrés pour fournir des explications sur leur survenue. Le champ parameters est disponible avec le champ messageId, comme dans cet exemple de journal pour un événement NoScaleUp.

Cette section décrit diverses valeurs messageId et indique les paramètres correspondants. Toutefois, elle ne contient pas tous les messages possibles et peut être étendue à tout moment.

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 Description Atténuation
"scale.up.error.out.of.resources" L'événement scaleUp a échoué, car certains MIG n'ont pas pu être augmentés en raison d'un manque de ressources.

Paramètres : ID des MIG défaillants.

 Suivez la procédure de résolution de problèmes pour la disponibilité des ressources.
"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.

Paramètres : ID des MIG défaillants.

 Consultez l'onglet Erreurs du MIG dans la console Google Cloud pour voir quel quota est dépassé. Suivez les instructions pour demander une augmentation de quota.
"scale.up.error.waiting.for.instances.timeout" L'événement scaleUp a échoué, car les instances de certains MIG n'ont pas pu apparaître à temps.

Paramètres : ID des MIG défaillants.

 Ce message est temporaire. Si ce n'est pas le cas, contactez l'assistance Google Cloud pour une analyse approfondie.
"scale.up.error.ip.space.exhausted" L'événement scaleUp a échoué, car le cluster ne dispose pas de suffisamment d'espace d'adresses IP non alloué à utiliser pour ajouter de nouveaux nœuds ou pods.

Paramètres : ID des MIG défaillants.

 Reportez-vous à la procédure de dépannage pour résoudre le problème d'espace d'adressage IP pour les nœuds ou les pods.
"scale.up.error.service.account.deleted" L'événement scaleUp a échoué, car un compte de service utilisé par l'autoscaler de cluster a été supprimé.

Paramètres : ID des MIG défaillants.

 Contactez l'assistance Google Cloud pour une analyse plus approfondie.

Erreurs liées aux événements scaleDown

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

Message Description Atténuation
"scale.down.error.failed.to.mark.to.be.deleted" L'événement scaleDown a échoué, car un nœud n'a pas pu être marqué pour suppression.

Paramètres : nom du nœud défaillant.

 Ce message est temporaire. Si le message persiste, contactez l'assistance Google Cloud pour une analyse approfondie.
"scale.down.error.failed.to.evict.pods" L'événement scaleDown a échoué, car certains des pods n'ont pas pu être évincés d'un nœud.

Paramètres : nom du nœud défaillant.

 Passez en revue les bonnes pratiques en matière de budgets d'interruption de pod pour vous assurer que les règles autorisent l'éviction des instances dupliquées d'applications lorsque cela est acceptable.
"scale.down.error.failed.to.delete.node.min.size.reached" L'événement scaleDown a échoué, car le cluster était déjà à sa taille minimale, ce qui a empêché la suppression d'un nœud.

Paramètres : nom du nœud défaillant.

 Examinez la valeur minimale définie pour l'autoscaling du pool de nœuds et ajustez les paramètres si nécessaire.

Motifs de survenue d'un événement noScaleUp

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 Description Atténuation
"no.scale.up.in.backoff" Un événement noScaleUp s'est produit, car le scaling à la hausse est dans une période d'interruption (il est temporairement bloqué). Il s'agit d'un message temporaire qui peut survenir lors des événements de scaling à la hausse comportant un grand nombre de pods. Si ce message persiste, contactez l'assistance Google Cloud 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 Description Atténuation
"no.scale.up.nap.disabled" Le provisionnement automatique des nœuds 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 consultez la section 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 Description 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.

Paramètres : motifs lisibles par l'humain pour lesquels il 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 MIG, car il ne répond pas aux exigences du prédicat pour les pods en attente.

Paramètres : nom du prédicat défaillant, motifs lisibles par l'humain 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 adapter le cluster à un groupe de pods particulier.

Message Description 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.

Paramètres : 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.

Paramètres : 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.

Paramètres : 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.

Paramètres : nom de la zone concernée, motifs lisibles par l'humain 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.

Motifs de survenue d'un événement noScaleDown

Motifs de premier niveau pour les événements noScaleDown

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

Message Description Atténuation
"no.scale.down.in.backoff" Un événement noScaleDown s'est produit, car le scaling à la baisse est dans une période d'interruption (il est temporairement bloqué). Cet événement est temporaire et peut se produire lorsqu'un événement de scaling à la hausse est récent. Suivez les étapes d'atténuation associées aux raisons de niveau inférieur pour le scaling à la baisse. Une fois les raisons sous-jacentes résolues, l'autoscaler de cluster quitte l'intervalle entre les tentatives. Si le message persiste après avoir résolu les raisons sous-jacentes, contactez l'assistance Google Cloud pour une analyse plus approfondie.
"no.scale.down.in.progress" Un événement noScaleDown s'est produit, car le scaling à la baisse est bloqué jusqu'à la suppression du nœud précédent dont la suppression est planifiée. Cet événement devrait être temporaire, car le pod sera supprimé de force. Si ce message apparaît fréquemment, vous pouvez vérifier la valeur gracefulTerminationPeriod du scaling à la baisse des pods. Si vous souhaitez accélérer la résolution, vous pouvez également forcer la suppression du pod s'il n'est plus nécessaire.

Motifs de niveau nœud pour les événements noScaleDown

Les messages de motif de niveau nœud pour les événements noScaleDown s'affichent dans le champ noDecisionStatus.noScaleDown.nodes[].reason. Le message contient un motif pour lequel l'autoscaler de cluster ne peut pas supprimer un nœud particulier.

Message Description Atténuation
"no.scale.down.node.scale.down.disabled.annotation" Impossible de supprimer le nœud, car il comporte une annotation scale-down-disabled. Examinez l'annotation qui empêche le scaling à la baisse en suivant les instructions de la page "Questions fréquentes sur l'autoscaler de cluster Kubernetes".
"no.scale.down.node.node.group.min.size.reached" Impossible de supprimer le nœud, car son groupe de nœuds a déjà atteint sa taille minimale. Examiner et ajuster la valeur minimale définie pour l'autoscaling du pool de nœuds.
"no.scale.down.node.minimal.resource.limits.exceeded" Le scaling à la baisse d'un nœud sous-utilisé est bloqué, car cela enfreindrait les limites minimales de ressources à l'échelle du cluster définies pour le provisionnement automatique des nœuds. Examinez les limites minimales de ressources à l'échelle du cluster.
"no.scale.down.node.no.place.to.move.pods" Le scaling à la baisse d'un nœud sous-utilisé est bloqué, car il exécute un pod qui ne peut pas être déplacé vers un autre nœud du cluster. Si vous prévoyez de reprogrammer le pod, consultez les exigences de planification des pods sur le nœud sous-utilisé pour déterminer s'ils peuvent être déplacés vers un autre nœud du cluster. Ce message est attendu si vous ne prévoyez pas de replanifier le pod, car il n'y a aucun autre nœud sur lequel il pourrait être planifié.
"no.scale.down.node.pod.not.backed.by.controller" Le pod bloque le scaling à la baisse d'un nœud sous-utilisé, car le pod ne dispose pas d'un contrôleur connu de l'autoscaler de cluster Kubernetes (ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet). Consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes pour découvrir les types de pods pouvant empêcher l'autoscaler de supprimer un nœud.

Paramètres : nom du pod à l'origine du blocage.

 Définissez une annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" pour le pod ou définissez un contrôleur (par exemple, ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet).
"no.scale.down.node.pod.has.local.storage" Le pod bloque le scaling à la baisse, car il demande un stockage en local. Consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes pour découvrir les types de pods pouvant empêcher l'autoscaler de supprimer un nœud.

Paramètres : nom du pod à l'origine du blocage.

 Définissez une annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" pour le pod si les données de stockage local pour le pod ne sont pas critiques.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Le pod bloque le scaling à la baisse, car il comporte une annotation "Évincement non sécurisé". Pour en savoir plus, consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes.

Paramètres : nom du pod à l'origine du blocage.

 Si le pod peut être évincé en toute sécurité, mettez à jour l'annotation sur "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" Le pod bloque le scaling à la baisse, car il s'agit d'un pod non DaemonSet, non mis en miroir et sans PodDisruptionBudget dans l'espace de noms kube-system.

Paramètres : nom du pod à l'origine du blocage.

 Suivez les instructions figurant dans les questions fréquentes sur l'autoscaler de cluster Kubernetes pour définir un paramètre PodDisruptionBudget permettant à l'autoscaler de cluster de déplacer des pods dans l'espace de noms kube-system.
"no.scale.down.node.pod.not.enough.pdb" Le pod bloque le scaling à la baisse, car son PodDisruptionBudget n'est pas suffisant. Pour en savoir plus, consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes.

Paramètres : nom du pod à l'origine du blocage.

 Consultez le PodDisruptionBudget du pod. Consultez les bonnes pratiques de PodDisruptionBudget. Vous pouvez peut-être résoudre le message en procédant au scaling de l'application ou en modifiant le paramètre PodDisruptionBudget de façon à autoriser l'ajout de pods non disponibles.
"no.scale.down.node.pod.controller.not.found" Le pod bloque le scaling à la baisse, car son contrôleur (par exemple, Deployment ou ReplicaSet) est introuvable. Consultez les journaux pour déterminer quelles actions ont été effectuées après la suppression du contrôleur d'un pod. Pour résoudre ce problème, vous pouvez supprimer manuellement le pod.
"no.scale.down.node.pod.unexpected.error" Le scaling à la baisse d'un nœud sous-utilisé est bloqué, car il comporte un pod à l'état "Erreur inattendue". Contactez l'assistance GCP pour une analyse plus approfondie.

Étape suivante