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.

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 prüfen Sie anhand der Releasenotes, ob die ausgeführte Version die gewünschten Funktionen und Ressourcen unterstützt:

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 Überprüfen des Status und der Ereignisse einer Ressource ist besonders hilfreich, um festzustellen, ob der Config Connector die Ressource nicht abgeglichen hat 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 Pods ausgeführt werden:READY

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

Sie können den Status des Controller-Pods prüfen, der für einen bestimmten Namespace verantwortlich ist, indem Sie Folgendes ausführen:

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 der Abgleichung 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 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 der Config Connector-Logs

Ressource verwerfen und akquirieren

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

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

Allgemeine Probleme

Die Ressource wird alle 5 bis 15 Minuten aktualisiert

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

Prüfen Sie zuerst, ob es keine externen Systeme gibt, die entweder den Config Connector oder die Google Cloud -Ressource ständig ändern (z. B. CI/CD-Pipelines, benutzerdefinierte Controller, Cron-Jobs usw.).

Wenn das Problem 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 z. B. die Formatierung (z. B. die Großschreibung) von Feldwerten, was zu einer Abweichung zwischen dem gewünschten und dem tatsächlichen Status der 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 die Config Connector-Ressource entsprechend. Suchen Sie insbesondere nach Werten, die von Google Cloudneu formatiert wurden. Weitere Informationen finden Sie beispielsweise in den GitHub-Problemen #578 und #294.

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

Wenn Sie das Problem nicht selbst lösen können, lesen Sie den Hilfeartikel Weitere Hilfe.

Löschvorgänge von Namespaces bleiben bei „Beendigung“ hängen

Das Löschen von Namespaces bleibt möglicherweise bei Terminating hängen, wenn Config Connector im namespace-mode installiert ist und der ConfigConnectorContext des Namespaces gelöscht wurde, bevor alle Config Connector-Ressourcen in diesem Namespace gelöscht wurden. Wenn der ConfigConnectorContext eines Namespaces 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.

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 vollständigen Namespaces, bevor alle Config Connector-Ressourcen in diesem Namespace gelöscht wurden, da sonst möglicherweise zuerst der ConfigConnectorContext gelöscht wird.

Außerdem erfahren Sie, warum das Löschen eines Namespaces, der ein Projekt und seine untergeordneten Elemente oder einen Ordner und seine untergeordneten Elemente enthält, fehlschlagen kann.

Das Löschen von Ressourcen bleibt nach dem Löschen des Projekts bei „DeleteFailed“ hängen

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

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

Um dieses Problem in Zukunft zu vermeiden, sollten Sie Google Cloud -Projekte erst löschen, nachdem alle untergeordneten Config Connector-Ressourcen aus Kubernetes gelöscht wurden. Löschen Sie keine gesamten Namespaces, die sowohl eine Project-Ressource als auch die 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 der Meldung hat, dass die Compute Engine-Metadaten nicht definiert sind, bedeutet das wahrscheinlich, dass das vom Config Connector verwendete IAM-Dienstkonto nicht existiert.

Beispiel für eine UpdateFailed-Nachricht:

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 dieses Problem in Zukunft zu vermeiden, folgen Sie der Anleitung zur Installation von Config Connector.

Fehler 403: Die Anfrage enthielt unzureichende Authentifizierungsbereiche

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

Beispiel für eine UpdateFailed-Nachricht:

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 den Pod aus Ihrem GKE-Cluster:

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

Verwenden Sie zum Beheben dieses Problems einen GKE-Cluster mit aktivierter Workload Identity Federation for GKE.

Wenn Sie in einem GKE-Cluster mit aktivierter Identitätsföderation von Arbeitslasten für GKE weiterhin dieselbe Fehlermeldung erhalten, 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 der Meldung „403-Fehler aufgrund der Workload Identity-Föderation für GKE“ hat, fehlt dem Kubernetes-Dienstkonto von Config Connector wahrscheinlich die entsprechende IAM-Berechtigung, um Ihr IAM-Dienstkonto als Workload Identity-Föderation für GKE-Nutzer zu imitieren.

Beispiel für eine UpdateFailed-Nachricht:

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

Weitere Informationen zur Behebung und Vermeidung des Problems finden Sie in der Anleitung zur Installation von Config Connector.

Fehler 403: Dem Aufrufer fehlt die IAM-Berechtigung

Wenn Ihre Config Connector-Ressource den Status UpdateFailed hat und die Meldung enthält, 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-Nachricht:

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 der Fehler weiterhin angezeigt wird, nachdem Sie Ihrem IAM-Dienstkonto die entsprechenden IAM-Berechtigungen erteilt haben, prüfen Sie, ob die Ressource im richtigen Projekt erstellt wird. Prüfen Sie das Feld spec.projectRef der Config Connector-Ressource (oder die cnrm.cloud.google.com/project-id-Anmerkung, falls die Ressource kein spec.projectRef-Feld unterstützt) und achten Sie darauf, dass 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 Namespaces als Projekt-ID. Weitere Informationen zum Konfigurieren des Zielprojekts für Ressourcen auf Projektebene

Wenn derselbe Fehler weiterhin angezeigt wird, prüfen Sie, ob die Identitätsföderation von Arbeitslasten für GKE auf Ihrem GKE-Cluster aktiviert ist.

Um dieses Problem in Zukunft zu vermeiden, folgen Sie der Anleitung zur Installation von Config Connector.

Version wird bei Config Connector-Add-on-Installationen 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-Clusters 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 aus der Liste eine Version aus, die die Anforderungen erfüllt.

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.

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

Config Connector lehnt Aktualisierungen an unveränderlichen Feldern bei der Aufnahme 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 ins Stocken geraten können, wenn sie keine Zulassungsfehler verarbeiten.

Da Config Connector keine Aktualisierungen für unveränderliche Felder zulässt, ist die einzige Möglichkeit, eine solche Aktualisierung durchzuführen, die Ressource zu löschen und neu zu erstellen.

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

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 nicht unbedingt, dass Sie die Ressource tatsächlich aktualisiert haben. Möglicherweise wurde über die Google Cloud API eine Änderung an einem unveränderlichen Feld vorgenommen, das Sie in der Config Connector-Ressource verwaltet haben. Dies führte zu einer Abweichung zwischen dem gewünschten Status und dem Live-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 setzen Sie die Anmerkung 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. Lassen Sie die Config Connector-Ressource los.
  4. Drucken Sie den Live-Status der entsprechenden Google Cloud Ressource mit der gcloud CLI aus.
  5. Suchen Sie die Abweichung zwischen der gcloud-Befehlszeilenausgabe 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 abzurufen.

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 den Typ „Foo“

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

Prüfen Sie, ob es sich um einen von Config Connector unterstützten Ressourcentyp handelt.

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 ausführen.

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

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. In der REST API-Dokumentation der Ressource (z. B. API-Dokumentation für PubSubTopic) sehen Sie, ob Labels unterstützt werden.

Failed calling webhook 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

Löschen Sie die entsprechenden Zertifikate und Pods, um das Problem zu umgehen:

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 eine Fehlermeldung wie die folgende sehen, enthält 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, wird folgende Fehlermeldung angezeigt:

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 wieder anwenden oder die Ressourcenspezifikation mit kubectl edit bearbeiten), wird dieses Feld weder aus der Spezifikation der Config Connector-Ressource noch aus der zugrunde liegenden Google Cloud -Ressource entfernt. Wenn Sie ein Feld aus der Spezifikation entfernen, wird es stattdessen extern verwaltet.

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

  • Legen Sie für ein Feld vom Listentyp mit [] 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, setzen Sie den Wert auf „Leeres String-Objekt“:

    spec:
  targetServiceAccounts: []

  • Legen Sie für ein Feld mit einem primitiven Typ eines der folgenden Elemente fest, um es leer zu lassen:

    Typ Leere Werte
    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, setzen Sie den Wert auf „Leeres String-Objekt“:

    spec:
  workloadIdentityConfig:
    identityNamespace: ""

  • Bei Objekttypfeldern gibt es derzeit in Config Connector keine einfache Möglichkeit, ein ganzes Objekttypfeld auf „NULL“ zu setzen. Sie können versuchen, die Unterfelder des Objekttyps wie oben beschrieben auf „Leeres Feld“ oder „Standard“ festzulegen und prüfen, ob das Problem dadurch behoben wird.

KNV2005: Synchronisierer aktualisiert Ressource zu oft

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

Beispiel für eine Protokollmeldung:

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 konkurrieren um eine Ressource, wenn sie immer wieder dasselbe Feld bzw. dieselben Felder mit unterschiedlichen Werten aktualisieren. Das Update einer Ressource löst eine Aktion der anderen aus, die die Ressource aktualisiert, was wiederum eine Aktion der anderen auslöst, die die Ressource aktualisiert usw.

Bei den meisten Feldern ist das 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 bei den meisten Feldern niemals dasselbe Feld auf unterschiedliche Werte aktualisieren.

Es gibt jedoch eine Ausnahme: Listenfelder. Ähnlich wie Config Connector Standardunterfelder in Objektfeldern festlegen kann, kann er auch Standardunterfelder in Objekten in Listen festlegen. Da Listenfelder in Config Connector-Ressourcen jedoch atomar sind, wird das Festlegen von Unterfeldern auf Standardwerte als vollständige Änderung des Listenwerts betrachtet.

Daher kommt es zu Konflikten zwischen Config Sync und Config Connector, wenn Config Sync ein Listenfeld festlegt und Config Connector alle untergeordneten Felder in dieser Liste standardmäßig festlegt.

Sie haben folgende Möglichkeiten, dieses Problem zu umgehen:

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

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

  2. Wenn Config Sync nicht mehr auf Aktualisierungen der Ressource auf dem Kubernetes API-Server reagieren soll, setzen Sie die Anmerkung client.lifecycle.config.k8s.io/mutation auf ignore. Weitere Informationen zum Ignorieren von Objektmutationen durch Config Sync

  3. Wenn Sie verhindern möchten, dass Config Connector die Spezifikation der Ressource vollständig aktualisiert, setzen Sie die Annotation cnrm.cloud.google.com/state-into-spec auf absent. Diese Anmerkung wird nicht für alle Ressourcen unterstützt. Ob Ihre Ressource die Anmerkung unterstützt, sehen Sie auf der entsprechenden Referenzseite für die Config Connector-Ressourcen. Weitere Informationen zur Anmerkung

failed calling webhook

Es kann sein, dass Config Connector sich in einem Status befindet, in dem er nicht deinstalliert werden kann. Das passiert häufig, wenn Sie das Config Connector-Add-on verwenden und Config Connector bevor Sie die Config Connector-CRDs entfernen deaktivieren. Beim Versuch, die Deinstallation durchzuführen, erhalten Sie eine Fehlermeldung wie die folgende:

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

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

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

Sie können dann mit der Deinstallation von Config Connector fortfahren.

Aktualisierungsfehler bei IAMPolicy, IAMPartialPolicy und IAMPolicyMember

Wenn Sie eine IAMServiceAccount-Config Connector-Ressource löschen, bevor Sie IAMPolicy-, IAMPartialPolicy- und IAMPolicyMember-Ressourcen bereinigen, die von diesem Dienstkonto abhängen, kann Config Connector das in diesen IAM-Ressourcen referenzierte Dienstkonto bei der Abgleichung nicht finden. Dies führt zu einem Status von UpdateFailed 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 Ihre Dienstkonten, um zu sehen, 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 bei IAMPolicyMember die gesamte Ressource. Entfernen Sie für IAMPolicy und IAMParitialPolicy nur die Verknüpfungen, die das gelöschte Dienstkonto betreffen. Durch diese Bereinigung werden die Rollenbindungen jedoch nicht sofort entfernt. Google Cloud Die Google Cloud -Rollenbindungen bleiben aufgrund der Aufbewahrungsdauer des gelöschten Dienstkontos 60 Tage lang erhalten. Weitere Informationen finden Sie in der Google Cloud IAM-Dokumentation unter Dienstkonto löschen.

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

Von Config Connector gelöschte Ressource

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

Es ist ein weit verbreiteter Irrtum, 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 aus Containerprotokollnachrichten oder Kubernetes-Cluster-Audit-Logs. Diese Löschanfragen sind auf externe Trigger zurückzuführen und Config Connector versucht, die Löschanfragen abzugleichen.

Wenn Sie wissen möchten, warum eine Ressource gelöscht wurde, müssen Sie sich die erste Löschanfrage ansehen, die an die entsprechende Ressource gesendet wurde. Am besten untersuchen Sie dazu die Audit-Logs des Kubernetes-Clusters.

Wenn Sie beispielsweise GKE verwenden, können Sie mit Cloud Logging GKE-Cluster-Audit-Logs abfragen. Wenn Sie beispielsweise nach den ursprünglichen Löschanfragen für eine BigQueryDataset-Ressource namens 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 Löschprotokollnachricht, um die Ursache für das Löschen zu ermitteln.

Controller-Pod aufgrund von fehlendem Arbeitsspeicher beendet

Wenn bei einem Config Connector-Controller-Pod der Fehler „OOMKilled“ angezeigt wird, wurde ein Container oder der gesamte Pod beendet, weil er mehr Arbeitsspeicher als zulässig verbraucht hat. Sie können dies mit dem Befehl kubectl describe prüfen. Der Status des Pods kann OOMKilled oder Terminating sein. 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, für den Sie die Fehlerbehebung durchführen.

Sie können dieses Problem beheben, indem Sie mit der benutzerdefinierten Ressource ControllerResource die Speicheranfrage und das Speicherlimit für den Pod erhöhen.

PodSecurityPolicy verhindert Upgrades

Wenn Sie vom Config Connector-Add-on zu einer manuellen Installation gewechselt und Config Connector auf eine neue Version aktualisiert haben, kann die Verwendung von PodSecurityPolicies verhindern, dass cnrm-Pods aktualisiert werden.

Um zu bestätigen, dass das Upgrade durch die PodSecurityPolicies verhindert wird, 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]

Um dieses Problem zu beheben, müssen Sie die Anmerkung in der PodSecurityPolicy angeben, die der im Fehler erwähnten Anmerkung entspricht. Im vorherigen Beispiel ist das seccomp.security.alpha.kubernetes.io.

Erzwungene Bereinigung

Wenn das Löschen Ihrer Config Connector-Ressourcen nicht abgeschlossen wird und Sie sie einfach aus Ihrem Kubernetes-Cluster entfernen möchten, können Sie das Löschen erzwingen, indem Sie die Finalisierer löschen.

passiert.

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

Da die Ressource durch das Löschen der Finalisierer 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. Daher sollten Sie Ihre Google Cloud Ressourcen danach manuell löschen.

Monitoring

Messwerte

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

Logging

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

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

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. Beispiel: PubSubTopic-Ressourcen haben 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 Protokollabfragen verwenden

Wenn Sie GKE verwenden, können Sie mit folgender Abfrage mit Cloud Logging nach Logs für eine bestimmte Ressource suchen:

# 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-Clusters ersetzen, in dem Config Connector ausgeführt wird
  • GKE_CLUSTER_LOCATION mit dem Standort des GKE-Clusters, in dem Config Connector ausgeführt wird. Beispiel: us-central1.
  • RESOURCE_KIND mit dem in Kleinbuchstaben geschriebenen Typ der Ressource. Beispiel: pubsubtopic
  • RESOURCE_NAMESPACE durch den Namespace der Ressource.
  • RESOURCE_NAME durch den Namen der Ressource.

Zusätzliche Hilfe

Wenn du weitere Hilfe benötigst, kannst du ein Problem bei GitHub melden oder dich an den Google Cloud -Support wenden.