Fehlerbehebung bei 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

Normalerweise 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, indem Sie prüfen, ob alle zugehörigen Pods READY sind:

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 Sie Config Connector im namespace-mode installiert haben, haben Sie einen Controller-Pod (cnrm-controller-manager) für jeden Namespace, der für die Verwaltung der Config Connector-Ressourcen in diesem Namespace zuständig 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

Die Controller-Pod-Logs enthalten Informationen und Fehler im Zusammenhang mit der Abstimmung 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-mode 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 aufrufen:

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 erwerben:

  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. 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 Art des Problems

In der folgenden Tabelle finden Sie Informationen zur Fehlerbehebung basierend auf der Art des Symptoms.

Art des Problems Allgemeine Probleme
Abstimmung
Löschen
Berechtigungen
Installation und Upgrades
Configuration

Abgleich

Im folgenden Abschnitt werden häufige Probleme im Zusammenhang mit der Abgleichung von Ressourcen durch Config Connector aufgeführt.

Ressource wird alle 5 bis 15 Minuten aktualisiert

Symptom

Ihre Config Connector-Ressource wechselt alle 5 bis 10 Minuten zwischen dem Status UpToDate und dem Status 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 die Config Connector- oder Google Cloud -Ressource ständig ändern (z. B. CI/CD-Pipelines, benutzerdefinierte Controller, Cron-Jobs usw.).

Wenn das Verhalten nicht auf ein externes System zurückzuführen ist, prüfen Sie, ob durch Google Cloud Werte geändert werden, die in Ihrer Config Connector-Ressource angegeben sind. 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 über die REST API (z. B. für ContainerCluster) oder die 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. Beispiele finden Sie in den GitHub-Problemen #578 und #294.

Das ist keine perfekte Methode, da die Config Connector- undGoogle Cloud -Ressourcenmodelle unterschiedlich sind. Sie sollten damit aber die meisten Fälle von unbeabsichtigten Unterschieden erkennen können.

Wenn Sie Ihr Problem nicht lösen können, lesen Sie den Abschnitt Zusätzliche Hilfe.

Ressource hat keinen Status

Symptom

Ihre Ressourcen haben kein status-Feld.

Ursache

Wahrscheinlich wird Config Connector nicht richtig ausgeführt.

Lösung

Prüfen Sie, ob Config Connector ausgeführt wird.

KNV2005: Syncer aktualisiert Ressource zu häufig

Symptom

Sie verwenden Config Sync und sehen KNV2005-Fehler für Config Connector-Ressourcen, ähnlich wie die folgenden:

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 dasselbe Feld oder 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 standardmäßig festgelegt 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 in Listen standardmäßig festlegen. Da Listenfelder in Config Connector-Ressourcen jedoch atomar sind, wird die Standardeinstellung von Unterfeldern als Änderung des Werts der Liste als Ganzes betrachtet.

Daher „streiten“ sich Config Sync und Config Connector um eine Ressource, wenn Config Sync ein Listenfeld festlegt und Config Connector alle Unterfelder in dieser Liste auf Standardwerte setzt.

Lösung

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

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

    Eine Möglichkeit hierfür 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. Sie können verhindern, 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 festlegen. Weitere Informationen dazu, wie Config Sync Objektänderungen ignoriert

  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 Annotation unterstützt, können Sie auf der entsprechenden Ressourcenreferenzseite nachsehen. Weitere Informationen zur Annotation

Von Config Connector gelöschte Ressource

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 niemals ohne externen Grund. 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 in Containerlogmeldungen oder Kubernetes-Cluster-Audit-Logs. 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 die erste Löschanfrage ansehen, die 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 GKE-Cluster-Audit-Logs abzufragen. Wenn Sie beispielsweise nach den ursprünglichen Löschanfragen für eine BigQueryDataset-Ressource mit dem Namen foo im Namespace bar 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/bar/bigquerydatasets/foo"

Mit dieser Abfrage suchen Sie nach der ersten Löschanfrage und prüfen dann authenticationInfo.principalEmail dieser Log-Nachricht, um die Ursache für das Löschen zu ermitteln.

Controller-Pod aufgrund von Arbeitsspeichermangel beendet

Symptom

In einem Config Connector-Controller-Pod wird der Fehler „OOMKilled“ 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 kann durch Ausführen des Befehls kubectl describe überprüft werden:

kubectl describe pod POD_NAME -n cnrm-system

Ersetzen Sie POD_NAME durch den Pod, bei dem 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 Speicheranforderung 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.

Löschen des Namespace 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 Sie Config Connector im namespaced-mode installiert haben und das ConfigConnectorContext des Namespace gelöscht wurde, bevor alle Config Connector-Ressourcen in diesem Namespace gelöscht wurden. Wenn der 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. 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.

Löschen von Ressourcen 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 das Löschen ganzer Namespaces, die sowohl eine Project-Ressource als auch ihre 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

Workload Identity Federation for GKE ist in Ihrem GKE-Cluster wahrscheinlich nicht aktiviert.

So prüfen Sie, ob die Identitätsföderation von Arbeitslasten für 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.

    Wird stattdessen das Compute Engine-Standarddienstkonto angezeigt, ist die Identitätsföderation von Arbeitslasten für GKE nicht in Ihrem GKE-Cluster und/oder Knotenpool 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 derselbe Fehler weiterhin angezeigt wird, prüfen Sie, ob Sie die Identitätsföderation von Arbeitslasten für GKE auch in den Knotenpools des Clusters aktiviert haben.

403 – Unzulässig: Der Aufrufer hat keine Berechtigung

Symptom

Ihre Config Connector-Ressource hat den Status UpdateFailed mit einer Meldung, die auf einen 403-Fehler aufgrund der Identitätsföderation von Arbeitslasten für 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 Workload Identity Federation for GKE-Nutzer zu übernehmen.

Lösung

Informationen zum Beheben und Vermeiden 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 von 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 nach dem Zuweisen der entsprechenden IAM-Berechtigungen für Ihr IAM-Dienstkonto weiterhin denselben Fehler sehen, 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. Hinweis: Wenn weder für die Ressource noch für den Namespace ein Zielprojekt angegeben ist, verwendet Config Connector den Namen des Namespace als Projekt-ID. Weitere Informationen zum Konfigurieren des Zielprojekts für Ressourcen auf Projektebene

Wenn derselbe Fehler weiterhin angezeigt wird, prüfen Sie, ob Workload Identity Federation for GKE für Ihren GKE-Cluster aktiviert ist.

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

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 IAMServiceAccount-Config Connector-Ressource löschen, bevor Sie die IAMPolicy-, IAMPartialPolicy- und IAMPolicyMember-Ressourcen 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. Durch diese Bereinigung werdenGoogle Cloud -Rollenbindungen jedoch nicht sofort entfernt. Die Google Cloud -Rollenbindungen werden aufgrund der Aufbewahrungsrichtlinie für das gelöschte Dienstkonto 60 Tage lang beibehalten. Weitere Informationen finden Sie in der IAM-Dokumentation unter Dienstkonto löschen Google Cloud.

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

Die Ressource ServiceIdentity schlägt mit IAM_SERVICE_NOT_CONFIGURED_FOR_IDENTITIES fehl

Symptom

Ihre ServiceIdentity-Ressource hat den Status UpdateFailed mit einer Fehlermeldung wie der folgenden:

Update call failed: error applying desired state: summary: Error creating Service Identity: googleapi: Error 400: com.google.api.tenant.error.TenantManagerException: IAM_SERVICE_NOT_CONFIGURED_FOR_IDENTITIES: ...

Ursache

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

Lösung

Mit der ServiceIdentity-Ressource können Dienstidentitäten nur für unterstützte Dienste generiert werden. Führen Sie den folgenden Befehl aus, um zu prüfen, ob ein Dienst die Erstellung von Dienstidentitäten auf Abruf unterstützt, bevor Sie Ihre Konfiguration anwenden:

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, bedeutet das, dass Config Connector keine Identität für diesen Dienst erstellen kann.

Installation und Upgrades

Im folgenden Abschnitt werden häufige Probleme bei der Installation oder Aktualisierung der Config Connector-Version aufgeführt.

Version wird bei 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 sind.

Ursache

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

Lösung

Prüfen Sie, ob die Version des GKE-Cluster die Anforderungen an Version und Funktionen erfüllt, um diesen Fehler zu beheben. Achten Sie darauf, dass 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 den Anforderungen entspricht.

failed calling webhook

Symptom

Sie können Config Connector nicht deinstallieren und erhalten einen Fehler, der dem folgenden ähnelt:

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 bevor Sie die Config Connector-CRDs entfernen deaktivieren.

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 auf eine manuelle Installation umgestellt 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.

So prüfen Sie, ob die PodSecurityPolicies das Upgrade verhindern: Sehen Sie sich die Ereignisse von config-connector-operator an und suchen Sie nach einem Fehler, der dem folgenden ähnelt:

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 in der Fehlermeldung genannten Annotation entspricht. Im vorherigen Beispiel ist die Annotation seccomp.security.alpha.kubernetes.io.

Konfiguration

Im folgenden Abschnitt werden häufige Probleme bei 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, ist die einzige Möglichkeit, eine solche Aktualisierung vorzunehmen, die Ressource zu löschen und neu zu erstellen.

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

Kurz nach dem Erstellen oder Abrufen einer Google Cloud -Ressource mit Config Connector werden möglicherweise die folgenden Fehler im Status der Config Connector-Ressource 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 möglicherweise nicht, 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 von Ihnen in der Config Connector-Ressource verwaltet wurde. Dies führte zu einer Abweichung zwischen dem gewünschten und dem tatsächlichen Status 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 dem Live-Status entsprechen. Gehen Sie dazu so vor:

  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 Diskrepanz zwischen der gcloud CLI-Ausgabe und der YAML-Konfiguration der Config Connector-Ressource und aktualisieren Sie die entsprechenden Felder in der YAML-Konfiguration.
  6. Wenden Sie die aktualisierte YAML-Konfiguration an, um die verlassene Ressource zu übernehmen.

Keine Übereinstimmungen für Typ „Foo“

Symptom

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

Ursache

Die CRD für den Ressourcentyp Foo ist in Ihrem Kubernetes-Cluster nicht installiert.

Lösung

Prüfen Sie, ob der Typ ein von Config Connector unterstützter Ressourcentyp ist.

Wenn der Typ 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 den einzelnen 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 Ihrem YAML-Code werden nicht in der Google Cloud -Ressource 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. Sehen Sie in der REST API-Dokumentation der Ressource nach (z. B. API-Dokumentation für PubSubTopic), 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.

so festzulegen, dass sie der im Spec angegebenen Liste entspricht.

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:

  • Setzen Sie das Feld für ein Feld vom Typ „Liste“ mit [] auf eine leere Liste.

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

    spec:
  targetServiceAccounts:
    - external: "foo-bar@foo-project.iam.gserviceaccount.com"
    - external: "bar@foo-project.iam.gserviceaccount.com"

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

    spec:
  targetServiceAccounts: []

  • Legen Sie für ein Feld vom einfachen Typ das Feld mit einer der folgenden Methoden auf leer fest:

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

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

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

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

    spec:
  workloadIdentityConfig:
    identityNamespace: ""

  • Bei Feldern vom Objekttyp können Sie versuchen, die Unterfelder des Objekttyps gemäß der Anleitung im vorherigen Abschnitt als leer oder als Standardwert festzulegen und zu prüfen, ob das funktioniert. Dies funktioniert jedoch nicht garantiert.

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 folgende Symptome auftreten:

  • Pods im Namespace cnrm-system bleiben im Status Pending.
  • In den Logs von Pods wird möglicherweise ein CrashLoopBackOff mit einer Fehlermeldung wie dieser angezeigt: exec user process caused "exec format error".
  • Die Beschreibung des Pods zeigt Planungsfehler oder Architekturabweichungen auf.

Lösung

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

  • 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 nur für x86 entwickelte 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 am 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, hat Config Connector möglicherweise (aber nicht unbedingt) keine Möglichkeit, das Löschen der zugrunde liegendenGoogle Cloud -Ressource abzuschließen. Das bedeutet, dass Sie Ihre Google Cloud Ressourcen möglicherweise manuell löschen müssen.

Monitoring

Wenn Sie Config Connector im Blick behalten 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 hilfreich, wenn Sie Probleme mit dem Abgleich von Ressourcen beheben müssen.

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

  • logger: Enthält die Art der Ressource in Kleinbuchstaben. PubSubTopic-Ressourcen haben beispielsweise einen logger von 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 folgender 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, auf dem Config Connector ausgeführt wird. Beispiel: us-central1.
  • RESOURCE_KIND durch den Typ der Ressource in Kleinbuchstaben. Beispiel: pubsubtopic
  • RESOURCE_NAMESPACE durch den Namespace der Ressource.
  • RESOURCE_NAME durch den Namen der Ressource.

Zusätzliche Hilfe

Weitere Informationen erhalten Sie, wenn Sie ein Problem bei GitHub melden oder sich an den Google Cloud -Support wenden.