Messwerte der Steuerungsebene verwenden

Sie können einen GKE-Cluster (Google Kubernetes Engine) so konfigurieren, dass bestimmte vom Kubernetes API-Server, Scheduler und Controller Manager an Cloud Monitoring ausgegebene Messwerte mit Google Cloud Managed Service for Prometheus gesendet werden. In diesem Dokument wird beschrieben, wie diese Messwerte formatiert werden, wenn sie in Cloud Monitoring geschrieben und abgefragt werden. Dieses Dokument enthält auch Tabellen, in denen die Messwerte in jedem Satz aufgeführt sind und wie Sie die Messwerte verwenden können.

Bevor Sie Messwerte der Steuerungsebene verwenden können, müssen Sie ihre Sammlung aktivieren.

Messwertformat

Alle in Cloud Monitoring geschriebenen Messwerte der Kubernetes-Steuerungsebene verwenden den Ressourcentyp prometheus_target. Jeder Messwertname hat das Präfix prometheus.googleapis.com/ und ein Suffix, das den Prometheus-Messwerttyp angibt, z. B. /gauge, /histogram oder /counter. Andernfalls ist jeder Messwertname mit dem Messwert von Open-Source-Kubernetes identisch.

Aus Cloud Monitoring exportieren

Messwerte der Steuerungsebene können mithilfe der Cloud Monitoring API aus Cloud Monitoring exportiert werden. Da alle Messwerte der Steuerungsebene mithilfe von Google Cloud Managed Service for Prometheus aufgenommen werden, können Messwerte der Steuerungsebene mit der Prometheus-Abfragesprache (PromQL) abgefragt werden. Eine Abfrage ist auch mit Monitoring Query Language (MQL) möglich.

Messwerte abfragen

Wenn Sie Messwerte der Steuerungsebene abfragen, hängt der Name davon ab, ob Sie PromQL- oder Cloud Monitoring-basierte Features wie MQL oder die menügesteuerte Oberfläche des Metrics Explorer verwenden.

Die folgenden Tabellen der Messwerte der Steuerungsebene zeigen zwei Versionen jedes Messwertnamens:

  • PromQL-Messwertname: Bei der Verwendung von PromQL auf Cloud Monitoring-Seiten der Google Cloud Console oder in PromQL-Feldern des Cloud Monitoring API verwenden Sie den PromQL-Messwertnamen.
  • Name des Cloud Monitoring-Messwerts: Verwenden Sie in den folgenden Tabellen den Cloud Monitoring-Messwertnamen, wenn Sie andere Cloud Monitoring-Features verwenden. Dieser Name muss das Präfix prometheus.googleapis.com/ haben, das in den Einträgen der Tabelle weggelassen wurde.

API-Servermesswerte

Dieser Abschnitt enthält eine Liste der API-Servermesswerte und zusätzliche Informationen zur Interpretation und Verwendung der Messwerte.

Liste der API-Servermesswerte

Wenn API-Servermesswerte aktiviert sind, werden alle in der folgenden Tabelle angezeigten Messwerte zu Cloud Monitoring im selben Projekt exportiert, in dem sich auch der GKE-Cluster befindet.

Die Cloud Monitoring-Messwertnamen in dieser Tabelle müssen das Präfix prometheus.googleapis.com/ haben. Dieses Präfix wurde in den Einträgen der Tabelle weggelassen.

PromQL-Messwertname Einführungsphase
Cloud Monitoring-Messwertname
Art, Typ, Einheit
Überwachte Ressourcen
Erforderliche GKE-Version		 Beschreibung
Labels
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Maximale Anzahl der aktuell verwendeten Inflight-Anfragelimits dieses API-Servers pro Anfrageart in der letzten Sekunde.

request_kind
apiserver_flowcontrol_current_executing_seats BETA
apiserver_flowcontrol_current_executing_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ 		Die Nebenläufigkeit (Anzahl der Lizenzen), die von der aktuell ausgeführten Anfrage (anfängliche Phase für eine Watch-Funktion, jede Phase) belegt wird.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BETA
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ für frühere Nebenversionen) 		Anzahl der derzeit in Warteschlangen des API-Prioritäts- und Fairness-Subsystems ausstehenden Anfragen.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats BETA
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.26.11+, 1.27.8+ für frühere Nebenversionen) 		Nominale Anzahl der Ausführungslizenzen, die für jede Prioritätsstufe konfiguriert sind.

priority_level
apiserver_flowcontrol_rejected_requests_total BETA
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ für frühere Nebenversionen) 		Anzahl der vom API-Prioritäts- und Fairness-Subsystem abgelehnten Anfragen.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BETA
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ für frühere Nebenversionen) 		Dauer der Wartezeit einer Anfrage in ihrer Warteschlange.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Antwortlatenzverteilung in Sekunden für jedes Verb, jeden Probelaufwert, jede Gruppe, Version, Ressource, Unterressource, jeden Bereich und jede Komponente.

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Zähler der API-Serveranfragen, die für jedes Verb, jeden Probelaufwert, jede Gruppe, Version, Ressource, jeden Bereich, jede Komponente und jeden HTTP-Antwortcode aufgeschlüsselt sind.

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Antwortgrößenverteilung in Byte für jede Gruppe, Version, jedes Verb, jede Ressource, Unterressource, jeden Bereich und jede Komponente.

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Anzahl der gespeicherten Objekte zum Zeitpunkt der letzten Prüfung, aufgeteilt nach Art.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Admission-Controller-Latenzhistogramm in Sekunden, angegeben nach Name und aufgeschlüsselt nach jedem Vorgang und jeder API-Ressource sowie jedem Typ (validieren oder zulassen).

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Zulassungsunterschritt-Latenzhistogramm in Sekunden, aufgeschlüsselt für jeden Vorgang und jede API-Ressource sowie jeden Schritttyp (validieren oder zulassen).

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Zulassungs-Webhook-Latenzhistogramm in Sekunden, angegeben nach Name und aufgeschlüsselt nach jedem Vorgang und jeder API-Ressource sowie jedem Typ (validieren oder zulassen).

name
operation
rejected
type

Die folgenden Abschnitte enthalten zusätzliche Informationen zu den API-Servermesswerten.

apiserver_request_duration_seconds

Verwenden Sie diesen Messwert, um die Latenz im API-Server zu überwachen. Die von diesem Messwert erfasste Anfragedauer umfasst alle Phasen der Anfrageverarbeitung ab dem Zeitpunkt, zu dem die Anfrage empfangen wurde, bis zum Abschluss der Antwort des Servers an den Client. Insbesondere beinhaltet dies Zeit für Folgendes:

  • Die Authentifizierung und Autorisierung der Anfrage.
  • Das Aufrufen der Drittanbieter- und System-Webhooks, die der Anfrage zugeordnet sind.
  • Das Abrufen des angeforderten Objekts aus einem In-Memory-Cache (für Anfragen mit dem URL-Parameter resourceVersion) oder aus etcd (für alle anderen Anfragen).
  • Sie können die Labels group, version, resource und subresource verwenden, um eine langsame Anfrage für eine weitere Untersuchung eindeutig zu identifizieren.
  • Das Schreiben der Antwort an den Client und das Empfangen der Antwort des Clients.

Weitere Informationen zur Verwendung dieses Messwerts finden Sie unter Latenz.

Dieser Messwert hat eine sehr hohe Kardinalität. Wenn Sie diesen Messwert verwenden, müssen Sie Filter oder Gruppierungen verwenden, um bestimmte Latenzquellen zu finden.

apiserver_admission_controller_admission_duration_seconds

Dieser Messwert misst die Latenz in integrierten Zulassungs-Webhooks, nicht in Drittanbieter-Webhooks. Zum Diagnostizieren von Latenzproblemen mit Drittanbieter-Webhooks verwenden Sie den Messwert apiserver_admission_webhook_admission_duration_seconds.

apiserver_admission_webhook_admission_duration_seconds und
apiserver_admission_step_admission_duration_seconds

Diese Messwerte messen die Latenz in externen Zulassungs-Webhooks. Der Messwert apiserver_admission_webhook_admission_duration_seconds ist im Allgemeinen der nützlichere Messwert. Weitere Informationen zur Verwendung dieses Messwerts finden Sie unter Latenz.

apiserver_request_total

Verwenden Sie diesen Messwert, um den Anfrage-Traffic auf Ihrem API-Server zu beobachten. Sie können damit auch die Erfolgs- und Fehlerraten Ihrer Anfragen ermitteln. Weitere Informationen zur Verwendung dieses Messwerts finden Sie unter Traffic und Fehlerrate.

Dieser Messwert hat eine sehr hohe Kardinalität. Wenn Sie diesen Messwert verwenden, müssen Sie Filter oder Gruppierungen verwenden, um Fehlerquellen zu identifizieren.

apiserver_storage_objects

Verwenden Sie diesen Messwert, um die Sättigung Ihres Systems zu erkennen und mögliche Schwachstellen an Ressourcen zu identifizieren. Weitere Informationen finden Sie unter Auslastung.

apiserver_current_inflight_requests

Dieser Messwert zeichnet die maximale Anzahl von Anfragen auf, die im letzten Zeitfenster von einer Sekunde aktiv verarbeitet wurden. Weitere Informationen finden Sie unter Auslastung.

Der Messwert enthält keine Anfragen mit langer Ausführungszeit wie „watch“.

API-Server überwachen

Die API-Servermesswerte können Ihnen einen Einblick in die Hauptsignale für den Systemzustand geben:

  • Latenz: Wie lange dauert es, eine Anfrage zu bearbeiten?
  • Traffic: Wie viel Nachfrage hat das System?
  • Fehlerrate: Wie oft schlagen Anfragen fehl?
  • Auslastung: Wie voll ist das System?

In diesem Abschnitt wird beschrieben, wie Sie mit den API-Servermesswerten den Zustand Ihres API-Servers überwachen.

Latenz

Wenn der API-Server überlastet ist, erhöht sich die Latenz der Anfrage. Verwenden Sie den Messwert apiserver_request_duration_seconds, um die Latenz der Anfragen an den API-Server zu messen. Um die Latenz genauer zu identifizieren, können Sie Messwerte nach dem Label verb oder resource gruppieren.

Die empfohlene Obergrenze für einen Aufruf mit einer Ressource wie GET, POST oder PATCH ist 1 Sekunde. Die empfohlene Obergrenze für Namespace- und clusterbezogene LIST-Aufrufe ist 30 Sekunden. Die Erwartungen an die Grenze werden durch SLOs definiert, die von der Open-Source-Kubernetes-Community definiert werden. Weitere Informationen finden Sie unter Details zu SLIs/SLOs für API-Aufruflatenz.

Wenn der Wert des Messwerts apiserver_request_duration_seconds über die erwartete Dauer hinaus ansteigt, prüfen Sie die folgenden möglichen Ursachen:

  • Die Kubernetes-Steuerungsebene ist möglicherweise überlastet. Prüfen Sie die Messwerte apiserver_request_total und apiserver_storage_objects, um das zu prüfen.
    • Mit dem Label code können Sie feststellen, ob Anfragen erfolgreich verarbeitet werden. Informationen zu den möglichen Werten finden Sie unter HTTP-Statuscodes.
    • Verwenden Sie die Labels group, version, resource und subresource, um eine Anfrage eindeutig zu identifizieren.

  • Ein Zulassungs-Webhook eines Drittanbieters ist langsam oder reagiert nicht. Wenn der Wert des Messwerts apiserver_admission_webhook_admission_duration_seconds zunimmt, sind einige Ihrer benutzerdefinierten Drittanbieter- oder benutzerdefinierten Zulassungs-Webhooks langsam oder reagieren nicht. Die Latenz im Zulassungs-Webhook kann zu Verzögerungen bei der Jobplanung führen.

    • Verwenden Sie die folgende PromQL-Abfrage, um die Webhook-Latenz des 99. Perzentils pro Instanz der Kubernetes-Steuerungsebene abzufragen:

      sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))

      Wir empfehlen auch, das 50., 90., 95. und 99.9. Perzentil zu betrachten. Sie können diese Abfrage anpassen. Ändern Sie dazu den Wert 0.99.

    • Externe Webhooks haben ein Zeitlimit von etwa 10 Sekunden. Sie können im Messwert apiserver_admission_webhook_admission_duration_seconds Benachrichtigungsrichtlinien festlegen, damit Sie informiert werden, wenn das Webhook-Zeitlimit fast erreicht ist.

    • Sie können auch den Messwert apiserver_admission_webhook_admission_duration_seconds für das Label name gruppieren, um mögliche Probleme mit bestimmten Webhooks zu diagnostizieren.

  • Sie listen viele Objekte auf. Es wird erwartet, dass die Latenz von LIST-Aufrufen zunimmt, wenn die Anzahl der Objekte eines bestimmten Typs (die Antwortgröße) zunimmt.

  • Clientseitige Probleme:

    • Der Client verfügt möglicherweise nicht über genügend Ressourcen, um Antworten zeitnah zu empfangen. Sehen Sie sich zur Prüfung die CPU-Nutzungsmesswerte für den Client-Pod an.
    • Der Client hat eine langsame Netzwerkverbindung. Dies kann vorkommen, wenn der Client auf einem Gerät wie einem Smartphone ausgeführt wird, aber unwahrscheinlich ist, dass Clients in einem Compute Engine-Netzwerk ausgeführt werden.
    • Der Client wurde unerwartet beendet, aber bei der TCP-Verbindung besteht ein Zeitlimit von zehn Sekunden. Bevor die Verbindung unterbrochen wird, werden die Ressourcen des Servers blockiert, was die Latenz erhöhen kann.

Traffic und Fehlerrate

Verwenden Sie den Messwert apiserver_request_total, um den Traffic und die Anzahl der erfolgreichen und fehlgeschlagenen Anfragen auf dem API-Server zu messen. Verwenden Sie beispielsweise die folgende PromQL-Abfrage, um den API-Server-Traffic pro Instanz der Kubernetes-Steuerungsebene zu messen:

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

  • Um die fehlgeschlagenen Anfragen abzufragen, filtern Sie das Label code mithilfe der folgenden PromQL-Abfrage nach 4xx- und 5xx-Werten:

    sum(rate(apiserver_request_total{code=~"[45].."}[5m]))

  • Filtern Sie zum Abfragen der erfolgreichen Anfragen das Label code mithilfe der folgenden PromQL-Abfrage nach 2xx-Werten:

    sum(rate(apiserver_request_total{code=~"2.."}[5m]))

  • Wenn Sie die abgelehnten Anfragen vom API-Server pro Instanz der Kubernetes-Steuerungsebene abfragen möchten, filtern Sie das Label code mit der folgenden PromQL-Abfrage nach dem Wert 429 (http.StatusTooManyRequests):

    sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))

Sättigung

Die Sättigung in Ihrem System können Sie mit den Messwerten apiserver_current_inflight_requests und apiserver_storage_objects messen.

Wenn der Wert des Messwerts apiserver_storage_objects zunimmt, tritt möglicherweise ein Problem mit einem benutzerdefinierten Controller auf, der Objekte erstellt, aber nicht löscht. Sie können den Messwert nach dem Label resource filtern oder gruppieren, um die Ressource mit dem Anstieg zu identifizieren.

Bewerten Sie den Messwert apiserver_current_inflight_requests gemäß den API-Prioritäts- und Fairness-Einstellungen. Diese Einstellungen wirken sich auf die Priorisierung von Anfragen aus, sodass Sie keine Schlussfolgerungen aus den Messwerten allein ziehen können. Weitere Informationen finden Sie unter API-Priorität und -Fairness.

Planermesswerte

Dieser Abschnitt enthält eine Liste der Planermesswerte und zusätzliche Informationen zur Interpretation und Verwendung der Messwerte.

Liste der Planermesswerte

Wenn Planermesswerte aktiviert sind, werden alle in der folgenden Tabelle angezeigten Messwerte zu Cloud Monitoring im selben Projekt exportiert, in dem sich auch der GKE-Cluster befindet.

Die Cloud Monitoring-Messwertnamen in dieser Tabelle müssen das Präfix prometheus.googleapis.com/ haben. Dieses Präfix wurde in den Einträgen der Tabelle weggelassen.

PromQL-Messwertname Einführungsphase
Cloud Monitoring-Messwertname
Art, Typ, Einheit
Überwachte Ressourcen
Erforderliche GKE-Version		 Beschreibung
Labels
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Anzahl der ausstehenden Pods, nach Warteschlangentyp. "Aktiv" steht für die Anzahl der Pods in activeQ. "Backoff" steht für die Anzahl der Pods in BackoffQ. "Nicht planbar" steht für die Anzahl der Pods in nicht planbaren Pods.

queue
scheduler_pod_scheduling_duration_seconds VERWORFEN
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.25.1 bis 1.29 (1.22.17-gke.3100+ , 1.23.11+ und 1.24.5+ für frühere Nebenversionen) 		[In Version 1.29 verworfen; in Version 1.30 entfernt und durch scheduler_pod_scheduling_sli_duration_seconds ersetzt.] E2e-Latenz für einen geplanten Pod, der mehrere Planungsversuche enthalten kann.

attempts
scheduler_pod_scheduling_sli_duration_seconds BETA
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.30+ 		E2e-Latenz für einen geplanten Pod ab dem Zeitpunkt, an dem der Pod in die Planungswarteschlange eintritt, und kann mehrere Planungsversuche umfassen.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Gesamte Versuche der vorzeitigen Beendigung im Cluster bis jetzt
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Anzahl der ausgewählten "Opfer" der vorzeitigen Beendigung
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6+ 		Latenz des Planungsversuchs in Sekunden (Planungsalgorithmus + Bindung).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Anzahl der Versuche, Pods zu planen, nach Zeitplan. "Nicht planbar" bedeutet, dass ein Pod nicht geplant werden konnte, "Fehler" weist hingegen auf ein internes Planerproblem hin.

profile
result

Die folgenden Abschnitte enthalten zusätzliche Informationen zu den API-Servermesswerten.

scheduler_pending_pods

Mit dem Messwert scheduler_pending_pods können Sie die Auslastung Ihres Planers überwachen. Wenn Sie Werte in diesem Messwert erhöhen, kann das auf Probleme bei der Ressourcenbereitstellung hindeuten. Der Planer hat drei Warteschlangen. Dieser Messwert meldet die Anzahl der ausstehenden Anfragen nach Warteschlange. Die folgenden Warteschlangen werden unterstützt:

  • Warteschlange active
    • Die Reihe an Pods, die der Planer einzuplanen versucht; der Pod mit der höchsten Priorität steht an der Spitze der Warteschlange.
  • Warteschlange backoff
    • Die Reihe an Pods, die beim letzten Versuch des Planers nicht planbar waren, die aber beim nächsten Mal planbar sein könnten.
    • Pods in dieser Warteschlange müssen einen Backoff-Zeitraum abwarten (maximal zehn Sekunden). Danach werden sie für einen weiteren Planungsversuch wieder in die Warteschlange active verschoben. Weitere Informationen zur Verwaltung der Warteschlange backoff finden Sie in der Implementierungsanfrage Kubernetes-Problem 75417.

  • unschedulable festgelegt

    • Die Pods, die vom Planer geplant werden sollen, aber nicht planbar sind. Die Platzierung in dieser Warteschlange kann auf Bereitschafts- oder Kompatibilitätsprobleme bei Ihren Knoten oder auf die Konfiguration Ihrer Knotenauswahl hinweisen.

      Wenn Ressourceneinschränkungen die Planung von Pods verhindern, unterliegen die Pods nicht einer Backoff-Verarbeitung. Wenn ein Cluster voll ist, können keine neuen Pods geplant und in die Warteschlange unscheduled gestellt werden.

    • Das Vorhandensein ungeplanter Pods kann darauf hinweisen, dass Sie nicht genügend Ressourcen haben oder ein Problem mit der Knotenkonfiguration vorliegt. Pods werden nach Ereignissen, die den Clusterstatus ändern, in die Warteschlange backoff oder active verschoben. Pods in dieser Warteschlange geben an, dass sich im Cluster nichts geändert hat, wodurch die Pods planbarer werden würden.

    • Affinitäten definieren Regeln dafür, wie Pods Knoten zugewiesen werden. Die Verwendung von Affinität oder Anti-Affinitätsregeln kann ein Grund für eine Erhöhung von ungeplanten Pods sein.

    • Einige Ereignisse, z. B. PVC/Service ADD/UPDATE, die Beendigung eines Pods oder die Registrierung neuer Knoten, verschieben einige oder alle nicht geplanten Pods in die Warteschlange backoff oder active. Weitere Informationen finden Sie unter Kubernetes-Problem 81214.

Weitere Informationen finden Sie unter Planer-Latenz und Ressourcenprobleme.

scheduler_scheduling_attempt_duration_seconds

Dieser Messwert misst die Dauer eines einzelnen Planungsversuchs innerhalb des Planers und wird nach dem Ergebnis aufgeschlüsselt: geplant, nicht planbar oder Fehler. Die Dauer beginnt, wenn der Planer einen Pod abruft, und endet, wenn der Planer einen Knoten findet und den Pod auf dem Knoten platziert, feststellt, dass der Pod nicht planbar ist, oder ein Fehler auftritt. Die Planungsdauer umfasst die Zeit im Planungsprozess sowie die Bindungszeit. Bindung ist der Prozess, bei dem der Planer seine Knotenzuweisung an den API-Server kommuniziert. Weitere Informationen finden Sie unter Planer-Latenz.

Dieser Messwert erfasst nicht die Zeit, die der Pod in der Zugriffskontrolle oder Validierung verbringt.

Weitere Informationen zur Planung finden Sie unter Pod planen.

scheduler_schedule_attempts_total

Dieser Messwert misst die Anzahl der Planungsversuche; jeder Versuch, einen Pod zu planen, erhöht den Wert. Sie können diesen Messwert verwenden, um zu bestimmen, ob der Planer verfügbar ist: Wenn der Wert zunimmt, ist der Planer einsatzbereit. Sie können das Label result verwenden, um den Erfolg zu bestimmen. Pods sind entweder scheduled oder unschedulable.

Dieser Messwert korreliert stark mit dem Messwert scheduler_pending_pods: Wenn es viele ausstehende Pods gibt, können Sie davon ausgehen, dass viele Versuche zum Planen der Pods angezeigt werden. Weitere Informationen finden Sie unter Ressourcenprobleme.

Dieser Messwert erhöht sich nicht, wenn der Planer keine Pods hat, die geplant werden können. Dies kann der Fall sein, wenn Sie einen benutzerdefinierten sekundären Planer haben.

scheduler_preemption_attempts_total und scheduler_preemptions_victims

Sie können mithilfe von Messwerten zur vorzeitigen Beendigung feststellen, ob Sie Ressourcen hinzufügen müssen.

Möglicherweise haben Sie Pods mit höherer Priorität, die nicht geplant werden können, da kein Platz für sie ist. In diesem Fall gibt der Planer Ressourcen frei. Dazu beendet er einen oder mehrere ausgeführte Pods auf einem Knoten vorzeitig. Der Messwert scheduler_preemption_attempts_total erfasst, wie oft der Planer versucht hat, Pods vorzeitig zu beenden.

Der Messwert scheduler_preemptions_victims zählt die Pods, die zum vorzeitigen Beenden ausgewählt wurden.

Die Anzahl der vorzeitigen Beendigungsversuche hängt stark mit dem Wert des Messwerts scheduler_schedule_attempts_total zusammen, wenn der Wert des Labels result unschedulable ist. Die beiden Werte sind nicht gleichwertig: Wenn ein Cluster beispielsweise 0 Knoten hat, gibt es keine vorzeitigen Beendigungsversuche, aber es kann möglicherweise fehlgeschlagene Planungsversuche geben.

Weitere Informationen finden Sie unter Ressourcenprobleme.

Planer überwachen

Die Planermesswerte können Ihnen einen Einblick in die Leistung Ihres Planers geben:

  • Planer-Latenz: Wird der Planer ausgeführt? Wie lange dauert es, Pods zu planen?
  • Ressourcenprobleme: Stoßen die Versuche, Pods zu planen, auf Ressourceneinschränkungen?

In diesem Abschnitt wird beschrieben, wie Sie mit Ihrem Planermesswert Ihren Planer überwachen.

Planerlatenz

Die Aufgabe des Planers besteht darin, die Ausführung der Pods sicherzustellen. Daher möchten Sie wissen, wann der Planer feststeckt oder langsam ausgeführt wird.

  • Wenn Sie prüfen möchten, ob der Planer ausgeführt wird und Pods geplant werden, verwenden Sie den Messwert scheduler_schedule_attempts_total.

  • Wenn der Planer langsam ausgeführt wird, können Sie die folgenden möglichen Ursachen untersuchen:

    • Die Anzahl der ausstehenden Pods erhöht sich. Verwenden Sie den Messwert scheduler_pending_pods, um die Anzahl der ausstehenden Pods zu überwachen. Die folgende PromQL-Abfrage gibt die Anzahl der ausstehenden Pods pro Warteschlange in einem Cluster zurück:

      sum by (queue)
(delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))

    • Einzelne Versuche, Pods zu planen, sind langsam. Verwenden Sie den Messwert scheduler_scheduling_attempt_duration_seconds, um die Latenz von Planungsversuchen zu überwachen.

      Wir empfehlen, diesen Messwert mindestens beim 50. und 95. Perzentil zu beobachten. Die folgende PromQL-Abfrage ruft 95. Perzentilwerte ab, kann jedoch angepasst werden:

      sum by (instance) (histogram_quantile(0.95, rate(
scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))

Ressourcenprobleme

Mithilfe der Planermesswerte können Sie auch feststellen, ob Sie genügend Ressourcen haben. Wenn der Wert des Messwerts scheduler_preemption_attempts_total zunimmt, prüfen Sie den Wert von scheduler_preemption_victims mithilfe der folgenden PromQL-Abfrage:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

Die Anzahl der vorzeitigen Beendigungsversuche und die Anzahl der "Opfer" der vorzeitigen Beendigung erhöhen sich, wenn Pods mit höherer Priorität zu planen sind. Die Messwerte zum vorzeitigen Beenden geben Ihnen nicht an, ob die Pods mit hoher Priorität, die das vorzeitige Beenden ausgelöst haben, geplant wurden. Wenn Sie also einen Anstieg der vorzeitigen Beendigungsmesswerte feststellen, können Sie auch den Wert des Messwerts scheduler_pending_pods überwachen. Wenn die Anzahl der ausstehenden Pods ebenfalls zunimmt, haben Sie möglicherweise nicht genügend Ressourcen, um die Pods mit höherer Priorität zu verarbeiten. Möglicherweise müssen Sie die verfügbaren Ressourcen hochskalieren, neue Pods mit reduzierten Ressourcenanforderungen erstellen oder die Knotenauswahl ändern.

  • Wenn die Anzahl der vorzeitigen Beendigungen nicht zunimmt, gibt es keine verbleibenden Pods mit niedriger Priorität, die entfernt werden können. Erwägen Sie in diesem Fall, weitere Knoten hinzuzufügen, damit die neuen Pods zugewiesen werden können.

  • Wenn die Anzahl der vorzeitigen Beendigungen zunimmt, gibt es Pods mit höherer Priorität, die auf die Planung warten, sodass der Planer einige der ausgeführten Pods vorzeitig beendet. Die Messwerte zur vorzeitigen Beendigung geben Ihnen nicht an, ob die Pods mit höherer Priorität erfolgreich geplant wurden.

    Wenn Sie herausfinden möchten, ob Pods mit höherer Priorität geplant sind, suchen Sie nach abnehmenden Werten des Messwerts scheduler_pending_pods. Wenn der Wert dieses Messwerts zunimmt, müssen Sie möglicherweise weitere Knoten hinzufügen.

Sie können vorübergehende Spitzen in den Werten für den Messwert scheduler_pending_pods erwarten, wenn Arbeitslasten in Ihrem Cluster geplant werden, z. B. bei Ereignissen wie Aktualisierungen oder Skalierungen. Wenn in Ihrem Cluster genügend Ressourcen vorhanden sind, sind diese Spitzen temporär. Wenn die Anzahl der ausstehenden Pods nicht sinkt, gehen Sie so vor:

  • Prüfen Sie, ob die Knoten gesperrt werden. Abgesicherte Knoten akzeptieren keine neuen Pods.
  • Prüfen Sie die folgenden Planungsanweisungen, die falsch konfiguriert sein können und möglicherweise einen Pod nicht planbarer machen:
    • Knotenaffinität und -selektor.
    • Markierungen und Toleranzen.
    • Streuungseinschränkungen für Pod-Topologien.

Wenn Pods aufgrund unzureichender Ressourcen nicht geplant werden können, sollten Sie einige der vorhandenen Knoten freigeben oder die Anzahl der Knoten erhöhen.

Controller Manager-Messwerte

Wenn Controller-Manager-Messwerte aktiviert sind, werden alle in der folgenden Tabelle angezeigten Messwerte zu Cloud Monitoring im selben Projekt exportiert, in dem sich auch der GKE-Cluster befindet.

Die Cloud Monitoring-Messwertnamen in dieser Tabelle müssen das Präfix prometheus.googleapis.com/ haben. Dieses Präfix wurde in den Einträgen der Tabelle weggelassen.

PromQL-Messwertname Einführungsphase
Cloud Monitoring-Messwertname
Art, Typ, Einheit
Überwachte Ressourcen
Erforderliche GKE-Version		 Beschreibung
Labels
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24+ 		Anzahl der Knotenentfernungen, die seit dem Start der aktuellen Instanz von NodeController stattgefunden haben.

zone