Auf dieser Seite werden die Messwerte und Dashboards beschrieben, die zum Überwachen der Startlatenz von Google Kubernetes Engine-Arbeitslasten (GKE) und den zugrunde liegenden Clusterknoten verfügbar sind. Sie können die Messwerte verwenden, um die Startlatenz zu verfolgen, Fehler zu beheben und sie zu reduzieren.
Diese Seite richtet sich an Plattformadministratoren und ‑betreiber, die die Startlatenz ihrer Arbeitslasten überwachen und optimieren müssen. Weitere Informationen zu gängigen Rollen, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE Nutzerrollen und -aufgaben.
Übersicht
Die Startlatenz hat erhebliche Auswirkungen darauf, wie Ihre Anwendung auf Trafficspitzen reagiert, wie schnell ihre Replikate nach Unterbrechungen wiederhergestellt werden und wie effizient die Betriebskosten Ihrer Cluster und Arbeitslasten sein können. Wenn Sie die Startlatenz Ihrer Arbeitslasten überwachen, können Sie Latenzverschlechterungen erkennen und die Auswirkungen von Arbeitslast- und Infrastrukturupdates auf die Startlatenz verfolgen.
Die Optimierung der Startlatenz von Arbeitslasten hat folgende Vorteile:
- Die Antwortlatenz Ihres Dienstes für Nutzer wird bei Trafficspitzen reduziert.
- Die überschüssige Bereitstellungskapazität, die zum Auffangen von Nachfragespitzen erforderlich ist, während neue Replikate erstellt werden, wird reduziert.
- Die Leerlaufzeit von Ressourcen, die bereits bereitgestellt wurden und darauf warten, dass die restlichen Ressourcen bei Batchberechnungen gestartet werden, wird reduziert.
Hinweis
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten,
installieren und dann
initialisieren Sie die
gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste
Version mit dem
gcloud components updateBefehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
Aktivieren Sie die Cloud Logging und Cloud Monitoring APIs.
Rollen, die zum Aktivieren von APIs erforderlich sind
Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (
roles/serviceusage.serviceUsageAdmin), die die Berechtigungserviceusage.services.enableenthält. Informationen zum Zuweisen von Rollen.
Voraussetzungen
Damit Sie Messwerte und Dashboards für die Startlatenz von Arbeitslasten aufrufen können, muss Ihr GKE-Cluster die folgenden Anforderungen erfüllen:
- Sie müssen mindestens GKE-Version 1.31.1-gke.1678000 verwenden.
- Sie müssen die Erfassung von Systemmesswerten konfigurieren.
- Sie müssen die Erfassung von Systemlogs konfigurieren.
- Aktivieren Sie Kube State Metrics mit
der
PODKomponente in Ihren Clustern, um die Pod- und Containermesswerte aufzurufen.
Erforderliche Rollen und Berechtigungen
Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Aktivieren der Loggenerierung sowie zum Zugriff auf Logs und deren Verarbeitung benötigen:
-
GKE-Cluster, ‑Knoten und ‑Arbeitslasten ansehen:
Kubernetes Engine-Betrachter (
roles/container.viewer) für Ihr Projekt -
Auf Messwerte zur Startlatenz zugreifen und die Dashboards aufrufen:
Monitoring Viewer (
roles/monitoring.viewer) für Ihr Projekt -
Auf Logs mit Latenzinformationen wie Kubelet-Image-Abrufereignissen zugreifen und sie im Log-Explorer und in Observability Analytics ansehen:
Log-Betrachter (
roles/logging.viewer) für Ihr Projekt
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.
Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.
Messwerte zur Startlatenz
Messwerte zur Startlatenz sind in den GKE-Systemmesswerten enthalten und werden in dasselbe Projekt wie der GKE-Cluster zu Cloud Monitoring exportiert.
Die Cloud Monitoring-Messwertnamen in dieser Tabelle müssen das Präfix kubernetes.io/ haben. Dieses Präfix wurde in den Einträgen der Tabelle weggelassen.
| Messwerttyp (Ebenen der Ressourcenhierarchie) Anzeigename |
|
|---|---|
|
Art, Typ, Einheit
Überwachte Ressourcen |
Beschreibung Labels |
pod/latencies/pod_first_ready
(Projekt)
Latenz der Pod-Bereitschaft |
|
GAUGE, Double, s
k8s_pod |
End-to-End-Startlatenz des Pods (von Created bis Ready), einschließlich Image-Abrufe. Alle 60 Sekunden wird eine Stichprobe erstellt. |
node/latencies/startup
(Projekt)
Latenz beim Knotenstart |
|
GAUGE, INT64, s
k8s_node |
Gesamte Startlatenz des Knotens, vom CreationTimestamp der GCE-Instanz bis zum ersten Kubernetes node ready. Alle 60 Sekunden wird eine Stichprobe erstellt.accelerator_family: Eine Klassifizierung von Knoten basierend auf Hardwarebeschleunigern: gpu, tpu, cpu.
kube_control_plane_available: Gibt an, ob die Knotenanfrage empfangen wurde, als die KCP (kube control plane) verfügbar war.
|
autoscaler/latencies/per_hpa_recommendation_scale_latency_seconds
(Projekt)
Latenz pro HPA-Skalierungsempfehlung |
|
GAUGE, DOUBLE, s
k8s_scale |
Latenz der Skalierungsempfehlung des horizontalen Pod-Autoscalers (HPA) (Zeit zwischen dem Erstellen von Messwerten und dem Anwenden der entsprechenden Skalierungsempfehlung auf den API-Server) für das HPA-Ziel. Alle 60 Sekunden wird eine Stichprobe erstellt. Nach der Stichprobe werden bis zu 20 Sekunden lang keine Daten angezeigt.metric_type: Der Typ der Messwertquelle. Mögliche Werte sind "ContainerResource", "External", "Object", "Pods" oder "Resource".
|
Dashboard „Startlatenz“ für Arbeitslasten aufrufen
Das Dashboard Startlatenz für Arbeitslasten ist nur für Deployments verfügbar. So rufen Sie Messwerte zur Startlatenz für Deployments in der Console auf: Google Cloud
Rufen Sie die Seite Arbeitslasten auf.
Klicken Sie auf den Namen der Arbeitslast, die Sie untersuchen möchten, um die Ansicht Deployment-Details zu öffnen.
Klicken Sie auf den Tab Beobachtbarkeit.
Wählen Sie im Menü auf der linken Seite Startlatenz aus.
Verteilung der Startlatenz von Pods ansehen
Die Startlatenz von Pods bezieht sich auf die gesamte Startlatenz, einschließlich Image-Abrufe. Sie misst die Zeit vom Status Created des Pods bis zum Status Ready. Sie können die Startlatenz von Pods anhand der folgenden beiden Diagramme bewerten:
Diagramm Verteilung der Pod-Startlatenz: In diesem Diagramm werden die Perzentile der Startlatenz von Pods (50., 95. und 99. Perzentil) angezeigt, die anhand der Beobachtungen von Pod-Startereignissen in festen 3-Stunden-Intervallen berechnet werden, z. B. 00:00–03:00 Uhr und 03:00–06:00 Uhr. Sie können dieses Diagramm für folgende Zwecke verwenden:
- Grundlegende Pod-Startlatenz verstehen
- Änderungen der Pod-Startlatenz im Zeitverlauf erkennen
- Änderungen der Pod-Startlatenz mit aktuellen Ereignissen korrelieren, z. B. Arbeitslast-Deployments oder Cluster Autoscaler-Ereignisse. Sie können die Ereignisse oben im Dashboard in der Liste Annotationen auswählen.
Diagramm Anzahl der Pod-Starts: In diesem Diagramm wird die Anzahl der Pods angezeigt, die in den ausgewählten Zeitintervallen gestartet wurden. Sie können dieses Diagramm für folgende Zwecke verwenden:
- Pod-Stichprobengrößen verstehen, die zum Berechnen der Perzentile der Verteilung der Pod-Startlatenz für ein bestimmtes Zeitintervall verwendet werden.
- Ursachen für Pod-Starts verstehen, z. B. Arbeitslast-Deployments oder Ereignisse des horizontalen Pod-Autoscalers. Sie können die Ereignisse oben im Dashboard in der Liste Annotationen auswählen.
Startlatenz einzelner Pods ansehen
Sie können die Startlatenz einzelner Pods im Zeitliniendiagramm Latenz der Pod-Bereitschaft und in der zugehörigen Liste ansehen.
- Verwenden Sie das Zeitliniendiagramm Latenz der Pod-Bereitschaft , um einzelne Pod-Starts mit aktuellen Ereignissen zu korrelieren, z. B. Ereignissen des horizontalen Pod-Autoscalers oder des Cluster Autoscalers. Sie können diese Ereignisse oben im Dashboard in der Liste Annotationen auswählen. Dieses Diagramm hilft Ihnen, potenzielle Ursachen für Änderungen der Startlatenz im Vergleich zu anderen Pods zu ermitteln.
- Verwenden Sie die Liste Latenz der Pod-Bereitschaft , um einzelne Pods zu identifizieren, die am längsten oder kürzesten zum Starten benötigt haben. Sie können die Liste nach der Spalte Latenz sortieren. Wenn Sie Pods mit der höchsten Startlatenz identifizieren, können Sie die Latenzverschlechterung beheben, indem Sie die Pod-Startereignisse mit anderen aktuellen Ereignissen korrelieren.
Sie können herausfinden, wann ein einzelner Pod erstellt wurde, indem Sie sich den Wert im Feld timestamp in einem entsprechenden Pod-Erstellungsereignis ansehen. Führen Sie die folgende Abfrage in
Log-Explorer aus, um das Feld
timestamp aufzurufen:
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
Verwenden Sie den folgenden Filter
in der vorherigen Abfrage, um alle Pod-Erstellungsereignisse für Ihre Arbeitslast aufzulisten:protoPayload.response.metadata.name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"
Wenn Sie die Latenzen einzelner Pods vergleichen, können Sie die Auswirkungen verschiedener Konfigurationen auf die Pod-Startlatenz testen und basierend auf Ihren Anforderungen eine optimale Konfiguration ermitteln.
Latenz der Pod-Planung bestimmen
Die Latenz der Pod-Planung ist die Zeit zwischen dem Erstellen eines Pods und dem Planen des Pods auf einem Knoten. Die Latenz der Pod-Planung trägt zur End-to-End-Startzeit eines Pods bei und wird berechnet, indem die Zeitstempel eines Pod-Planungsereignisses und einer Pod-Erstellungsanfrage voneinander subtrahiert werden.
Einen Zeitstempel eines einzelnen Pod-Planungsereignisses finden Sie im Feld jsonPayload.eventTime in einem entsprechenden Pod-Planungsereignis. Führen Sie die folgende Abfrage in
Log-Explorer aus, um das jsonPayload.eventTime Feld aufzurufen:
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
Verwenden Sie den folgenden Filter
in der vorherigen Abfrage:
resource.labels.pod_name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}", um alle Pod-Planungsereignisse für Ihre Arbeitslast aufzulisten:
Latenz beim Abrufen von Images ansehen
Die Latenz beim Abrufen von Container-Images trägt in Szenarien zur Pod-Startlatenz bei, in denen das Image noch nicht auf dem Knoten verfügbar ist oder aktualisiert werden muss. Wenn Sie die Latenz beim Abrufen von Images optimieren, reduzieren Sie die Startlatenz Ihrer Arbeitslast bei Cluster-Scale-out-Ereignissen.
In der Tabelle Kubelet-Image-Abrufereignisse können Sie sehen, wann die Container-Images der Arbeitslast abgerufen wurden und wie lange der Vorgang gedauert hat.
Die Latenz beim Abrufen von Images ist im Feld jsonPayload.message verfügbar, das eine Nachricht wie die folgende enthält:
"Successfully pulled image "gcr.io/example-project/image-name" in 17.093s (33.051s including waiting). Image size: 206980012 bytes."
Verteilung der Latenz von HPA-Skalierungsempfehlungen ansehen
Die Latenz von Skalierungsempfehlungen des horizontalen Pod-Autoscalers (HPA) für das HPA-Ziel ist die Zeit zwischen dem Erstellen der Messwerte und dem Anwenden der entsprechenden Skalierungsempfehlung auf den API-Server. Wenn Sie die Latenz von HPA-Skalierungsempfehlungen optimieren, reduzieren Sie die Startlatenz Ihrer Arbeitslast bei Scale-out-Ereignissen.
Die HPA-Skalierung kann in den folgenden beiden Diagrammen angezeigt werden:
Diagramm Verteilung der Latenz von HPA-Skalierungsempfehlungen: In diesem Diagramm werden die Perzentile der Latenz von HPA-Skalierungsempfehlungen (50., 95. und 99. Perzentil) angezeigt, die anhand der Beobachtungen von HPA-Skalierungsempfehlungen in den letzten 3-Stunden-Intervallen berechnet werden. Sie können dieses Diagramm für folgende Zwecke verwenden:
- Grundlegende Latenz von HPA-Skalierungsempfehlungen verstehen
- Änderungen der Latenz von HPA-Skalierungsempfehlungen im Zeitverlauf erkennen
- Änderungen der Latenz von HPA-Skalierungsempfehlungen mit aktuellen Ereignissen korrelieren. Sie können die Ereignisse oben im Dashboard in der Liste Annotationen auswählen.
Diagramm Anzahl der HPA-Skalierungsempfehlungen: In diesem Diagramm wird die Anzahl der HPA-Skalierungsempfehlungen angezeigt, die im ausgewählten Zeitintervall beobachtet wurden. Verwenden Sie das Diagramm für die folgenden Aufgaben:
- Stichprobengrößen für HPA-Skalierungsempfehlungen verstehen. Die Stichproben werden verwendet, um die Perzentile in der Verteilung der Latenz für HPA-Skalierungsempfehlungen für ein bestimmtes Zeitintervall zu berechnen.
- HPA-Skalierungsempfehlungen mit Startereignissen neuer Pods und mit Ereignissen des horizontalen Pod-Autoscalers korrelieren. Sie können die Ereignisse oben im Dashboard in der Liste Annotationen auswählen.
Planungsprobleme für Pods ansehen
Probleme bei der Pod-Planung können sich auf die End-to-End-Startlatenz Ihrer Arbeitslast auswirken. Um die End-to-End-Startlatenz Ihrer Arbeitslast zu reduzieren, beheben Sie diese Probleme und reduzieren Sie ihre Anzahl.
Die folgenden beiden Diagramme sind zum Verfolgen solcher Probleme verfügbar:
- Im Diagramm Nicht planbare/ausstehende/fehlgeschlagene Pods werden die Anzahl der nicht planbaren, ausstehenden und fehlgeschlagenen Pods im Zeitverlauf angezeigt.
- Im Diagramm Container mit Backoff/im Wartezustand/mit fehlgeschlagener Bereitschaftsprüfung werden die Anzahl der Container in diesen Zuständen im Zeitverlauf angezeigt.
Dashboard „Startlatenz“ für Knoten aufrufen
So rufen Sie Messwerte zur Startlatenz für Knoten in der Google Cloud Console auf:
Rufen Sie die Seite Kubernetes-Cluster auf.
Klicken Sie auf den Namen des Clusters, den Sie untersuchen möchten, um die Ansicht Clusterdetails zu öffnen.
Klicken Sie auf den Tab Beobachtbarkeit.
Wählen Sie im Menü auf der linken Seite Startlatenz aus.
Verteilung der Startlatenz von Knoten ansehen
Die Startlatenz eines Knotens bezieht sich auf die gesamte Startlatenz, die die Zeit vom CreationTimestamp des Knotens bis zum Status Kubernetes node ready misst. Die Latenz beim Knotenstart kann in den folgenden beiden Diagrammen angezeigt werden:
Diagramm Verteilung der Latenz beim Knotenstart: In diesem Diagramm werden die Perzentile der Latenz beim Knotenstart (50., 95. und 99. Perzentil) angezeigt, die anhand der Beobachtungen von Knotenstartereignissen in festen 3-Stunden-Intervallen berechnet werden, z. B. 00:00–03:00 Uhr und 03:00–06:00 Uhr. Sie können dieses Diagramm für folgende Zwecke verwenden:
- Grundlegende Latenz beim Knotenstart verstehen
- Änderungen der Latenz beim Knotenstart im Zeitverlauf erkennen
- Änderungen der Latenz beim Knotenstart mit aktuellen Ereignissen korrelieren, z. B. Clusterupdates oder Knotenpoolupdates. Sie können die Ereignisse oben im Dashboard in der Liste Annotationen auswählen.
Diagramm Anzahl der Knotenstarts: In diesem Diagramm wird die Anzahl der Knoten angezeigt, die in den ausgewählten Zeitintervallen gestartet wurden. Sie können dieses Diagramm für folgende Zwecke verwenden:
- Knotenstichprobengrößen verstehen, die zum Berechnen der Perzentile der Verteilung der Latenz beim Knotenstart für ein bestimmtes Zeitintervall verwendet werden.
- Ursachen für Knotenstarts verstehen, z. B. Knotenpoolupdates oder Cluster Autoscaler-Ereignisse. Sie können die Ereignisse oben im Dashboard in der Liste Annotationen auswählen.
Startlatenz einzelner Knoten ansehen
Wenn Sie die Latenzen einzelner Knoten vergleichen, können Sie die Auswirkungen verschiedener Knotenkonfigurationen auf die Latenz beim Knotenstart testen und basierend auf Ihren Anforderungen eine optimale Konfiguration ermitteln. Sie können die Startlatenz einzelner Knoten im Zeitliniendiagramm Latenz beim Knotenstart und in der zugehörigen Liste ansehen.
Verwenden Sie das Zeitliniendiagramm Latenz beim Knotenstart , um einzelne Knotenstarts mit aktuellen Ereignissen zu korrelieren, z. B. Clusterupdates oder Knotenpoolupdates. Sie können potenzielle Ursachen für Änderungen der Startlatenz im Vergleich zu anderen Knoten ermitteln. Sie können die Ereignisse oben im Dashboard in der Liste Annotationen auswählen.
Verwenden Sie die Liste Latenz beim Knotenstart , um einzelne Knoten zu identifizieren, die am längsten oder kürzesten zum Starten benötigt haben. Sie können die Liste nach der Spalte Latenz sortieren. Wenn Sie Knoten mit der höchsten Startlatenz identifizieren, können Sie die Latenzverschlechterung beheben, indem Sie Knotenstartereignisse mit anderen aktuellen Ereignissen korrelieren.
Sie können herausfinden, wann ein einzelner Knoten erstellt wurde, indem Sie sich den Wert des Felds protoPayload.metadata.creationTimestamp in einem entsprechenden Knoten-Erstellungsereignis ansehen. Führen Sie die
folgende Abfrage im Log-Explorer aus, um das Feld protoPayload.metadata.creationTimestamp aufzurufen:
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
Startlatenz in einem Knotenpool ansehen
Wenn Ihre Knotenpools unterschiedliche Konfigurationen haben, z. B. um verschiedene Arbeitslasten auszuführen, müssen Sie die Latenz beim Knotenstart möglicherweise separat nach Knotenpools überwachen. Wenn Sie die Latenzen beim Knotenstart in Ihren Knotenpools vergleichen, erhalten Sie Einblicke in die Auswirkungen der Knotenkonfiguration auf die Latenz beim Knotenstart und können die Latenz entsprechend optimieren.
Standardmäßig werden im Dashboard Latenz beim Knotenstart die aggregierte Verteilung der Startlatenz und die einzelnen Latenzen beim Knotenstart für alle Knotenpools in einem Cluster angezeigt. Wenn Sie die Latenz beim Knotenstart für einen bestimmten Knotenpool aufrufen möchten, wählen Sie den Namen des Knotenpools mit dem Filter $node_pool_name_var oben im Dashboard aus.
Nächste Schritte
- Informationen zum Beschleunigen des Anwendungsstarts mit dem CPU-Boost beim Starten
- Informationen zum Optimieren des Pod-Autoscalings anhand von Messwerten
- Weitere Informationen zu Möglichkeiten zum Reduzieren der Kaltstartlatenz in GKE
- Informationen zum Reduzieren der Latenz beim Abrufen von Images mit Image-Streaming
- Informationen zu den überraschenden wirtschaftlichen Vorteilen der Optimierung des horizontalen Pod-Autoscalings.
- Arbeitslasten mit der automatischen Anwendungsüberwachung überwachen