Probleme mit der Beobachtbarkeit von GKE on Bare Metal beheben

Dieses Dokument hilft Ihnen bei der Behebung von Beobachtbarkeitsproblemen in Google Distributed Cloud Virtual for Bare Metal. Wenn eines dieser Probleme auftritt, sehen Sie sich die Vorschläge zur Fehlerbehebung und Problemumgehung 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 das Flag disableCloudAuditLogging festgelegt.

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

Der Cloud-Audit-Logs-Proxy-Container wird als DaemonSet in allen Google Distributed Cloud Virtual for 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 Bereitstellung mit einem einzelnen 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 größeres Ausfallrisiko für 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 Cluster-Controller und nicht von KSM.

Wenn KSM-Messwerte fehlen, lesen 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 nicht genügend Ressourcen eingeschränkt ist.
    • Wenn diese zusammenfassenden API-Messwerte für KSM nicht verfügbar sind, tritt das Problem bei gke-metrics-agent auf demselben Knoten wahrscheinlich ebenfalls 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.

Absturzschleife von kube-state-metrics

Symptom

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

Ursache

Dieses Szenario tritt eher bei 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 Speicher auf. Für jedes dieser Ressourcenobjekte werden Messwerte generiert. Wenn eine der Ressourcen viele Objekte hat, z. B. ein Cluster mit mehr als 10.000 Pods, geht KSM möglicherweise nicht genügend Arbeitsspeicher aus.

Betroffene Versionen

Dieses Problem kann bei jeder Version von Google Distributed Cloud Virtual for Bare Metal auftreten.

Das CPU- und Arbeitsspeicherlimit wurden in den letzten Versionen von Google Distributed Cloud Virtual for Bare Metal erhöht, sodass diese Ressourcenprobleme seltener auftreten.

Problembehebung und Behelfslösung

So prüfen Sie, 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 prüfen Sie vor dem Neustart, ob das Limit erreicht wird.

Wenn Sie feststellen, dass Probleme mit unzureichendem Arbeitsspeicher vorliegen, verwenden Sie eine der folgenden Lösungen:

  • Erhöhen Sie die Arbeitsspeicheranfrage 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.

    Bei Google Distributed Cloud Virtual for Bare Metal 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 in früheren Versionen. Sie können jedoch mit demselben Verfahren die Anzahl der KSM-Messwerte weiter reduzieren.

    Für Versionen von Google Distributed Cloud Virtual for Bare Metal 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 auf dem Knoten, auf dem kube-state-metrics vorhanden ist, Probleme mit unzureichendem Arbeitsspeicher auftreten, liegt dies an einer großen Anzahl von kube-state-metrics-Messwerten. Sie können dieses Problem umgehen, indem Sie stackdriver-operator herunterskalieren und KSM ändern, um eine kleine Anzahl von erforderlichen Messwerten verfügbar zu machen, wie im vorherigen Abschnitt beschrieben. Denken Sie daran, stackdriver-operator hochzuskalieren, nachdem der Cluster auf Google Distributed Cloud Virtual for Bare Metal 1.13 aktualisiert wurde, wobei KSM standardmäßig eine kleinere 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 anpassen. Fügen Sie dazu das Feld resourceAttrOverride der benutzerdefinierten Stackdriver-Ressource 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 Bereitstellung mit einem einzelnen 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 Virtual for Bare Metal auftreten.

Das CPU- und Arbeitsspeicherlimit wurde in den letzten Versionen von Google Distributed Cloud Virtual for Bare Metal erhöht, sodass diese Ressourcenprobleme seltener auftreten.

Problembehebung und Behelfslösung

So prüfen Sie, 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 Fehlerstatusmeldung.
  • Prüfen Sie den Messwert für Arbeitsspeichernutzung und -auslastung für stackdriver-metadata-agent und prüfen Sie, ob das Limit erreicht ist, bevor Sie neu starten.
Wenn Sie feststellen, dass Probleme durch unzureichenden Arbeitsspeicher 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 jedoch durch Fehler aufgrund fehlenden Arbeitsspeichers in großen Clustern oder Clustern mit hoher Pod-Dichte verursacht.

Dieses Problem kann bei jeder Version von Google Distributed Cloud Virtual for Bare Metal auftreten.

Problembehebung und Behelfslösung

Erhöhen Sie die Ressourcenlimits des Messwertservers. In Google Distributed Cloud Virtual for Bare Metal 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 Virtual for Bare Metal würde das Bearbeiten der Nanny-Konfiguration bei einem Cluster-Update oder ‐Upgrade rückgängig gemacht werden. Sie müssen die Konfigurationsänderungen noch einmal anwenden. Sie können diese Einschränkung umgehen, indem Sie metrics-server-operator herunterskalieren und den metrics-server-Pod manuell ändern.

Nächste Schritte

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