Messwerte der Steuerungsebene erfassen und aufrufen

Auf dieser Seite wird beschrieben, wie Sie einen GKE-Cluster (Google Kubernetes Engine) so konfigurieren, dass Messwerte, die vom Kubernetes API-Server, Scheduler und Controller Manager ausgegeben werden, mit Google Cloud Managed Service for Prometheus an Cloud Monitoring gesendet werden. Auf dieser Seite wird auch beschrieben, wie diese Messwerte formatiert werden, wenn sie in Monitoring geschrieben und abgefragt werden.

Hinweise

Führen Sie die folgenden Schritte durch, 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 update ab.

Voraussetzungen

Für das Senden von Messwerten, die von Komponenten der Kubernetes-Steuerungsebene an Cloud Monitoring ausgegeben werden, gelten die folgenden Anforderungen:

• Für den Cluster müssen Systemmesswerte aktiviert sein.

Erfassung von Messwerten der Steuerungsebene konfigurieren

Sie können Steuerungsebenenmesswerte in einem vorhandenen GKE-Cluster mit der Google Cloud Console, der gcloud CLI oder Terraform aktivieren.

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Kontingent

Messwerte der Steuerungsebene nutzen das Kontingent „Zeitachsenaufnahmeanfragen pro Minute“ der Cloud Monitoring API. Bevor Sie die Messwertpakete aktivieren, prüfen Sie Ihre letzte Spitzennutzung dieses Kontingents. Wenn sich viele Cluster im selben Projekt befinden oder sich dem Limit dieses Kontingents nähern, können Sie eine Erhöhung des Kontingentlimits beantragen, bevor Sie ein Beobachtbarkeitspaket aktivieren.

Preise

GKE-Steuerungsebenenmesswerte verwenden Google Cloud Managed Service for Prometheus, um Messwerte in Cloud Monitoring zu laden. In Cloud Monitoring fallen Gebühren für die Aufnahme dieser Messwerte basierend auf der Anzahl der aufgenommenen Stichproben an. Für registrierte Cluster, die zu einem Projekt gehören, bei denen GKE Enterprise-Edition aktiviert ist, fallen keine Kosten an.

Weitere Informationen finden Sie unter Cloud Monitoring-Preise.

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 Kubernetes-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 Kubernetes-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 Kubernetes-Steuerungsebene enthalten 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.

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.

Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Best Practices für die Verwendung von API-Priorität und ‑Fairness.

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.

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.