Fehlerbehebung bei Config Connector

Auf dieser Seite werden Techniken zur Fehlerbehebung beschrieben, mit denen Sie Probleme mit Config Connector beheben können. Außerdem werden häufige Probleme beschrieben, die bei der Verwendung des Produkts auftreten können.

Grundlegende Verfahren zur Fehlerbehebung

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-Modus installiert haben, gibt es für jeden Namespace, der für die Verwaltung der Config Connector-Ressourcen in diesem Namespace zuständig ist, einen Controller-Pod (cnrm-controller-manager).

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 Abgleichung von Config Connector-Ressourcen.

Sie können die Logs des Controller-Pods mit folgendem Befehl aufrufen:

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

Allgemeine Probleme

Ressource wird alle 5 bis 15 Minuten aktualisiert

Wenn Ihre Config Connector-Ressource alle 5 bis 10 Minuten zwischen dem Status UpToDate und dem Status Updating wechselt, erkennt Config Connector wahrscheinlich unbeabsichtigte Unterschiede zwischen dem gewünschten und dem tatsächlichen Status der Ressource. Dadurch wird die Ressource von Config Connector ständig aktualisiert.

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 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 mit 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. Beispiele 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, lesen Sie den Abschnitt Zusätzliche Hilfe.

Löschvorgänge von Namespaces, die im Status „Wird beendet“ hängen bleiben

Das Löschen von Namespaces kann bei Terminating hängen bleiben, wenn Config Connector im Namespaced-Modus installiert ist und das ConfigConnectorContext des Namespace gelöscht wurde, bevor alle Config Connector-Ressourcen in diesem Namespace gelöscht wurden. Wenn das 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.

Zur Behebung dieses Problems 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 den ConfigConnectorContext erst, nachdem 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.

Hier erfahren Sie auch, wie das Löschen eines Namespace, der ein Projekt und seine untergeordneten Elemente oder einen Ordner und seine untergeordneten Elemente enthält, hängen bleiben kann.

Löschvorgänge von Ressourcen bleiben nach dem Löschen des Projekts im Status „DeleteFailed“ hängen

Das Löschen von Config Connector-Ressourcen kann bei DeleteFailed hängen bleiben, wenn das zugehörige Google Cloud -Projekt zuvor gelöscht wurde.

Um dieses Problem zu beheben, stellen Sie das Projekt aufGoogle Cloudwieder her, damit Config Connector verbleibende untergeordnete 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 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.

Compute Engine-Metadaten nicht definiert

Wenn Ihre Config Connector-Ressource den Status UpdateFailed mit einer Meldung hat, dass die Compute Engine-Metadaten nicht definiert sind, bedeutet das wahrscheinlich, dass das von Config Connector verwendete IAM-Dienstkonto nicht vorhanden ist.

Beispiel für eine UpdateFailed-Meldung:

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:

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

Wenn Ihre Config Connector-Ressource den Status UpdateFailed mit einer Meldung hat, die auf einen 403-Fehler aufgrund unzureichender Authentifizierungsbereiche hinweist, ist Workload Identity wahrscheinlich nicht in Ihrem GKE-Cluster aktiviert.

Beispiel für eine UpdateFailed-Meldung:

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.

Führen Sie zur Untersuchung dieses Umstands folgende Schritte aus:

  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

Verwenden Sie zur Behebung dieses Problems einen GKE-Cluster, in dem die Workload Identity Federation for GKE aktiviert ist.

Wenn Sie weiterhin denselben Fehler in einem GKE-Cluster mit aktivierter Identitätsföderation von Arbeitslasten für GKE sehen, prüfen Sie, ob Sie die Identitätsföderation von Arbeitslasten für GKE auch für die Knotenpools des Clusters aktiviert haben. Weitere Informationen zum Aktivieren der Identitätsföderation von Arbeitslasten für GKE in vorhandenen Knotenpools Wir empfehlen, die Identitätsföderation von Arbeitslasten für GKE für alle Knotenpools Ihres Clusters zu aktivieren, da Config Connector in einem beliebigen dieser Pools ausgeführt werden kann.

403 Forbidden: Der Aufrufer hat keine Berechtigung. Weitere Informationen finden Sie in der Dokumentation zur Identitätsföderation von Arbeitslasten für GKE.

Wenn Ihre Config Connector-Ressource den Status UpdateFailed mit einer Meldung hat, die auf einen 403-Fehler aufgrund der Workload Identity-Föderation für GKE hinweist, fehlt dem Kubernetes-Dienstkonto von Config Connector wahrscheinlich die entsprechenden IAM-Berechtigungen, um die Identität Ihres IAM-Dienstkontos als Nutzer der Workload Identity-Föderation für GKE zu übernehmen.

Beispiel für eine UpdateFailed-Meldung:

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 Federation for GKE documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

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

Wenn Ihre Config Connector-Ressource den Status UpdateFailed mit einer Meldung hat, die besagt, dass dem Aufrufer eine IAM-Berechtigung fehlt, bedeutet das wahrscheinlich, dass dem von Config Connector verwendeten IAM-Dienstkonto die in der Meldung angegebene IAM-Berechtigung fehlt, die zum Verwalten der Google Cloud -Ressource erforderlich ist.

Beispiel für eine UpdateFailed-Meldung:

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:

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 Sie weiterhin denselben Fehler sehen, 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.

Version wird bei Installationen des Config Connector-Add-ons nicht unterstützt

Wenn Sie das Config Connector-Add-on nicht aktivieren können, wird folgende Fehlermeldung angezeigt: Node version 1.15.x-gke.x s unsupported. Prüfen Sie, ob die Version des GKE-Cluster die Anforderungen an Version und Funktionen erfüllt, um diesen Fehler zu beheben.

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.

Die Fehlermeldung wird auch angezeigt, wenn Workload Identity Federation for GKE oder GKE Monitoring deaktiviert sind. Achten Sie darauf, dass diese Funktionen aktiviert sind, um den Fehler zu beheben.

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, besteht die einzige Möglichkeit, eine solche Aktualisierung vorzunehmen, darin, 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 Diskrepanz zwischen dem gewünschten und dem aktuellen 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.

Ressource hat keinen Status

Wenn Ihre Ressourcen kein status-Feld haben, wird Config Connector wahrscheinlich nicht richtig ausgeführt. Prüfen Sie, ob Config Connector ausgeführt wird.

Keine Übereinstimmungen für Typ „Foo“

Wenn dieser Fehler auftritt, ist die CRD für den Ressourcentyp Foo in Ihrem Kubernetes-Cluster nicht installiert.

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 Google Cloud -Ressource weitergegeben

Config Connector überträgt Labels, die in metadata.labels gefunden werden, an die zugrunde liegendeGoogle Cloud -Ressource. Beachten Sie jedoch, dass nicht alle Google Cloud-Ressourcen Labels unterstützen. Sehen Sie in der REST API-Dokumentation der Ressource nach (z. B. API-Dokumentation für PubSubTopic), ob Labels unterstützt werden.

Fehler beim Aufrufen des Webhooks x509: certificate relies on legacy Common Name field

Wenn Sie einen Fehler wie im folgenden Beispiel sehen, liegt möglicherweise ein Problem mit Zertifikaten vor:

Error from server (InternalError): error when creating "/mnt/set-weaver-dns-record.yml": Internal error occurred: failed calling webhook "annotation-defaulter.cnrm.cloud.google.com": Post "https://cnrm-validating-webhook.cnrm-system.svc:443/annotation-defaulter?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

So umgehen Sie das Problem: Löschen Sie die entsprechenden Zertifikate und die Pods:

kubectl delete -n cnrm-system secrets cnrm-webhook-cert-abandon-on-uninstall
kubectl delete -n cnrm-system secrets cnrm-webhook-cert-cnrm-validating-webhook
kubectl delete -n cnrm-system pods -l "cnrm.cloud.google.com/component=cnrm-webhook-manager"

Nachdem Sie diese Ressourcen gelöscht haben, wird das richtige Zertifikat neu generiert.

Weitere Informationen zu diesem Fehler finden Sie im GitHub-Problem.

Fehler aufgrund von Sonderzeichen im Ressourcennamen

Sonderzeichen sind im Kubernetes-Feld metadata.name nicht zulässig. Wenn Sie einen Fehler wie im folgenden Beispiel sehen, enthält die metadata.name der Ressource wahrscheinlich einen Wert mit Sonderzeichen:

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])?)*')

Die folgende SQLUser-Ressource enthält beispielsweise ein ungültiges Zeichen in metadata.name:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: test.example@example-project.iam
spec:
  instanceRef:
    name: test-cloudsql-db
  type: "CLOUD_IAM_USER"

Wenn Sie versuchen, diese Ressource zu erstellen, erhalten Sie die folgende Fehlermeldung:

Error from server (Invalid): error when creating "sqlusercrd.yaml": SQLUser.sql.cnrm.cloud.google.com "test.example@example-project.iam" is invalid: metadata.name: Invalid value: "test.example@example-project.iam": 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])?)*')

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

Wenn Sie ein Feld aus der Spezifikation einer Config Connector-Ressource entfernen (indem Sie die .yaml-Datei der Ressource aktualisieren und noch einmal anwenden oder indem Sie kubectl edit verwenden, um die Ressourcenspezifikation zu bearbeiten), wird das Feld nicht aus der Spezifikation der Config Connector-Ressource oder der zugrunde liegenden Google Cloud Ressource entfernt. Wenn Sie ein Feld aus der Spezifikation entfernen, wird es stattdessen nur extern verwaltet.

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

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“ das Feld mit [] auf eine leere Liste fest.

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

  • Derzeit gibt es in Config Connector keine einfache Möglichkeit, ein ganzes Feld vom Typ „object“ auf „NULL“ zu setzen. Sie können versuchen, die Unterfelder des Objekttyps gemäß der Anleitung oben als leer oder als Standard festzulegen und zu prüfen, ob es funktioniert.

KNV2005: Syncer aktualisiert Ressource zu häufig

Wenn Sie Config Sync verwenden und KNV2005-Fehler für Config Connector-Ressourcen angezeigt werden, konkurrieren Config Sync und Config Connector wahrscheinlich um die Ressource.

Beispiel für eine Logmeldung:

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

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 die Aktion des anderen aus, die Ressource zu aktualisieren, was wiederum die Aktion des anderen auslöst, die Ressource zu aktualisieren usw.

Kämpfe sind für die meisten Felder kein Problem. Felder, die in Config Sync angegeben sind, 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 die meisten Felder niemals mit unterschiedlichen Werten aktualisieren.

Es gibt jedoch eine Ausnahme: 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 kommt es zu Konflikten zwischen Config Sync und Config Connector, wenn Config Sync ein Listenfeld festlegt und Config Connector für alle Unterfelder in dieser Liste Standardwerte verwendet.

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

  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 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 mit der Ressource auf dem Kubernetes API-Server übereinstimmt.

  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

failed calling webhook

Es kann vorkommen, dass sich Config Connector in einem Zustand befindet, in dem Sie Config Connector nicht deinstallieren können. Dies geschieht häufig, wenn Sie das Config Connector-Add-on verwenden und Config Connector bevor Sie die Config Connector-CRDs entfernen deaktivieren. Beim Deinstallieren erhalten Sie eine Fehlermeldung ähnlich der folgenden:

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

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.

Aktualisierungsfehler bei IAMPolicy, IAMPartialPolicy und IAMPolicyMember

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. Dies führt zu einem UpdateFailed-Status mit einer Fehlermeldung wie der folgenden:

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

Prüfen Sie, 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 werden Google 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 Google Cloud IAM-Dokumentation unter Dienstkonto löschen.

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

Von Config Connector gelöschte Ressource

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 erstellt und gelöscht hat. Wenn Sie beispielsweise Config Connector verwenden, stellen Sie möglicherweise Löschanfragen des Config Connector-Controller-Managers für bestimmte Ressourcen in Containerlogmeldungen oder Kubernetes-Cluster-Audit-Logs fest. Diese Löschanfragen sind das Ergebnis externer Trigger und Config Connector versucht, die Löschanfragen abzugleichen.

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

Wenn Sie in einem Config Connector-Controller-Pod den Fehler „OOMKilled“ sehen, bedeutet das, dass ein Container oder der gesamte Pod beendet wurde, weil er mehr Arbeitsspeicher als zulässig verwendet hat. Dies kann durch Ausführen des Befehls kubectl describe überprüft werden. Der Status des Pods kann als OOMKilled oder Terminating angezeigt werden. Außerdem können Sie in den Ereignisprotokollen des Pods nach OOM-bezogenen Ereignissen suchen.

kubectl describe pod POD_NAME -n cnrm-system

Ersetzen Sie POD_NAME durch den Pod, bei dem Sie die Fehlerbehebung durchführen.

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.

PodSecurityPolicy verhindert Upgrades

Nachdem Sie vom Config Connector-Add-on auf eine manuelle Installation umgestellt und Config Connector auf eine neue Version aktualisiert haben, kann die Verwendung von PodSecurityPolicies 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]

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.

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

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.

Cloud Logging für erweiterte Log-Abfragen 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

Wenn Sie weitere Hilfe benötigen, können Sie ein Problem bei GitHub melden oder sich an den Google Cloud -Support wenden.