Beobachtbarkeitsprobleme von GKE on VMware beheben

Dieses Dokument hilft Ihnen, Beobachtbarkeitsprobleme in Google Distributed Cloud Virtual for VMware zu beheben. 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

Prüfen Sie, ob im Abschnitt cloudAuditLogging der Clusterkonfiguration Cloud-Audit-Logs aktiviert sind. Prüfen Sie, ob Projekt-ID, Standort und Dienstkontoschlüssel korrekt 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, warum Logs nicht erfasst werden. In diesem Szenario werden Fehlermeldungen über verweigerte Berechtigungen im Proxy-Container von Cloud-Audit-Logs angezeigt.

Der Proxy-Container für Cloud-Audit-Logs wird folgendermaßen ausgeführt:

  • Ein statischer Pod im Administratorcluster oder im 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 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 für VMware auftreten.

Das Standard-CPU- und Arbeitsspeicherlimit wurde in den letzten Versionen von Google Distributed Cloud Virtual for VMware 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.

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

    1. Für Google Distributed Cloud Virtual for VMware Version 1.9 und niedriger, 1.10.6 oder niedriger, 1.11.2 oder niedriger und 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 durch neue 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 Virtual for VMware 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 Speicherzahlen nach Bedarf 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 die KSM-Bereitstellung 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 aus KSM.

    Bei Google Distributed Cloud Virtual für VMware 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 VMware 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 für VMware 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 für VMware auftreten.

Das Standard-CPU- und Arbeitsspeicherlimit wurde in den letzten Versionen von Google Distributed Cloud Virtual für VMware 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 für VMware auftreten.

Problembehebung und Behelfslösung

Erhöhen Sie die Ressourcenlimits des Messwertservers. In Google Distributed Cloud Virtual for VMware 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.