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

L'autoscaler de cluster Google Kubernetes Engine (GKE) émet des événements de visibilité, disponibles sous forme d'entrées de journal dans Cloud Logging. Cette page explique comment afficher ces événements journalisés pour savoir quand et pourquoi l'autoscaler de cluster GKE décide de procéder à un autoscaling.

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

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.

Pour afficher les journaux, procédez comme suit :

  1. Dans Cloud Console, accédez à la page Visionneuse de journaux.

    Accéder à la visionneuse de journaux

  2. Recherchez les journaux à l'aide de l'interface de requête de base ou avancée.

    Pour rechercher des journaux à l'aide de l'interface de requête de base, procédez comme suit :

    1. Dans la liste déroulante des ressources, sélectionnez Cluster Kubernetes, puis sélectionnez l'emplacement et le nom de votre cluster.
    2. Dans la liste déroulante des type de journaux, sélectionnez container.googleapis.com/cluster-autoscaler-visibility.
    3. Dans la liste déroulante des périodes, sélectionnez la période souhaitée.

    Pour rechercher des journaux à l'aide de l'interface de requête avancée, appliquez le filtre avancé suivant :

    resource.type="k8s_cluster"
    resource.labels.location="cluster-location"
    resource.labels.cluster_name="cluster-name"
    logName="projects/project-id/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
    

    où :

    • cluster-location est l'emplacement du cluster que vous inspectez.
    • cluster-name est le nom du cluster.
    • project-id est l'ID du projet.

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. Cet événement contient des informations sur les groupes d'instances gérés (MIG, Managed Instance Groups) qui ont fait l'objet d'un scaling à la hausse, le nombre de nœuds concernés et 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. Cet événement contient des informations sur les nœuds qui sont supprimés et sur les pods à évincer en conséquence.

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.

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"
          }
        }
      ]
    }
  }
}

É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. 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"
      }
    }
  }
}

Scénarios de débogage

Cette section explique comment déboguer 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 la visionneuse 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 la visionneuse 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 (visibles dans le champ messageId) pour fournir des explications sur leur survenue.

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

"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.


"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.


"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.

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

"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.


"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.


"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.

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

"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é).

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

"no.scale.up.nap.disabled"
Comme le provisionnement automatique des nœuds était désactivé, il n'a provisionné aucun groupe de nœuds. Pour en savoir plus, consultez la section Activer le provisionnement automatique des nœuds.

"no.scale.up.nap.no.locations.available"
Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds, car aucun emplacement de provisionnement automatique des nœuds n'était disponible.

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

"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 explicites pour lesquels il a été ignoré.


"no.scale.up.mig.failing.predicate"
Impossible d'effectuer un scaling à la hausse d'un MIG, car un prédicat a échoué pour ce MIG.

Paramètres : nom du prédicat défaillant, motifs explicites de l'échec.

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

"no.scale.up.nap.pod.gpu.no.limit.defined"
Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod, car celui-ci a une requête de GPU, et il n'y a aucune limite définie pour le GPU.

Paramètres : type de GPU demandé.


"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 spécifie un GPU non compatible. Pour en savoir plus, consultez la section Configurer les limites du GPU.

Paramètres : type de GPU demandé.


"no.scale.up.nap.pod.gpu.other.error"
Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod en raison d'autres problèmes liés à la configuration du GPU. Pour en savoir plus, consultez la section Configurer les limites du GPU.

"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.

Paramètres : nom de la zone concernée.


"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 explicites pour lesquels les prédicats sont défaillants.

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

"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é).

"no.scale.down.in.progress"
Un événement noScaleDown s'est produit, car un événement scaleDown précédent est toujours en cours.

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

"no.scale.down.node.scale.down.disabled.annotation"
Impossible de supprimer le nœud, car il comporte une annotation "Scaling à la baisse désactivé". Pour en savoir plus, consultez les 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.

"no.scale.down.node.minimal.resource.limits.exceeded"
Impossible de supprimer le nœud, car cela enfreindrait les limites de ressources minimales à l'échelle du cluster.

"no.scale.down.node.no.place.to.move.pods"
Impossible de supprimer le nœud, car il n'y a pas d'emplacement où déplacer ses pods.

"no.scale.down.node.pod.not.backed.by.controller"
Le pod bloque le scaling à la baisse, car il n'est pas appuyé par un contrôleur. Pour en savoir plus, consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes.

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


"no.scale.down.node.pod.has.local.storage"
Le pod bloque le scaling à la baisse, car il demande un stockage en local. Pour en savoir plus, consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes.

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


"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.


"no.scale.down.node.pod.kube.system.unmovable"
Le pod bloque le scaling à la baisse, car il s'agit d'un pod kube-system non-daemonset, non mis en miroir et non attribué par PDB. Pour en savoir plus, consultez les questions fréquentes sur l'autoscaler de cluster Kubernetes.

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


"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.

Étape suivante