Fehlerbehebung bei Systemmesswerten


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

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

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 der Google Cloud Console aufrufen 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-Befehlszeilentool 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 wie im 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 setzt diese Kommunikation voraus. 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.

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

Wenn Sie die oben genannten Schritte zur Fehlerbehebung ausprobiert haben und die Messwerte immer noch nicht angezeigt werden, hat der Messwert-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:

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

    kubectl get pods -n kube-system -l component=gke-metrics-agent
    
  2. 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
    
  3. 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"
    
  4. 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