Collecter et afficher les métriques du plan de contrôle

Cette page explique comment configurer un cluster Google Kubernetes Engine (GKE) pour envoyer les métriques émises par le serveur d'API Kubernetes, le programmeur et le gestionnaire de contrôleurs à Cloud Monitoring à l'aide de Google Cloud Managed Service pour Prometheus. Cette page décrit également le format de ces métriques lorsqu'elles sont écrites dans Monitoring, et comment interroger des métriques.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Conditions requises

L'envoi de métriques du plan de contrôle Kubernetes à Cloud Monitoring présente les exigences suivantes :

Configurer la collecte de métriques du plan de contrôle

Vous pouvez activer les métriques du plan de contrôle dans un cluster GKE existant à l'aide de la console Google Cloud, de gcloud CLI ou de Terraform.

Console

Vous pouvez activer les métriques du plan de contrôle pour un cluster à partir de l'onglet Observabilité du cluster ou de l'onglet Détails du cluster. Lorsque vous utilisez l'onglet Observabilité, vous pouvez prévisualiser les graphiques et les métriques disponibles avant d'activer le package de métriques.

Procédez comme suit pour activer les métriques du plan de contrôle à partir de l'onglet Observabilité du cluster :

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

    Accéder à la page Clusters Kubernetes

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Kubernetes Engine.

  2. Cliquez sur le nom de votre cluster, puis sélectionnez l'onglet Observabilité.

  3. Sélectionnez Plan de contrôle dans la liste des caractéristiques.

  4. Cliquez sur Activer le package.

    Si les métriques du plan de contrôle sont déjà activées, un ensemble de graphiques associés à ces métriques va alors s'afficher.

Procédez comme suit pour activer les métriques du plan de contrôle à partir de l'onglet Détails du cluster :

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

    Accéder à la page Clusters Kubernetes

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Kubernetes Engine.

  2. Cliquez sur le nom de votre cluster.

  3. Sur la ligne Fonctionnalités intitulée Cloud Monitoring, cliquez sur l'icône Modifier.

  4. Dans la boîte de dialogue Modifier Cloud Monitoring qui s'affiche, vérifiez que l'option Activer Cloud Monitoring est sélectionnée.

  5. Dans le menu déroulant Composants sélectionnez les composants du plan de contrôle à partir desquels vous souhaitez collecter des métriques : Serveur d'API, Programmeur ou Gestionnaire de contrôleurs.

  6. Cliquez sur OK.

  7. Cliquez sur Save Changes (Enregistrer les modifications).

gcloud

Mettez à jour votre cluster pour collecter des métriques émises par le serveur d'API Kubernetes, le programmeur et le gestionnaire de contrôleurs :

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Remplacez les éléments suivants :

Terraform

Pour configurer la collecte de métriques du plan de contrôle Kubernetes à l'aide de Terraform, consultez le bloc monitoring_config dans le registre Terraform pour google_container_cluster. Pour obtenir des informations générales sur l'utilisation de Google Cloud avec Terraform, consultez la page Terraform avec Google Cloud.

Quota

Les métriques du plan de contrôle consomment le quota "Time series ingestion requests per minute" (requêtes d'ingestion de séries temporelles par minute) de l'API Cloud Monitoring. Avant d'activer les packages de métriques, vérifiez votre utilisation maximale récente de ce quota. Si vous avez plusieurs clusters dans le même projet ou que vous approchez déjà de la limite de ce quota, vous pouvez demander une augmentation de la limite de quota avant d'activer un package d'observabilité.

Tarifs

Les métriques du plan de contrôle GKE utilisent Google Cloud Managed Service for Prometheus pour charger des métriques dans Cloud Monitoring. Les frais liés à l'ingestion de ces métriques sont calculés par Cloud Monitoring en fonction du nombre d'échantillons ingérés. Toutefois, ces métriques sont gratuites pour les clusters enregistrés qui appartiennent à un projet sur lequel l'édition GKE Enterprise est activée.

Pour en savoir plus, consultez la tarification Cloud Monitoring.

Format de la métrique

Toutes les métriques du plan de contrôle Kubernetes écrites dans Cloud Monitoring utilisent le type de ressource prometheus_target. Chaque nom de métrique inclut un préfixe prometheus.googleapis.com/ et un suffixe indiquant le type de métrique Prometheus, tel que /gauge, /histogram ou /counter. En dehors de cela, chaque nom de métrique est identique au nom de métrique exposé par Kubernetes Open Source.

Exporter depuis Cloud Monitoring

Les métriques du plan de contrôle Kubernetes peuvent être exportées depuis Cloud Monitoring à l'aide de l'API Cloud Monitoring. Étant donné que toutes les métriques du plan de contrôle Kubernetes sont ingérées à l'aide de Google Cloud Managed Service pour Prometheus, les métriques du plan de contrôle Kubernetes peuvent être interrogées à l'aide du langage de requête Prometheus (PromQL). Vous pouvez également les interroger à l'aide du langage MQL (Monitoring Query Language).

Interroger les métriques

Lorsque vous interrogez les métriques du plan de contrôle Kubernetes, le nom que vous utilisez varie selon que vous utilisez des fonctionnalités basées sur PromQL ou Cloud Monitoring, telles que MQL ou l' interface basée sur des menus de l'Explorateur de métriques.

Les tableaux suivants des métriques du plan de contrôle Kubernetes présentent deux versions de chaque nom de métrique :

  • Nom de la métrique PromQL : lors de l'utilisation de PromQL sur des pages Cloud Monitoring de la console Google Cloud ou dans les champs PromQL de l'API Cloud Monitoring, utilisez le nom de la métrique PromQL.
  • Nom de la métrique Cloud Monitoring : lorsque vous utilisez d'autres fonctionnalités de Cloud Monitoring, utilisez le nom de la métrique Cloud Monitoring répertorié dans les tableaux ci-dessous. Ce nom doit être précédé du préfixe prometheus.googleapis.com/, qui a été omis dans les entrées du tableau.

Métriques du serveur d'API

Cette section fournit une liste des métriques du serveur d'API et des informations supplémentaires sur leur interprétation et leur utilisation.

Liste des métriques du serveur d'API

Lorsque les métriques du serveur d'API sont activées, toutes les métriques répertoriées dans le tableau ci-dessous sont exportées vers Cloud Monitoring dans le même projet que le cluster GKE.

Les noms des métriques Cloud Monitoring figurant dans ce tableau doivent être précédés du préfixe prometheus.googleapis.com/. Ce préfixe a été omis dans les entrées du tableau.

Nom de la métrique PromQL Étape de lancement
Nom de la métrique Cloud Monitoring
Genre, Type, Unité
Ressources surveillées
Version de GKE requise		 Description
Libellés
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13 et versions ultérieures 		Limite du nombre maximal de requêtes en cours actuellement utilisées pour ce serveur d'API par genre de requête au cours de la dernière seconde.

request_kind
apiserver_flowcontrol_current_executing_seats BÊTA
apiserver_flowcontrol_current_executing_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3 et versions ultérieures 		Simultanéité (nombre de licences utilisateur) occupée par les requêtes en cours d'exécution (étape initiale pour une requête WATCH, ou n'importe quelle étape dans les autres cas) dans le sous-système de priorité et d'équité des API.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BÊTA
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ pour les versions mineures précédentes) 		Nombre de requêtes en attente dans les files d'attente du sous-système de priorité et d'équité des API.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats BÊTA
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.26.11+, 1.27.8+ pour les versions mineures précédentes) 		Nombre nominal de licences d'exécution configurées pour chaque niveau de priorité.

priority_level
apiserver_flowcontrol_rejected_requests_total BÊTA
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ pour les versions mineures précédentes) 		Nombre de requêtes refusées par le sous-système de priorité et d'équité des API.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BÊTA
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ pour les versions mineures précédentes) 		Temps passé par une requête dans sa file d'attente.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6 et versions ultérieures 		Répartition de la latence des réponses en secondes pour chaque verbe, valeur de simulation, groupe, version, ressource, sous-ressource, champ d'application et composant.

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13 et versions ultérieures 		Compteur des requêtes au serveur d'API réparties pour chaque verbe, valeur de simulation, groupe, version, ressource, champ d'application, composant et code de réponse HTTP.

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13 et versions ultérieures 		Distribution de la taille de la réponse en octets pour chaque groupe, version, verbe, ressource, sous-ressource, champ d'application et composant.

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13 et versions ultérieures 		Nombre d'objets stockés au moment de la dernière vérification, répartis par genre.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6 et versions ultérieures 		Histogramme de latence du contrôleur d'admission en secondes, identifié par son nom, et ventilé pour chaque opération, chaque ressource d'API et chaque type (valider ou accepter).

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13 et versions ultérieures 		Histogramme de latence des sous-étapes d'admission en secondes, ventilé pour chaque opération, chaque ressource d'API et chaque type d'étape (validation ou admis).

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13 et versions ultérieures 		Histogramme de latence du webhook d'admission en secondes, identifié par son nom, et ventilé pour chaque opération, chaque ressource d'API et chaque type (valider ou accepter).

name
operation
rejected
type

Les sections suivantes fournissent des informations supplémentaires sur les métriques du serveur d'API.

apiserver_request_duration_seconds

Utilisez cette métrique pour surveiller la latence sur le serveur d'API. La durée de requête enregistrée par cette métrique inclut toutes les phases du traitement des requêtes, de la réception à la fin de la réponse du serveur au client. Plus précisément, elle inclut le temps consacré aux tâches suivantes :

  • L'authentification et l'autorisation de la requête.
  • Les appels système et des webhooks tiers associés à la requête.
  • La récupération de l'objet de la requête à partir d'un cache en mémoire (pour les requêtes spécifiant un paramètre d'URL resourceVersion) ou de etcd (pour toutes les autres requêtes).
  • Vous pouvez utiliser les étiquettes group, version, resource et subresource pour identifier de manière unique une requête lente pour une analyse plus approfondie.
  • Écrire la réponse au client et recevoir la réponse du client.

Pour plus d'informations sur l'utilisation de cette métrique, consultez la section Latence.

Cette métrique présente une cardinalité très élevée. Lorsque vous utilisez cette métrique, vous devez utiliser des filtres ou le regroupement pour rechercher des sources de latence spécifiques.

apiserver_admission_controller_admission_duration_seconds

Cette métrique mesure la latence des webhooks d'admission intégrés, et non des webhooks tiers. Pour diagnostiquer les problèmes de latence avec des webooks tiers, utilisez la métrique apiserver_admission_webhook_admission_duration_seconds.

apiserver_admission_webhook_admission_duration_seconds et
apiserver_admission_step_admission_duration_seconds

Ces métriques mesurent la latence des webhooks d'admission externes tiers. La métrique apiserver_admission_webhook_admission_duration_seconds est généralement la plus utile. Pour plus d'informations sur l'utilisation de cette métrique, consultez la section Latence.

apiserver_request_total

Utilisez cette métrique pour surveiller le trafic des requêtes sur votre serveur d'API. Vous pouvez également l'utiliser pour déterminer les taux de réussite et d'échec de vos requêtes. Pour en savoir plus sur l'utilisation de cette métrique, consultez la page Trafic et taux d'erreurs.

Cette métrique présente une cardinalité très élevée. Lorsque vous utilisez cette métrique, vous devez utiliser des filtres ou le regroupement pour identifier les sources d'erreurs.

apiserver_storage_objects

Utilisez cette métrique pour détecter la saturation de votre système et identifier les fuites de ressources possibles. Pour en savoir plus, consultez la section Saturation.

apiserver_current_inflight_requests

Cette métrique enregistre le nombre maximal de requêtes diffusées activement au cours de la dernière fenêtre d'une seconde. Pour en savoir plus, consultez la section Saturation.

La métrique n'inclut pas les requêtes de longue durée telles que "watch".

Surveiller le serveur d'API

Les métriques du serveur d'API peuvent vous donner un aperçu des principaux signaux d'état du système :

  • Latence : combien de temps faut-il pour traiter une requête ?
  • Trafic : quelle est la demande rencontrée par le système ?
  • Taux d'erreur : à quelle fréquence les requêtes échouent-elles ?
  • Saturation : le système est-il saturé ?

Cette section explique comment utiliser les métriques du serveur d'API pour surveiller l'état du serveur d'API.

Latence

Lorsque le serveur d'API est surchargé, la latence des requêtes augmente. Pour mesurer la latence des requêtes adressées au serveur d'API, utilisez la métrique apiserver_request_duration_seconds. Pour identifier la source de la latence plus spécifiquement, vous pouvez regrouper les métriques par étiquette verb ou resource.

La limite supérieure suggérée pour un appel de ressource unique tel que GET, POST ou PATCH est de 1 seconde. La limite supérieure suggérée pour les appels LIST au niveau de l'espace de noms et du cluster est de 30 secondes. Les limites supérieures sont fixées par des SLO définis par la communauté Open Source de Kubernetes. Pour en savoir plus, consultez la page Détails des SLI/SLO de latence des appels d'API.

Si la valeur de la métrique apiserver_request_duration_seconds dépasse la durée attendue, examinez les causes possibles :

  • Le plan de contrôle Kubernetes est peut-être surchargé. Pour vérifier, consultez les métriques apiserver_request_total et apiserver_storage_objects.
    • Utilisez l'étiquette code pour déterminer si les requêtes sont traitées correctement. Pour en savoir plus sur les valeurs possibles, consultez la section Codes d'état HTTP.
    • Utilisez les étiquettes group, version, resource et subresource pour identifier de manière unique une requête.

  • Un webhook d'admission tiers est lent ou non réactif. Si la valeur de la métrique apiserver_admission_webhook_admission_duration_seconds augmente, certains de vos webhooks d'admission tiers ou définis par l'utilisateur sont lents ou non réactifs. La latence dans le webhook d'admission peut entraîner des retards dans la planification des jobs.

    • Pour interroger la latence du webhook de 99e centile par instance du plan de contrôle Kubernetes, utilisez la requête PromQL suivante :

      sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))

      Nous vous recommandons également d'examiner les 50e, 90e, 95e et 99,9e centiles ; vous pouvez ajuster cette requête en modifiant la valeur 0.99.

    • Les webhooks externes ont un délai avant expiration d'environ 10 secondes. Vous pouvez définir des règles d'alerte sur la métrique apiserver_admission_webhook_admission_duration_seconds pour être averti lorsque vous approchez du délai avant expiration du webhook.

    • Vous pouvez également regrouper la métrique apiserver_admission_webhook_admission_duration_seconds sur l'étiquette name pour diagnostiquer les problèmes possibles avec des webhooks spécifiques.

  • Vous répertoriez de nombreux objets. La latence des appels LIST devrait augmenter à mesure que le nombre d'objets d'un type donné (la taille de la réponse) augmente.

  • Problèmes côté client :

    • Il est possible que le client ne dispose pas de ressources suffisantes pour recevoir des réponses en temps opportun. Pour vérifier, examinez les métriques d'utilisation du processeur pour le pod client.
    • La connexion réseau du client est lente. Cela peut se produire lorsque le client s'exécute sur un appareil tel qu'un téléphone mobile, mais il est peu probable que les clients s'exécutent sur un réseau Compute Engine.
    • Le client s'est fermé de manière inattendue, mais la connexion TCP a un délai avant expiration en dizaines de secondes. Avant l'expiration de la connexion, les ressources du serveur sont bloquées, ce qui peut augmenter la latence.

Pour en savoir plus, consultez la section Bonnes pratiques pour utiliser la priorité et l'équité des API dans la documentation Kubernetes.

Trafic et taux d'erreurs

Pour mesurer le trafic et le nombre de requêtes ayant abouti ou échoué sur le serveur d'API, utilisez la métrique apiserver_request_total. Par exemple, pour mesurer le trafic du serveur d'API par instance du plan de contrôle Kubernetes, utilisez la requête PromQL suivante :

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

  • Pour interroger les requêtes ayant échoué, filtrez le libellé code pour les valeurs 4xx et 5xx à l'aide de la requête PromQL suivante :

    sum(rate(apiserver_request_total{code=~"[45].."}[5m]))

  • Pour interroger les requêtes réussies, filtrez le libellé code pour les valeurs 2xx à l'aide de la requête PromQL suivante :

    sum(rate(apiserver_request_total{code=~"2.."}[5m]))

  • Pour interroger les requêtes refusées par le serveur d'API par instance du plan de contrôle Kubernetes, filtrez le libellé code pour la valeur 429 (http.StatusTooManyRequests) à l'aide de la requête PromQL suivante :

    sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))

Saturation

Vous pouvez mesurer la saturation dans votre système à l'aide des métriques apiserver_current_inflight_requests et apiserver_storage_objects .

Si la valeur de la métrique apiserver_storage_objects augmente, il se peut que le problème soit causé par un contrôleur personnalisé qui crée des objets, mais ne les supprime pas. Vous pouvez filtrer ou regrouper la métrique en fonction du libellé resource pour identifier la ressource faisant l'objet de l'augmentation.

Evaluez la métrique apiserver_current_inflight_requests conformément à vos paramètres de priorité et d'équité de l'API ; ces paramètres affectent la priorité des requêtes. Vous ne pouvez donc pas tirer de conclusions à partir des valeurs de métriques uniquement. Pour plus d'informations, consultez la section Priorité et équité des API.

Métriques du programmeur

Cette section fournit une liste des métriques du programmeur et des informations supplémentaires sur leur interprétation et leur utilisation.

Liste des métriques du programmeur

Lorsque les métriques du programmeur sont activées, toutes les métriques répertoriées dans le tableau ci-dessous sont exportées vers Cloud Monitoring dans le même projet que le cluster GKE.

Les noms des métriques Cloud Monitoring figurant dans ce tableau doivent être précédés du préfixe prometheus.googleapis.com/. Ce préfixe a été omis dans les entrées du tableau.

Nom de la métrique PromQL Étape de lancement
Nom de la métrique Cloud Monitoring
Genre, Type, Unité
Ressources surveillées
Version de GKE requise		 Description
Libellés
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13 et versions ultérieures 		Nombre de pods en attente, par type de file d'attente. "active" représente le nombre de pods dans ActiveQ. "backoff" représente le nombre de pods dans backoffQ. "unschedulable" représente le nombre de pods dans unschedulablePods.

queue
scheduler_pod_scheduling_duration_seconds OBSOLÈTE
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.25.1 à 1.29 (1.22.17-gke.3100+, 1.23.11+, et 1.24.5+ pour les versions mineures précédentes) 		[Obsolète dans la version 1.29 ; supprimée dans la version 1.30 et remplacée par scheduler_pod_scheduling_sli_duration_seconds.] Latence E2e pour un pod en cours de planification, qui peut inclure plusieurs tentatives de planification.

attempts
scheduler_pod_scheduling_sli_duration_seconds BÊTA
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.30 et versions ultérieures 		Latence E2e pour un pod en cours de planification, à partir du moment où le pod entre dans la file d'attente de planification et peut impliquer plusieurs tentatives de planification.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13 et versions ultérieures 		Nombre total de tentatives de préemption dans le cluster jusqu'à maintenant
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13 et versions ultérieures 		Nombre de cibles sélectionnées pour la préemption
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6 et versions ultérieures 		Latence de la tentative de planification en secondes (algorithme de planification + liaison)

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13 et versions ultérieures 		Nombre de tentatives de planification de pods, en fonction du résultat. "unschedulable" signifie qu'un pod n'a pas pu être planifié, tandis que "error" traduit un problème interne au programmeur.

profile
result

Les sections suivantes fournissent des informations supplémentaires sur les métriques du serveur d'API.

scheduler_pending_pods

Vous pouvez utiliser la métrique scheduler_pending_pods pour surveiller la charge sur votre programmeur. L'augmentation des valeurs de cette métrique peut indiquer des problèmes de ressources. Le programmeur comporte trois files d'attente, et cette métrique indique le nombre de requêtes en attente par file d'attente. Les files d'attente suivantes sont acceptées :

  • File d'attente active
    • Ensemble de pods que le planificateur tente de planifier. Le pod ayant la priorité la plus élevée se trouve en haut de la file d'attente.
  • File d'attente backoff
    • L'ensemble de pods n'était pas programmable la dernière fois que le programmeur a essayé, mais peut être programmable la prochaine fois.
    • Les pods de cette file d'attente doivent attendre une période d'attente (10 secondes maximum), après quoi ils sont renvoyés dans la file d'attente active pour une autre tentative de planification. Pour en savoir plus sur la gestion de la file d'attente backoff, consultez la demande d'implémentation, Problème Kubernetes 75417.

  • Ensemble unschedulable

    • Ensemble de pods que le programmeur a tenté de planifier, mais qui ont été identifiés comme non programmables. L'emplacement de cette file d'attente peut indiquer des problèmes de préparation ou de compatibilité avec vos nœuds ou la configuration de vos sélecteurs de nœuds.

      Lorsque des contraintes de ressources empêchent de programmer des pods, ils ne sont pas soumis au traitement d'attente. Lorsqu'un cluster est plein, les nouveaux pods ne parviennent pas à être programmés et sont placés en file d'attente unscheduled.

    • La présence de pods non planifiés peut indiquer que vous disposez de ressources insuffisantes ou que vous rencontrez un problème de configuration des nœuds. Les pods sont déplacés vers la file d'attente backoff ou active après des événements qui modifient l'état du cluster. Les pods de cette file d'attente indiquent que rien n'a changé dans le cluster qui rendrait les pods programmables.

    • Les affinités définissent des règles concernant l'attribution des pods aux nœuds. L'utilisation de règles d'affinité ou d'anti-affinité peut expliquer l'augmentation du nombre de pods non planifiés.

    • Certains événements, tels que les PVC/services ADD/UPDATE, l'arrêt d'un pod ou l'enregistrement de nouveaux nœuds, déplacent tout ou partie des pods non planifiés vers la file d'attente backoff ou active. Pour plus d'informations, consultez le problème Kubernetes 81214.

Pour en savoir plus, consultez les sections Latence du programmeur et Problèmes liés aux ressources.

scheduler_scheduling_attempt_duration_seconds

Cette métrique mesure la durée d'une seule tentative de planification dans le programmeur lui-même et elle est divisée par résultat : planifié, non programmable ou erreur. Cette durée s'exécute entre le moment où le planificateur récupère un pod et le moment où il le localise et le place sur le nœud, détermine que le pod n'est pas programmable ou rencontre une erreur. La durée de planification inclut l'heure du processus de planification ainsi que la durée de la liaison. La liaison est le processus par lequel le programmeur communique son attribution de nœuds au serveur d'API. Pour plus d'informations, consultez la section Latence du programmeur.

Cette métrique ne capture pas le temps passé par le pod dans le contrôle ou la validation d'admission.

Pour en savoir plus sur la planification, consultez la page Planifier un pod.

scheduler_schedule_attempts_total

Cette métrique mesure le nombre de tentatives de planification ; chaque tentative de planification d'un pod augmente la valeur. Vous pouvez utiliser cette métrique pour déterminer si le programmeur est disponible : si la valeur augmente, le programmeur est opérationnel. Vous pouvez utiliser le libellé result pour déterminer la réussite. Les pods sont scheduled ou unschedulable.

Cette métrique est fortement corrélée à la métrique scheduler_pending_pods : lorsque de nombreux pods sont en attente, vous pouvez vous attendre à de nombreuses tentatives de planification des pods. Pour en savoir plus, consultez la section Problèmes liés aux ressources.

Cette métrique n'augmente pas si le programmeur n'a pas de pods à planifier, ce qui peut être le cas si vous disposez d'un programmeur secondaire personnalisé.

scheduler_preemption_attempts_total et scheduler_preemptions_victims

Vous pouvez utiliser les métriques de préemption pour déterminer si vous devez ajouter des ressources.

Il se peut que certains pods de priorité plus élevée ne puissent pas être planifiés, car il n'y a pas d'espace pour eux. Dans ce cas, le programmeur libère des ressources en préemptant un ou plusieurs pods en cours d'exécution sur un nœud. La métrique scheduler_preemption_attempts_total permet de suivre le nombre de fois où le programmeur a tenté de préempter les pods.

La métrique scheduler_preemptions_victims compte les pods sélectionnés pour la préemption.

Le nombre de tentatives de préemption est fortement corrélé à la valeur de la métrique scheduler_schedule_attempts_total lorsque la valeur de l'étiquette result est unschedulable. Les deux valeurs ne sont pas équivalentes. Par exemple, si un cluster ne comporte aucun nœud, il n'y a pas de tentatives de préemption, mais des planifications peuvent échouer.

Pour en savoir plus, consultez la section Problèmes liés aux ressources.

Surveiller le programmeur

Les métriques du programmeur peuvent vous donner un aperçu des performances de votre programmeur :

Cette section explique comment utiliser la métrique du programmeur pour surveiller celui-ci.

Latence du programmeur

La tâche du programmeur est de s'assurer que vos pods sont exécutés. Vous devez donc savoir si le programmeur est bloqué ou s'exécute lentement.

  • Pour vérifier que le programmeur exécute et planifie des pods, utilisez la métrique scheduler_schedule_attempts_total.

  • Lorsque le programmeur s'exécute lentement, examinez les causes possibles :

    • Le nombre de pods en attente augmente. Utilisez la métrique scheduler_pending_pods pour surveiller le nombre de pods en attente. La requête PromQL suivante renvoie le nombre de pods en attente par file d'attente dans un cluster :

      sum by (queue)
(delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))

    • Les tentatives individuelles de programmer des pods sont lentes. Utilisez la métrique scheduler_scheduling_attempt_duration_seconds pour surveiller la latence des tentatives de planification.

      Nous vous recommandons d'observer cette métrique au moins aux 50e et 95e centiles. La requête PromQL suivante récupère les valeurs du 95e centile, mais peut être ajustée :

      sum by (instance) (histogram_quantile(0.95, rate(
scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))

Problèmes de ressources

Les métriques du programmeur peuvent également vous aider à évaluer si vous disposez de ressources suffisantes. Si la valeur de la métrique scheduler_preemption_attempts_total augmente, vérifiez la valeur de scheduler_preemption_victims à l'aide de la requête PromQL suivante :

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

Le nombre de tentatives de préemption et le nombre de victimes atteintes de préemption augmentent tous les deux lorsqu'il y a des pods de priorité plus élevée à planifier. Les métriques de préemption ne vous indiquent pas si les pods à priorité élevée qui ont déclenché les préemptions ont été planifiés. Par conséquent, lorsque vous constatez une augmentation de la valeur des métriques de préemption, vous pouvez également surveiller la valeur de la métrique scheduler_pending_pods. Si le nombre de pods en attente augmente également, vous ne disposez peut-être pas de ressources suffisantes pour gérer les pods de priorité supérieure. Vous devrez peut-être faire évoluer les ressources disponibles, créer des pods avec des revendications de ressources réduites ou modifier le sélecteur de nœud.

  • Si le nombre de victimes de préemption n'augmente pas, il n'y a plus de pods avec une faible priorité pouvant être supprimés. Dans ce cas, envisagez d'ajouter des nœuds afin que les nouveaux pods puissent être alloués.

  • Si le nombre de victimes de préemption augmente, cela signifie que des pods de priorité plus élevée sont en attente de planification. Le planificateur préempte donc certains des pods en cours d'exécution. Les métriques de préemption ne vous indiquent pas si les pods de priorité supérieure ont été planifiés avec succès.

    Pour déterminer si les pods de priorité supérieure sont planifiés, recherchez les valeurs décroissantes de la métrique scheduler_pending_pods. Si la valeur de cette métrique augmente, vous devrez peut-être ajouter des nœuds.

Vous pouvez vous attendre à des pics temporaires de valeurs pour la métrique scheduler_pending_pods lorsque des charges de travail sont planifiées dans votre cluster, par exemple lors d'événements tels que des mises à jour ou des scalings. Si le cluster dispose de suffisamment de ressources, ces pics sont temporaires. Si le nombre de pods en attente ne diminue pas, procédez comme suit :

  • Vérifiez que les nœuds ne sont pas bloqués. Les nœuds bloqués n'acceptent pas les nouveaux pods.
  • Vérifiez les directives de planification suivantes, qui peuvent être mal configurées et peuvent rendre le pod non planifiable :
    • Affinité et sélecteur de nœud.
    • Rejets et tolérances
    • Contraintes de répartition de la topologie des pods

Si les pods ne peuvent pas être programmés en raison de ressources insuffisantes, envisagez de libérer certains nœuds existants ou d'augmenter leur nombre.

Métriques du gestionnaire de contrôleurs

Lorsque les métriques du gestionnaire de contrôleurs sont activées, toutes les métriques répertoriées dans le tableau ci-dessous sont exportées vers Cloud Monitoring dans le même projet que le cluster GKE.

Les noms des métriques Cloud Monitoring figurant dans ce tableau doivent être précédés du préfixe prometheus.googleapis.com/. Ce préfixe a été omis dans les entrées du tableau.

Nom de la métrique PromQL Étape de lancement
Nom de la métrique Cloud Monitoring
Genre, Type, Unité
Ressources surveillées
Version de GKE requise		 Description
Libellés
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24 et versions ultérieures 		Nombre d'évictions de nœuds ayant eu lieu depuis le démarrage de l'instance actuelle de NodeController.

zone