Probleme mit der Beobachtbarkeit von GKE on Bare Metal beheben

In diesem Dokument erfahren Sie, wie Sie Probleme mit der Beobachtbarkeit in GKE on Bare Metal beheben. Wenn eines dieser Probleme auftritt, lesen Sie die Vorschläge zur Fehlerbehebung und Problemumgehung.

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 das Flag disableCloudAuditLogging 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 zu abgelehnten Berechtigungen im Proxy-Container von Cloud-Audit-Logs angezeigt.

Der Proxy-Container für Cloud-Audit-Logs wird als DaemonSet in allen GKE on Bare Metal-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-Deployment 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 von 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 aus dem lokalen Clustercontroller und nicht aus KSM.

Wenn KSM-Messwerte fehlen, prüfen Sie die folgenden Schritte zur Fehlerbehebung:

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

Absturzschleife von kube-state-metrics

Symptom

Von Cloud Monitoring sind keine Messwerte von kube-state-metrics (KSM) 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 PersistentVolumes auf. Für jedes dieser Ressourcenobjekte werden Messwerte generiert. Wenn eine der Ressourcen viele Objekte enthält, z. B. ein Cluster mit über 10.000 Pods, geht KSM möglicherweise nicht mehr der Arbeitsspeicher aus.

Betroffene Versionen

Dieses Problem kann in jeder Version von GKE on Bare Metal auftreten.

Das Standardlimit für CPU und Arbeitsspeicher wurde in den letzten GKE on Bare Metal-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 Probleme mit unzureichendem 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 Arbeitsspeicherverbrauch und -auslastung für KSM und bestätigen Sie vor dem Neustart, ob das Limit erreicht wird.

Wenn Sie sicher sind, dass das Problem durch nicht genügend Arbeitsspeicher verursacht wird, verwenden Sie eine der folgenden Lösungen:

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

    Verwenden Sie zum Anpassen von CPU und Arbeitsspeicher von KSM die resourceOverride der benutzerdefinierten Stackdriver-Ressource für kube-state-metrics.

  • Reduzieren Sie die Anzahl der Messwerte aus KSM.

    Für GKE on Bare Metal 1.13 stellt KSM standardmäßig nur eine kleinere Anzahl von Messwerten zur Verfügung, die als Core Metrics bezeichnet werden. Dieses Verhalten bedeutet, dass die Ressourcennutzung geringer als in früheren Versionen ist, aber mit dem gleichen Verfahren die Anzahl der KSM-Messwerte weiter reduziert werden kann.

    Für GKE on Bare Metal-Versionen vor 1.13 verwendet KSM die Standard-Flags. Diese Konfiguration stellt eine große Anzahl von Messwerten bereit.

Absturzschleife von gke-metrics-agent

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. Sie können dieses Problem beheben, indem Sie stackdriver-operator herunterskalieren und KSM so ändern, dass eine kleine Gruppe von erforderlichen Messwerten verfügbar gemacht wird, wie im vorherigen Abschnitt beschrieben. Denken Sie daran, stackdriver-operator hochzuskalieren, nachdem der Cluster auf GKE on Bare Metal 1.13 aktualisiert wurde, wobei KSM standardmäßig eine kleinere Anzahl von Kernmesswerten bereitstellt.

Prüfen Sie bei Problemen, die nicht mit Ereignissen mit unzureichendem Arbeitsspeicher zusammenhängen, die Pod-Logs von gke-metric-agent. Sie können die CPU und den Arbeitsspeicher für alle gke-metrics-agent-Pods anpassen. Fügen Sie dazu der benutzerdefinierten Stackdriver-Ressource das Feld resourceAttrOverride hinzu.

Absturzschleife von stackdriver-metadata-agent

Symptom

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

Ursache

Der häufigste Fall von stackdriver-metadata-agent-Absturzschleifen ist auf Ereignisse mit unzureichendem Arbeitsspeicher zurückzuführen. Dieses Ereignis ähnelt kube-state-metrics. Obwohl stackdriver-metadata-agent nicht alle Ressourcen auflistet, werden trotzdem alle Objekte für die relevanten Ressourcentypen wie Pods, Deployments und NetworkPolicy aufgelistet. Der Agent wird als ein einziges Replikat-Deployment 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 in jeder Version von GKE on Bare Metal auftreten.

Das Standardlimit für CPU und Arbeitsspeicher wurde in den letzten GKE on Bare Metal-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 Probleme mit unzureichendem Arbeitsspeicher zurückzuführen ist:

  • Verwenden Sie kubectl describe pod oder kubectl get pod -o yaml und prüfen Sie die Statusmeldung des Fehlers.
  • Prüfen Sie den Messwert für Arbeitsspeicherverbrauch und -auslastung für stackdriver-metadata-agent und prüfen Sie, ob das Limit erreicht wird, bevor Sie neu starten.
Wenn Sie sich vergewissert haben, dass Probleme aufgrund fehlenden Arbeitsspeichers zu Problemen führen, erhöhen Sie das Arbeitsspeicherlimit im Feld resourceAttrOverride der benutzerdefinierten Stackdriver-Ressource.

Absturzschleife von metrics-server

Symptom

Horizontales Pod-Autoscaling und kubectl top funktionieren in Ihrem Cluster nicht.

Ursache und betroffene Versionen

Dieses Problem tritt nicht sehr häufig auf, wird aber durch Fehler aufgrund fehlenden Arbeitsspeichers in großen Clustern oder Clustern mit hoher Pod-Dichte verursacht.

Dieses Problem kann in jeder Version von GKE on Bare Metal auftreten.

Problembehebung und Behelfslösung

Serverressourcenlimits für Messwerte erhöhen: In GKE on Bare Metal Version 1.13 und höher wurden der Namespace von metrics-server und dessen Konfiguration von kube-system nach gke-managed-metrics-server verschoben.

Bei GKE on Bare Metal wird das Bearbeiten der Nanny-Konfiguration bei einem Clusterupdate oder -upgrade rückgängig gemacht. In diesem Fall müssen Sie die Konfigurationsänderungen noch einmal anwenden. Sie können diese Einschränkung umgehen, indem Sie metrics-server-operator herunterskalieren und den Pod metrics-server manuell ändern.

Nächste Schritte

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