Probleme mit Ressourcenkonflikten beheben

Auf dieser Seite wird beschrieben, wie Sie Probleme mit Ressourcenkonflikten in Ihrer GKE on VMware-Umgebung identifizieren und beheben können.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an Cloud Customer Care.

Überblick

Manchmal kann es in GKE on VMware zu Ressourcenkonflikten kommen, was dazu führt, dass Ihre Container verlangsamt werden, ihre Leistung beeinträchtigt oder beendet wird. Dies kann an einer hohen CPU- oder Arbeitsspeichernutzung durch die Container liegen.

Funktionsweise der CPU- und Arbeitsspeicherverwaltung

  • CPU:

    • Ein Pod wird basierend auf den CPU-Anfragen, die von den Containern im Pod angegeben wurden, für einen Knoten geplant.
    • Ein Container in einem Pod kann nicht mehr CPUs als das vom Container angegebene Limit verwenden
    • Die CPU-Nutzung des Containers wird auf das CPU-Limit gedrosselt.
    • Wenn die CPU-Nutzung auf Knotenebene gedrosselt wird, werden den Containern automatisch die CPU-Zyklen proportional zu den Anfragen zugewiesen.

    Weitere Informationen zum Planen von Pods mit Ressourcenanfragen

  • Arbeitsspeicher:

    • Ein Pod wird basierend auf den von den Containern im Pod angegebenen Speicheranforderungen für einen Knoten geplant.
    • Ein Container kann nicht mehr Arbeitsspeicher als das vom Container angegebene Limit verwenden.
    • Wenn kein Arbeitsspeicherlimit angegeben ist, verbraucht ein Container möglicherweise den gesamten verfügbaren Arbeitsspeicher auf einem Knoten. Dann löst das System möglicherweise den OOM-Killer (Out Of Memory Killer) aus und entfernt die Pods mit niedriger Priorität.

Weitere Informationen finden Sie unter CPU-Ressourcen zuweisen, Arbeitsspeicherressourcen in Kubernetes zuweisen und GKE Enterprise-Messwerte.

Probleme

Container wird langsam

Probleme mit CPU-Konflikten können dazu führen, dass die Container langsam sind. Hier einige mögliche Gründe dafür:

Hohe CPU-Auslastung für den Container:

Ein Container kann langsam werden, wenn er keine CPU-Zyklen erhält, die proportional zu den CPU-Anfragen sind, oder wenn die CPU-Anfragen zu niedrig sind, als der Container benötigt. Prüfen Sie daher das Verhältnis von CPU-Limit zur CPU-Auslastung für den Container.

Führen Sie in der Google Cloud Console > Monitoring > Metrics Explorer im MQL-Editor die folgende Abfrage aus:

  fetch k8s_container
  | metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
  | group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
  | filter resource.cluster_name == 'CLUSTER_NAME'
  | filter resource.container_name == 'CONTAINER_NAME'
  | filter resource.pod_name == 'POD_NAME'
  | filter resource.namespace_name == 'NAMESPACE_NAME'
  | every 1m

Wählen Sie dann eine der folgenden Optionen aus:

Hohe CPU-Auslastung auf dem Knoten

Wenn das Verhältnis von CPU-Limit zur Auslastung für einen einzelnen Container des Pods nicht hoch ist, hat der Knoten möglicherweise nicht genügend CPU-Zyklen, um ihn der Gruppe von Containern zuzuweisen, die auf dem Knoten ausgeführt werden. Führen Sie die folgenden Schritte aus, um das Verhältnis der tatsächlichen CPU-Nutzung zu den zuweisbaren CPUs auf dem Knoten zu prüfen:

  1. Rufen Sie den Knoten für den Pod ab, der langsam arbeitet:

    kubectl get pod –kubeconfig CLUSTER_KUBECONFIG --namespace NAMESPACE POD --output wide

  2. Führen Sie in der Google Cloud Console > Monitoring > Metrics Explorer im MQL-Editor die folgende Abfrage aus:

    fetch k8s_node
| metric 'kubernetes.io/anthos/node/cpu/allocatable_utilization'
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| every 1m

    Wenn dieses Verhältnis hoch ist (>=0,8), bedeutet dies, dass der Knoten nicht genügend CPU-Zyklen hat und zu viel abonniert ist. Führen Sie die folgenden Schritte aus, um die CPU-Auslastung für alle anderen Pods auf diesem Knoten zu prüfen und zu prüfen, ob ein anderer Container mehr CPUs verwendet.

    1. Rufen Sie alle Pods auf dem Knoten ab:
    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
    1. Prüfen Sie die CPU-Auslastung jedes Containers:
    fetch k8s_container
| metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

    Wenn ein anderer Container auf dem Knoten eine hohe CPU-Auslastung verwendet, erhöhen Sie die CPU-Anfragen und -Limits für den langsam arbeitenden Container. Dadurch wird der Pod auf einem anderen Knoten neu erstellt, um die erforderlichen CPU-Zyklen abzurufen.

Falls es sich um einen System-Pod handelt, der langsam arbeitet, wenden Sie sich an den Google-Support.

CPU-Überbelegung auf vSphere-Ebene

Wenn die CPU-Nutzung sowohl auf dem Knoten als auch auf dem Pod nicht hoch ist und der Container immer noch langsam ist, ist die VM auf vSphere-Ebene möglicherweise überbelegt. Daher kann der Knoten die erwarteten CPU-Zyklen nicht aus der zugrunde liegenden Virtualisierung abrufen.

Führen Sie diese Schritte aus, um zu prüfen, ob die VM zu viel abonniert ist. Wenn ein Überabo festgestellt wird, versuchen Sie Folgendes:

  • Verschieben Sie einige VMs auf andere Hosts.
  • Bewerten und reduzieren Sie die Anzahl der vCPUs pro VM für den Host.
  • Den GKE Enterprise-VMs weitere Ressourcen zuweisen.
  • Erhöhen Sie die CPU-Anfragen und -Limits für den Container. Dadurch wird der Pod auf einem anderen Knoten neu erstellt, um die erforderlichen CPU-Zyklen abzurufen.

Pod wird zu OOMkilled (nicht mehr Arbeitsspeicher beendet)

Die Pods können aufgrund von Speicherlecks oder der schlechten Konfiguration von Arbeitsspeicheranfragen und -limits für die Container zu „OOMKilled“ führen. Hier einige mögliche Gründe dafür:

Hohe Arbeitsspeichernutzung im Container

Ein Pod kann als „OOMkilled“ ausgegeben werden, wenn ein Container in einem Pod über den insgesamt zugewiesenen Arbeitsspeicher verfügt. Prüfen Sie daher das Verhältnis von Arbeitsspeicheranfragen zu Arbeitsspeicherlimits im Container.

Führen Sie in der Google Cloud Console > Monitoring > Metrics Explorer im MQL-Editor die folgende Abfrage aus:

fetch k8s_container
| metric 'kubernetes.io/anthos/container/memory/limit_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

Wählen Sie dann eine der folgenden Optionen aus:

Hohe Arbeitsspeichernutzung auf dem Knoten

Ein Pod kann als „OOMkilled“ ausgegeben werden, wenn die Arbeitsspeichernutzung aller auf dem Knoten ausgeführten Pods den verfügbaren Arbeitsspeicher überschreitet. Prüfen Sie daher, ob die MemoryPressure-Bedingung des Knotens True ist.

  1. Führen Sie den folgenden Befehl aus und prüfen Sie den Abschnitt Conditions:

    kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME

  2. Wenn die Bedingung MemoryPressure den Wert True hat, prüfen Sie die Arbeitsspeicherauslastung des Knotens:

    fetch k8s_node
| metric 'kubernetes.io/anthos/node/memory/allocatable_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name = 'NODE_NAME'
| every 1m

    Wenn dieses Verhältnis hoch ist (>= 0,8), bedeutet dies, dass der Knoten nicht genügend Arbeitsspeicher hat, um dem Pod zuzuweisen.Dies kann daran liegen, dass einige Prozesse oder andere Pods viel Arbeitsspeicher belegen.

  3. Führen Sie in Google Cloud Console > Monitoring > Metrics Explorer im MQL-Editor die folgende Abfrage aus, um die Arbeitsspeichernutzung für die Container auf dem Knoten zu prüfen:

    fetch k8s_node
| metric 'kubernetes.io/anthos/container_memory_usage_bytes'
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| group_by 1m,
    [value_container_memory_usage_bytes_mean:
      mean(value.container_memory_usage_bytes)]
| every 1m

    Wenn ein Container viel Arbeitsspeicher verwendet, untersuchen Sie seine Funktionsweise oder erhöhen Sie bei Bedarf die Speicheranforderung für den Container.

Falls es sich um einen System-Pod handelt, der viel Arbeitsspeicher belegt, wenden Sie sich an den Google-Support.

Darüber hinaus können Sie das Autoscaling-Feature in GKE on VMware aktivieren, um die Knotenpools je nach Anforderungen Ihrer Arbeitslasten automatisch hoch- und herunterzuskalieren.

Autoscaling aktivieren

Probleme mit etc.

Manchmal können in Anthos-Cluster auf VMware aufgrund von Problemen mit dem etcd-Server Containerfehler auftreten und Folgendes angezeigt wird:

  • Wiederholte API-Serverprotokolle in folgendem Format:

    etcdserver: request timed out und etcdserver: leader changed

  • Wiederholte etcd-Logs im folgenden Format:

    W | wal: sync duration of 2.466870869s, expected less than 1s und W | etcdserver: read-only range request * took too long

Hier einige mögliche Gründe dafür:

CPU-Drosselung

Der etcd-Server ist möglicherweise aufgrund der CPU-Drosselung auf dem etcd-Server-Pod und/oder dem Knoten, auf dem der etcd-Server ausgeführt wird, langsam. Prüfen Sie anhand der Schritte im Abschnitt Container wird langsam, ob es Probleme mit CPU-Konflikten gibt.

Wenn Sie CPU-Konflikte auf dem ectd-Server-Pod oder auf dem Knoten erkennen, fügen Sie dem Knoten der Steuerungsebene des Nutzerclusters CPUs hinzu. Verwenden Sie gkectl update, um das Feld cpus in der Konfigurationsdatei des Nutzerclusters zu bearbeiten.

EtCD Pod OOMkilled

Der etcd-Pod wird möglicherweise aufgrund von Ressourcenkonflikten zu „OOMkilled“. Führen Sie die Schritte im Abschnitt Podwird OOMkilled (Out of Memory-Killed) durch, um zu prüfen, ob es Probleme mit Arbeitsspeicherkonflikten mit dem etcd-Server-Pod und/oder dem Knoten gibt, auf dem der etcd-Server ausgeführt wird.

Wenn Sie OOMkills für den etcd-Pod erkennen, erhöhen Sie den für den Knoten der Steuerungsebene des Nutzerclusters verfügbaren Arbeitsspeicher. Verwenden Sie gkectl update, um das Feld memoryMB in der Konfigurationsdatei des Nutzerclusters zu bearbeiten.

Langsamkeit des Laufwerks

Wenn keine Probleme mit der CPU- oder Arbeitsspeichernutzung auf dem etcd-Server-Pod oder dem Knoten vorliegen, ist der etcd möglicherweise langsam, wenn der zugrunde liegende Datenspeicher langsam oder gedrosselt ist.

Überprüfen Sie, ob eines der folgenden Probleme vorliegt:

  • So prüfen Sie, ob der etcd-Server für das Lesen/Schreiben auf dem zugrunde liegenden Laufwerk zu lange dauert:

    1. Rufen Sie die etcd-Logs ab:

      kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n ETCD_POD_NAMESPACE ETCD_POD

    2. Suchen Sie nach den Einträgen des folgenden Musters, um festzustellen, ob das Lesen von etcd vom Laufwerk zu lange dauert:

      W | etcdserver: read-only range request "key:\"/registry/configmaps/default/clusterapi-vsphere-controller-manager-leader-election\" " with result "range_response_count:1 size:685" took too long (6.893127339s) to execute

    3. Suchen Sie nach den Einträgen des folgenden Musters, um festzustellen, ob das Schreiben von etcd auf das Laufwerk zu lange dauert:

      W | wal: sync duration of 2.466870869s, expected less than 1s

    Wenn eines oder beide der oben genannten Logmuster häufig in den etcd-Protokollen angezeigt werden, weist dies auf eine langsame Festplatte hin. Prüfen Sie dann die Leistung des Datenspeichers und der Laufwerke.

  • So überprüfen Sie die etcd-Messwerte:

    1. Rufen Sie die wal-Synchronisierungslatenzen von etcd ab:

      Führen Sie in der Google Cloud Console > Monitoring > Metrics Explorer im MQL-Editor die folgende Abfrage aus:

      fetch k8s_container::kubernetes.io/anthos/etcd_disk_wal_fsync_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99

    2. Rufen Sie die Schreiblatenzen von etcd ab:

      Führen Sie in der Google Cloud Console > Monitoring > Metrics Explorer im MQL-Editor die folgende Abfrage aus:

      fetch k8s_container::kubernetes.io/anthos/etcd_disk_backend_commit_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99

    Wenn p99 für etcd_disk_wal_fsync_duration_seconds kontinuierlich über 10 ms und/oder p99 für etcd_disk_backend_commit_duration_seconds kontinuierlich über 25 ms liegt, weist dies auf das langsame Laufwerk hin. Prüfen Sie dann die Leistung des Datenspeichers und der Laufwerke.

Lese-/Schreiblatenzen auf dem VM-Laufwerk

Führen Sie die folgenden Schritte aus, um die Lese-/Schreiblatenzen auf dem virtuellen VM-Laufwerk zu prüfen

  1. Ermitteln Sie den Knoten für den langsamen etcd-Pod:

    kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods -n ETCD_POD_NAMESPACE ETCD_POD -owide

  2. Melden Sie sich bei vSphere an und wählen Sie die im obigen Schritt identifizierte VM aus: Rufen Sie in vSphere Monitor > Performance (Leistung) > Advanced auf und wählen Sie im Abschnitt View (Ansicht) die Option Virtual Disk (Virtuelles Laufwerk) aus, um die Lese- und Schreiblatenzen für die virtuellen Laufwerke zu ermitteln.

    Wenn die Lese-/Schreiblatenz des virtuellen Laufwerks hoch ist:

    • Sehen Sie sich andere VMs an, die im Datenspeicher ausgeführt werden, um die hohe IOPS-Nutzung (Input/Output Operations per Second) zu ermitteln. Wenn bei einer VM Spitzen bei den IOPS auftreten, prüfen Sie die Funktionsfähigkeit dieser VM.
    • Wenden Sie sich an Ihr Labor-/Infrastrukturteam, um sicherzustellen, dass die Bandbreite für Lese- und Schreibvorgänge zu keinem Zeitpunkt gedrosselt oder begrenzt wird.
    • Wenden Sie sich an Ihr Lab-/Infrastrukturteam, um etwaige Probleme mit der Laufwerksleistung und der Speicherleistung zu ermitteln.

Weitere Informationen finden Sie in den Best Practices zum Skalieren Ihrer Ressourcen.

Probleme mit dem API-Server

Wenn die Container in GKE on VMware bei der Kommunikation mit dem API-Server Latenz haben oder die Kubectl-Befehle fehlschlagen oder zu lange zum Antworten benötigen, kann dies auf Probleme mit dem API-Server hindeuten.

Hier einige mögliche Gründe dafür:

Hohe Anzahl von API-Anfragen

Der API-Server antwortet möglicherweise langsam, wenn Frequenz und Volumen der Anfragen auf ihm zu hoch sind. Die lange Antwortzeit bleibt möglicherweise bestehen, auch wenn der API-Server damit beginnt, die Anfragen zu drosseln. Prüfen Sie daher die Rate der API-Anfragen auf dem API-Server.

Führen Sie in der Google Cloud Console > Monitoring > Metrics Explorer im MQL-Editor die folgende Abfrage aus:

fetch k8s_container::kubernetes.io/anthos/apiserver_request_total
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'APISERVER_POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| align rate(1m)
| every 1m
| group_by [metric.verb]

Sollte es zu einem unerwarteten Anstieg der API-Anfragen kommen, verwenden Sie Cloud-Audit-Logging, um den Pod zu ermitteln, der den API-Server möglicherweise zu oft abfragt.

  • Wenn es sich um einen System-Pod handelt, wenden Sie sich an den Google-Support.
  • Wenn es sich um einen Nutzer-Pod handelt, prüfen Sie weiter, ob die API-Anfragen zu erwarten sind.

CPU-Drosselung

Eine hohe Anforderungsrate auf dem API-Server kann zu einer CPU-Drosselung führen. Dann kann der API-Server aufgrund von CPU-Konflikten auf dem API-Server-Pod und/oder dem Knoten langsam werden.

Lesen Sie den Abschnitt Container wird langsam, um zu prüfen, ob es Probleme mit CPU-Konflikten mit dem Pod und/oder dem Knoten gibt.

API-Server-Pod OOMkilled

Der API-Server-Pod wird möglicherweise aufgrund von Ressourcenkonflikten als „OOMkilled“ beendet. Überprüfen Sie anhand der Schritte im Abschnitt Pod wird OOMkilled (Out of Memory-Killed) auf Speicherkonflikte mit dem Pod und/oder dem Knoten.

Langsame etcd-Antworten

Der API-Server ist auf die Kommunikation mit dem etcd-Cluster angewiesen, um Lese-/Schreibanfragen an die Clients zu verarbeiten. Wenn der etcd langsam ist oder nicht reagiert, wird auch der API-Server langsam.

Rufen Sie die Protokolle des API-Servers ab, um zu prüfen, ob der API-Server aufgrund von etcd-Problemen langsam ist:

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Wenn Sie wiederkehrende Logs wie etcdserver: request timedout oder etcdserver: leader changed sehen, folgen Sie der Anleitung unter Probleme mit etc. in Zusammenhang mit dem Laufwerk, um etwaige Probleme mit dem Laufwerk zu beheben.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an Cloud Customer Care.