Fehlerbehebung für Config Connector

Auf dieser Seite werden Techniken zur Fehlerbehebung für Config Connector und häufige Probleme beschrieben, die bei der Verwendung des Produkts auftreten können.

Config Connector-Status und -Bedingungen prüfen

Version von Config Connector prüfen

Führen Sie den folgenden Befehl aus, um die installierte Config Connector-Version abzurufen, und prüfen Sie anhand der Versionshinweise, ob die ausgeführte Version die Features und Ressourcen unterstützt, die Sie verwenden möchten:

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

Status und Ereignisse der Ressource prüfen

In der Regel können Sie das Problem mit Ihren Config Connector-Ressourcen ermitteln, indem Sie den Status Ihrer Ressourcen in Kubernetes prüfen. Das Prüfen des Status und der Ereignisse einer Ressource ist besonders hilfreich, um festzustellen, ob Config Connector die Ressource nicht abgleichen konnte und warum der Abgleich fehlgeschlagen ist.

Prüfen, ob Config Connector ausgeführt wird

Prüfen Sie, ob Config Connector ausgeführt wird. Dazu müssen alle Pods den Status READY haben:

kubectl get pod -n cnrm-system

Beispielausgabe:

NAME                                            READY   STATUS    RESTARTS   AGE
cnrm-controller-manager-0                       1/1     Running   0          1h
cnrm-deletiondefender-0                         1/1     Running   0          1h
cnrm-resource-stats-recorder-77dc8cc4b6-mgpgp   1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-pqwhz           1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-wdcn4           1/1     Running   0          1h

Wenn Config Connector im Namespace-Modus installiert ist, haben Sie einen Controller-Pod (cnrm-controller-manager) für jeden Namespace, der für die Verwaltung der Config Connector-Ressourcen in diesem Namespace verantwortlich ist.

Sie können den Status des Controller-Pods, der für einen bestimmten Namespace verantwortlich ist, mit folgendem Befehl prüfen:

kubectl get pod -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager

Ersetzen Sie NAMESPACE durch den Namen des Namespace.

Controller-Logs prüfen

Der Controller-Pod protokolliert Informationen und Fehler im Zusammenhang mit dem Abgleich von Config Connector-Ressourcen.

Sie können die Logs des Controller-Pods mit folgendem Befehl prüfen:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Wenn Config Connector im Namespace-Modus installiert ist, werden mit dem vorherigen Befehl die Logs aller Controller-Pods kombiniert angezeigt. Sie können die Logs des Controller-Pods für einen bestimmten Namespace mit folgendem Befehl prüfen:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Ersetzen Sie NAMESPACE durch den Namen des Namespace.

Weitere Informationen zum Prüfen und Abfragen von Config Connector-Logs

Ressource verwerfen und übernehmen

In einigen Fällen müssen Sie möglicherweise ein unveränderliches Feld in einer Ressource aktualisieren. Da Sie unveränderliche Felder nicht bearbeiten können, müssen Sie die Ressource aufgeben und dann neu abrufen:

  1. Aktualisieren Sie die YAML-Konfiguration der Config Connector-Ressource und setzen Sie die Annotation cnrm.cloud.google.com/deletion-policy auf abandon.
  2. Wenden Sie die aktualisierte YAML-Konfiguration an, um die Richtlinie zur Datenlöschung der Config Connector-Ressource zu aktualisieren.
  3. Config Connector-Ressource verwerfen
  4. Aktualisieren Sie die unveränderlichen Felder, die in der YAML-Konfiguration geändert werden müssen.
  5. Wenden Sie die aktualisierte YAML-Konfiguration an, um die aufgegebene Ressource zu übernehmen.

Fehlerbehebung nach Problemtyp

Anhand der folgenden Tabelle können Sie das Problem je nach Art des Symptoms beheben.

Art des Problems Häufige Probleme
Abgleich
Löschen
Berechtigungen
Installation und Upgrades
Configuration

Abgleich

Im folgenden Abschnitt sind häufige Probleme im Zusammenhang mit dem Abgleich von Ressourcen durch Config Connector aufgeführt.

Ressource wird alle 5–15 Minuten aktualisiert

Symptom

Ihre Config Connector-Ressource wechselt alle 5–10 Minuten zwischen dem Status UpToDate und Updating.

Ursache

Es ist wahrscheinlich, dass Config Connector unbeabsichtigte Unterschiede zwischen dem gewünschten und dem tatsächlichen Zustand der Ressource erkennt, was dazu führt, dass Config Connector die Ressource ständig aktualisiert.

Lösung

Prüfen Sie zuerst, ob Sie externe Systeme haben, die entweder den Config Connector oder die Google Cloud -Ressource ständig ändern (z. B. CI/CD-Pipelines, benutzerdefinierte Controller, Cronjobs usw.).

Wenn das Verhalten nicht auf ein externes System zurückzuführen ist, prüfen Sie, ob Google Cloud einen der in Ihrer Config Connector-Ressource angegebenen Werte ändert. In einigen Fällen ändert Google Cloud beispielsweise die Formatierung (z. B. Großschreibung) von Feldwerten, was zu einer Abweichung zwischen dem gewünschten und dem tatsächlichen Zustand Ihrer Ressource führt.

Rufen Sie den Status der Google Cloud -Ressource mithilfe der REST API (z. B. für ContainerCluster) oder der Google Cloud CLI ab. Vergleichen Sie diesen Status dann mit Ihrer Config Connector-Ressource. Suchen Sie nach Feldern, deren Werte nicht übereinstimmen, und aktualisieren Sie dann Ihre Config Connector-Ressource entsprechend. Achten Sie insbesondere auf Werte, die von Google Cloudneu formatiert wurden. Weitere Informationen finden Sie in den GitHub-Problemen #578 und #294.

Diese Methode ist nicht perfekt, da sich die Config Connector- undGoogle Cloud -Ressourcenmodelle unterscheiden. Sie sollten damit aber die meisten Fälle von unbeabsichtigten Unterschieden erkennen können.

Wenn Sie das Problem nicht beheben können, finden Sie unter Zusätzliche Hilfe weitere Informationen.

Abgleich schlägt fehl oder wird aufgrund automatischer Feldaktualisierungen wiederholt

Dieses Problem tritt auf, wenn Google Cloud ein Feld in einer Ressource, die die Annotation cnrm.cloud.google.com/state-into-spec: merge verwendet, automatisch aktualisiert.

Symptom

Ihre Config Connector-Ressource wechselt in den Status UpdateFailed oder wiederholt in den Status Updating, nachdem Google Cloud ein Feld, das Sie nicht in Ihrem YAML-Manifest angegeben haben, automatisch aktualisiert wurde.

Wenn Cloud SQL beispielsweise ein automatisches Wartungsupdate für eine SQLInstance-Ressource ausführt, kann der Abgleich mit einem Fehler wie dem folgenden fehlschlagen:

Update call failed: error updating: patching SQLInstance ... maintenanceVersion failed: googleapi: Error 400: Invalid request: The requested maintenance version is not an available maintenance version to upgrade. Please refer to the availableMaintenanceVersions on the instance resource to see the available maintenance versions.., invalid

Ursache

Die Ressource hat die Annotation cnrm.cloud.google.com/state-into-spec: merge. Diese Annotation war die Standardeinstellung für Ressourcen, die vor Config Connector-Version 1.123.1 für CustomResourceDefinitions (CRDs) erstellt wurden, die in Version 1.113.0 und früher hinzugefügt wurden. Ihre Ressource kann diese Annotation auch haben, wenn das Feld spec.stateIntoSpec in Ihrer benutzerdefinierten ConfigConnector- oder ConfigConnectorContext-Ressource auf Merge gesetzt ist.

Wenn die Annotation cnrm.cloud.google.com/state-into-spec auf merge gesetzt ist, füllt Config Connector nicht angegebene Felder, z. B. das Feld spec.maintenanceVersion, während der ersten Abstimmung in das Feld spec der Kubernetes-Ressource ein. Wenn Google Cloud dieses Feld später automatisch in der zugrunde liegenden Ressource aktualisiert, behandelt Config Connector den älteren Wert, der im Feld spec gespeichert ist, als Zielzustand und versucht, die Änderung rückgängig zu machen. Wenn die Google Cloud API Downgrades ablehnt (wie Cloud SQL für das Feld spec.maintenanceVersion), schlägt der Abgleich fehl.

Lösung

Migrieren Sie die Ressource vom Verhalten Merge zum Verhalten Absent, damit Config Connector nicht mehr nicht angegebene Felder in das Feld spec einfügt:

  1. Lassen Sie im YAML-Manifest der Ressource das automatisch aktualisierte Feld (z. B. das Feld spec.maintenanceVersion) weg und setzen Sie die Annotation cnrm.cloud.google.com/state-into-spec auf absent.
  2. Folgen Sie der Anleitung unter Ressourcen von Merge zu Absent migrieren, um die Kubernetes-Ressource zu verwerfen und mit dem aktualisierten YAML-Manifest neu zu erfassen.

Häufige Wiederholungsversuche bei fehlerhaften Ressourcen erschöpfen API-Kontingente

Dieses Problem tritt auf, wenn bei Ressourcen dauerhafte Abgleichfehler auftreten, z. B. wenn eine Ressource von einer fehlenden externen Google Cloud Ressource abhängt oder eine ungültige Konfiguration hat.

Symptom

Eine Config Connector-Ressource hat den Status UpdateFailed oder DependencyNotFound und wiederholte Abgleichversuche generieren übermäßigen Google Cloud API-Traffic oder erschöpfen Google Cloud API-Kontingente.

Ursache

Wenn der Abgleich fehlschlägt, wiederholt Config Connector den Vorgang für die Ressource mit exponentiellem Backoff und einer standardmäßigen maximalen Verzögerung von 2 Minuten.

Lösung

Konfigurieren Sie für Ressourcen, die von direkten Controllern in Config Connector Version 1.160.0 und höher verwaltet werden, die Annotation cnrm.cloud.google.com/backoff-max-delay-in-seconds, um die maximale Wiederholungsverzögerung zu erhöhen, oder setzen Sie die Annotation auf "0", um automatische Wiederholungen zu beenden.

Ressourcen, die von Terraform- oder DCL-basierten Controllern verwaltet werden, unterstützen diese Annotation nicht. Versuchen Sie Folgendes, um die Anzahl der Wiederholungsversuche für diese Ressourcen zu reduzieren:

  1. Wenn ein direkter Controller für die Ressource verfügbar ist, wechseln Sie zum direkten Controller und verwenden Sie die Annotation.
  2. Beheben Sie den zugrunde liegenden Fehler.
  3. Als letzte Möglichkeit können Sie die Ressource vorübergehend aus der Verwaltung entfernen, indem Sie die Annotation cnrm.cloud.google.com/deletion-policy: "abandon" festlegen und das Kubernetes-Objekt löschen. Alternativ können Sie spec.actuationMode: Paused für ConfigConnectorContext festlegen.

Ressource hat keinen Status

Symptom

Ihre Ressourcen haben kein status-Feld.

Ursache

Es ist wahrscheinlich, dass Config Connector nicht ordnungsgemäß ausgeführt wird.

Lösung

Prüfen, ob Config Connector ausgeführt wird

KNV2005: Syncer aktualisiert Ressource übermäßig

Symptom

Sie verwenden Config Sync und sehen KNV2005-Fehler für Config Connector-Ressourcen, die in etwa so aussehen:

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

Ursache

Es ist wahrscheinlich, dass Config Sync und Config Connector um die Ressource konkurrieren.

Config Sync und Config Connector „kämpfen“ um eine Ressource, wenn sie dieselben Felder immer wieder mit unterschiedlichen Werten aktualisieren. Die Aktualisierung des einen Controllers löst die Aktion des anderen aus, die Ressource zu aktualisieren, was wiederum den anderen Controller dazu veranlasst, die Ressource zu aktualisieren. Dies wiederholt sich endlos.

Kämpfe sind für die meisten Felder kein Problem. In Config Sync angegebene Felder werden von Config Connector nicht geändert. Felder, die nicht in Config Sync angegeben sind und von Config Connector standardmäßig festgelegt werden, werden von Config Sync ignoriert. Daher sollten Config Sync und Config Connector für die meisten Felder nicht dasselbe Feld aktualisieren müssen.

Eine Ausnahme sind Listenfelder. Ähnlich wie Config Connector Unterfelder in Objektfeldern standardmäßig festlegen kann, kann Config Connector auch Unterfelder in Objekten innerhalb von Listen standardmäßig festlegen. Da Listenfelder in Config Connector-Ressourcen jedoch atomar sind, wird das Festlegen von Standardwerten für Unterfelder als vollständige Änderung des Listenwerts betrachtet.

Daher „kämpfen“ Config Sync und Config Connector um eine Ressource, wenn Config Sync ein Listenfeld festlegt und Config Connector alle Unterfelder in dieser Liste standardmäßig festlegt.

Lösung

Sie haben die folgenden Möglichkeiten, dieses Problem zu umgehen:

  1. Aktualisieren Sie das Ressourcenmanifest im Config Sync-Repository so, dass es mit dem übereinstimmt, was Config Connector für die Ressource festlegen möchte.

    Eine Möglichkeit besteht darin, die Synchronisierung von Konfigurationen vorübergehend zu beenden, zu warten, bis Config Connector die Ressource abgeglichen hat, und dann das Ressourcenmanifest so zu aktualisieren, dass es mit der Ressource auf dem Kubernetes API-Server übereinstimmt.

  2. Verhindern Sie, dass Config Sync auf Aktualisierungen der Ressource auf dem Kubernetes API-Server reagiert, indem Sie die Annotation client.lifecycle.config.k8s.io/mutation auf ignore setzen. Config Sync-Ignorieren von Objektmutationen

  3. Verhindern Sie, dass Config Connector die Spezifikation der Ressource vollständig aktualisiert, indem Sie die Annotation cnrm.cloud.google.com/state-into-spec für die Ressource auf absent setzen. Diese Annotation wird nicht für alle Ressourcen unterstützt. Ob Ihre Ressource die Annotation unterstützt, können Sie auf der entsprechenden Ressourcenreferenzseite nachsehen. Weitere Informationen zur Annotation

Ressource von Config Connector gelöscht

Symptom

Eine Ressource wurde aus Ihrem Cluster gelöscht und Sie vermuten, dass Config Connector sie gelöscht hat.

Ursache

Config Connector löscht Ihre Ressourcen nie ohne externe Ursache. Beispielsweise kann das Ausführen von kubectl delete, die Verwendung von Konfigurationsverwaltungstools wie Argo CD oder die Verwendung eines benutzerdefinierten API-Clients zum Löschen von Ressourcen führen.

Ein häufiges Missverständnis ist, dass Config Connector einige der Ressourcen in Ihrem Cluster initiiert und gelöscht hat. Wenn Sie beispielsweise Config Connector verwenden, sehen Sie möglicherweise Löschanfragen des Config Connector-Controller-Managers für bestimmte Ressourcen, entweder in Container-Logeinträgen oder in Audit-Logs von Kubernetes-Clustern. Diese Löschanfragen sind das Ergebnis externer Trigger und Config Connector versucht, die Löschanfragen abzugleichen.

Lösung

Wenn Sie herausfinden möchten, warum eine Ressource gelöscht wurde, müssen Sie sich die erste Löschanfrage ansehen, die für die entsprechende Ressource gesendet wurde. Am besten lässt sich dies anhand der Audit-Logs des Kubernetes-Clusters untersuchen.

Wenn Sie beispielsweise GKE verwenden, können Sie Cloud Logging verwenden, um Audit-Logs für GKE-Cluster abzufragen. Wenn Sie beispielsweise nach den ersten Löschanfragen für eine BigQueryDataset-Ressource mit dem Namen my-dataset im Namespace my-namespace suchen möchten, führen Sie eine Abfrage wie die folgende aus:

resource.type="k8s_cluster"
resource.labels.project_id="my-project-id"
resource.labels.cluster_name="my-cluster-name"
protoPayload.methodName="com.google.cloud.cnrm.bigquery.v1beta1.bigquerydatasets.delete"
protoPayload.resourceName="bigquery.cnrm.cloud.google.com/v1beta1/namespaces/my-namespace/bigquerydatasets/my-dataset"

Mit dieser Abfrage suchen Sie nach der ersten Löschanfrage und prüfen dann authenticationInfo.principalEmail dieser Löschprotokollnachricht, um die Ursache des Löschens zu ermitteln.

Controller-Pod aufgrund von fehlendem Arbeitsspeicher beendet

Symptom

In einem Config Connector-Controller-Pod wird ein OOMKilled-Fehler angezeigt. Der Status des Pods kann als OOMKilled oder Terminating angezeigt werden.

Ursache

Ein Container oder der gesamte Pod wurde beendet, weil mehr Arbeitsspeicher als zulässig verwendet wurde. Dies lässt sich mit dem Befehl kubectl describe prüfen:

kubectl describe pod POD_NAME -n cnrm-system

Ersetzen Sie POD_NAME durch den Pod, für den Sie die Fehlerbehebung durchführen.

Außerdem können Sie in den Ereignisprotokollen des Pods nach OOM-bezogenen Ereignissen suchen.

Lösung

Um dieses Problem zu beheben, können Sie die benutzerdefinierte Ressource ControllerResource verwenden, um die Speicheranfrage und das Speicherlimit für den Pod zu erhöhen.

Löschen

Im folgenden Abschnitt sind häufige Probleme im Zusammenhang mit vom Nutzer initiierten Löschvorgängen aufgeführt, die zu Konflikten mit Config Connector führen können.

Namespace-Löschung bleibt bei „Wird beendet“ hängen

Symptom

Das Löschen eines Namespace bleibt in der Phase Terminating hängen.

Ursache

Dieses Problem kann auftreten, wenn Config Connector im Namespace-Modus installiert ist und die ConfigConnectorContext des Namespace gelöscht wurde, bevor alle Config Connector-Ressourcen in diesem Namespace gelöscht wurden. Wenn die ConfigConnectorContext eines Namespace gelöscht wird, wird Config Connector für diesen Namespace deaktiviert. Dadurch wird verhindert, dass verbleibende Config Connector-Ressourcen in diesem Namespace gelöscht werden.

Lösung

Um dieses Problem zu beheben, müssen Sie eine erzwungene Bereinigung durchführen und anschließend die zugrunde liegenden Google Cloud -Ressourcen manuell löschen.

Um dieses Problem in Zukunft zu vermeiden, löschen Sie den ConfigConnectorContext erst, nachdem alle Config Connector-Ressourcen in seinem Namespace aus Kubernetes gelöscht wurden. Vermeiden Sie es, ganze Namespaces zu löschen, bevor alle Config Connector-Ressourcen in diesem Namespace gelöscht wurden, da der ConfigConnectorContext möglicherweise zuerst gelöscht wird.

Ressourcenlöschung bleibt nach dem Löschen des Projekts bei „DeleteFailed“ hängen

Symptom

Das Löschen einer Config Connector-Ressource schlägt mit dem Status DeleteFailed fehl.

Ursache

Dieses Problem kann auftreten, wenn ein Google Cloud -Projekt vor der Ressource gelöscht wird.

Lösung

Um dieses Problem zu beheben, stellen Sie das Projekt inGoogle Cloudwieder her, damit Config Connector die verbleibenden untergeordneten Ressourcen aus Kubernetes löschen kann. Alternativ können Sie eine erzwungene Bereinigung durchführen.

Um dieses Problem in Zukunft zu vermeiden, sollten Sie Google Cloud -Projekte erst löschen, nachdem alle untergeordneten Config Connector-Ressourcen aus Kubernetes gelöscht wurden. Vermeiden Sie es, ganze Namespaces zu löschen, die sowohl eine Project-Ressource als auch die zugehörigen untergeordneten Config Connector-Ressourcen enthalten, da die Project-Ressource möglicherweise zuerst gelöscht wird.

Berechtigungen und Authentifizierung

Im folgenden Abschnitt sind häufige Probleme im Zusammenhang mit Berechtigungen und Authentifizierung aufgeführt.

Compute Engine-Metadaten nicht definiert

Symptom

Ihre Config Connector-Ressource hat den Status UpdateFailed mit einer Meldung, dass die Compute Engine-Metadaten nicht definiert sind, ähnlich dem folgenden Fehler:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
metadata: Compute Engine metadata "instance/service-accounts/default/token?
scopes=https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)compute%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSIN
G)auth%!F(MISSING)cloud-platform%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)cloud-identity%!C(MISSING)https%!A(MISSING)%!F(MISS
ING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)ndev.clouddns.readwrite%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSIN
G)devstorage.full_control%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)userinfo.email%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F
(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)drive.readonly" not
defined, detail:

Ursache

Es ist wahrscheinlich, dass das von Config Connector verwendete IAM-Dienstkonto nicht vorhanden ist.

Lösung

Prüfen Sie, ob das von Config Connector verwendete IAM-Dienstkonto vorhanden ist, um das Problem zu beheben.

Um dieses Problem in Zukunft zu vermeiden, folgen Sie der Installationsanleitung für Config Connector.

Fehler 403: Request had insufficient authentication scopes

Symptom

Ihre Config Connector-Ressource hat den Status UpdateFailed mit einer Meldung, die auf einen 403-Fehler aufgrund unzureichender Authentifizierungsbereiche hinweist, ähnlich dem folgenden Fehler:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner-instance": googleapi: Error 403: Request had
insufficient authentication scopes.

Ursache

Die Workload Identity-Föderation für GKE ist wahrscheinlich nicht in Ihrem GKE-Cluster aktiviert.

So prüfen Sie, ob Workload Identity Federation for GKE nicht aktiviert ist:

  1. Speichern Sie folgende Pod-Konfiguration als wi-test.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
  namespace: cnrm-system
spec:
  containers:
  - image: google/cloud-sdk:slim
    name: workload-identity-test
    command: ["sleep","infinity"]
  serviceAccountName: cnrm-controller-manager

    Wenn Sie Config Connector im Namespace-Modus installiert haben, sollte serviceAccountName den Wert cnrm-controller-manager-NAMESPACE haben. Ersetzen Sie NAMESPACE durch den Namespace, den Sie bei der Installation verwendet haben.

  2. Erstellen Sie den Pod in Ihrem GKE-Cluster:

    kubectl apply -f wi-test.yaml

  3. Öffnen Sie eine interaktive Sitzung im Pod:

    kubectl exec -it workload-identity-test \
    --namespace cnrm-system \
    -- /bin/bash

  4. Listen Sie Ihre Identität auf:

    gcloud auth list

  5. Prüfen Sie, ob die aufgeführte Identität mit dem Google-Dienstkonto übereinstimmt, das an Ihre Ressourcen gebunden ist.

    Wenn Sie stattdessen das Compute Engine-Standarddienstkonto sehen, bedeutet dies, dass die Workload Identity Federation for GKE in Ihrem GKE-Cluster und/oder Knotenpool nicht aktiviert ist.

  6. Beenden Sie die interaktive Sitzung und löschen Sie den Pod aus Ihrem GKE-Cluster:

    kubectl delete pod workload-identity-test \
    --namespace cnrm-system

Lösung

Achten Sie darauf, dass die Workload Identity Federation for GKE in Ihrem Cluster aktiviert ist, um dieses Problem zu beheben.

Wenn Sie immer noch denselben Fehler sehen, prüfen Sie, ob Sie auch die Workload Identity Federation for GKE in den Knotenpools des Clusters aktiviert haben.

403 Forbidden: Der Aufrufer hat keine Berechtigung

Symptom

Ihre Config Connector-Ressource hat den Status UpdateFailed mit einer Meldung, die auf einen 403-Fehler aufgrund von Workload Identity Federation for GKE hinweist, ähnlich dem folgenden Fehler:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
compute: Received 403 `Unable to generate access token; IAM returned 403
Forbidden: The caller does not have permission
This error could be caused by a missing IAM policy binding on the target IAM
service account.
For more information, refer to the Workload Identity documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

Ursache

Dem Kubernetes-Dienstkonto von Config Connector fehlen die entsprechenden IAM-Berechtigungen, um die Identität Ihres IAM-Dienstkontos als Nutzer der Workload Identity-Föderation für GKE zu übernehmen.

Lösung

Informationen zum Beheben und Minimieren des Problems in der Zukunft finden Sie in der Installationsanleitung für Config Connector.

Fehler 403: Dem Aufrufer fehlt die IAM-Berechtigung

Symptom

Ihre Config Connector-Ressource hat den Status UpdateFailed mit einer Meldung, dass dem Aufrufer eine IAM-Berechtigung fehlt, ähnlich dem folgenden Fehler:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": googleapi: Error 403: Caller is missing IAM
permission spanner.instances.get on resource
projects/my-project/instances/my-spanner-instance., detail:

Ursache

Dem von Config Connector verwendeten IAM-Dienstkonto fehlt die in der Nachricht angegebene IAM-Berechtigung, die zum Verwalten der Ressource Google Cloud erforderlich ist.

Lösung

Wenn Sie den gleichen Fehler weiterhin sehen, nachdem Sie Ihrem IAM-Dienstkonto die entsprechenden IAM-Berechtigungen zugewiesen haben, prüfen Sie, ob Ihre Ressource im richtigen Projekt erstellt wird. Prüfen Sie das Feld spec.projectRef der Config Connector-Ressource (oder die Annotation cnrm.cloud.google.com/project-id, wenn die Ressource kein Feld spec.projectRef unterstützt) und prüfen Sie, ob die Ressource auf das richtige Projekt verweist. Beachten Sie, dass Config Connector den Namen des Namespace als Projekt-ID verwendet, wenn weder die Ressource noch der Namespace ein Zielprojekt angibt. Weitere Informationen zum Konfigurieren des Zielprojekts für projektbezogene Ressourcen

Wenn der Fehler weiterhin auftritt, prüfen Sie, ob die Workload Identity Federation for GKE in Ihrem GKE-Cluster aktiviert ist.

Um dieses Problem in Zukunft zu vermeiden, folgen Sie der Installationsanleitung für Config Connector.

Aktualisierungsfehler bei IAMPolicy, IAMPartialPolicy und IAMPolicyMember

Symptom

Sie sehen den Status UpdateFailed mit einer Fehlermeldung, die auf einen 400-Fehler hinweist, da das Dienstkonto nicht vorhanden ist:

Update call failed: error setting policy member: error applying changes: summary: Request `Create IAM Members roles/[MYROLE] serviceAccount:[NAME]@[PROJECT_ID].iam.gserviceaccount.com for project \"projects/[PROJECT_ID]\"` returned error: Error applying IAM policy for project \"projects/[PROJECT_ID]\": Error setting IAM policy for project \"projects/[PROJECT_ID]\": googleapi: Error 400: Service account [NAME]@[PROJECT_ID].iam.gserviceaccount.com does not exist., badRequest

Ursache

Wenn Sie eine Config Connector-Ressource vom Typ IAMServiceAccount löschen, bevor Sie die Ressourcen IAMPolicy, IAMPartialPolicy und IAMPolicyMember bereinigen, die von diesem Dienstkonto abhängen, kann Config Connector das in diesen IAM-Ressourcen referenzierte Dienstkonto während des Abgleichs nicht finden.

Lösung

Prüfen Sie Ihre Dienstkonten, um festzustellen, ob das erforderliche Dienstkonto für diese IAM-Ressourcen gelöscht wurde. Wenn das Dienstkonto gelöscht wird, bereinigen Sie auch die zugehörigen IAM-Config Connector-Ressourcen. Löschen Sie für IAMPolicyMember die gesamte Ressource. Entfernen Sie für IAMPolicy und IAMParitialPolicy nur die Bindungen, die das gelöschte Dienstkonto betreffen. Bei einer solchen Bereinigung werdenGoogle Cloud -Rollenbindungen jedoch nicht sofort entfernt. Die Google Cloud -Rollenbindungen werden aufgrund der Aufbewahrung des gelöschten Dienstkontos 60 Tage lang aufbewahrt. Weitere Informationen finden Sie in der Google CloudIAM-Dokumentation unter Dienstkonto löschen.

Um dieses Problem zu vermeiden, sollten Sie die Config Connector-Ressourcen IAMPolicy, IAMPartialPolicy und IAMPolicyMember immer vor dem Löschen der referenzierten IAMServiceAccount bereinigen.

ServiceIdentity-Ressource schlägt mit Invalid service producer fehl

Symptom

Ihre ServiceIdentity-Ressource hat den Status UpdateFailed und eine Fehlermeldung, die in etwa so aussieht:

Update call failed: error applying desired state: summary: Error creating Service Identity: Invalid service producer: ...

Ursache

Dieser Fehler bedeutet, dass die angegebene Ressource die On-Demand-Erstellung von Dienstidentitäten nicht unterstützt.

Lösung

Die Ressource ServiceIdentity kann Dienstidentitäten nur für unterstützte Dienste generieren. Wenn Sie prüfen möchten, ob ein Dienst die On-Demand-Erstellung von Dienstidentitäten unterstützt, bevor Sie Ihre Konfiguration anwenden, führen Sie den folgenden Befehl aus:

gcloud beta services identity create --service SERVICE_NAME.googleapis.com

Ersetzen Sie SERVICE_NAME durch den Namen des Dienstes, z. B. spanner.

Wenn der Befehl erfolgreich ist, kann Config Connector eine Identität für diesen Dienst erstellen. Wenn der Befehl fehlschlägt, kann Config Connector keine Identität für diesen Dienst erstellen.

Installation und Upgrades

Im folgenden Abschnitt sind häufige Probleme im Zusammenhang mit der Installation oder dem Upgrade der Config Connector-Version aufgeführt.

Version wird in Config Connector-Add-on-Installationen nicht unterstützt

Symptom

Wenn Sie das Config Connector-Add-on nicht aktivieren können, wird folgende Fehlermeldung angezeigt: Node version 1.15.x-gke.x s unsupported.

Die Fehlermeldung wird auch angezeigt, wenn die Identitätsföderation von Arbeitslasten für GKE oder GKE Monitoring deaktiviert ist.

Ursache

Die Version des GKE-Cluster erfüllt die Anforderungen nicht oder erforderliche Features sind deaktiviert.

Lösung

Prüfen Sie zur Behebung dieses Fehlers, ob die Version des GKE-Cluster die Anforderungen an Version und Features erfüllt. Prüfen Sie, ob Workload Identity Federation for GKE und GKE Monitoring aktiviert sind.

Führen Sie folgenden Befehl aus, um alle gültigen Versionen für Ihre Cluster abzurufen:

gcloud container get-server-config --format "yaml(validMasterVersions)" \
    --zone ZONE

Ersetzen Sie ZONE durch die Compute Engine-Zone.

Wählen Sie eine Version aus der Liste aus, die die Anforderungen erfüllt.

failed calling webhook

Symptom

Sie können Config Connector nicht deinstallieren und erhalten eine Fehlermeldung wie die folgende:

error during reconciliation: error building deployment objects: error finalizing the deletion of Config Connector system components deployed by ConfigConnector controller: error waiting for CRDs to be deleted: error deleting CRD accesscontextmanageraccesslevels.accesscontextmanager.cnrm.cloud.google.com: Internal error occurred: failed calling webhook "abandon-on-uninstall.cnrm.cloud.google.com": failed to call webhook: Post "https://abandon-on-uninstall.cnrm-system.svc:443/abandon-on-uninstall?timeout=3s": service "abandon-on-uninstall" not found

Ursache

Dieses Problem kann auftreten, wenn Sie das Config Connector-Add-on verwenden und Config Connector deaktivieren, bevor Sie die Config Connector-CRDs entfernen.

Lösung

Um diesen Fehler zu beheben, müssen Sie die Webhooks zuerst manuell löschen:

kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

Anschließend können Sie Config Connector deinstallieren.

PodSecurityPolicy verhindert Upgrades

Symptom

Nachdem Sie vom Config Connector-Add-on zu einer manuellen Installation gewechselt und Config Connector auf eine neue Version aktualisiert haben, können cnrm-Pods nicht aktualisiert werden.

Ursache

Die Verwendung von PodSecurityPolicies kann verhindern, dass cnrm-Pods aktualisiert werden.

Um zu prüfen, ob die PodSecurityPolicies das Upgrade verhindern, prüfen Sie die Ereignisse des config-connector-operator und suchen Sie nach einem Fehler, der in etwa so aussieht:

create Pod configconnector-operator-0 in StatefulSet configconnector-operator failed error: pods "configconnector-operator-0" is forbidden: PodSecurityPolicy: unable to admit pod: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: Forbidden: seccomp may not be set]

Lösung

Um dieses Problem zu beheben, müssen Sie die Annotation für die PodSecurityPolicy angeben, die der im Fehler genannten Annotation entspricht. Im vorherigen Beispiel lautet die Annotation seccomp.security.alpha.kubernetes.io.

Konfiguration

Im folgenden Abschnitt werden häufige Probleme im Zusammenhang mit der Konfiguration von Ressourcen aufgeführt.

An unveränderlichen Feldern können keine Änderungen vorgenommen werden

Config Connector lehnt Aktualisierungen unveränderlicher Felder bei der Zulassung ab.

Wenn Sie beispielsweise ein unveränderliches Feld mit kubectl apply aktualisieren, schlägt der Befehl sofort fehl.

Das bedeutet, dass Tools, die Ressourcen kontinuierlich neu anwenden (z. B. GitOps), beim Aktualisieren einer Ressource hängen bleiben können, wenn sie keine Zulassungsfehler verarbeiten.

Da Config Connector keine Aktualisierungen unveränderlicher Felder zulässt, können Sie eine solche Aktualisierung nur durchführen, wenn Sie die Ressource löschen und neu erstellen.

Fehler beim Aktualisieren der unveränderlichen Felder, wenn kein Update vorhanden ist

Kurz nachdem Sie eine Google Cloud -Ressource mit Config Connector erstellt oder erworben haben, werden im Status der Config Connector-Ressource möglicherweise die folgenden Fehler angezeigt:

  • Update call failed: error applying desired state: infeasible update: ({true \<nil\>}) would require recreation (Beispiel)

  • Update call failed: cannot make changes to immutable field(s) (Beispiel)

Das bedeutet nicht unbedingt, dass Sie die Ressource tatsächlich aktualisiert haben. Der Grund kann sein, dass die Google Cloud API eine Änderung an einem unveränderlichen Feld vorgenommen hat, das Sie in der Config Connector-Ressource verwaltet haben. Dies führte zu einer Diskrepanz zwischen dem gewünschten Zustand und dem Live-Zustand der unveränderlichen Felder.

Sie können das Problem beheben, indem Sie die Werte dieser unveränderlichen Felder in der Config Connector-Ressource so aktualisieren, dass sie mit dem Livestatus übereinstimmen. Gehen Sie dazu so vor:

  1. Aktualisieren Sie die YAML-Konfiguration der Config Connector-Ressource und setzen Sie die Annotation cnrm.cloud.google.com/deletion-policy auf abandon.
  2. Wenden Sie die aktualisierte YAML-Konfiguration an, um die Richtlinie zur Datenlöschung der Config Connector-Ressource zu aktualisieren.
  3. Config Connector-Ressource verwerfen
  4. Geben Sie den Livestatus der entsprechenden Google Cloud -Ressource mit der gcloud CLI aus.
  5. Suchen Sie nach der Abweichung zwischen der Ausgabe der gcloud CLI und der YAML-Konfiguration der Config Connector-Ressource und aktualisieren Sie diese Felder in der YAML-Konfiguration.
  6. Wenden Sie die aktualisierte YAML-Konfiguration an, um die aufgegebene Ressource zu übernehmen.

Keine Übereinstimmungen für die Art „RESOURCE_KIND“

Symptom

Der Fehler No matches for kind "RESOURCE_KIND" wird angezeigt.

Ursache

In Ihrem Kubernetes-Cluster ist die CRD für die Ressourcenart RESOURCE_KIND nicht installiert.

Lösung

Prüfen Sie, ob die Art eine von Config Connector unterstützte Ressourcenart ist.

Wenn die Art unterstützt wird, ist Ihre Config Connector-Installation entweder veraltet oder ungültig.

Wenn Sie Config Connector mit dem GKE-Add-on installiert haben, sollte Ihre Installation automatisch aktualisiert werden. Wenn Sie Config Connector manuell installiert haben, müssen Sie ein manuelles Upgrade durchführen.

Prüfen Sie im GitHub-Repository, welche Ressourcentypen von welchen Config Connector-Versionen unterstützt werden (z. B. die von Config Connector v1.44.0 unterstützten Typen).

Labels werden nicht an die Ressource Google Cloud weitergegeben.

Symptom

Labels in Ihrer YAML-Datei werden nicht in der Ressource Google Cloud angezeigt.

Ursache

Nicht alle Google Cloud -Ressourcen unterstützen Labels.

Lösung

Config Connector gibt in metadata.labels gefundene Labels an die zugrunde liegendeGoogle Cloud -Ressource weiter. In der REST API-Dokumentation der Ressource (z. B. API-Dokumentation für PubSubTopic) können Sie nachsehen, ob Labels unterstützt werden.

Fehler aufgrund von Sonderzeichen im Ressourcennamen

Symptom

Sie sehen einen Fehler im Zusammenhang mit ungültigen Zeichen in metadata.name:

a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Ursache

Sonderzeichen sind im Kubernetes-Feld metadata.name nicht zulässig.

Lösung

Wenn Sie Ihrer Ressource einen Namen geben möchten, der kein gültiger Kubernetes-Name, aber ein gültiger Google Cloud -Ressourcenname ist, können Sie das Feld resourceID verwenden, wie im folgenden Beispiel gezeigt:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: 'test'
spec:
  instanceRef:
    name: sqlinstance-sample-postgresql
  host: "%"
  type: CLOUD_IAM_USER
  resourceID: test.example@example-project.iam

Diese Konfiguration bewirkt, dass Config Connector resourceID anstelle von metadata.name als Namen der Ressource verwendet.

Felder können nicht aus der Ressourcenspezifikation entfernt werden

Symptom

Wenn Sie ein Feld aus der Spezifikation einer Config Connector-Ressource entfernen, wird es nicht aus der Ressource entfernt.

Ursache

Wenn Sie ein Feld aus der Spezifikation für eine von Config Connector verwaltete Ressource entfernen, wird dieses Feld nicht geleert oder auf einen Standardwert zurückgesetzt. Stattdessen wird das Feld extern verwaltet.

Lösung

Wenn Sie den Wert eines Felds in der zugrunde liegendenGoogle Cloud -Ressource auf „leer“ oder „Standard“ ändern möchten, müssen Sie das Feld in der Config Connector-Ressourcenspezifikation auf null setzen:

  • Legen Sie für ein Feld vom Typ „Liste“ mit [] eine leere Liste fest.

    Das folgende Beispiel zeigt das Feld targetServiceAccounts, das wir entfernen möchten:

    spec:
  targetServiceAccounts:
    - external: "example-sa-1@example-project.iam.gserviceaccount.com"
    - external: "example-sa-2@example-project.iam.gserviceaccount.com"

    Wenn Sie dieses Feld entfernen möchten, setzen Sie den Wert auf „leer“:

    spec:
  targetServiceAccounts: []

  • Verwenden Sie eine der folgenden Optionen, um ein Feld mit einem primitiven Typ zu leeren:

    Typ Leerer Wert
    String ""
    bool "false"
    integer 0

    Das folgende Beispiel zeigt das Feld identityNamespace, das wir entfernen möchten:

    spec:
  workloadIdentityConfig:
    identityNamespace: "example-project.svc.id.goog"

    Wenn Sie dieses Feld entfernen möchten, setzen Sie den Wert auf „leer“:

    spec:
  workloadIdentityConfig:
    identityNamespace: ""

  • Bei Feldern vom Typ „Objekt“ können Sie versuchen, die Unterfelder des Objekttyps gemäß der Anleitung im vorherigen Abschnitt auf „leer“ oder „Standard“ zu setzen und zu prüfen, ob das funktioniert. Es kann jedoch nicht garantiert werden, dass dies funktioniert.

Ungültiger Wert „merge“ für die Annotation „state-into-spec“

Dieses Problem tritt auf, wenn eine Ressource die Annotation cnrm.cloud.google.com/state-into-spec: merge verwendet, die Ressourcenart oder die Config Connector-Version den Wert merge jedoch ablehnt.

Symptom

Der Abgleich Ihrer Config Connector-Ressource schlägt mit einer Fehlermeldung wie der folgenden fehl:

Update call failed: error applying desired state: invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation

Ursache

Dieser Fehler tritt aus einem der folgenden Gründe auf:

  • Die Ressourcenart unterstützt das Verhalten Merge nicht, aber die Ressource hat die Annotation cnrm.cloud.google.com/state-into-spec: merge. Diese Annotation kann direkt für die Ressource festgelegt oder von der Einstellung spec.stateIntoSpec: Merge in Ihrer ConfigConnector- oder ConfigConnectorContext-CR übernommen werden. CRDs, die in Config Connector-Version 1.114.0 und höher hinzugefügt wurden, unterstützen nur das Verhalten Absent.
  • Sie haben ein Upgrade auf Config Connector-Version 1.134.0 oder 1.134.1 durchgeführt und haben eine vorhandene SQLInstance-Ressource, die standardmäßig die Annotation cnrm.cloud.google.com/state-into-spec: merge aus einer früheren Version hatte. In den Versionen 1.134.0 und 1.134.1 gab es ein bekanntes Problem, bei dem der Wert merge für SQLInstance-Ressourcen abgelehnt wurde.

Lösung

Führen Sie die Schritte aus, die für Ihr Szenario gelten, um das Problem zu beheben:

  • Ihre Ressourcenart unterstützt das Verhalten Merge nicht: Legen Sie die Annotation cnrm.cloud.google.com/state-into-spec: absent im YAML-Manifest Ihrer Ressource fest und setzen Sie das Feld spec.stateIntoSpec in Ihrer ConfigConnector- oder ConfigConnectorContext-CR auf Absent. Informationen dazu, ob Ihre Ressourcenart das Verhalten Merge unterstützt, finden Sie unter Arten mit Merge-Unterstützung. Wenn die Annotation bereits für eine vorhandene Ressource im Cluster vorhanden ist, führen Sie die Schritte unter Ressourcen von Merge zu Absent migrieren aus.
  • Sie verwenden eine vorhandene SQLInstance-Ressource in Config Connector-Version 1.134.0 oder 1.134.1: Aktualisieren Sie Config Connector auf Version 1.134.2 oder höher. Alternativ können Sie die SQLInstance-Ressource zur Annotation cnrm.cloud.google.com/state-into-spec: absent migrieren. Folgen Sie dazu der Anleitung unter Ressourcen von Merge zu Absent migrieren.

Config Connector kann auf ARM-basierten Knoten nicht gestartet werden

Wenn Ihr Cluster Knotenpools mit der Arm-Architektur enthält (z. B. die Maschinenserien C4A, N4A oder Tau T2A), können Config Connector-Komponenten möglicherweise nicht ausgeführt werden. Dies ist eine bekannte Einschränkung, da Config Connector keine Arm-basierten Systeme unterstützt.

Symptome

Wenn Ihre Config Connector-Instanz von diesem Problem betroffen ist, können die folgenden Symptome auftreten:

  • Pods im Namespace cnrm-system bleiben im Status Pending.
  • Pods zeigen möglicherweise einen CrashLoopBackOff mit einer Fehlermeldung in den Logs an, die in etwa so aussieht: exec user process caused "exec format error".
  • Wenn Sie den Pod beschreiben, werden Planungsfehler oder Architekturkonflikte angezeigt.

Lösung

Achten Sie zur Behebung dieses Problems darauf, dass Config Connector-Komponenten auf Knoten mit x86-Architektur geplant sind:

  • x86-Knotenpool hinzufügen: Wenn Ihr Cluster nur Arm-Knoten enthält, fügen Sie mindestens einen Knotenpool mit einem x86-Maschinentyp (z. B. e2-standard-2) hinzu, um die Config Connector-Controller-Pods zu hosten.
  • Knotenmarkierungen prüfen: GKE-Arm-Knoten sind in der Regel mit kubernetes.io/arch=arm64:NoSchedule markiert, um zu verhindern, dass reine x86-Arbeitslasten auf ihnen geplant werden. Achten Sie darauf, dass Sie den Config Connector-Bereitstellungen keine Toleranzen hinzugefügt haben, die es ihnen ermöglichen würden, auf diesen Knoten ausgeführt zu werden.

Erzwungene Bereinigung

Wenn Ihre Config Connector-Ressourcen beim Löschen hängen bleiben und Sie sie einfach aus Ihrem Kubernetes-Cluster entfernen möchten, können Sie das Löschen erzwingen, indem Sie ihre Finalizer löschen.

Sie können die Finalizer einer Ressource löschen, indem Sie die Ressource mit kubectl edit bearbeiten, das Feld metadata.finalizers löschen und dann die Datei speichern, um Ihre Änderungen am Kubernetes API-Server beizubehalten.

Da durch das Löschen der Finalizer einer Ressource die Ressource sofort aus dem Kubernetes-Cluster gelöscht werden kann, hat Config Connector möglicherweise (aber nicht unbedingt) keine Gelegenheit, das Löschen der zugrunde liegendenGoogle Cloud -Ressource abzuschließen. Das bedeutet, dass Sie Ihre Google Cloud -Ressourcen danach möglicherweise manuell löschen müssen.

Monitoring

Wenn Sie Config Connector überwachen und die zugehörigen Logs untersuchen, können Sie die Ursache von Problemen ermitteln und unerwartetes Verhalten besser nachvollziehen.

Messwerte

Sie können Prometheus verwenden, um Messwerte von Config Connector zu erfassen und anzuzeigen.

Logging

Alle Config Connector-Pods geben strukturierte Logs im JSON-Format aus.

Die Logs der Controller-Pods sind besonders nützlich, um Probleme beim Abgleich von Ressourcen zu beheben.

Sie können Logs für bestimmte Ressourcen abfragen, indem Sie nach den folgenden Feldern in den Logeinträgen filtern:

  • logger: enthält die Art der Ressource in Kleinbuchstaben. PubSubTopic-Ressourcen haben beispielsweise den logger pubsubtopic-controller.
  • resource.namespace: enthält den Namespace der Ressource.
  • resource.name: enthält den Namen der Ressource.

Logging für erweiterte Logabfragen verwenden

Wenn Sie GKE verwenden, können Sie mit der folgenden Abfrage Cloud Logging verwenden, um Logs für eine bestimmte Ressource abzufragen:

# Filter to include only logs coming from the controller Pods
resource.type="k8s_container"
resource.labels.container_name="manager"
resource.labels.namespace_name="cnrm-system"
labels.k8s-pod/cnrm_cloud_google_com/component="cnrm-controller-manager"

# Filter to include only logs coming from a particular GKE cluster
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.location="GKE_CLUSTER_LOCATION"

# Filter to include only logs for a particular Config Connector resource
jsonPayload.logger="RESOURCE_KIND-controller"
jsonPayload.resource.namespace="RESOURCE_NAMESPACE"
jsonPayload.resource.name="RESOURCE_NAME"

Ersetzen Sie Folgendes:

  • GKE_CLUSTER_NAME durch den Namen des GKE-Cluster, auf dem Config Connector ausgeführt wird
  • GKE_CLUSTER_LOCATION durch den Standort des GKE-Cluster, in dem Config Connector ausgeführt wird. Beispiel: us-central1.
  • RESOURCE_KIND durch die Art der Ressource in Kleinbuchstaben. Beispiel: pubsubtopic
  • RESOURCE_NAMESPACE durch den Namespace der Ressource.
  • RESOURCE_NAME durch den Namen der Ressource.

Zusätzliche Hilfe

Wenn Sie weitere Unterstützung benötigen, können Sie ein Problem auf GitHub melden oder sich an den Google Cloud -Support wenden.