Auf dieser Seite werden die Messwerte und Dashboards beschrieben, die zum Überwachen der Startlatenz von Google Kubernetes Engine-Arbeitslasten (GKE) und den zugrunde liegenden Clusternknoten verfügbar sind. Mithilfe der Messwerte können Sie die Startlatenz nachvollziehen, Fehler beheben und sie 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 Enterprise-Nutzerrollen und -Aufgaben.
Übersicht
Die Startlatenz hat erhebliche Auswirkungen darauf, wie Ihre Anwendung auf Trafficspitzen reagiert, wie schnell ihre Replikate sich von Störungen erholen und wie effizient die Betriebskosten Ihrer Cluster und Arbeitslasten sein können. Wenn Sie die Startlatenz Ihrer Arbeitslasten im Blick behalten, können Sie Latenzverschlechterungen erkennen und die Auswirkungen von Arbeitslast- und Infrastrukturupdates auf die Startlatenz nachvollziehen.
Die Optimierung der Startlatenz von Arbeitslasten hat folgende Vorteile:
- Die Antwortlatenz Ihres Dienstes für Nutzer bei Traffic-Spitzen wird verringert.
- Reduziert die zusätzliche Bereitstellungskapazität, die erforderlich ist, um Nachfragespitzen abzufangen, während neue Replikate erstellt werden.
- Reduziert die Leerlaufzeit von Ressourcen, die bereits bereitgestellt wurden und darauf warten, dass die verbleibenden Ressourcen bei Batchberechnungen gestartet werden.
Hinweise
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, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit
gcloud components updateab.
Aktivieren Sie die Cloud Logging API und die Cloud Monitoring API.
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 benötigen die GKE-Version 1.31.1-gke.1678000 oder höher.
- Sie müssen die Erfassung von Systemmesswerten konfigurieren.
- Sie müssen die Erfassung von Systemlogs konfigurieren.
- Aktivieren Sie Kube State Metrics mit der Komponente
PODin 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 Protokollgenerierung sowie zum Aufrufen und Verarbeiten von Protokollen benötigen:
-
GKE-Cluster, Knoten und Arbeitslasten ansehen:
Kubernetes Engine Viewer (
roles/container.viewer) für Ihr Projekt -
So greifen Sie auf Messwerte zur Startlatenz zu und rufen die Dashboards auf:
Monitoring-Betrachter (
roles/monitoring.viewer) für Ihr Projekt -
Greifen Sie auf Logs mit Latenzinformationen zu, z. B. Kubelet-Ereignisse zum Abrufen von Images, und sehen Sie sie sich im Log-Explorer und in Log Analytics an:
Logbetrachter (
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 für die Startlatenz
Messwerte für die Startlatenz sind in den GKE-Systemmesswerten enthalten und werden in dasselbe Projekt wie der GKE-Cluster in 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 |
Die End-to-End-Startlatenz des Pods (von Pod Created bis Ready), einschließlich Image-Abrufen. Alle 60 Sekunden wird eine Stichprobe erstellt. |
node/latencies/startup
(Projekt)
Latenz beim Knotenstart |
|
GAUGE, INT64, s
k8s_node |
Die gesamte Startlatenz des Knotens, vom ersten 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 Anfrage zum Erstellen des Knotens empfangen wurde, als KCP (kube-control-plane) verfügbar war.
|
autoscaler/latencies/per_hpa_recommendation_scale_latency_seconds
(Projekt)
Latenz für die Skalierung pro HPA-Empfehlung |
|
GAUGE, DOUBLE, s
k8s_scale |
Latenz der HPA-Skalierungsempfehlung (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. Er sollte einer der folgenden Werte sein: "ContainerResource", "External", "Object", "Pods" oder "Resource".
|
Dashboard „Startlatenz“ für Arbeitslasten ansehen
Das Dashboard Startlatenz für Arbeitslasten ist nur für Bereitstellungen verfügbar. So rufen Sie Startlatenzmesswerte für Bereitstellungen in der Google Cloud -Konsole auf:
Zur Seite „Arbeitslasten“
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 Startup Latency (Startlatenz) aus.
Verteilung der Startlatenz von Pods ansehen
Die Startlatenz von Pods bezieht sich auf die gesamte Startlatenz, einschließlich Image-Abrufen, und 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. Perzentil, 95. Perzentil und 99. Perzentil) dargestellt, die auf Grundlage der Beobachtungen von Pod-Startereignissen in festen 3‑Stunden-Zeitintervallen berechnet werden, z. B. 00:00–03:00 Uhr und 03:00–06:00 Uhr. Sie können dieses Diagramm für die folgenden Zwecke verwenden:
- Latenz beim Starten von Pods im Ausgangszustand
- Veränderungen der Pod-Startlatenz im Laufe der Zeit erkennen.
- Setzen Sie Änderungen bei der Pod-Startlatenz in Beziehung zu den letzten Ereignissen, z. B. Arbeitslastbereitstellungen oder Cluster Autoscaler-Ereignissen. Sie können die Ereignisse oben im Dashboard in der Liste Anmerkungen auswählen.
Diagramm Anzahl der Pod-Starts: In diesem Diagramm sehen Sie die Anzahl der Pods, die in den ausgewählten Zeitintervallen gestartet wurden. Sie können dieses Diagramm für die folgenden Zwecke verwenden:
- Hier sehen Sie die Pod-Stichprobengrößen, die zum Berechnen der Perzentile der Verteilung der Pod-Startlatenz für ein bestimmtes Zeitintervall verwendet werden.
- Ursachen für Pod-Starts nachvollziehen, z. B. Workload-Deployments oder Ereignisse für horizontales Pod-Autoscaling. Sie können die Ereignisse oben im Dashboard in der Liste Anmerkungen auswählen.
Startlatenz einzelner Pods ansehen
Die Startlatenz einzelner Pods können Sie im Zeitachsendiagramm Pod First Ready Latency (Latenz bis zum ersten bereiten Pod) und in der zugehörigen Liste sehen.
- Mithilfe des Zeitachsendiagramms Pod First Ready Latency (Latenz bis zum ersten bereiten Pod) können Sie einzelne Pod-Starts mit aktuellen Ereignissen wie Ereignissen des horizontalen Pod-Autoscalers oder des Cluster-Autoscalers korrelieren. Sie können diese Ereignisse oben im Dashboard in der Liste Anmerkungen auswählen. Mithilfe dieses Diagramms können Sie potenzielle Ursachen für Änderungen der Startlatenz im Vergleich zu anderen Pods ermitteln.
- Mithilfe der Liste Pod First Ready Latency (Latenz bis zum ersten Bereitstatus des Pods) können Sie einzelne Pods mit den längsten oder kürzesten Startvorgängen identifizieren. 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. Wenn Sie das Feld timestamp sehen möchten, führen Sie die folgende Abfrage im Log-Explorer aus:
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
Wenn Sie alle Ereignisse zur Pod-Erstellung für Ihre Arbeitslast auflisten möchten, verwenden Sie den folgenden Filter in der vorherigen Abfrage:
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 anhand Ihrer Anforderungen eine optimale Konfiguration ermitteln.
Latenz der Pod-Planung ermitteln
Die Latenz bei der Pod-Planung ist die Zeitspanne zwischen dem Erstellen eines Pods und dem Zeitpunkt, zu dem der Pod auf einem Knoten geplant wurde. Die Pod-Planungslatenz 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.
Den Zeitstempel eines einzelnen Pod-Planungsereignisses finden Sie im Feld jsonPayload.eventTime eines entsprechenden Pod-Planungsereignisses. Wenn Sie das Feld jsonPayload.eventTime sehen möchten, führen Sie die folgende Abfrage im Log-Explorer aus:
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
Wenn Sie alle Pod-Planungsereignisse für Ihre Arbeitslast auflisten möchten, 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}"
Latenz beim Abrufen von Images ansehen
Die Latenz beim Abrufen von Container-Images trägt zur Startlatenz von Pods bei, wenn das Image noch nicht auf dem Knoten verfügbar ist oder aktualisiert werden muss. Wenn Sie die Latenz beim Abrufen von Images optimieren, verringern Sie die Startlatenz Ihrer Arbeitslast bei Scale-out-Ereignissen des Clusters.
In der Tabelle Kubelet Image Pull Events (Kubelet-Ereignisse zum Abrufen von Images) sehen Sie, wann die Container-Images der Arbeitslast abgerufen wurden und wie lange der Vorgang gedauert hat.
Die Latenz des Image-Pulls 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."
Latenzverteilung von HPA-Skalierungsempfehlungen ansehen
Die Latenz von HPA-Skalierungsempfehlungen 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, verringern Sie die Startlatenz Ihrer Arbeitslast bei Scale-out-Ereignissen.
Die HPA-Skalierung kann in den folgenden beiden Diagrammen eingesehen werden:
Diagramm Verteilung der HPA-Skalierungsempfehlungslatenz: In diesem Diagramm werden die Perzentile der HPA-Skalierungsempfehlungslatenz (50. Perzentil, 95. Perzentil und 99. Perzentil) dargestellt, die auf Grundlage der Beobachtungen von HPA-Skalierungsempfehlungen in den letzten 3‑Stunden-Zeiträumen berechnet werden. Sie können dieses Diagramm für folgende Zwecke verwenden:
- Ausgangslatenz der HPA-Skalierungsempfehlung ermitteln.
- Sie können Veränderungen der HPA-Skalierungsempfehlungslatenz im Laufe der Zeit erkennen.
- Sie können Änderungen der HPA-Skalierungsempfehlungslatenz mit aktuellen Ereignissen in Beziehung setzen. Sie können die Ereignisse oben im Dashboard in der Liste Anmerkungen 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 Die Stichproben werden verwendet, um die Perzentile in der Verteilung der Latenz für HPA-Skalierungsempfehlungen für ein bestimmtes Zeitintervall zu berechnen.
- Korrelieren Sie HPA-Skalierungsempfehlungen mit Startereignissen neuer Pods und mit Ereignissen des horizontalen Pod-Autoscalers. Sie können die Ereignisse oben im Dashboard in der Liste Anmerkungen 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 verringern, müssen Sie die Anzahl dieser Probleme beheben und reduzieren.
Die folgenden beiden Diagramme sind verfügbar, um solche Probleme zu verfolgen:
- Das Diagramm Nicht planbare/ausstehende/fehlgeschlagene Pods zeigt die Anzahl der nicht planbaren, ausstehenden und fehlgeschlagenen Pods im Zeitverlauf.
- Das Diagramm Container mit Backoff/im Wartezustand/mit fehlgeschlagener Bereitschaftsprüfung zeigt die Anzahl der Container in diesen Status im Zeitverlauf.
Dashboard zur Startlatenz für Knoten ansehen
So rufen Sie Messwerte zur Startlatenz für Knoten in derGoogle 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ähle im Menü auf der linken Seite Startup Latency (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 eingesehen werden:
Diagramm Verteilung der Knotenstartlatenz: In diesem Diagramm werden die Perzentile der Knotenstartlatenz (50., 95. und 99. Perzentil) dargestellt, die auf Grundlage der Beobachtungen von Knotenstartereignissen in festen 3‑Stunden-Zeitintervallen berechnet werden, z. B. 00:00–03:00 Uhr und 03:00–06:00 Uhr. Sie können dieses Diagramm für die folgenden Zwecke verwenden:
- Latenz beim Starten des Basis-Knotens
- Sie können Veränderungen der Knotenstartlatenz im Laufe der Zeit erkennen.
- Setzen Sie Änderungen bei der Knotenstartlatenz in Beziehung zu den letzten Ereignissen, z. B. Cluster- oder Knotenpool-Updates. Sie können die Ereignisse oben im Dashboard in der Liste Anmerkungen auswählen.
Diagramm Anzahl der Knotenstarts: Dieses Diagramm zeigt die Anzahl der Knoten, die in den ausgewählten Zeitintervallen gestartet wurden. Sie können das Diagramm für die folgenden Zwecke verwenden:
- Die Stichprobengrößen für Knoten, die zum Berechnen der Verteilungsperzentile für die Knotenstartlatenz für ein bestimmtes Zeitintervall verwendet werden.
- Die Ursachen für Knotenstarts verstehen, z. B. Knotenpool-Updates oder Cluster Autoscaler-Ereignisse. Sie können die Ereignisse oben im Dashboard in der Liste Anmerkungen auswählen.
Startlatenz einzelner Knoten ansehen
Wenn Sie die Latenzen einzelner Knoten vergleichen, können Sie die Auswirkungen verschiedener Knotenkonfigurationen auf die Knotenstartlatenz testen und anhand Ihrer Anforderungen eine optimale Konfiguration ermitteln. Sie können die Startlatenz einzelner Knoten im Zeitachsendiagramm Node Startup Latency (Startlatenz von Knoten) und in der zugehörigen Liste ansehen.
Mithilfe des Zeitachsendiagramms Knotenstartlatenz können Sie einzelne Knotenstarts mit aktuellen Ereignissen wie Cluster- oder Knotenpool-Updates in Beziehung setzen. Sie können mögliche Ursachen für Änderungen der Startlatenz im Vergleich zu anderen Knoten ermitteln. Sie können die Ereignisse oben im Dashboard in der Liste Anmerkungen auswählen.
Mithilfe der Liste Node Startup Latency (Knoten-Startlatenz) können Sie einzelne Knoten mit den längsten oder kürzesten Startvorgängen identifizieren. 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 in Beziehung setzen.
Sie können herausfinden, wann ein einzelner Knoten erstellt wurde, indem Sie sich den Wert des Felds protoPayload.metadata.creationTimestamp in einem entsprechenden Ereignis zur Knotenerstellung 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
Latenz beim Starten in einem Knotenpool ansehen
Wenn Ihre Knotenpools unterschiedliche Konfigurationen haben, z. B. um verschiedene Arbeitslasten auszuführen, müssen Sie die Knotenstartlatenz möglicherweise separat nach Knotenpools überwachen. Wenn Sie die Knotenstartlatenzen Ihrer Knotenpools vergleichen, können Sie herausfinden, wie sich die Knotenkonfiguration auf die Knotenstartlatenz auswirkt, und die Latenz entsprechend optimieren.
Standardmäßig werden im Dashboard Knotenstartlatenz die aggregierte Verteilung der Startlatenz und die einzelnen Knotenstartlatenzen für alle Knotenpools in einem Cluster angezeigt. Wenn Sie die Knoten-Startlatenz 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
- Pod-Autoscaling anhand von Messwerten optimieren
- Weitere Informationen zum Reduzieren der Kaltstartlatenz in GKE
- Image-Streaming kann die Latenz beim Pull von Images reduzieren.
- Überraschende wirtschaftliche Aspekte der Optimierung des horizontalen Pod-Autoscalings
- Mit automatischem Anwendungsmonitoring können Sie Ihre Arbeitslasten im Blick behalten.