Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei Systemmesswerten

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Probleme im Zusammenhang mit Systemmesswerten in Ihren Google Kubernetes Engine-Clustern (GKE) beheben.

Messwerte aus Ihrem Cluster werden nicht in Cloud Monitoring angezeigt

Achten Sie darauf, dass Sie die Monitoring API und die Logging API in Ihrem Projekt aktiviert haben. Prüfen Sie außerdem, ob Sie Ihr Projekt in der Cloud Monitoring-Übersicht in derGoogle Cloud Console sehen können.

Wenn das Problem weiterhin besteht, prüfen Sie folgende mögliche Ursachen:

Haben Sie die Überwachung für Ihr Cluster aktiviert?

Das Monitoring ist standardmäßig für Cluster aktiviert, die über die Google Cloud Console und das Google Cloud CLI erstellt wurden. Zur Prüfung können Sie den folgenden Befehl ausführen oder in der Google Cloud Console auf die Clusterdetails klicken:
```
gcloud container clusters describe CLUSTER_NAME
```
Die Ausgabe dieses Befehls sollte SYSTEM_COMPONENTS in der Liste der enableComponents im Abschnitt monitoringConfig enthalten, ähnlich dem folgenden Beispiel:
```
monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
```
Aktivieren Sie das Monitoring gegebenenfalls mithilfe des folgenden Befehls:
```
gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
```
Wie lange ist es her, dass Ihr Cluster erstellt oder das Monitoring aktiviert wurde?

Es kann bis zu einer Stunde dauern, bis die Messwerte eines neuen Clusters in Cloud Monitoring angezeigt werden.
Wird in Ihrem Cluster im Namespace kube-system ein heapster oder gke-metrics-agent (der OpenTelemetry Collector) ausgeführt?

Unter Umständen kann der Pod keine Arbeitslasten planen, weil die Ressourcen im Cluster zur Neige gehen. Prüfen Sie, ob Heapster oder OpenTelemetry ausgeführt wird. Rufen Sie dazu kubectl get pods --namespace=kube-system auf und suchen Sie nach Pods mit heapster oder gke-metrics-agent im Namen.
Kann Ihre Cluster-Steuerungsebene mit den Knoten kommunizieren?

Cloud Monitoring ist auf diese Kommunikation angewiesen. Mit dem folgenden Befehl können Sie prüfen, ob die Steuerungsebene mit den Knoten kommuniziert:
```
kubectl logs POD_NAME
```
Wenn dieser Befehl einen Fehler zurückgibt, wird das Problem möglicherweise von den SSH-Tunnels verursacht. Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei SSH-Problemen.

Berechtigungsprobleme beim Schreiben von Messwerten identifizieren und beheben

GKE verwendet IAM-Dienstkonten, die an Ihre Knoten angehängt sind, um Systemaufgaben wie Logging und Monitoring auszuführen. Diese Knoten-Dienstkonten müssen in Ihrem Projekt mindestens die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) haben. Standardmäßig verwendet GKE das Compute Engine-Standarddienstkonto, das automatisch in Ihrem Projekt erstellt wird, als Knotendienstkonto.

Wenn Ihre Organisation die Einschränkung der Organisationsrichtlinie iam.automaticIamGrantsForDefaultServiceAccounts erzwingt, erhält das Compute Engine-Standarddienstkonto in Ihrem Projekt möglicherweise nicht automatisch die erforderlichen Berechtigungen für GKE.

Suchen Sie zur Identifizierung des Problems in der Arbeitslast für die Systemüberwachung in Ihrem Cluster nach 401-Fehlern:
```
[[ $(kubectl logs -l k8s-app=gke-metrics-agent -n kube-system -c gke-metrics-agent | grep -cw "Received 401") -gt 0 ]] && echo "true" || echo "false"
```
Wenn die Ausgabe true ist, treten bei der Systemarbeitslast 401-Fehler auf, die auf fehlende Berechtigungen hinweisen. Wenn die Ausgabe false lautet, überspringen Sie die restlichen Schritte und versuchen Sie es mit einer anderen Vorgehensweise zur Fehlerbehebung.

So weisen Sie dem Compute Engine-Standarddienstkonto die Rolle roles/container.defaultNodeServiceAccount zu:

Console

Rufen Sie die Seite Willkommen auf:
Zur Begrüßungsseite
Klicken Sie im Feld Projektnummer auf In die Zwischenablage kopieren.
Rufen Sie die IAM-Seite auf.
IAM aufrufen
Klicken Sie auf Zugriffsrechte erteilen.
Geben Sie im Feld Neue Hauptkonten den folgenden Wert an:
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
Ersetzen Sie PROJECT_NUMBER durch die kopierte Projektnummer.
Wählen Sie im Menü Rolle auswählen die Rolle Kubernetes Engine Default Node Service Account aus.
Klicken Sie auf Speichern.

gcloud

So finden Sie Ihre Google Cloud Projektnummer:
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Die Ausgabe sieht etwa so aus:
```
12345678901
```

Weisen Sie dem Compute Engine-Standarddienstkonto die Rolle roles/container.defaultNodeServiceAccount zu:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

Ersetzen Sie PROJECT_NUMBER durch die Projektnummer aus dem vorherigen Schritt.

Prüfen, ob der Messwert-Agent über genügend Arbeitsspeicher verfügt

Wenn Sie die vorherigen Schritte zur Fehlerbehebung ausprobiert haben und die Messwerte weiterhin nicht angezeigt werden, hat der Messwerte-Agent möglicherweise nicht genügend Arbeitsspeicher.

In den meisten Fällen ist die Standardzuweisung von Ressourcen an den GKE-Messwert-Agent ausreichend. Wenn das DaemonSet jedoch wiederholt abstürzt, können Sie den Grund für die Beendigung mit den folgenden Anweisungen prüfen:

Rufen Sie die Namen der GKE-Messwert-Agent-Pods ab:

kubectl get pods -n kube-system -l component=gke-metrics-agent

Suchen Sie den Pod mit dem Status CrashLoopBackOff.

Die Ausgabe sieht in etwa so aus:

NAME                    READY STATUS           RESTARTS AGE
gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m

Beschreiben Sie den Pod mit dem Status CrashLoopBackOff:
```
kubectl describe pod POD_NAME -n kube-system
```
Ersetzen Sie POD_NAME durch den Namen des Pods aus dem vorherigen Schritt.

Wenn der Beendigungsgrund des Pods OOMKilled lautet, benötigt der Agent zusätzlichen Speicher.

Die Ausgabe sieht in etwa so aus:
```
  containerStatuses:
  ...
  lastState:
    terminated:
      ...
      exitCode: 1
      finishedAt: "2021-11-22T23:36:32Z"
      reason: OOMKilled
      startedAt: "2021-11-22T23:35:54Z"
```
Fügen Sie dem Knoten mit dem fehlerhaften Messwert-Agent ein Knotenlabel hinzu. Sie können entweder ein persistentes oder ein temporäres Knotenlabel verwenden. Wir empfehlen Ihnen, weitere 20 MB hinzuzufügen. Wenn der Agent weiterhin abstürzt, können Sie diesen Befehl noch einmal ausführen. Ersetzen Sie dabei das Knotenlabel durch einen Knoten, der eine größere Menge an zusätzlichen Arbeitsspeicher anfordert.

Führen Sie den folgenden Befehl aus, um einen Knotenpool mit einem nichtflüchtigen Label zu aktualisieren:
```
gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --node-labels=ADDITIONAL_MEMORY_NODE_LABEL \
    --location=COMPUTE_LOCATION
```
Ersetzen Sie dabei Folgendes:
- NODEPOOL_NAME ist der Name des Knotenpools.
- CLUSTER_NAME den Namen des vorhandenen Clusters.
- ADDITIONAL_MEMORY_NODE_LABEL ist eines der zusätzlichen Speicherknotenlabels. Verwenden Sie einen der folgenden Werte:
  - So fügen Sie 10 MB hinzu: cloud.google.com/gke-metrics-agent-scaling-level=10
  - So fügen Sie 20 MB hinzu: cloud.google.com/gke-metrics-agent-scaling-level=20
  - So fügen Sie 50 MB hinzu: cloud.google.com/gke-metrics-agent-scaling-level=50
  - So fügen Sie 100 MB hinzu: cloud.google.com/gke-metrics-agent-scaling-level=100
  - So fügen Sie 200 MB hinzu: cloud.google.com/gke-metrics-agent-scaling-level=200
  - So fügen Sie 500 MB hinzu: cloud.google.com/gke-metrics-agent-scaling-level=500
- COMPUTE_LOCATION: der Compute Engine-Standort des Clusters.
Alternativ können Sie mit dem folgenden Befehl ein temporäres Knotenlabel hinzufügen, das nach einem Upgrade nicht beibehalten wird:
```
kubectl label node/NODE_NAME \
ADDITIONAL_MEMORY_NODE_LABEL --overwrite
```
Ersetzen Sie dabei Folgendes:
- NODE_NAME: der Name des Knotens des betroffenen Messwert-Agents.
- ADDITIONAL_MEMORY_NODE_LABEL: eines der zusätzlichen Speicherknotenlabels. Verwenden Sie einen der Werte aus dem vorherigen Beispiel.

Nächste Schritte

Wenn ein Problem mit dem Cloud Logging-Agent besteht, lesen Sie die Dokumentation zur Fehlerbehebung.
Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen:
- Sie können eine Supportanfrage erstellen, indem Sie sich an den Cloud Customer Care wenden.
- Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen und mit dem Tag google-kubernetes-engine nach ähnlichen Problemen suchen. Sie können auch dem #kubernetes-engine-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten.
- Sie können Fehler melden oder Funktionsanfragen stellen, indem Sie die öffentliche Problemverfolgung verwenden.