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

Cette page fournit des informations sur les événements de visibilité émis par l'autoscaler de cluster dans Google Kubernetes Engine (GKE). En analysant ces événements, vous pouvez obtenir des insights sur la façon dont l'autoscaler de cluster gère le scaling de votre cluster et comprendre les raisons de ses décisions.

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 requises

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

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 Détails Paramètres Atténuation
"scale.up.error.out.of.resources" Des erreurs de ressources se produisent lorsque vous tentez de demander de nouvelles ressources dans une zone qui ne peut pas traiter votre requête du fait de l'indisponibilité actuelle d'une ressource Compute Engine, telle que les GPU ou les processeurs. ID des MIG défaillants. Suivez la procédure de dépannage pour la disponibilité des ressources dans la documentation Compute Engine.
"scale.up.error.quota.exceeded" L'événement scaleUp a échoué, car certains MIG n'ont pas pu être augmentés en raison d'un dépassement de quota Compute Engine. ID des MIG défaillants. Consultez l'onglet Erreurs du MIG dans la console Google Cloud pour voir quel quota est dépassé. Une fois que vous savez quel quota est dépassé, suivez les instructions pour demander une augmentation de quota.
"scale.up.error.waiting.for.instances.timeout" Le scaling à la hausse du groupe d'instances géré a échoué en raison du dépassement du délai avant expiration. ID des MIG défaillants. Ce message devrait être temporaire. Si le problème persiste, contactez l'assistance Cloud Customer Care pour une analyse approfondie.
"scale.up.error.ip.space.exhausted" Impossible d'effectuer un scaling à la hausse, car les instances de certains groupes d'instances gérés se sont trouvées à court d'adresses IP. Cela signifie que le cluster ne dispose pas de suffisamment d'espace d'adresses IP non alloué à utiliser pour ajouter de nouveaux nœuds ou pods. ID des MIG défaillants. Suivez la procédure de dépannage décrite dans la section Pas assez d'espace d'adresses IP libre pour les pods.
"scale.up.error.service.account.deleted" Impossible d'effectuer un scaling à la hausse, car le compte de service a été supprimé. ID des MIG défaillants. Essayez d'annuler la suppression du compte de service. Si cette procédure ne fonctionne pas, contactez l'assistance Cloud Customer Care pour une analyse approfondie.

Motifs de survenue d'un événement noScaleUp

Un événement noScaleUp est émis régulièrement lorsque le cluster comporte des pods non programmables et que l'autoscaler de cluster ne peut pas effectuer un scaling à la hausse du cluster pour planifier les pods. Les événements noScaleUp reposent sur le principe du "meilleur effort" et ne couvrent pas tous les cas possibles.

Motifs de premier niveau pour les événements noScaleUp

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

Message Détails Atténuation
"no.scale.up.in.backoff" Aucun scaling à la hausse n'a eu lieu, car cette opération est dans une période d'interruption (il est temporairement bloqué). Ce message peut survenir lors des événements de scaling à la hausse comportant un grand nombre de pods. Ce message devrait être temporaire. Vérifiez cette erreur au bout de quelques minutes. Si ce message persiste, contactez l'assistance Cloud Customer Care pour une analyse plus approfondie.

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

Les messages de motif de premier niveau lié au provisionnement automatique des nœuds pour les événements noScaleUp s'affichent dans le champ noDecisionStatus.noScaleUp.napFailureReason. Le message contient un motif de premier niveau pour lequel l'autoscaler de cluster ne peut pas provisionner de nouveaux pools de nœuds.

Message Détails Atténuation
"no.scale.up.nap.disabled"

Le provisionnement automatique des nœuds n'a pas pu être effectué, car il n'est pas activé au niveau du cluster.

Si le provisionnement automatique des nœuds est désactivé, les nouveaux nœuds ne sont pas provisionnés automatiquement si le pod en attente présente des exigences qui ne peuvent pas être satisfaites par des pools de nœuds existants.

 Vérifiez la configuration du cluster et envisagez d'activer le provisionnement automatique des nœuds.

Motifs de niveau MIG pour les événements noScaleUp

Les messages de motif de niveau MIG pour les événements noScaleUp s'affichent dans les champs noDecisionStatus.noScaleUp.skippedMigs[].reason et noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. Le message contient un motif pour lequel l'autoscaler de cluster ne peut pas augmenter la taille d'un MIG particulier.

Message Détails Paramètres Atténuation
"no.scale.up.mig.skipped" Impossible d'effectuer un scaling à la hausse d'un MIG, car il a été ignoré lors de la simulation. Motifs pour lesquels le MIG a été ignoré (par exemple, absence d'une exigence de pod). Examinez les paramètres inclus dans le message d'erreur et indiquez la raison pour laquelle le MIG a été ignoré.
"no.scale.up.mig.failing.predicate" Impossible d'effectuer un scaling à la hausse d'un pool de nœuds, car un prédicat de planification est défaillant pour les pods en attente. Nom du prédicat défaillant et raisons de l'échec. Examiner les exigences du pod, telles que les règles d'affinité, les rejets ou les tolérances, ainsi que les besoins en ressources.

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

Les messages de motif de niveau groupe de pods lié au provisionnement automatique des nœuds pour les événements noScaleUp s'affichent dans le champ noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. Le message contient un motif pour lequel l'autoscaler de cluster ne peut pas provisionner un nouveau pool de nœuds pour planifier un groupe de pods particulier.

Message Détails Paramètres Atténuation
"no.scale.up.nap.pod.gpu.no.limit.defined" Le provisionnement automatique des nœuds n'a pas pu provisionner de groupe de nœuds, car un pod en attente reçoit une requête de GPU, mais les limites de ressources des GPU ne sont pas définies au niveau du cluster. Type de GPU demandé. Examinez la requête de GPU du pod en attente et mettez à jour la configuration du provisionnement automatique des nœuds au niveau du cluster pour les limites de GPU.
"no.scale.up.nap.pod.gpu.type.not.supported" Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod, car il reçoit des requêtes pour un type de GPU inconnu. Type de GPU demandé. Vérifiez la configuration du pod en attente pour le type de GPU afin de vous assurer qu'il correspond au type de GPU compatible.
"no.scale.up.nap.pod.zonal.resources.exceeded" Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod dans cette zone, car cela enfreindrait les limites de ressources maximales à l'échelle du cluster, cela dépasserait les ressources disponibles dans la zone, ou il n'y a aucun type de machine adapté à la requête. Nom de la zone considérée. Examinez et mettez à jour les limites maximales de ressources à l'échelle du cluster, les demandes de ressources de pod ou les zones disponibles pour le provisionnement automatique des nœuds.
"no.scale.up.nap.pod.zonal.failing.predicates" Le provisionnement automatique des nœuds n'a provisionné aucun groupe de nœuds pour le pod dans cette zone en raison de prédicats défaillants. Nom de la zone considérée et motifs pour lesquels les prédicats sont défaillants. Examiner les exigences du pod en attente, telles que les règles d'affinité, les rejets, les tolérances ou les besoins en ressources.

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 d'événement Détails Paramètre Atténuation
"scale.down.error.failed.to.mark.to.be.deleted" Un nœud n'a pas pu être marqué pour suppression. Nom du nœud défaillant. Ce message devrait être temporaire. Si le problème persiste, contactez l'assistance Cloud Customer Care pour une analyse approfondie.
"scale.down.error.failed.to.evict.pods" L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car certains des pods ne pouvaient pas être évincés d'un nœud. Nom du nœud défaillant. Examinez le PodDisruptionBudget du pod et assurez-vous que les règles autorisent l'éviction des instances répliquées d'applications lorsque cela est acceptable. Pour en savoir plus, consultez la section Spécifier un budget d'interruption pour votre application dans la documentation Kubernetes.
"scale.down.error.failed.to.delete.node.min.size.reached" L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car le cluster étant déjà à sa taille minimale, aucun nœud n'a pu être supprimé. 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. Pour en savoir plus, consultez la section Erreur: les nœuds du cluster ont atteint la taille minimale.

Motifs de survenue d'un événement 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 événements noScaleDown reposent sur le principe du "meilleur effort" et ne couvrent pas tous les cas possibles.

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 d'événement Détails Atténuation
"no.scale.down.in.backoff" L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car cette opération 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.

Si le message persiste, contactez l'assistance Cloud Customer Care pour une analyse plus approfondie.
"no.scale.down.in.progress"

L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car une opération de scaling à la baisse précédente était toujours en cours.

 Ce message devrait être temporaire, car le pod sera supprimé à terme. Si ce message apparaît fréquemment, vérifiez le délai de préavis de résiliation pour le scaling à la baisse des pods. Pour accélérer la résolution, vous pouvez également supprimer le 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 field. Le message contient un motif pour lequel l'autoscaler de cluster ne peut pas supprimer un nœud particulier.

Message d'événement Détails Paramètres Atténuation
"no.scale.down.node.scale.down.disabled.annotation" L'autoscaler de cluster ne peut pas supprimer un nœud du pool de nœuds, car le nœud est annoté avec cluster-autoscaler.kubernetes.io/scale-down-disabled: true. N/A Cluster Autoscaler ignore les nœuds avec cette annotation sans tenir compte de leur utilisation. Ce message est consigné, quel que soit le facteur d'utilisation du nœud. Si vous souhaitez que l'autoscaler de cluster réduise le nombre de ces nœuds, supprimez l'annotation.
"no.scale.down.node.node.group.min.size.reached"

L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse lorsque la taille du groupe de nœuds a dépassé la limite minimale.

Cela se produit, car la suppression de nœuds enfreindrait les limites minimales de ressources à l'échelle du cluster définies dans les paramètres de provisionnement automatique de vos nœuds.

 N/A Vérifiez la valeur minimale définie pour l'autoscaling du pool de nœuds. Si vous souhaitez que l'autoscaler de cluster réduise la taille de ce nœud, ajustez la valeur minimale.
"no.scale.down.node.minimal.resource.limits.exceeded"

L'autoscaler de cluster ne peut pas réduire la taille des nœuds, car cela enfreindrait les limites de ressources minimales à l'échelle du cluster.

Il s'agit des limites de ressources définies pour le provisionnement automatique des nœuds.

 N/A Examinez vos limites de mémoire et de vCPU et, si vous souhaitez que l'autoscaler de cluster réduise la taille de ce nœud, diminuez les limites.
"no.scale.down.node.no.place.to.move.pods" L'autoscaler de cluster ne peut pas effectuer de scaling à la baisse, car il n'y a pas d'emplacement où déplacer les pods. N/A 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. Pour en savoir plus, consultez la section Erreur : aucun emplacement pour déplacer les pods.
"no.scale.down.node.pod.not.backed.by.controller"

Le pod bloque le scaling à la baisse, car il n'est pas secondé par un contrôleur.

Plus précisément, l'autoscaler de cluster ne peut pas effectuer de scaling à la baisse d'un nœud sous-utilisé en raison d'un pod qui ne dispose pas d'un contrôleur reconnu. Les contrôleurs autorisés incluent ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet.

 Nom du pod à l'origine du blocage. Définissez l'annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" pour le pod ou définissez un contrôleur acceptable.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Un pod sur le nœud comporte l'annotation safe-to-evict=false. Nom du pod à l'origine du blocage. Si le pod peut être évincé en toute sécurité, modifiez le fichier manifeste du pod et 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. Nom du pod à l'origine du blocage.

Dans les versions de GKE antérieures à 1.32.4-gke.1236000, l'autoscaler de cluster ne supprime pas les pods de l'espace de noms kube-system. À partir de la version 1.32.4-gke.1236000, l'autoscaler de cluster envisage de supprimer ces pods une heure après leur création.

Pour résoudre ce problème, ajoutez un PodDisruptionBudget pour les pods kube-system ou utilisez une combinaison de rejets et de tolérances de pools de nœuds pour séparer les pods kube-system des pods de votre application. Pour en savoir plus, consultez Erreur: kube-system Pod unmoveable.
"no.scale.down.node.pod.not.enough.pdb" Le pod bloque le scaling à la baisse, car le PodDisruptionBudget n'est pas suffisant. Nom du pod à l'origine du blocage. Examinez le PodDisruptionBudget du pod et envisagez de le rendre moins restrictive. Pour en savoir plus, consultez Erreur : PodDisruptionBudget insuffisant.
"no.scale.down.node.pod.controller.not.found" Le pod bloque le scaling à la baisse, car son contrôleur (par exemple, un déploiement ou un ReplicaSet) est introuvable. N/A Pour déterminer quelles actions ont été effectuées après la suppression du contrôleur d'un pod, consultez les journaux. Pour résoudre ce problème, supprimez manuellement le pod.
"no.scale.down.node.pod.unexpected.error" Le pod bloque le scaling à la baisse en raison d'une erreur inattendue. N/A La cause de cette erreur est inconnue. Contactez l'équipe Cloud Customer Care pour une analyse plus approfondie.

Étapes suivantes