Fehlerbehebung für Config Connector

Auf dieser Seite werden Methoden 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 vergleichen Sie sie mit den Versionshinweisen, um zu prüfen, ob die ausgeführte Version die Funktionen 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 alle Pods von Config Connector READY sind, um festzustellen, ob Config Connector ausgeführt wird:

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 zuständig 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 Sie Config Connector im Namespace-Modus installiert haben, werden mit dem vorherigen Befehl die Logs aller Controller-Pods zusammen 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 Löschrichtlinie 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 verlassene 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 werden 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 bis 10 Minuten zwischen dem Status UpToDate und Updating.

Ursache

Wahrscheinlich erkennt Config Connector unbeabsichtigte Unterschiede zwischen dem gewünschten und dem tatsächlichen Status der Ressource, wodurch 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. die Groß- und Kleinschreibung) von Feldwerten, was zu einem Unterschied zwischen dem gewünschten und dem tatsächlichen Status 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 Zustand 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 sollte jedoch die meisten Fälle von unbeabsichtigten Unterschieden abdecken.

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

Abstimmung schlägt fehl oder wird wiederholt aufgrund automatischer Feldaktualisierungen

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 automatisch ein Feld aktualisiert hat, das Sie nicht in Ihrem YAML-Manifest angegeben haben.

Wenn Cloud SQL beispielsweise ein automatisches Wartungsupdate für eine SQLInstance-Ressource durchführt, kann die Abstimmung 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 der Standard 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 (CR) auf Merge gesetzt ist.

Wenn die Annotation cnrm.cloud.google.com/state-into-spec auf merge gesetzt ist, füllt Config Connector bei der ersten Abstimmung nicht angegebene Felder wie das Feld spec.maintenanceVersion in das Feld spec der Kubernetes-Ressource ein. Wenn Google Cloud später automatisch das Feld in der zugrunde liegenden Ressource aktualisiert, behandelt Config Connector den älteren Wert, der im Feld spec gespeichert ist, als Zielstatus 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

Um dieses Problem zu beheben, migrieren Sie die Ressource vom Merge-Verhalten zum Absent-Verhalten, 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 entfernen und mit dem aktualisierten YAML-Manifest neu zu erstellen.

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 Sie, 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

Wahrscheinlich konkurrieren Config Sync und Config Connector um die Ressource.

Config Sync und Config Connector „kämpfen“ um eine Ressource, wenn sie dieselben Felder immer wieder mit unterschiedlichen Werten aktualisieren. Das Update des einen löst eine Aktion des anderen aus, wodurch die Ressource aktualisiert wird. Das wiederum löst eine Aktion des anderen aus, wodurch die Ressource aktualisiert wird. Dieser Vorgang wiederholt sich endlos.

Kämpfe sind für die meisten Felder kein Problem. Felder, die in Config Sync angegeben sind, werden von Config Connector nicht geändert. Entsprechend werden Felder, die in Config Sync nicht angegeben und von Config Connector auf Standardwerte gesetzt werden, von Config Sync ignoriert. Daher sollten Config Sync und Config Connector die meisten Felder nicht gleichzeitig 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 die Standardeinstellung von Unterfeldern 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 folgende Möglichkeiten, dieses Problem zu umgehen:

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

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

  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. Sie können verhindern, 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 festlegen. Diese Anmerkung wird nicht für alle Ressourcen unterstützt. Ob Ihre Ressource die Anmerkung unterstützt, können Sie auf der entsprechenden Ressourcenreferenzseite nachsehen. Weitere Informationen zur Anmerkung

Ressource wurde 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. Wenn Sie beispielsweise kubectl delete ausführen, Konfigurationsverwaltungstools wie Argo CD verwenden oder einen benutzerdefinierten API-Client verwenden, kann dies 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 vom Config Connector-Controller-Manager 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

Um herauszufinden, warum eine Ressource gelöscht wurde, müssen Sie sich den ersten Löschantrag ansehen, der für die entsprechende Ressource gesendet wurde. Die beste Möglichkeit, dies zu untersuchen, ist die Analyse der Kubernetes-Cluster-Audit-Logs.

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 dieses Logeintrags, um die Ursache des Löschens zu ermitteln.

Controller-Pod aufgrund von Arbeitsspeichermangel 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 die Ereignisprotokolle des Pods auf OOM-bezogene Ereignisse prüfen.

Lösung

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

Löschen

Im folgenden Abschnitt werden 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 dann die zugrunde liegenden Google Cloud Ressourcen manuell löschen.

Um dieses Problem in Zukunft zu vermeiden, löschen Sie die ConfigConnectorContext erst, wenn alle Config Connector-Ressourcen im zugehörigen Namespace aus Kubernetes gelöscht wurden. Löschen Sie keine ganzen Namespaces, 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 aufGoogle 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, wenn 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 werden 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

Wahrscheinlich ist das von Config Connector verwendete IAM-Dienstkonto nicht vorhanden.

Lösung

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

Damit dieses Problem in Zukunft nicht mehr auftritt, sollten Sie die Installationsanleitung für Config Connector befolgen.

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 cnrm-controller-manager-NAMESPACE sein. 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, ist die Workload Identity Federation for GKE in Ihrem GKE-Cluster und/oder -Knotenpool nicht aktiviert.

  6. Beenden Sie die interaktive Sitzung und löschen Sie dann 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 den Fehler weiterhin 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 zur Behebung und Vermeidung des Problems in 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 vom Config Connector verwendeten IAM-Dienstkonto fehlt die in der Meldung angegebene IAM-Berechtigung, die zum Verwalten der Google Cloud -Ressource 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 Sie weiterhin denselben Fehler sehen, prüfen Sie, ob Workload Identity Federation for GKE für Ihren 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

Der Status UpdateFailed wird mit einer Fehlermeldung angezeigt, 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 zum Löschen eines Dienstkontos.

Um dieses Problem zu vermeiden, sollten Sie immer die Config Connector-Ressourcen IAMPolicy, IAMPartialPolicy und IAMPolicyMember bereinigen, bevor Sie die referenzierte IAMServiceAccount löschen.

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 werden häufige Probleme im Zusammenhang mit der Installation oder dem Upgrade der Version von Config Connector 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 Workload Identity Federation for 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, ob die Version des GKE-Cluster den Anforderungen an Version und Funktionen entspricht, um diesen Fehler zu beheben. 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, die so aussieht:

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

So beheben Sie diesen Fehler:

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 von 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 in der 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.

Unveränderliche Felder können nicht geändert werden

Config Connector lehnt Aktualisierungen unveränderlicher Felder beim Zulassen 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 möglicherweise hängen bleiben, wenn sie keine Zulassungsfehler verarbeiten.

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

Fehler beim Aktualisieren der unveränderlichen Felder, wenn keine Aktualisierung erfolgt

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 Abweichung 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. Führen Sie dazu die folgenden Schritte aus:

  1. Aktualisieren Sie die YAML-Konfiguration der Config Connector-Ressource und legen Sie die Annotation cnrm.cloud.google.com/deletion-policy auf abandon fest.
  2. Wenden Sie die aktualisierte YAML-Konfiguration an, um die Löschrichtlinie der Config Connector-Ressource zu aktualisieren.
  3. Config Connector-Ressource aufgeben
  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 den Ressourcentyp 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.

Im GitHub-Repository können Sie nachsehen, welche Ressourcenarten von welchen Config Connector-Versionen unterstützt werden. Hier finden Sie beispielsweise die von Config Connector v1.44.0 unterstützten Arten.

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 überträgt Labels, die in metadata.labels gefunden werden, an die zugrunde liegendeGoogle Cloud -Ressource. In der REST API-Dokumentation der Ressource (z. B. in der 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

Durch diese Konfiguration verwendet Config Connector resourceID anstelle von metadata.name als Namen der Ressource.

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 das Feld nicht leer 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 in „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, legen Sie den Wert auf „leer“ fest:

    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, legen Sie den Wert auf „leer“ fest:

    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. Dies funktioniert jedoch nicht garantiert.

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

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

Symptom

Der Abgleich Ihrer Config Connector-Ressource schlägt mit einer Fehlermeldung ähnlich 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 merge-Wert 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 verbleiben 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. Prüfen Sie, ob Sie den Config Connector-Bereitstellungen Toleranzen hinzugefügt haben, die es ihnen ermöglichen, 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 die Datei dann speichern, um die Änderungen auf dem Kubernetes API-Server zu übernehmen.

Da durch das Löschen der Finalizer einer Ressource die Ressource sofort aus dem Kubernetes-Cluster gelöscht werden kann, kann (aber nicht unbedingt) Config Connector die zugrunde liegendeGoogle Cloud -Ressource möglicherweise nicht vollständig löschen. Das bedeutet, dass Sie Ihre Google Cloud Ressourcen 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

Mit Prometheus können Sie Messwerte von Config Connector erfassen und anzeigen.

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 Log-Abfragen verwenden

Wenn Sie GKE verwenden, können Sie Cloud Logging verwenden, um Logs für eine bestimmte Ressource abzufragen. Verwenden Sie dazu die folgende Abfrage:

# 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, auf 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.