Anthos Clusters on VMware heißt jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Probleme mit Ressourcenkonflikten beheben

Auf dieser Seite wird beschrieben, wie Sie Probleme mit Ressourcenkonflikten in Ihrer Google Distributed Cloud-Umgebung erkennen und beheben.

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

Übersicht

Manchmal kommt es in der Google Distributed Cloud zu Ressourcenkonflikten, die dazu führen, dass Ihre Container langsamer werden, nicht die gewünschte Leistung erzielen oder beendet werden. Das kann auf einen hohen CPU- oder Arbeitsspeicherverbrauch durch die Container zurückzuführen sein.

So funktioniert die CPU- und Speicherverwaltung

CPU:
- Ein Pod wird basierend auf den CPU-Anfragen, die von den Containern im Pod angegeben werden, auf einem Knoten geplant.
- Ein Container in einem Pod kann nicht mehr CPUs verwenden als das vom Container angegebene Limit.
- Die CPU-Auslastung des Containers wird auf das CPU-Limit gedrosselt.
- Wenn die CPU-Auslastung auf Knotenebene gedrosselt wird, werden den Containern automatisch CPU-Zyklen proportional zu den Anfragen zugewiesen.
Weitere Informationen zum Planen von Pods mit Ressourcenanfragen
Arbeitsspeicher:
- Ein Pod wird basierend auf den Arbeitsspeicheranfragen, die von den Containern im Pod angegeben werden, auf einem Knoten geplant.
- Ein Container kann nicht mehr Arbeitsspeicher verbrauchen als das vom Container angegebene Limit.
- Wenn kein Arbeitsspeicherlimit angegeben ist, kann ein Container den gesamten verfügbaren Arbeitsspeicher eines Knotens belegen. 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 zuweisen in Kubernetes und GKE Enterprise-Messwerte.

Probleme

Container wird langsam

CPU-Konflikte können dazu führen, dass die Container langsam werden. Mögliche Gründe:

Hohe CPU-Auslastung auf dem Container:

Ein Container kann langsam werden, wenn er CPU-Zyklen nicht proportional zu den CPU-Anfragen erhält oder die CPU-Anfragen zu niedrig für die Anforderungen des Containers sind. Prüfen Sie daher das Verhältnis von CPU-Limit zu CPU-Auslastung für den Container.

Führen Sie in 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:

Wenn dieses Verhältnis hoch ist (≥ 0,8), bedeutet das, dass das CPU-Limit für den Container niedrig ist und Kubernetes die CPU-Zyklen des Containers drosselt, um die CPU-Auslastung innerhalb des Limits zu halten. Erhöhen Sie das CPU-Limit für den Container, um dieses Problem zu beheben.
Wenn dieses Verhältnis nicht hoch ist (< 0,8), prüfen Sie, ob die CPU-Auslastung auf dem Knoten hoch ist.

Hohe CPU-Auslastung auf dem Knoten

Wenn das Verhältnis von CPU-Limit zu CPU-Auslastung für einzelne Container des Pods nicht hoch ist, hat der Knoten möglicherweise nicht genügend CPU-Zyklen, um sie den auf dem Knoten ausgeführten Containern zuzuweisen. So prüfen Sie das Verhältnis der tatsächlichen CPU-Auslastung zu den zuweisbaren CPUs auf dem Knoten:

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

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

Führen Sie in 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 das, dass der Knoten nicht genügend CPU-Zyklen hat und überbelegt ist. Führen Sie die folgenden Schritte aus, um die CPU-Auslastung aller anderen Pods auf diesem Knoten zu prüfen und herauszufinden, ob es einen anderen Container gibt, der mehr CPUs verwendet.

Alle Pods auf dem Knoten abrufen:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

CPU-Auslastung der einzelnen Container prüfen:

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 viele CPUs nutzt, erhöhen Sie die CPU-Anfragen und ‑Limits für den Container, der langsam arbeitet. Dadurch wird der Pod auf einem anderen Knoten neu erstellt, um die erforderlichen CPU-Zyklen zu erhalten.

Wenn ein System-Pod langsam arbeitet, wenden Sie sich an den Google-Support.

CPU-Überbelegung auf vSphere-Ebene

Wenn die CPU-Auslastung weder auf dem Knoten noch auf dem Pod hoch ist und der Container immer noch langsam ist, ist die VM möglicherweise auf vSphere-Ebene überbelegt. Daher kann der Knoten nicht die erwarteten CPU-Zyklen von der zugrunde liegenden Virtualisierung erhalten.

Folgen Sie dieser Anleitung, um zu prüfen, ob die VM überbelegt ist. Wenn eine Überbelegung erkannt wird, versuchen Sie Folgendes:

Verschieben Sie einige VMs auf andere Hosts.
Bewerten und verringern Sie die Anzahl der vCPUs pro VM für den Host.
Weisen Sie den GKE Enterprise-VMs mehr Ressourcen zu.
Erhöhen Sie die CPU-Anforderungen und ‑Limits für den Container. Dadurch wird der Pod auf einem anderen Knoten neu erstellt, um die erforderlichen CPU-Zyklen zu erhalten.

Pod wird aufgrund von fehlendem Arbeitsspeicher beendet

Die Pods können aufgrund von Speicherlecks oder einer falschen Konfiguration der Speicheranforderungen und ‑limits für die Container den Status „OOMKilled“ erhalten. Mögliche Gründe:

Hohe Arbeitsspeichernutzung auf dem Container

Ein Pod kann aufgrund von fehlendem Arbeitsspeicher beendet werden, wenn ein Container in einem Pod den gesamten zugewiesenen Arbeitsspeicher verbraucht. Prüfen Sie daher das Verhältnis von Arbeitsspeicheranfragen zu Speicherlimits im Container.

Führen Sie in 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:

Wenn dieses Verhältnis hoch ist (≥ 0,8), erhöhen Sie das Speicherlimit für den Container.
Wenn dieses Verhältnis nicht hoch ist (< 0,8), prüfen Sie, ob die Arbeitsspeichernutzung auf dem Knoten hoch ist.

Hohe Arbeitsspeichernutzung auf dem Knoten

Ein Pod kann aufgrund von fehlendem Arbeitsspeicher beendet werden, wenn die Arbeitsspeichernutzung aller Pods, die auf dem Knoten ausgeführt werden, den verfügbaren Arbeitsspeicher überschreitet. Prüfen Sie also, ob die MemoryPressure-Bedingung am Knoten True ist.

Führen Sie den folgenden Befehl aus und sehen Sie sich den Abschnitt Conditions an:
```
kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME
```

Wenn die MemoryPressure-Bedingung True ist, prüfen Sie die Arbeitsspeichernutzung auf dem Knoten:

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 das, dass der Knoten nicht genügend Arbeitsspeicher für den Pod hat. Dies kann daran liegen, dass einige Prozesse oder andere Pods viel Arbeitsspeicher verbrauchen.

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 verbraucht, prüfen Sie die Funktionsweise des Containers oder erhöhen Sie bei Bedarf die Arbeitsspeicheranfrage für den Container.

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

Außerdem können Sie die Autoscaling-Funktion in Google Distributed Cloud aktivieren, um die Knotenpools automatisch je nach Anforderungen Ihrer Arbeitslasten hoch- oder herunterzuskalieren.

Weitere Informationen zum Aktivieren des Autoscalers

Etcd-Probleme

Manchmal treten in Anthos Clusters on VMware aufgrund von Problemen mit dem etcd-Server Containerfehler auf. Dabei können folgende Symptome auftreten:

Wiederholte API-Server-Logs im Format:

etcdserver: request timed out und etcdserver: leader changed
Wiederholte etcd-Logs im Format:

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

Mögliche Gründe:

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. Folgen Sie der Anleitung im Abschnitt Container wird langsam, um nach CPU-Konflikten zu suchen.

Wenn Sie einen CPU-Konflikt auf dem ectd-Server-Pod oder auf dem Knoten feststellen, 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 wird aufgrund von fehlendem Arbeitsspeicher beendet

Der etcd-Pod wird möglicherweise aufgrund von Ressourcenkonflikten durch „OOMkilled“ beendet. Folgen Sie der Anleitung im Abschnitt Pod wird aufgrund von fehlendem Arbeitsspeicher beendet, um nach Problemen mit Arbeitsspeicherkonflikten beim etcd-Server-Pod und/oder dem Knoten zu suchen, auf dem der etcd-Server ausgeführt wird.

Wenn Sie OOMkills für den etcd-Pod feststellen, 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.

Laufwerk läuft zu langsam

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

Überprüfen Sie, ob eines oder mehrere dieser Probleme vorliegen:

So prüfen Sie, ob der etcd-Server zu lange für das Lesen/Schreiben auf dem zugrunde liegenden Laufwerk benötigt:
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 auf dem Laufwerk über etcd 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 auf das Laufwerk über etcd 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-Log vorkommen, ist das Laufwerk zu langsam. Prüfen Sie dann die Leistung des Datenspeichers und der Laufwerke.
So prüfen Sie die etcd-Messwerte:
1. Rufen Sie die etcd-WAL-Synchronisierungslatenzen ab:
  
  Führen Sie in 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 etcd-Schreiblatenzen ab:
  
  Führen Sie in 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, ist das Laufwerk zu langsam. Prüfen Sie dann die Leistung des Datenspeichers und der Laufwerke.

Lese-/Schreiblatenzen auf dem VM-Laufwerk

So prüfen Sie die Lese-/Schreiblatenzen des virtuellen Laufwerks der VM:

Identifizieren Sie den Knoten für den langsamen etcd-Pod:

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

Melden Sie sich in vSphere an und wählen Sie die oben identifizierte VM aus: Gehen Sie in vSphere zu Monitor > Leistung > Erweitert und wählen Sie im Bereich Ansicht die Option Virtuelles Laufwerk aus, um die Lese- und Schreiblatenzen für die virtuellen Laufwerke zu ermitteln.

Wenn die Lese-/Schreiblatenz des virtuellen Laufwerks hoch ist:
- Prüfen Sie andere VMs, die auf dem Datenspeicher ausgeführt werden, auf eine hohe IOPS-Nutzung (Eingabe-/Ausgabevorgänge pro Sekunde). Wenn bei einer VM Spitzen bei den IOPS auftreten, prüfen Sie die Funktion dieser VM.
- Wenden Sie sich an Ihr Lab-/Infrastrukturteam, um sicherzustellen, dass die Lese- und Schreibbandbreite zu keinem Zeitpunkt gedrosselt oder eingeschränkt wird.
- Wenden Sie sich an Ihr Lab-/Infrastrukturteam, um mögliche Probleme mit der Laufwerkleistung und der Speicherleistung zu identifizieren.

Weitere Informationen finden Sie in den Best Practices für die Skalierung Ihrer Ressourcen.

Probleme mit dem API-Server

Wenn die Container in Google Distributed Cloud bei der Kommunikation mit dem API-Server eine Latenz aufweisen oder die Kubectl-Befehle fehlschlagen oder die Antwort zu lange dauert, kann das auf Probleme mit dem API-Server hinweisen.

Mögliche Gründe:

Hohes Volume an API-Anfragen

Der API-Server reagiert möglicherweise langsam, wenn die Häufigkeit und das Volume der Anfragen zu hoch sind. Die lange Antwortzeit kann auch dann andauern, wenn der API-Server die Anfragen drosselt. Prüfen Sie daher die Rate der API-Anfragen auf dem API-Server.

Führen Sie in 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]

Wenn die Anzahl der API-Anfragen unerwartet steigt, verwenden Sie das 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, ob die API-Anfragen erwartet werden.

CPU-Drosselung

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

Im Abschnitt Container wird langsam finden Sie Informationen dazu, wie Sie Probleme mit CPU-Konflikten des Pods und/oder des Knotens prüfen.

API-Server-Pod wird aufgrund von fehlendem Arbeitsspeicher beendet

Der API-Server-Pod wird möglicherweise aufgrund von Ressourcenkonflikten durch „OOMkilled“ beendet. Folgen Sie der Anleitung im Abschnitt Pod wird aufgrund von fehlendem Arbeitsspeicher beendet, um nach Problemen mit Arbeitsspeicherkonflikten mit dem Pod und/oder dem Knoten zu suchen.

Langsame etcd-Antworten

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

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

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Wenn Sie wiederholte Logs wie etcdserver: request timedout oder etcdserver: leader changed sehen, folgen Sie der Anleitung unter Etcd-Probleme, um alle laufwerkbezogenen Probleme zu beheben.

Wenn Ihr Cluster keine Messwerte exportiert

Bei den zuvor in diesem Dokument beschriebenen Methoden werden Messwerte aus Ihrem Cluster in ein Google Cloud-Projekt exportiert.

Wenn Ihr Cluster keine Messwerte exportiert, können Sie die Ressourcenkonflikte mithilfe der Befehlszeile untersuchen. Im Folgenden finden Sie einige Befehle, die Sie auf Ihrer Administrator-Workstation ausführen können, um Messwerte aufzurufen.

Rufen Sie Messwerte für einen Knoten auf:

kubectl --kubeconfig CLUSTER_KUBECONFIG get --raw \
    /apis/metrics.k8s.io/v1beta1/nodes/NODE_NAME | jq

Ersetzen Sie Folgendes:

CLUSTER_KUBECONFIG: Pfad der kubeconfig-Datei des Clusters
NODE_NAME: der Name des Knotens

Rufen Sie Messwerte für einen Pod auf:

kubectl --kubeconfig CLUSTER_KUBECONFIG get --raw \
    /apis/metrics.k8s.io/v1beta1/namespaces/NAMESPACE/pods/POD_NAME | jq

Ersetzen Sie Folgendes:

NAMESPACE: Namespace des Pods
POD_NAME: Name des Pods

Rufen Sie Messwerte für alle Knoten auf:

kubectl --kubeconfig CLUSTER_KUBECONFIG top node

Rufen Sie Messwerte für alle Pods in einem Namespace auf:

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --namespace NAMESPACE

Rufen Sie Messwerte für die Container in allen Pods in einem Namespace auf:

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --containers --namespace NAMESPACE

Weitere Informationen finden Sie unter kubectl top pod und kubectl top node.

Sie können den Befehl top auch in einem Container ausführen, der auf einem Knoten ausgeführt wird.

Es gibt zwei Möglichkeiten, einen Befehl in einem Container auszuführen:

Führen Sie auf Ihrer Administrator-Workstation den Befehl kubectl exec aus, um eine Shell im Container zu öffnen. Führen Sie den Befehl in der Shell aus.
Stellen Sie eine SSH-Verbindung zu einem Knoten her Verwenden Sie dann docker exec, um eine Shell im Container zu starten. Führen Sie den Befehl in der Shell aus.

Nächste Schritte

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