Probleme mit der Beobachtbarkeit von 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, sehen Sie sich die vorgeschlagenen Lösungen und Behelfslösungen an.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Google-Support.

Cloud-Audit-Logs werden nicht erfasst

Cloud-Audit-Logs sind standardmäßig aktiviert, es sei denn, im Abschnitt clusterOperations der Clusterkonfiguration ist ein disableCloudAuditLogging-Flag festgelegt.

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

Der Cloud-Audit-Log-Proxy-Container wird als DaemonSet in allen Google Distributed Cloud-Clustern ausgeführt.

Wenn Berechtigungsfehler angezeigt werden, folgen Sie der Anleitung zum Beheben von Berechtigungsproblemen.

kube-state-metrics Messwerte werden nicht erfasst

kube-state-metrics (KSM) wird als einzelnes Replikat im Cluster ausgeführt und generiert Messwerte für fast alle Ressourcen im Cluster. Wenn KSM und gke-metrics-agent auf demselben Knoten ausgeführt werden, besteht ein höheres Ausfallrisiko der Messwert-Agents auf allen Knoten.

Die Namen von KSM-Messwerten folgen dem Muster kube_<ResourceKind>, z. B. kube_pod_container_info. Messwerte, die mit kube_onpremusercluster_ beginnen, stammen vom lokalen Cluster-Controller 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 mithilfe der zusammenfassenden API-Messwerte wie kubernetes.io/anthos/container/... . Dies ist eine separate Pipeline mit KSM. Prüfen Sie, ob der KSM-Pod nicht durch nicht genügend Ressourcen eingeschränkt ist.
    • Wenn diese zusammenfassenden API-Messwerte für KSM nicht verfügbar sind, tritt wahrscheinlich auch gke-metrics-agent auf demselben Knoten auf.
  • Prüfen Sie im Cluster den Status und die Logs des KSM-Pods und des Pods gke-metrics-agent auf demselben Knoten mit KSM.

kube-state-metrics Absturzschleife

Symptom

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

Ursache

Dieses Szenario tritt eher in großen Clustern oder Clustern mit großen Ressourcenmengen auf. KSM wird als Deployment mit einem einzelnen Replikat ausgeführt und listet fast alle Ressourcen im Cluster wie Pods, Deployments, DaemonSets, ConfigMaps, Secrets und nichtflüchtige Volumes auf. Messwerte werden für jedes dieser Ressourcenobjekte generiert. Wenn eine der Ressourcen viele Objekte enthält, z. B. ein Cluster mit über 10.000 Pods, hat KSM möglicherweise nicht mehr genügend Arbeitsspeicher.

Betroffene Versionen

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

Das Standard-CPU- und Arbeitsspeicherlimit wurde in den letzten Google Distributed Cloud-Versionen erhöht, sodass diese Ressourcenprobleme weniger häufig auftreten.

Problembehebung und Behelfslösung

Prüfen Sie mit den folgenden Schritten, ob das Problem auf unzureichenden Arbeitsspeicher zurückzuführen ist:

  • Verwenden Sie kubectl describe pod oder kubectl get pod -o yaml und prüfen Sie die Fehlermeldung.
  • Prüfen Sie den Messwert für Arbeitsspeichernutzung und -auslastung für KSM und bestätigen Sie, ob das Limit erreicht ist, bevor Sie neu starten.

Wenn Sie feststellen, dass das Problem mit unzureichendem Arbeitsspeicher zusammenhängt, verwenden Sie eine der folgenden Lösungen:

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

    Wenn Sie die CPU und den Arbeitsspeicher von KSM anpassen möchten, verwenden Sie resourceOverride der benutzerdefinierten Stackdriver-Ressource für kube-state-metrics.

  • Reduzieren Sie die Anzahl der Messwerte von KSM.

    Bei Google Distributed Cloud 1.13 stellt KSM standardmäßig nur eine kleinere Anzahl von Messwerten bereit, die als Core Metrics bezeichnet werden. Dieses Verhalten bedeutet, dass die Ressourcennutzung geringer ist als bei früheren Versionen. Sie können aber dieselbe Vorgehensweise verwenden, um die Anzahl der KSM-Messwerte weiter zu reduzieren.

    In Google Distributed Cloud-Versionen vor 1.13 verwendet KSM die Standard-Flags. Diese Konfiguration stellt eine große Anzahl von Messwerten zur Verfügung.

gke-metrics-agent Absturzschleife

Wenn bei gke-metrics-agent nur Probleme mit unzureichendem Arbeitsspeicher auf dem Knoten auftreten, auf dem kube-state-metrics vorhanden ist, liegt dies an einer großen Anzahl von kube-state-metrics-Messwerten. Skalieren Sie stackdriver-operator herunter und ändern Sie KSM, um dieses Problem zu beheben, um einen kleinen Satz erforderlicher Messwerte bereitzustellen, wie im vorherigen Abschnitt beschrieben. Denken Sie daran, stackdriver-operator nach dem Upgrade des Clusters auf Google Distributed Cloud 1.13 hochzuskalieren, wobei KSM standardmäßig eine kleinere Anzahl von Kernmesswerten bereitstellt.

Prüfen Sie bei Problemen, die nicht auf Ereignisse mit unzureichendem Arbeitsspeicher zurückzuführen sind, die Pod-Logs von gke-metric-agent. Sie können CPU und Arbeitsspeicher für alle gke-metrics-agent-Pods anpassen, indem Sie der benutzerdefinierten Stackdriver-Ressource das Feld resourceAttrOverride hinzufügen.

stackdriver-metadata-agent Absturzschleife

Symptom

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

Ursache

Der häufigste Fall von stackdriver-metadata-agent-Absturzschleifen ist aufgrund von nicht genügend Arbeitsspeicher. Dieses Ereignis ähnelt kube-state-metrics. stackdriver-metadata-agent listet zwar nicht alle Ressourcen auf, aber trotzdem alle Objekte für die relevanten Ressourcentypen wie Pods, Deployments und NetworkPolicy. Der Agent wird als Deployment mit nur einem Replikat ausgeführt. Dadurch erhöht sich das Risiko von Ereignissen mit unzureichendem Arbeitsspeicher, wenn die Anzahl der Objekte zu groß ist.

Betroffene Version

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

Das Standard-CPU- und Arbeitsspeicherlimit wurde in den letzten Google Distributed Cloud-Versionen erhöht, sodass diese Ressourcenprobleme weniger häufig auftreten.

Problembehebung und Behelfslösung

Prüfen Sie mit den folgenden Schritten, ob das Problem auf unzureichenden Arbeitsspeicher zurückzuführen ist:

  • Verwenden Sie kubectl describe pod oder kubectl get pod -o yaml und prüfen Sie die Fehlermeldung.
  • Prüfen Sie den Messwert für Arbeitsspeichernutzung und Auslastung für stackdriver-metadata-agent und bestätigen Sie, ob das Limit erreicht ist, bevor Sie neu starten.
Wenn Sie feststellen, dass Probleme mit unzureichendem Arbeitsspeicher die Ursache für Probleme sind, erhöhen Sie das Arbeitsspeicherlimit im Feld resourceAttrOverride der benutzerdefinierten Stackdriver-Ressource.

metrics-server Absturzschleife

Symptom

Horizontales Pod-Autoscaling 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 Serverressourcenlimits für Messwerte. 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 bei einem Clusterupdate oder ‐upgrade rückgängig gemacht. In diesem Fall müssen Sie die Konfigurationsänderungen noch einmal anwenden. Skalieren Sie metrics-server-operator herunter und ändern Sie den Pod metrics-server manuell, um diese Einschränkung zu umgehen.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Google-Support.