Probleme mit der Beobachtbarkeit in Google Distributed Cloud beheben

In diesem Dokument erfahren Sie, wie Sie Probleme mit der Beobachtbarkeit in Google Distributed Cloud beheben. Wenn eines dieser Probleme auftritt, finden Sie hier Vorschläge zur Fehlerbehebung und Problemumgehung.

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

Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören:

Cloud-Audit-Logs werden nicht erfasst

Prüfen Sie, ob Cloud-Audit-Logs im Abschnitt cloudAuditLogging der Clusterkonfiguration aktiviert sind. Prüfen Sie, ob die Projekt-ID, der Speicherort und der Dienstkontoschlüssel richtig konfiguriert sind. Die Projekt-ID muss mit der Projekt-ID unter gkeConnect übereinstimmen.

Wenn Cloud-Audit-Logs aktiviert sind, sind Berechtigungen der häufigste Grund dafür, dass Logs nicht erfasst werden. In diesem Szenario werden Fehlermeldungen zur verweigerten Berechtigung im Proxy-Container für Cloud-Audit-Logs angezeigt.

Der Cloud-Audit-Logs-Proxy-Container wird als einer der folgenden Typen ausgeführt:

  • Als statischer Pod im Administrator- oder eigenständigen Cluster.
  • Als Sidecar-Container im kube-apiserver-Pod

Wenn Berechtigungsfehler angezeigt werden, folgen Sie der Anleitung zur Fehlerbehebung und Behebung von Berechtigungsproblemen.

Eine weitere mögliche Ursache ist, dass Ihr Projekt das unterstützte Dienstkontolimit erreicht hat. Weitere Informationen finden Sie unter Cloud Audit Logs-Dienstkonto ist durchgesickert.

kube-state-metrics-Messwerte werden nicht erfasst

kube-state-metrics (KSM) läuft als eine einzige Replikatbereitstellung im Cluster und generiert Messwerte für fast alle Ressourcen im Cluster. Wenn KSM und der gke-metrics-agent auf demselben Knoten ausgeführt werden, besteht ein größeres Risiko eines Ausfalls der Messwert-Agents auf allen Knoten.

Die Namen von KSM-Messwerten entsprechen dem Muster kube_<ResourceKind>, z. B. kube_pod_container_info. Messwerte, die mit kube_onpremusercluster_ beginnen, stammen vom lokalen Clustercontroller und nicht von KSM.

Wenn KSM-Messwerte fehlen, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

  • Prüfen Sie in Cloud Monitoring die CPU-, Arbeitsspeicher- und Neustartanzahl von KSM mit der Zusammenfassung der API-Messwerte wie kubernetes.io/anthos/container/.... Dies ist eine separate Pipeline mit KSM. Prüfen Sie, ob der KSM-Pod nicht durch unzureichende Ressourcen eingeschränkt ist.
    • Wenn diese API-Zusammenfassungsmesswerte für KSM nicht verfügbar sind, tritt das Problem wahrscheinlich auch auf gke-metrics-agent auf demselben Knoten auf.
  • Prüfen Sie im Cluster den Status und die Logs des KSM-Pods und des gke-metrics-agent-Pods auf demselben Knoten mit KSM.

kube-state-metrics-Absturzschleife

Symptom

In Cloud Monitoring sind keine Messwerte von kube-state-metrics (KSM) verfügbar.

Ursache

Dieses Szenario tritt eher in großen Clustern oder Clustern mit vielen Ressourcen auf. KSM wird als einzelnes Replikat-Deployment ausgeführt und listet fast alle Ressourcen im Cluster auf, z. B. Pods, Deployments, DaemonSets, ConfigMaps, Secrets und PersistentVolumes. Für jedes dieser Ressourcen-Objekte werden Messwerte generiert. Wenn eine der Ressourcen viele Objekte hat, z. B. einen Cluster mit über 10.000 Pods, geht KSM möglicherweise der Arbeitsspeicher aus.

Betroffene Versionen

Dieses Problem kann bei jeder Version von Google Distributed Cloud auftreten.

Das Standard-Limit für CPU und Arbeitsspeicher wurde in den letzten Versionen von Google Distributed Cloud erhöht, sodass diese Ressourcenprobleme seltener auftreten sollten.

Problembehebung und Behelfslösung

So prüfen Sie, ob das Problem auf zu wenig Arbeitsspeicher zurückzuführen ist:

  • Verwenden Sie kubectl describe pod oder kubectl get pod -o yaml und überprüfen Sie die Fehler-Statusmitteilung.
  • Prüfen Sie den Messwert für den Arbeitsspeicherverbrauch und die Auslastung von KSM und achten Sie darauf, dass er das Limit erreicht, bevor er neu gestartet wird.

Wenn Sie feststellen, dass Probleme mit zu wenig Arbeitsspeicher das Problem sind, verwenden Sie eine der folgenden Lösungen:

  • Erhöhen Sie die Arbeitsspeicheranfrage und das Limit für KSM.

    So passen Sie die CPU und den Arbeitsspeicher von KSM an:

    • Bei Google Distributed Cloud-Versionen 1.16.0 oder höher wird KSM von Google Cloud Observability verwaltet. Informationen zum Aktualisieren von KSM finden Sie unter Standardmäßige CPU- und Speicheranforderungen und Limits für eine Stackdriver-Komponente überschreiben.

    • Erstellen Sie für Google Distributed Cloud-Versionen 1.10.7 oder höher, 1.11.3 oder höher, 1.12.2 oder höher und 1.13 oder höher, aber niedriger als 1.16.0, eine ConfigMap, um die CPU und den Arbeitsspeicher anzupassen:

      1. Erstellen Sie eine ConfigMap mit dem Namen kube-state-metrics-resizer-config im Namespace kube-system (gke-managed-metrics-server für Version 1.13 oder höher) mit der folgenden Definition. Passen Sie die Werte für CPUs und den Arbeitsspeicher nach Bedarf an:

          apiVersion: v1
  kind: ConfigMap
  metadata:
    name: kube-state-metrics-resizer-config
    namespace: kube-system
  data:
    NannyConfiguration: |-
      apiVersion: nannyconfig/v1alpha1
      kind: NannyConfiguration
      baseCPU: 200m
      baseMemory: 1Gi
      cpuPerNode: 3m
      memoryPerNode: 20Mi
  ```

      2. Nachdem Sie die ConfigMap erstellt haben, starten Sie das KSM-Deployment neu, indem Sie den KSM-Pod mit dem folgenden Befehl löschen:

        kubectl -n kube-system rollout restart deployment kube-state-metrics

    • Bei Google Distributed Cloud-Versionen 1.9 und niedriger, 1.10.6 und niedriger, 1.11.2 und niedriger sowie 1.12.1 und niedriger:

      • Keine gute langfristige Lösung: Wenn Sie die KSM-bezogene Ressource bearbeiten, werden die Änderungen von monitoring-operator automatisch rückgängig gemacht.
      • Sie können monitoring-operator auf 0 Replikate herunterskalieren und dann das KSM-Deployment bearbeiten, um das Ressourcenlimit anzupassen. Der Cluster erhält jedoch keine Sicherheits-Patches, die über neue Patch-Releases mit monitoring-operator bereitgestellt werden. Denken Sie daran, monitoring-operator wieder hochzuskalieren, nachdem der Cluster mit der Fehlerbehebung auf eine neuere Version aktualisiert wurde.

  • Reduzieren Sie die Anzahl der Messwerte aus KSM.

    Für Google Distributed Cloud 1.13 stellt KSM standardmäßig nur eine kleinere Anzahl von Messwerten, die wichtigsten Messwerte, zur Verfügung. Dadurch ist die Ressourcennutzung geringer als bei früheren Versionen. Sie können jedoch dasselbe Verfahren anwenden, um die Anzahl der KSM-Messwerte weiter zu reduzieren.

    Für Google Distributed Cloud-Versionen vor 1.13 verwendet KSM die Standard-Flags. Diese Konfiguration stellt eine große Anzahl an Messwerten bereit.

gke-metrics-agent-Absturzschleife

Wenn bei gke-metrics-agent nur Probleme mit unzureichendem Arbeitsspeicher auf dem Knoten auftreten, auf dem kube-state-metrics existiert, ist die Ursache eine große Anzahl von kube-state-metrics-Messwerten. Um dieses Problem zu beheben, skalieren Sie stackdriver-operator herunter und ändern Sie KSM zur Bereitstellung einiger erforderlicher Messwerte, wie im vorherigen Abschnitt beschrieben. Denken Sie daran, stackdriver-operator wieder hochzuskalieren, nachdem der Cluster auf Google Distributed Cloud 1.13 aktualisiert wurde, wo KSM standardmäßig eine geringere Anzahl von Kernmesswerten bereitstellt.

Prüfen Sie bei Problemen, die nicht im Zusammenhang mit Ereignissen mit unzureichendem Arbeitsspeicher stehen, die Pod-Logs von gke-metric-agent. Sie können CPU und Arbeitsspeicher für alle gke-metrics-agent-Pods durch Hinzufügen des Felds resourceAttrOverride zur benutzerdefinierten Stackdriver-Ressource anpassen.

stackdriver-metadata-agent-Absturzschleife

Symptom

Beim Filtern von Messwerten in Cloud Monitoring ist kein Systemmetadatenlabel verfügbar.

Ursache

Die häufigste Ursache von stackdriver-metadata-agent-Absturzschleifen ist zu wenig Arbeitsspeicher. Dieses Ereignis ähnelt kube-state-metrics. Obwohl stackdriver-metadata-agent nicht alle Ressourcen auflistet, listet es dennoch alle Objekte für die relevanten Ressourcentypen wie Pods, Bereitstellungen und NetworkPolicy auf. Der Agent wird als einzelne Replikat-Bereitstellung ausgeführt, was das Risiko von Speicherproblemen erhöht, wenn die Anzahl der Objekte zu groß ist.

Betroffene Version

Dieses Problem kann bei jeder Version von Google Distributed Cloud auftreten.

Das Standard-Limit für CPU und Arbeitsspeicher wurde in den letzten Versionen von Google Distributed Cloud erhöht, sodass diese Ressourcenprobleme seltener auftreten sollten.

Problembehebung und Behelfslösung

So prüfen Sie, ob das Problem auf zu wenig Arbeitsspeicher zurückzuführen ist:

  • Verwenden Sie kubectl describe pod oder kubectl get pod -o yaml und überprüfen Sie die Fehler-Statusmitteilung.
  • Prüfen Sie den Messwert für den Arbeitsspeicherverbrauch und die Auslastung von stackdriver-metadata-agent und stellen Sie sicher, dass er das Limit erreicht, bevor er neu gestartet wird.
. Wenn Sie feststellen, dass Probleme aufgrund von unzureichendem Arbeitsspeicher zu Problemen führen, erhöhen Sie das Arbeitsspeicherlimit im Feld resourceAttrOverride der benutzerdefinierten Stackdriver-Ressource.

metrics-server-Absturzschleife

Symptom

Der horizontale Pod-Autoscaler und kubectl top funktionieren in Ihrem Cluster nicht.

Ursache und betroffene Versionen

Dieses Problem ist nicht sehr häufig, wird aber durch Fehler aufgrund von unzureichendem Arbeitsspeicher in großen Clustern oder in Clustern mit hoher Pod-Dichte verursacht.

Dieses Problem kann bei jeder Version von Google Distributed Cloud auftreten.

Problembehebung und Behelfslösung

Erhöhen Sie die Ressourcenlimits des Messwertservers. In Google Distributed Cloud Version 1.13 und höher wurden der Namespace von metrics-server und seine Konfiguration von kube-system nach gke-managed-metrics-server verschoben.

Nicht alle Ressourcen werden beim Löschen von Dienstkonten für Cloud-Audit-Logs entfernt

Wenn Sie ein Dienstkonto löschen, das für Cloud-Audit-Logs verwendet wird, werden nicht alle Google Cloud-Ressourcen gelöscht. Wenn Sie Dienstkonten, die für Cloud-Audit-Logs verwendet werden, regelmäßig löschen und neu erstellen, schlägt das Audit-Logging irgendwann fehl.

Symptom

Fehlermeldungen zur verweigerten Berechtigung werden im Proxy-Container für Cloud-Audit-Logs angezeigt.

Führen Sie den folgenden Befehl aus, um zu bestätigen, dass der Audit-Log-Fehler durch dieses Problem verursacht wird:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging

Ersetzen Sie PROJECT_NUMBER durch die Projekt-ID.

In der Antwort werden alle Dienstkonten zurückgegeben, die mit Cloud-Audit-Logs im Projekt verwendet werden, einschließlich der Dienstkonten, die gelöscht wurden.

Ursache und betroffene Versionen

Nicht alle Google Cloud Ressourcen werden entfernt, wenn Sie ein für Cloud-Audit-Logs verwendetes Dienstkonto löschen. Irgendwann erreichen Sie das Limit von 1.000 Dienstkonten für das Projekt.

Dieses Problem kann bei jeder Version von Google Distributed Cloud auftreten.

Problembehebung und Behelfslösung

  1. Erstellen Sie eine Umgebungsvariable, die eine kommagetrennte Liste aller Dienstkonten enthält, die Sie behalten möchten. Setzen Sie die E-Mail-Adresse jedes Dienstkontos in einfache Anführungszeichen und die gesamte Liste in doppelte Anführungszeichen. Sie können die folgenden Informationen als Ausgangspunkt verwenden:

    SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Ihre Projekt-ID.
    • SERVICE_ACCOUNT_NAME: der Name des Dienstkontos

    Die fertige Liste sollte in etwa so aussehen:

    "'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"

  2. Führen Sie den folgenden Befehl aus, um die Funktion „Cloud-Audit-Logs“ aus dem Projekt zu entfernen:

    curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging

    Ersetzen Sie Folgendes:

    • PROJECT_NUMBER: die Projektnummer
    • FLEET_REGION: Der Standort der Flottenmitgliedschaft für Ihre Cluster. Das kann eine bestimmte Region wie us-central1 oder global sein. Sie können den Befehl gcloud container fleet memberships list ausführen, um den Standort der Mitgliedschaft abzurufen.

    Mit diesem Befehl werden alle Dienstkonten vollständig gelöscht.

  3. Erstellen Sie die Cloud-Audit-Logs-Funktion mit nur den Dienstkonten neu, die Sie behalten möchten:

    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \
    -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'

Metadatenlabels verschwinden aus Messwerten

Symptom

Metadatenlabels wie „node_name“ werden in Cloud Monitoring nicht ausgefüllt.

Ursache und betroffene Versionen

Dieses Problem kann bei jeder Version von Google Distributed Cloud auftreten.

Problembehebung und Behelfslösung

Durch Änderungen am Pod werden die Metadaten-Labels wieder angezeigt. Beispielsweise durch Ausführen von Befehlen wie kubectl rollout restart deployment <workload_name>.

Nächste Schritte

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

Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören: