Cette page décrit les métriques et les tableaux de bord disponibles pour surveiller la latence de démarrage des charges de travail Google Kubernetes Engine (GKE) et des nœuds de cluster sous-jacents. Vous pouvez utiliser les métriques pour suivre, résoudre et réduire la latence de démarrage.
Cette page s'adresse aux administrateurs et opérateurs de plate-forme qui doivent surveiller et optimiser la latence de démarrage de leurs charges de travail. Pour en savoir plus sur les rôles courants que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.
Présentation
La latence de démarrage a un impact important sur la façon dont votre application répond aux pics de trafic, la rapidité avec laquelle ses réplicas se rétablissent après une interruption et l'efficacité des coûts d'exploitation de vos clusters et de vos charges de travail. Surveiller la latence de démarrage de vos charges de travail peut vous aider à détecter les dégradations de latence et à suivre l'impact des mises à jour de la charge de travail et de l'infrastructure sur la latence de démarrage.
Optimiser la latence de démarrage des charges de travail présente les avantages suivants:
- Réduit la latence de réponse de votre service aux utilisateurs lors des pics de trafic.
- Réduit la capacité de diffusion excédentaire nécessaire pour absorber les pics de demande pendant la création de nouveaux réplicas.
- Réduit le temps d'inactivité des ressources déjà déployées et qui attendent le démarrage des ressources restantes lors des calculs par lot.
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.
Activez les API Cloud Logging et Cloud Monitoring.
Conditions requises
Pour afficher les métriques et les tableaux de bord de la latence de démarrage des charges de travail, votre cluster GKE doit répondre aux exigences suivantes:
- Vous devez disposer de la version 1.31.1-gke.1678000 ou ultérieure de GKE.
- Vous devez configurer la collecte des métriques système.
- Vous devez configurer la collecte des journaux système.
- Activez les métriques d'état Kube avec le composant
PODsur vos clusters pour afficher les métriques des pods et des conteneurs.
Rôles et autorisations requis
Pour obtenir les autorisations nécessaires pour activer la génération de journaux, et pour y accéder et les traiter, demandez à votre administrateur de vous accorder les rôles IAM suivants:
-
Afficher les clusters, les nœuds et les charges de travail GKE : Afficheur Kubernetes Engine (
roles/container.viewer) dans votre projet -
Accédez aux métriques de latence de démarrage et affichez les tableaux de bord : Lecteur de tableau de bord Monitoring (
roles/monitoring.viewer) sur votre projet -
Accédez aux journaux contenant des informations sur la latence, telles que les événements d'extraction d'images Kubelet, et affichez-les dans l'explorateur de journaux et l'analyse de journaux :
Visionneuse de journaux (
roles/logging.viewer) sur votre projet
Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.
Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.
Métriques de latence de démarrage
Les métriques de latence de démarrage sont incluses dans les métriques système de GKE et 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 kubernetes.io/. Ce préfixe a été omis dans les entrées du tableau.
| Type de métrique (Niveaux de la hiérarchie des ressources) Nom à afficher |
|
|---|---|
|
Genre, Type, Unité
Ressources surveillées |
Description Libellés |
pod/latencies/pod_first_ready
(project)
Latence du premier pod prêt |
|
GAUGE, Double, s
k8s_pod |
La latence de démarrage du pod de bout en bout (du pod Created au Ready), y compris les extractions d'images. Échantillonné toutes les 60 secondes. |
node/latencies/startup
(project)
Latence de démarrage des nœuds |
|
GAUGE, INT64, s
k8s_node |
Latence de démarrage totale du nœud, de CreationTimestamp à Kubernetes node ready pour la première fois dans l'instance GCE. Échantillonné toutes les 60 secondes.accelerator_family: classification des nœuds en fonction des accélérateurs matériels: gpu, tpu et cpu.
kube_control_plane_available: indique si la requête de création de nœud a été reçue lorsque le KCP (plan de contrôle kube) était disponible.
|
autoscaler/latencies/per_hpa_recommendation_scale_latency_seconds
(project)
Latence de scaling par recommandation HPA |
|
GAUGE, DOUBLE, s
k8s_scale |
Latence de la recommandation de scaling de l'autoscaler horizontal de pods (HPA) (temps écoulé entre la création des métriques et l'application de la recommandation de scaling correspondante au serveur d'API) pour la cible HPA. Échantillonné toutes les 60 secondes. Après échantillonnage, les données ne sont pas visibles pendant un délai pouvant atteindre 20 secondes.metric_type: type de source de métrique. Il doit être défini sur "ContainerResource", "External", "Object", "Pods" ou "Resource".
|
Afficher le tableau de bord "Latence de démarrage" pour les charges de travail
Le tableau de bord Latence de démarrage pour les charges de travail n'est disponible que pour les déploiements. Pour afficher les métriques de latence de démarrage pour les déploiements, procédez comme suit dans la console Google Cloud:
Accédez à la page "Charges de travail".
Pour ouvrir la vue Détails du déploiement, cliquez sur le nom de la charge de travail que vous souhaitez inspecter.
Cliquez sur l'onglet Observabilité.
Sélectionnez Délai de démarrage dans le menu de gauche.
Afficher la distribution de la latence de démarrage des pods
La latence de démarrage des pods fait référence à la latence de démarrage totale, y compris les extractions d'images, qui mesure le temps écoulé entre l'état Created du pod et l'état Ready. Vous pouvez évaluer la latence de démarrage des pods à l'aide des deux graphiques suivants:
Graphique Distribution de la latence de démarrage des pods : ce graphique affiche les centiles de latence de démarrage des pods (cinquante-cinquième centile, quatre-vingt-cinquième centile et quatre-vingt-neuvième centile) calculés en fonction des observations des événements de démarrage des pods sur des intervalles de trois heures fixes, par exemple, de minuit à 3h00 et de 3h00 à 6h00. Vous pouvez utiliser ce graphique aux fins suivantes :
- Comprendre la latence de démarrage de votre pod de référence
- Identifiez les changements de latence de démarrage des pods au fil du temps.
- Correlez les modifications de la latence de démarrage des pods avec des événements récents, tels que les déploiements de charges de travail ou les événements de l'autoscaler de cluster. Vous pouvez sélectionner les événements dans la liste Annotations en haut du tableau de bord.
Graphique Nombre de démarrages de pod: ce graphique indique le nombre de pods démarrés au cours des intervalles de temps sélectionnés. Vous pouvez utiliser ce graphique pour les objectifs suivants:
- Découvrez les tailles d'échantillon de pod utilisées pour calculer les centiles de latence de démarrage des pods pour un intervalle de temps donné.
- Comprendre les causes des démarrages de pod, tels que les déploiements de charges de travail ou les événements d'autoscaler horizontal de pod Vous pouvez sélectionner les événements dans la liste Annotations en haut du tableau de bord.
Afficher la latence de démarrage de chaque pod
Vous pouvez consulter la latence de démarrage de chaque pod dans le graphique chronologique Latence de première disponibilité du pod et la liste associée.
- Utilisez le graphique chronologique de la latence de premier démarrage du pod pour établir une corrélation entre les démarrages individuels des pods et les événements récents, tels que les événements de l'autoscaler horizontal de pods ou de l'autoscaler de cluster. Vous pouvez sélectionner ces événements dans la liste Annotations en haut du tableau de bord. Ce graphique vous aide à déterminer les causes potentielles de toute modification de la latence de démarrage par rapport aux autres pods.
- Utilisez la liste Latence de premier démarrage du pod pour identifier les pods individuels qui ont mis le plus ou le moins de temps à démarrer. Vous pouvez trier la liste par colonne Latence. Lorsque vous identifiez les pods qui présentent la latence de démarrage la plus élevée, vous pouvez résoudre les problèmes de dégradation de la latence en établissant une corrélation entre les événements de démarrage du pod et d'autres événements récents.
Vous pouvez savoir quand un pod individuel a été créé en examinant la valeur du champ timestamp dans un événement de création de pod correspondant. Pour afficher le champ timestamp, exécutez la requête suivante dans l'explorateur de journaux:
log_id("cloudaudit.googleapis.com/activity") AND
protoPayload.methodName="io.k8s.core.v1.pods.create" AND
resource.labels.project_id=PROJECT_ID AND
resource.labels.cluster_name=CLUSTER_NAME AND
resource.labels.location=CLUSTER_LOCATION AND
protoPayload.response.metadata.namespace=NAMESPACE AND
protoPayload.response.metadata.name=POD_NAME
Pour répertorier tous les événements de création de pod pour votre charge de travail, utilisez le filtre suivant dans la requête précédente :
protoPayload.response.metadata.name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"
Lorsque vous comparez les latences de pods individuels, vous pouvez tester l'impact de différentes configurations sur la latence de démarrage des pods et identifier une configuration optimale en fonction de vos exigences.
Déterminer la latence de planification des pods
La latence de planification des pods correspond au temps écoulé entre la création d'un pod et sa planification sur un nœud. La latence de planification du pod contribue au temps de démarrage de bout en bout du pod. Elle est calculée en soustrayant les codes temporels d'un événement de planification de pod et d'une demande de création de pod.
Vous pouvez trouver un code temporel d'un événement de planification de pod individuel dans le champ jsonPayload.eventTime d'un événement de planification de pod correspondant. Pour afficher le champ jsonPayload.eventTime, exécutez la requête suivante dans l'explorateur de journaux:
log_id("events")
jsonPayload.reason="Scheduled"
resource.type="k8s_pod"
resource.labels.project_id=PROJECT_ID
resource.labels.location=CLUSTER_LOCATION
resource.labels.cluster_name=CLUSTER_NAME
resource.labels.namespace_name=NAMESPACE
resource.labels.pod_name=POD_NAME
Pour répertorier tous les événements de planification de pod pour votre charge de travail, utilisez le filtre suivant dans la requête précédente :
resource.labels.pod_name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"
Afficher la latence d'extraction d'image
La latence d'extraction de l'image du conteneur contribue à la latence de démarrage du pod dans les scénarios où l'image n'est pas encore disponible sur le nœud ou doit être actualisée. Lorsque vous optimisez la latence d'extraction d'image, vous réduisez la latence de démarrage de votre charge de travail lors des événements d'extension du cluster.
Vous pouvez consulter le tableau Événements d'extraction d'images Kubelet pour voir quand les images de conteneur de la charge de travail ont été extraites et la durée du processus.
La latence de récupération d'image est disponible dans le champ jsonPayload.message, qui contient un message semblable à celui-ci:
"Successfully pulled image "gcr.io/example-project/image-name" in 17.093s (33.051s including waiting). Image size: 206980012 bytes."
Afficher la distribution de la latence des recommandations de scaling HPA
La latence des recommandations de scaling de l'autoscaler horizontal de pods (HPA) pour la cible HPA correspond au temps écoulé entre la création des métriques et l'application de la recommandation de scaling correspondante au serveur d'API. Lorsque vous optimisez la latence des recommandations de scaling HPA, vous réduisez la latence de démarrage de votre charge de travail lors des événements d'extension.
Vous pouvez consulter le scaling HPA dans les deux graphiques suivants:
Graphique Répartition de la latence des recommandations de scaling HPA: ce graphique affiche les centiles de latence des recommandations de scaling HPA (cinquante-cinquième centile, quatre-vingt-cinquième centile et quatre-vingt-neuvième centile) calculés en fonction des observations des recommandations de scaling HPA sur les intervalles de trois heures précédents. Vous pouvez utiliser ce graphique aux fins suivantes:
- Comprendre la latence de référence des recommandations de scaling HPA
- Identifiez les fluctuations de la latence des recommandations de scaling HPA au fil du temps.
- Correlez les fluctuations de la latence des recommandations de scaling HPA avec les événements récents. Vous pouvez sélectionner les événements dans la liste Annotations en haut du tableau de bord.
Graphique Nombre de recommandations de scaling HPA: ce graphique indique le nombre de recommandations de scaling HPA observées au cours de l'intervalle de temps sélectionné. Utilisez le graphique pour les tâches suivantes:
- Comprendre les tailles d'échantillon des recommandations de scaling HPA Les échantillons sont utilisés pour calculer les centiles de la distribution de latence des recommandations de scaling HPA pour un intervalle de temps donné.
- Correlez les recommandations de scaling HPA avec les nouveaux événements de démarrage de pod et avec les événements de l'autoscaler horizontal de pods. Vous pouvez sélectionner les événements dans la liste Annotations en haut du tableau de bord.
Afficher les problèmes de planification des pods
Les problèmes de planification des pods peuvent avoir un impact sur la latence de démarrage de bout en bout de votre charge de travail. Pour réduire la latence de démarrage de bout en bout de votre charge de travail, corrigez et réduisez le nombre de ces problèmes.
Voici les deux graphiques disponibles pour suivre ces problèmes:
- Le graphique Pods non programmables/en attente/en échec indique le nombre de pods non programmables, en attente et en échec au fil du temps.
- Le graphique Conteneurs Intervalle entre les tentatives/En attente/Échec aptitude indique le nombre de conteneurs dans ces états au fil du temps.
Afficher le tableau de bord de latence de démarrage pour les nœuds
Pour afficher les métriques de latence de démarrage pour les nœuds, procédez comme suit dans la console Google Cloud:
Accédez à la page Clusters Kubernetes.
Pour ouvrir la vue Détails du cluster, cliquez sur le nom du cluster que vous souhaitez inspecter.
Cliquez sur l'onglet Observabilité.
Dans le menu de gauche, sélectionnez Latence de démarrage.
Afficher la distribution de la latence de démarrage des nœuds
La latence de démarrage d'un nœud fait référence à la latence de démarrage totale, qui mesure le temps écoulé entre l'état CreationTimestamp du nœud et l'état Kubernetes node ready. La latence de démarrage des nœuds peut être consultée dans les deux graphiques suivants:
Graphique Distribution de la latence de démarrage du nœud : ce graphique affiche les percentiles de la latence de démarrage du nœud (50e percentile, 95e percentile et 99e percentile) calculés en fonction des observations des événements de démarrage du nœud sur des intervalles de temps fixes de trois heures, par exemple de minuit à 3h et de 3h à 6h. Vous pouvez utiliser ce graphique aux fins suivantes :
- Comprendre la latence de démarrage de votre nœud de référence
- Identifiez les changements de latence de démarrage des nœuds au fil du temps.
- Correlez les modifications de la latence de démarrage des nœuds avec des événements récents, tels que des mises à jour de cluster ou de pool de nœuds. Vous pouvez sélectionner les événements dans la liste Annotations en haut du tableau de bord.
Graphique Nombre de démarrages de nœuds: ce graphique indique le nombre de nœuds démarrés au cours des intervalles de temps sélectionnés. Vous pouvez utiliser le graphique pour les objectifs suivants:
- Comprendre les tailles d'échantillon des nœuds, utilisées pour calculer les centiles de latence de démarrage des nœuds pour un intervalle de temps donné.
- Comprendre les causes des démarrages de nœuds, tels que les mises à jour du pool de nœuds ou les événements de l'autoscaler de cluster Vous pouvez sélectionner les événements dans la liste Annotations en haut du tableau de bord.
Afficher la latence de démarrage de chaque nœud
Lorsque vous comparez les latences de nœuds individuels, vous pouvez tester l'impact de différentes configurations de nœuds sur la latence de démarrage du nœud et identifier une configuration optimale en fonction de vos exigences. Vous pouvez afficher la latence de démarrage de chaque nœud dans le graphique chronologique Latence de démarrage du nœud et la liste associée.
Utilisez le graphique chronologique de la latence de démarrage des nœuds pour établir une corrélation entre les démarrages de nœuds individuels et les événements récents, tels que les mises à jour de cluster ou de pool de nœuds. Vous pouvez déterminer les causes potentielles des modifications de latence de démarrage par rapport aux autres nœuds. Vous pouvez sélectionner les événements dans la liste Annotations en haut du tableau de bord.
Utilisez la liste Latence de démarrage du nœud pour identifier les nœuds individuels qui ont mis le plus ou le moins de temps à démarrer. Vous pouvez trier la liste par colonne Latence. Lorsque vous identifiez les nœuds présentant la latence de démarrage la plus élevée, vous pouvez résoudre les problèmes de dégradation de la latence en corrélant les événements de démarrage des nœuds avec d'autres événements récents.
Vous pouvez savoir quand un nœud individuel a été créé en examinant la valeur du champ protoPayload.metadata.creationTimestamp dans un événement de création de nœud correspondant. Pour afficher le champ protoPayload.metadata.creationTimestamp, exécutez la requête suivante dans l'explorateur de journaux:
log_id("cloudaudit.googleapis.com/activity") AND
protoPayload.methodName="io.k8s.core.v1.nodes.create" AND
resource.labels.project_id=PROJECT_ID AND
resource.labels.cluster_name=CLUSTER_NAME AND
resource.labels.location=CLUSTER_LOCATION AND
protoPayload.response.metadata.name=NODE_NAME
Afficher la latence de démarrage dans un pool de nœuds
Si vos pools de nœuds ont des configurations différentes, par exemple pour exécuter différentes charges de travail, vous devrez peut-être surveiller la latence de démarrage des nœuds séparément par pool de nœuds. Lorsque vous comparez les latences de démarrage des nœuds dans vos pools de nœuds, vous pouvez obtenir des insights sur l'impact de la configuration des nœuds sur la latence de démarrage des nœuds et, par conséquent, optimiser la latence.
Par défaut, le tableau de bord Latence de démarrage des nœuds affiche la distribution agrégée de la latence de démarrage et les latences de démarrage individuelles des nœuds pour tous les pools de nœuds d'un cluster. Pour afficher la latence de démarrage des nœuds pour un pool de nœuds spécifique, sélectionnez le nom du pool de nœuds à l'aide du filtre $node_pool_name_var situé en haut du tableau de bord.
Étape suivante
- Découvrez comment optimiser l'autoscaling des pods en fonction des métriques.
- Découvrez comment réduire la latence de démarrage à froid sur GKE.
- Découvrez comment réduire la latence d'extraction des images avec le streaming d'images.
- Découvrez les aspects économiques surprenants de l'ajustement de l'autoscaling horizontal des pods.
- Surveillez vos charges de travail grâce à la surveillance automatique des applications.