Probleme mit der Beobachtbarkeit in Google Distributed Cloud beheben

Wenn Sie fehlende Audit-Logs, Messwerte oder Metadatenlabels in Google Distributed Cloud-Clustern wiederherstellen möchten, können Sie die folgenden Lösungen für häufige Beobachtbarkeitsprobleme verwenden. Die meisten dieser Probleme werden durch Berechtigungsfehler oder durch Abstürze aufgrund von unzureichendem Arbeitsspeicher in Komponenten wie kube-state-metrics in großen Clustern verursacht. Einige Probleme wirken sich auch auf das horizontale Pod-Autoscaling und kubectl top aus.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care. Weitere Informationen zu Supportressourcen finden Sie unter Support erhalten. Dazu gehören:

  • Anforderungen für das Erstellen einer Supportanfrage.
  • Tools zur Fehlerbehebung, z. B. Umgebungskonfiguration, Logs und Messwerte.
  • Unterstützte Komponenten.

Cloud-Audit-Logs werden nicht erfasst

Cloud-Audit-Logs sind standardmäßig aktiviert, sofern im Abschnitt clusterOperations der Clusterkonfiguration nicht das Flag disableCloudAuditLogging festgelegt ist.

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 in allen Google Distributed Cloud-Clustern als DaemonSet ausgeführt.

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

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

kube-state-metrics-Messwerte werden nicht erfasst

kube-state-metrics (KSM) wird als einzelnes Replikat-Deployment im Cluster ausgeführt 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.

  • 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.

Bei Google Distributed Cloud wird die Bearbeitung der Nanny-Konfiguration im Falle eines Clusterupdates oder -upgrades rückgängig gemacht. In diesem Fall müssen Sie Ihre Konfigurationsänderungen erneut vornehmen. Um diese Einschränkung zu umgehen, skalieren Sie metrics-server-operator herunter und ändern Sie den metrics-server-Pod manuell.

Nicht alle Ressourcen werden beim Löschen des Cloud-Audit-Logs-Dienstkontos 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 auf dieses Problem zurückzuführen ist:

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.

Die Antwort enthält alle Dienstkonten, die mit Cloud-Audit-Logs im Projekt verwendet werden, einschließlich gelöschter Dienstkonten.

Ursache und betroffene Versionen

Wenn Sie ein Dienstkonto löschen, das für Cloud-Audit-Logs verwendet wird, werden nicht alle Google Cloud -Ressourcen entfernt. 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 mit einer durch Kommas getrennten Liste aller Dienstkonten, die Sie beibehalten möchten. Setzen Sie jede Dienstkonto-E-Mail-Adresse in einfache Anführungszeichen und die gesamte Liste in doppelte Anführungszeichen. Sie können die folgenden 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 das Cloud-Audit-Logs-Feature 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. Dies 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 das Cloud-Audit-Logs-Feature nur mit 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, z. B. 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

Bei Änderungen am Pod werden die Metadatenlabels wiederhergestellt. 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 erhalten. Dazu gehören:

  • Anforderungen für das Erstellen einer Supportanfrage.
  • Tools zur Fehlerbehebung, z. B. Umgebungskonfiguration, Logs und Messwerte.
  • Unterstützte Komponenten.