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 nachverfolgen, 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-Nutzerrollen und -Aufgaben.
Übersicht
Die Startlatenz hat erhebliche Auswirkungen darauf, wie Ihre Anwendung auf Traffic-Spitzen reagiert, wie schnell sich ihre Replikate 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 Infrastrukturaktualisierungen auf die Startlatenz nachvollziehen.
Die Optimierung der Startlatenz von Arbeitslasten bietet folgende Vorteile:
- Verringert die Antwortlatenz Ihres Dienstes für Nutzer bei Traffic-Spitzen.
- Reduziert die zusätzliche Serving-Kapazitä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.
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, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl
gcloud components updateab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Aktivieren Sie die Cloud Logging und Cloud Monitoring APIs.
Erforderliche Rollen zum Aktivieren von APIs
Zum Aktivieren von APIs benötigen Sie die Berechtigung
serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Inhaberrolle (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. 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 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 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-Betrachter (
roles/container.viewer) für Ihr Projekt -
So greifen Sie auf Messwerte zur Startlatenz zu und rufen die Dashboards auf:
Monitoring Viewer (
roles/monitoring.viewer) für Ihr Projekt -
Zugriff auf Logs mit Latenzinformationen, z. B. Kubelet-Ereignisse zum Abrufen von Images, und Anzeige dieser Logs im Log-Explorer und in Observability Analytics:
Logs Viewer (
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 Latenz beim Start
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 (Ressourcenhierarchieebenen) 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 bis zum ersten Kubernetes node ready der GCE-Instanz. 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-Steuerungsebene) verfügbar war.
|
autoscaler/latencies/per_hpa_recommendation_scale_latency_seconds
(Projekt)
Latenz der Skalierung pro HPA-Empfehlung |
|
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. Er sollte "ContainerResource", "External", "Object", "Pods" oder "Resource" sein.
|
Dashboard für die Startlatenz von Arbeitslasten ansehen
Das Dashboard Startlatenz für Arbeitslasten ist nur für Bereitstellungen verfügbar. So rufen Sie Messwerte zur Startlatenz für Bereitstellungen in der Google Cloud Console auf:
Zur Seite „Arbeitslasten“
Klicken Sie auf den Namen der Arbeitslast, die Sie prü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 gesamte Startlatenz, einschließlich des Abrufs von Images. 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 sehen Sie die Perzentile der Startlatenz von Pods (50. Perzentil, 95. Perzentil und 99. Perzentil), die anhand der Beobachtungen von Pod-Startereignissen über feste 3‑Stunden-Zeitintervalle 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:
- Baseline-Pod-Startlatenz ermitteln.
- Sie können Veränderungen der Pod-Startlatenz im Laufe der Zeit erkennen.
- Korrelieren Sie Änderungen bei der Pod-Startlatenz mit den letzten Ereignissen, z. B. Arbeitslastbereitstellungen oder Cluster Autoscaler-Ereignissen. Sie können die Ereignisse in der Liste Anmerkungen oben im Dashboard auswählen.
Diagramm Anzahl der Pod-Starts: In diesem Diagramm wird die Anzahl der Pods dargestellt, die in den ausgewählten Zeitintervallen gestartet wurden. Sie können dieses Diagramm für die folgenden Zwecke verwenden:
- Pod-Stichprobengrößen, die zur Berechnung der Perzentile der Verteilung der Pod-Startlatenz für ein bestimmtes Zeitintervall verwendet werden.
- Ursachen für Pod-Starts, z. B. Arbeitslastbereitstellungen oder Ereignisse des horizontalen Pod-Autoscalings, nachvollziehen. 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.
- Verwenden Sie das Zeitachsendiagramm Latenz der Pod-Bereitschaft, um einzelne Pod-Starts mit aktuellen Ereignissen wie Horizontal Pod Autoscaler- oder Cluster Autoscaler-Ereignissen zu 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 Latenz bis zur ersten Bereitschaft 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-Start-Ereignisse mit anderen aktuellen Ereignissen in Beziehung setzen.
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 im 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
Wenn Sie alle Pod-Erstellungsereignisse 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 bei der Pod-Planung ermitteln
Die Pod-Planungslatenz ist die Zeitspanne zwischen dem Erstellen eines Pods und dem Planen des Pods auf einem Knoten. 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.
Einen Zeitstempel für ein einzelnes Pod-Planungsereignis finden Sie im Feld jsonPayload.eventTime des entsprechenden Pod-Planungsereignisses. Führen Sie die folgende Abfrage im Log-Explorer aus, um das Feld jsonPayload.eventTime 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, um alle Pod-Planungsereignisse für Ihre Arbeitslast aufzulisten:
resource.labels.pod_name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"
Latenz beim Image-Abruf 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 Arbeitslasten bei Cluster-Scale-out-Ereignissen.
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 für das Pullen des Images ist im Feld jsonPayload.message verfügbar, das eine Meldung 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 der Skalierungsempfehlungen für das horizontale Pod-Autoscaling (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, verringern Sie die Startlatenz Ihrer Arbeitslast bei Scale-out-Ereignissen.
Die HPA-Skalierung kann in den folgenden beiden Diagrammen eingesehen werden:
Diagramm Latenzverteilung der HPA-Skalierungsempfehlung: Dieses Diagramm zeigt die Perzentile der HPA-Skalierungsempfehlungslatenz (50., 95. und 99. Perzentil), die anhand der Beobachtungen von HPA-Skalierungsempfehlungen über die letzten 3 Stunden berechnet werden. Sie können dieses Diagramm für die folgenden Zwecke verwenden:
- Ausgangsniveau der Latenz von HPA-Skalierungsempfehlungen nachvollziehen
- 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. Sie können das Diagramm für die folgenden Aufgaben verwenden:
- 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.
- Sie können 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 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-Startverzögerung 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 für Startlatenz für Knoten ansehen
Führen Sie die folgenden Schritte in derGoogle Cloud Console aus, um Messwerte zur Startlatenz 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 Startup Latency (Startlatenz) aus.
Verteilung der Startlatenz von Knoten ansehen
Die Startlatenz eines Knotens bezieht sich auf die Gesamtstartlatenz, 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 Knotenstartvorgängen 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
- Änderungen der Knotenstartlatenz im Laufe der Zeit erkennen.
- Korrelieren Sie Änderungen der Startlatenz von Knoten mit kürzlich aufgetretenen Ereignissen, z. B. Cluster- oder Knotenpool-Updates. Sie können die Ereignisse in der Liste Anmerkungen oben im Dashboard auswählen.
Diagramm Anzahl der Knotenstarts: In diesem Diagramm wird die Anzahl der Knotenstarts in den ausgewählten Zeitintervallen dargestellt. Sie können das Diagramm für die folgenden Zwecke verwenden:
- Hier sehen Sie die Stichprobengrößen für Knoten, die zur Berechnung der Verteilungsperzentile für die Knotenstartlatenz für ein bestimmtes Zeitintervall verwendet werden.
- Ursachen für Knotenstarts wie Knotenpool-Updates oder Cluster Autoscaler-Ereignisse verstehen. Sie können die Ereignisse in der Liste Anmerkungen 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 Knotenstartlatenz testen und anhand Ihrer Anforderungen eine optimale Konfiguration ermitteln. Sie können die Startlatenz einzelner Knoten im Zeitachsendiagramm Knotenstartlatenz 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 potenzielle Ursachen für Änderungen bei der Startlatenz im Vergleich zu anderen Knoten ermitteln. Sie können die Ereignisse in der Liste Anmerkungen oben im Dashboard auswählen.
Mithilfe der Liste Knotenstartlatenz 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
Startlatenz 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 Latenzzeiten für den Start von Knoten in Ihren Knotenpools vergleichen, können Sie herausfinden, wie sich die Knotenkonfiguration auf die Latenzzeiten für den Start von Knoten auswirkt, und 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 Knotenstartlatenz 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
- Weitere Informationen zum Beschleunigen des Anwendungsstarts mit dem CPU-Boost beim Start
- Weitere Informationen zum Reduzieren der Kaltstartlatenz in GKE
- Image-Streaming reduziert die Latenz beim Image-Pull.
- Überraschende wirtschaftliche Aspekte der Optimierung des horizontalen Pod-Autoscalings
- Arbeitslasten mit dem automatischen Anwendungsmonitoring überwachen