Anthos-Cluster auf VMware ist jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei Problemen mit Ressourcenkonflikten

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

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

Überblick

Manchmal kommt es in Google Distributed Cloud zu Ressourcenkonflikten, sodass Ihre Container langsamer, schlecht abschneiden oder beendet werden. Dies kann an einer hohen CPU- oder Arbeitsspeichernutzung durch die Container liegen.

Funktionsweise der CPU- und Speicherverwaltung

CPU:
- Basierend auf den CPU-Anfragen, die von den Containern im Pod angegeben werden, wird ein Pod für einen Knoten geplant.
- Ein Container in einem Pod kann nicht mehr CPUs verwenden als das vom Container festgelegte Limit
- 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 im Verhältnis zu den Anfragen zugewiesen.
Weitere Informationen zum Planen von Pods mit Ressourcenanfragen
Arbeitsspeicher:
- Ein Pod wird für einen Knoten basierend auf den Speicheranfragen geplant, die von den Containern im Pod angegeben werden.
- Ein Container darf nicht mehr Arbeitsspeicher nutzen, als vom Container festgelegt ist.
- Wenn kein Arbeitsspeicherlimit angegeben ist, nutzt ein Container möglicherweise den gesamten verfügbaren Arbeitsspeicher auf einem Knoten. Dann kann das System den OOM-Killer (Out Of Memory Killer) auslösen und die Pods mit niedriger Priorität entfernen.

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

Probleme

Container wird langsam

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

Hohe CPU-Auslastung im Container:

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

Führen Sie unter 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 dies, dass das CPU-Limit für den Container niedrig ist und Kubernetes die CPU-Zyklen des Containers drosselt, um die CPU-Nutzung 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 des CPU-Limits zur Auslastung für einen einzelnen Container des Pods nicht hoch ist, kann es sein, dass der Knoten nicht genügend CPU-Zyklen hat, 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:

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 unter 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 viele CPU-Zyklen aufweist. Führen Sie die folgenden Schritte aus, um die CPU-Auslastung aller anderen Pods auf diesem Knoten zu prüfen und zu ermitteln, 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 mit einer hohen CPU-Leistung auf dem Knoten arbeitet, 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 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 weder auf dem Knoten noch auf dem Pod hoch ist und der Container immer noch langsam ist, ist die VM auf vSphere-Ebene möglicherweise zu stark abonniert. 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 überlastet ist. Wenn eine übermäßige Anzahl von Abos erkannt wird, versuchen Sie Folgendes:

Verschieben Sie einige VMs auf andere Hosts.
Prüfen und reduzieren 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-Anfragen und -Limits für den Container. Dadurch wird der Pod auf einem anderen Knoten neu erstellt, um die erforderlichen CPU-Zyklen zu erhalten.

Pod erhält OOMkilled (nicht genügend Arbeitsspeicher)

Aufgrund von Speicherlecks oder einer schlechten Konfiguration von Arbeitsspeicheranfragen und ‐limits für die Container können die Pods den Status „OOMKilled“ erhalten. Hier einige mögliche Gründe:

Hohe Arbeitsspeichernutzung auf dem Container

Ein Pod kann einen OOMkill erhalten, wenn ein Container in einem Pod zu viel Arbeitsspeicher belegt. Prüfen Sie daher das Verhältnis von Arbeitsspeicheranfragen zu Arbeitsspeicherlimits für den Container.

Führen Sie unter 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 Arbeitsspeicherlimit 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 einen OOMkill erhalten, wenn die Arbeitsspeichernutzung aller auf dem Knoten ausgeführten Pods den verfügbaren Arbeitsspeicher überschreitet. Prüfen Sie daher, ob die MemoryPressure-Bedingung auf dem Knoten True ist.

Führen Sie den folgenden Befehl aus und prüfen Sie den Abschnitt Conditions:
```
kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME
```
Wenn die Bedingung MemoryPressure True ist, 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 über genügend Arbeitsspeicher verfügt, um dem Pod zuzuweisen.Dies liegt möglicherweise daran, dass einige Prozesse oder andere Pods viel Arbeitsspeicher verbrauchen.
Führen Sie im MQL-Editor unter Google Cloud Console > Monitoring > Metrics Explorer 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, prüfen Sie seine Funktionsweise oder erhöhen Sie gegebenenfalls die Arbeitsspeicheranforderung für den Container.

Sollte ein System-Pod viel Arbeitsspeicher verbrauchen, wenden Sie sich an den Google-Support.

Darüber hinaus können Sie die Autoscaling-Funktion in Google Distributed Cloud aktivieren, um die Knotenpools je nach den Anforderungen Ihrer Arbeitslasten automatisch hoch- und herunterzuskalieren.

Autoscaling aktivieren

ETC-Probleme

Manchmal können in Ihren Anthos-Cluster auf VMware aufgrund von etcd-Serverproblemen Containerfehler auftreten. Dabei kann Folgendes auftreten:

Wiederholte API-Serverprotokolle 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

Hier einige 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. Führen Sie die Schritte im Abschnitt Container wird langsam aus, um zu prüfen, ob es Probleme mit CPU-Konflikten gibt.

Wenn Sie CPU-Konflikte auf dem ectd-Server-Pod oder 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 OOMkilled

Der etcd-Pod wird aufgrund von Ressourcenkonflikten möglicherweise als OOM beendet. Prüfen Sie anhand der Schritte im Abschnitt Pod wird OOMkilled (Out of Memory-Killed), um mögliche Speicherkonflikte mit dem etcd-Server-Pod und/oder dem Knoten zu prüfen, auf dem der etcd-Server ausgeführt wird.

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

Langsames Laufwerk

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

Prüfen Sie, ob folgende Probleme vorliegen:

So prüfen Sie, ob der etcd-Server zum Lesen/Schreiben auf dem zugrunde liegenden Laufwerk zu lange braucht:
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 für das folgende Muster, um festzustellen, ob das Lesen von 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 von etcd zu lange auf das Laufwerk 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-Logs auftreten, weist dies auf eine langsame Festplatte hin. Überprüfen Sie dann die Leistung des Datenspeichers und der Laufwerke.
So überprüfen Sie die etcd-Messwerte:
1. Rufen Sie die etcd-Wal-Synchronisierungslatenzen ab:
  
  Führen Sie unter 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 unter 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 eine langsame Festplatte hin. Überprü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

Ermitteln 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 bei vSphere an und wählen Sie die im vorherigen Schritt identifizierte VM aus: Rufen Sie in vSphere Monitor > Performance > Advanced (Überwachen > Leistung > Erweitert) 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 bestimmen.

Wenn die Lese-/Schreiblatenz des virtuellen Laufwerks hoch ist:
- Untersuchen Sie andere VMs, die im Datenspeicher ausgeführt werden, um die hohe Auslastung der Ein-/Ausgabevorgänge pro Sekunde (IOPS) zu ermitteln. Wenn eine VM Spitzen bei den IOPS anzeigt, bewerten Sie die Funktion dieser VM.
- Wenden Sie sich an Ihr Labor- bzw. Infrastruktur-Team, um sicherzustellen, dass die Lese- und Schreibbandbreite zu keiner Zeit gedrosselt oder begrenzt wird.
- Wenden Sie sich an Ihr Labor- bzw. Infrastruktur-Team, um etwaige Probleme mit der Laufwerksleistung 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 Ihrer Google Distributed Cloud bei der Kommunikation mit dem API-Server Latenzen verursachen oder die Kubectl-Befehle fehlschlagen oder zu lange zum Antworten brauchen, kann dies auf Probleme mit dem API-Server hindeuten.

Hier einige mögliche Gründe:

Hohe Anzahl an API-Anfragen

Der API-Server reagiert möglicherweise langsam, wenn die Häufigkeit und das Volumen der Anfragen auf ihm zu hoch sind. Die langsame Antwortzeit kann auch dann bestehen bleiben, wenn der API-Server mit der Drosselung der Anfragen beginnt. Überprüfen Sie daher die Rate der API-Anfragen auf dem API-Server.

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

Bei einem unerwarteten Anstieg der API-Anfragen verwenden Sie das Cloud-Audit-Logging, um den Pod zu identifizieren, der möglicherweise zu oft den API-Server abfragt.

Wenn es sich um einen System-Pod handelt, wenden Sie sich an den Google-Support.
Wenn es sich um einen Nutzer-Pod handelt, sollten Sie weiter untersuchen, um festzustellen, ob die API-Anfragen erwartet werden.

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 nach CPU-Konflikten mit dem Pod und/oder Knoten zu suchen.

API-Server-Pod außer Betrieb genommen

Der API-Server-Pod wird aufgrund von Ressourcenkonflikten möglicherweise als OOM beendet. Prüfen Sie anhand der Schritte im Abschnitt Pod wird OOMkilled (Out of Memory-Killed), um mögliche Speicherkonflikte mit dem Pod und/oder Knoten zu überprüfen.

Langsame etcd-Antworten

Der API-Server benötigt die Kommunikation mit dem etcd-Cluster, um Lese-/Schreibanfragen an die Clients zu senden. Wenn das etcd-Speicher 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 der etcd-Probleme 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 den Schritten unter ETCD-Probleme, um etwaige Probleme mit dem Laufwerk zu beheben.

Wenn Ihr Cluster keine Messwerte exportiert

Die zuvor in diesem Dokument gezeigten Verfahren basieren darauf, dass Messwerte aus Ihrem Cluster in ein Google Cloud-Projekt exportiert werden.

Wenn Ihr Cluster keine Messwerte exportiert, können Sie Ressourcenkonflikte über die Befehlszeile untersuchen. Im Folgenden finden Sie einige Befehle, die Sie auf Ihrer Administratorworkstation ausführen können, um Messwerte anzusehen.

Sehen Sie sich Messwerte für einen Knoten an:

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

Sehen Sie sich Messwerte für einen Pod an:

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: der Name des Pods

Sehen Sie sich Messwerte für alle Knoten an:

kubectl --kubeconfig CLUSTER_KUBECONFIG top node

Sehen Sie sich Messwerte für alle Pods in einem Namespace an:

kubectl --kubeconfig CLUSTER_KUBECONFIG top pod --namespace NAMESPACE

Sehen Sie sich Messwerte für die Container in allen Pods in einem Namespace an:

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 kubectl exec aus, um eine Shell im Container abzurufen. 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 abzurufen. 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.