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

Prüfen Sie, ob Cloud-Audit-Logs im Abschnitt cloudAuditLogging der Clusterkonfiguration aktiviert sind. Prüfen Sie, ob die Projekt-ID, der Standort 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 über verweigerte Berechtigungen im Cloud-Audit-Logs-Proxy-Container angezeigt.

Der Cloud-Audit-Log-Proxy-Container wird so ausgeführt:

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

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.

  Hinweis: Selbst wenn KSM nach Erhöhung der Ressource stabil wird, kann der gke-metrics-agent auf demselben Knoten ein Engpass beim Ausschleusen großer Mengen von Messwerten aus KSM bleiben.

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

  1. Für Google Distributed Cloud-Versionen 1.9 und niedriger, 1.10.6 oder niedriger, 1.11.2 oder früher sowie 1.12.1 oder niedriger:

     1. Keine gute langfristige Lösung. Wenn Sie die KSM-bezogene Ressource bearbeiten, werden Änderungen automatisch von monitoring-operator rückgängig gemacht.

     2. 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 Patches für Sicherheitslücken, die von neuen Patchreleases mit monitoring-operator bereitgestellt werden.

        Denken Sie daran, monitoring-operator wieder hochzuskalieren, nachdem der Cluster auf eine neuere Version mit Fehlerkorrektur aktualisiert wurde.

  2. 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 und höher eine ConfigMap mit dem Namen kube-state-metrics-resizer-config im Namespace kube-system (gke-managed-metrics-server für 1.13 oder höher) mit der folgenden Definition. Passen Sie die CPU- und Speichernummern wie gewünscht 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
     

     1. Starten Sie nach dem Erstellen der ConfigMap das KSM-Deployment neu. Löschen Sie dazu den KSM-Pod mit dem folgenden Befehl:

          kubectl -n kube-system rollout restart deployment 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.

Nächste Schritte

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