Auf dieser Seite werden die Messwerte und Dashboards beschrieben, mit denen Sie die Startlatenz von Google Kubernetes Engine-Arbeitslasten (GKE) und der zugrunde liegenden Clusterknoten überwachen können. Mithilfe der Messwerte können Sie die Startlatenz erfassen, beheben und 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 unseren Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und ‑Aufgaben. Google Cloud
Übersicht
Die Startlatenz wirkt sich erheblich darauf aus, wie Ihre Anwendung auf Traffic-Spitzen reagiert, wie schnell sich ihre Repliken von Störungen erholen und wie effizient die Betriebskosten Ihrer Cluster und Arbeitslasten sein können. Wenn Sie die Startlatenz Ihrer Arbeitslasten überwachen, können Sie Leistungseinbußen erkennen und die Auswirkungen von Arbeitslast- und Infrastrukturupdates auf die Startlatenz verfolgen.
Die Optimierung der Latenz beim Starten von Arbeitslasten bietet folgende Vorteile:
- Verringert die Antwortlatenz Ihres Dienstes für Nutzer bei Traffic-Spitzen.
- Reduziert die überschüssige Auslieferungskapazität, die erforderlich ist, um Nachfragespitzen zu absorbieren, während neue Repliken erstellt werden.
- Reduziert die Inaktivitätszeiten von Ressourcen, die bereits bereitgestellt sind und während der Batchberechnungen auf das Starten der verbleibenden Ressourcen warten.
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 zur 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 Systemprotokollen konfigurieren.
- Aktivieren Sie Kube State Metrics mit der
POD-Komponente 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 Protokollerstellung und zum Zugriff auf und zur Verarbeitung 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 -
Sie können auf Logs mit Latenzinformationen zugreifen, z. B. auf Kubelet-Ereignisse zum Abrufen von Images, und sie im Log-Explorer und in Log Analytics aufrufen:
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 zur Startlatenz
Startlatenzmesswerte 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 |
Die End-to-End-Startlatenz des Pods (von Pod Created zu 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 Gesamtstartzeit des Knotens, vom ersten Mal, dass die GCE-Instanz CreationTimestamp zu Kubernetes node ready wechselt. 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
(project)
Latenz pro HPA-Empfehlung skalieren |
|
GAUGE, DOUBLE, s
k8s_scale |
Latenz der Skalierungsempfehlung für das horizontale Pod-Autoscaling (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 Messwertquellentyp. Es sollte einer der folgenden Werte sein: "ContainerResource", "External", "Object", "Pods" oder "Resource".
|
Dashboard „Startlatenz“ für Arbeitslasten aufrufen
Das Dashboard Startlatenz für Arbeitslasten ist nur für Bereitstellungen verfügbar. So rufen Sie in der Google Cloud Console Messwerte zur Startlatenz für Bereitstellungen auf:
Zur Seite „Arbeitslasten“
Klicken Sie auf den Namen der Arbeitslast, die Sie überprüfen 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 Gesamtstartlatenz, einschließlich Image-Abrufen. Dabei wird die Zeit vom Created-Status des Pods bis zum Ready-Status gemessen. Sie können die Startlatenz von Pods anhand der folgenden beiden Diagramme beurteilen:
Diagramm Pod-Startlatenzverteilung: Dieses Diagramm zeigt die Perzentile der Startlatenz von Pods (50. Perzentil, 95. Perzentil und 99. Perzentil), die anhand 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:
- Ausgangslatenz für das Starten von Pods ermitteln
- Veränderungen der Pod-Startlatenz im Laufe der Zeit erkennen.
- Stellen Sie eine Korrelation zwischen Änderungen bei der Pod-Startlatenz und aktuellen Ereignissen wie Arbeitslast-Deployments oder Cluster Autoscaler-Ereignissen her. Sie können die Ereignisse in der Liste Hinweise oben im Dashboard auswählen.
Diagramm Anzahl der Pod-Starts: Dieses Diagramm zeigt die Anzahl der Pods, die in den ausgewählten Zeitintervallen gestartet wurden. Sie können dieses Diagramm für die folgenden Zwecke verwenden:
- Informationen zu den Pod-Stichprobengrößen, die zur Berechnung der Perzentile der Verteilung der Pod-Startlatenz für ein bestimmtes Zeitintervall verwendet werden.
- Informationen zu den Ursachen von Pod-Starts, z. B. Arbeitslast-Deployments oder Horizontal Pod Autoscaler-Ereignisse. Sie können die Ereignisse in der Liste Hinweise oben im Dashboard auswählen.
Startlatenz einzelner Pods ansehen
Die Startlatenz einzelner Pods finden Sie im Zeitachsendiagramm Pod First Ready Latency (Zeit bis zur Betriebsbereitschaft des Pods) und in der zugehörigen Liste.
- Im Zeitleistendiagramm Pod First Ready Latency (Pod-Erstbereitschaftslatenz) können Sie einzelne Pod-Starts mit aktuellen Ereignissen wie Horizontal Pod Autoscaler- oder Cluster Autoscaler-Ereignissen in Beziehung setzen. Sie können diese Ereignisse oben im Dashboard in der Liste Hinweise auswählen. Anhand dieses Diagramms können Sie mögliche Ursachen für Änderungen der Startlatenz im Vergleich zu anderen Pods ermitteln.
- In der Liste Pod First Ready Latency (Pod-Latenz bis zur ersten Bereitschaft) können Sie einzelne Pods mit dem längsten oder kürzesten Startvorgang identifizieren. Sie können die Liste nach der Spalte Latenz sortieren. Wenn Sie Pods mit der höchsten Startlatenz ermitteln, können Sie die Latenzprobleme 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 Pod-Erstellungsereignisse für Ihre Arbeitslast auflisten möchten, verwenden Sie in der vorherigen Abfrage den folgenden Filter:
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 Planen des Pods auf einem Knoten. Die Latenz bei der Pod-Planung trägt zur End-to-End-Startzeit eines Pods bei. Sie wird berechnet, indem die Zeitstempel eines Pod-Planungsereignisses und einer Pod-Erstellungsanfrage abgezogen werden.
Sie finden den Zeitstempel eines einzelnen Pod-Planungsereignisses 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 in der vorherigen Abfrage den folgenden Filter:
resource.labels.pod_name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"
Latenz beim Bildabruf ansehen
Die Latenz beim Abrufen von Container-Images trägt in Szenarien, in denen das Image noch nicht auf dem Knoten verfügbar ist oder aktualisiert werden muss, zur Startlatenz des Pods bei. Wenn Sie die Latenz beim Abrufen von Images optimieren, reduzieren Sie die Startlatenz der Arbeitslast bei Cluster-Skalierungsereignissen.
In der Tabelle 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 beim Bildabruf ist im Feld jsonPayload.message verfügbar. Es enthält eine Meldung wie die folgende:
"Successfully pulled image "gcr.io/example-project/image-name" in 17.093s (33.051s including waiting). Image size: 206980012 bytes."
Latenzverteilung der HPA-Skalierungsempfehlungen ansehen
Die Latenz der Skalierungsempfehlungen des horizontalen Pod-Autoscalings (HPA) für das HPA-Ziel ist die Zeitspanne zwischen dem Erstellen der Messwerte und dem Anwenden der entsprechenden Skalierungsempfehlung auf den API-Server. Wenn Sie die Latenz der HPA-Skalierungsempfehlung optimieren, verringern Sie die Startlatenz der Arbeitslast bei Skalierungsereignissen.
Die HPA-Skalierung kann in den folgenden beiden Diagrammen angezeigt werden:
Diagramm Latenzverteilung der HPA-Skalierungsempfehlung: Dieses Diagramm zeigt die Perzentile der HPA-Skalierungsempfehlungslatenz (50. Perzentil, 95. Perzentil und 99. Perzentil), die anhand der Beobachtungen von HPA-Skalierungsempfehlungen in den letzten 3-Stunden-Zeitintervallen berechnet werden. Sie können dieses Diagramm für folgende Zwecke verwenden:
- Informationen zur Latenz der HPA-Skalierungsempfehlung
- Veränderungen der HPA-Skalierungsempfehlungslatenz im Laufe der Zeit erkennen
- Korrelieren Sie Änderungen der HPA-Skalierungsempfehlungslatenz mit aktuellen Ereignissen. Sie können die Ereignisse in der Liste Hinweise oben im Dashboard auswählen.
Diagramm Anzahl der HPA-Skalierungsempfehlungen: Dieses Diagramm zeigt die Anzahl der HPA-Skalierungsempfehlungen, die im ausgewählten Zeitraum beobachtet wurden. Verwenden Sie das Diagramm für die folgenden Aufgaben:
- Informationen zu den Stichprobengrößen für HPA-Skalierungsempfehlungen Anhand der Stichproben werden die Perzentile in der Latenzverteilung für HPA-Skalierungsempfehlungen für ein bestimmtes Zeitintervall berechnet.
- Korrelieren Sie HPA-Skalierungsempfehlungen mit neuen Pod-Startereignissen und mit Ereignissen des horizontalen Pod-Autoscalings. Sie können die Ereignisse in der Liste Hinweise oben im Dashboard auswählen.
Planungsprobleme für Pods ansehen
Probleme mit der Pod-Planung können sich auf die End-to-End-Startlatenz Ihrer Arbeitslast auswirken. Um die End-to-End-Startverzögerung Ihrer Arbeitslast zu verringern, beheben Sie diese Probleme und reduzieren Sie ihre Anzahl.
Es gibt zwei Diagramme, mit denen Sie solche Probleme im Blick behalten können:
- Im Diagramm Nicht planbare/Ausstehende/Fehlgeschlagene Pods sehen Sie die Anzahl der nicht planbaren, ausstehenden und fehlgeschlagenen Pods im Zeitverlauf.
- Im Diagramm Container mit Backoff/im Wartezustand/mit fehlgeschlagener Bereitschaftsprüfung sehen Sie die Anzahl der Container in diesen Status im Zeitverlauf.
Dashboard zur Startlatenz für Knoten aufrufen
Führen Sie die folgenden Schritte in der Google Cloud Console aus, um Startlatenzmesswerte für Knoten aufzurufen:
Rufen Sie die Seite Kubernetes-Cluster auf.
Klicken Sie auf den Namen des Clusters, den Sie prüfen 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 Startzeit eines Knotens bezieht sich auf die Gesamtstartzeit, die die Zeit vom CreationTimestamp des Knotens bis zum Kubernetes node ready-Status misst. Die Latenz beim Knotenstart wird in den folgenden beiden Diagrammen angezeigt:
Diagramm Verteilung der Knotenstartlatenz: Dieses Diagramm zeigt die Perzentile der Knotenstartlatenz (50. Perzentil, 95. Perzentil und 99. Perzentil), die anhand 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:
- Ausgangslatenz beim Starten des Knotens ermitteln
- Veränderungen der Knotenstartlatenz im Laufe der Zeit erkennen
- Korrelieren Sie Änderungen bei der Startlatenz von Knoten mit aktuellen Ereignissen wie Cluster- oder Knotenpool-Aktualisierungen. Sie können die Ereignisse in der Liste Hinweise oben im Dashboard 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 folgende Zwecke verwenden:
- Informationen zu den Knotenstichprobengrößen, die zur Berechnung der Verteilungsperzentile der Knotenstartlatenz für ein bestimmtes Zeitintervall verwendet werden
- Ursachen für Knotenstarts ermitteln, z. B. Knotenpool-Aktualisierungen oder Cluster Autoscaler-Ereignisse Sie können die Ereignisse in der Liste Hinweise oben im Dashboard auswählen.
Startlatenz einzelner Knoten ansehen
Wenn Sie die Latenzen einzelner Knoten vergleichen, können Sie die Auswirkungen verschiedener Knotenkonfigurationen auf die Startlatenz des Knotens testen und anhand Ihrer Anforderungen eine optimale Konfiguration ermitteln. Die Startlatenz einzelner Knoten finden Sie im Zeitachsendiagramm Knotenstartlatenz und in der zugehörigen Liste.
Im Zeitleistendiagramm Knotenstartlatenz können Sie einzelne Knotenstarts mit aktuellen Ereignissen wie Cluster- oder Knotenpool-Aktualisierungen 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 in der Liste Hinweise oben im Dashboard auswählen.
In der Liste Knotenstartlatenz können Sie einzelne Knoten mit dem längsten oder kürzesten Start identifizieren. Sie können die Liste nach der Spalte Latenz sortieren. Wenn Sie die Knoten mit der höchsten Startlatenz ermitteln, können Sie die Latenzminderung 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. Wenn Sie das Feld protoPayload.metadata.creationTimestamp 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.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 unterschiedliche Arbeitslasten auszuführen, müssen Sie die Latenz beim Starten von Knoten möglicherweise für jeden Knotenpool separat überwachen. Wenn Sie die Latenz beim Starten von Knoten in Ihren Knotenpools vergleichen, erhalten Sie Informationen dazu, wie sich die Knotenkonfiguration auf die Latenz beim Starten von Knoten auswirkt, und können die Latenz entsprechend optimieren.
Standardmäßig zeigt das Dashboard Knotenstartlatenz die zusammengefasste Verteilung der Startlatenz und die einzelnen Knotenstartlatenzen aller Knotenpools in einem Cluster an. Wenn Sie die Latenz beim Starten von Knoten für einen bestimmten Knotenpool sehen möchten, wählen Sie den Namen des Knotenpools mit dem Filter $node_pool_name_var oben im Dashboard aus.
Nächste Schritte
- Weitere Informationen zum Optimieren des Pod-Autoscalings anhand von Messwerten
- Weitere Informationen zum Verringern der Latenz beim Kaltstart in GKE
- Informationen zum Verringern der Latenz beim Abrufen von Images
- Überraschende Wirtschaftlichkeit der Optimierung des horizontalen Pod-Autoscalings
- Überwachen Sie Ihre Arbeitslasten mit dem automatischen Anwendungsmonitoring.