Bekannte Probleme mit Config Sync

Auf dieser Seite sind bekannte Probleme mit unterstützten Versionen von Config Sync aufgeführt.

Viele der hier aufgeführten Probleme wurden behoben. In der Spalte Version, in der der Fehler behoben wurde wird die Version angegeben, in der die Fehlerbehebung eingeführt wurde. Wenn Sie diese Fehlerbehebung erhalten möchten, führen Sie ein Upgrade auf die aufgeführte Version oder höher aus.

Wenn Sie am Google-Entwicklerprogramm teilnehmen, speichern Sie diese Seite, um Benachrichtigungen zu erhalten, wenn eine Versionsanmerkung zu dieser Seite veröffentlicht wird. Weitere Informationen finden Sie unter Gespeicherte Seiten.

Zum Filtern der bekannten Probleme nach einer Produktversion oder -kategorie wählen Sie in den folgenden Drop-down-Menüs die gewünschten Filter aus.

Wählen Sie die Config Sync-Version aus:

Wählen Sie eine Kategorie für Ihr Problem aus:

Sie können auch nach bekannten Problemen filtern:

Kategorie Ermittelte Version Korrigierte Version Problem und Problemumgehung
Messwerte 1.5.0 1.21.0

Problem behoben: Messwerte für gelöschte Pakete werden gemeldet

Wenn Sie ein RootSync- oder RepoSync-Objekt löschen, aber nicht das ResourceGroup-Objekt mit demselben Namen, meldet Config Sync weiterhin die folgenden Messwerte für dieses ResourceGroup-Objekt:

  • rg_reconcile_duration_seconds
  • resource_group_total
  • resource_count
  • ready_resource_count
  • resource_ns_count
  • cluster_scoped_resource_count
  • crd_count
  • kcc_resource_count
  • pipeline_error_observed
Das ResourceGroup-Objekt wird nur dann automatisch gelöscht, wenn die Löschweitergabe vor dem Löschen des RootSync- oder RepoSync-Objekts aktiviert wurde.

Workaround:

Löschen Sie das ResourceGroup-Objekt:

kubectl delete resourcegroup RESOURCE_GROUP_NAME -n config-management-system

Ersetzen Sie RESOURCE_GROUP_NAME durch den Namen des ResourceGroup-Objekts, das gelöscht werden muss. Weitere Informationen zur Benennung von ResourceGroup finden Sie unter Objekte „ResourceGroup Controller“ und „ResourceGroup“.
Komponentenzustand 1.15.0

Abgleich nicht planbar

Config Sync-Abgleicher benötigen je nach Konfiguration des RootSync- oder RepoSync-Objekts unterschiedliche Mengen an Ressourcen. Für bestimmte Konfigurationen sind mehr Ressourcen erforderlich als für andere.

Wenn ein Abgleichsprozess nicht geplant werden kann, liegt das möglicherweise daran, dass mehr Ressourcen angefordert werden, als auf Ihren Knoten verfügbar sind.

Wenn Sie GKE-Cluster im Standardmodus verwenden, sind die Ressourcenanforderungen des Abgleichs sehr niedrig. Diese Einstellung wurde gewählt, um die Planung zu ermöglichen, auch wenn dies zu einer Drosselung und langsamen Leistung führen würde, damit Config Sync auf kleinen Clustern und kleinen Knoten funktioniert. In GKE Autopilot-Clustern sind die Abgleicheranfragen jedoch höher, um die Nutzung während der Synchronisierung realistischer darzustellen.

Workaround:

GKE Autopilot oder GKE Standard mit aktivierter automatischer Knotenbereitstellung sollte in der Lage sein, die Anzahl der angeforderten Ressourcen zu erkennen und entsprechend dimensionierte Knoten für die Planung zu erstellen. Wenn Sie die Knoten oder die Knotengrößen jedoch manuell konfigurieren, müssen Sie diese Einstellungen möglicherweise an die Ressourcenanforderungen des Reconciler-Pods anpassen.
Messwerte 1.15.0

Export fehlgeschlagen. Berechtigung verweigert

Wenn der Reconciler-Manager Standardanmeldedaten für Anwendungen erkennt, wird der otel-collector standardmäßig so konfiguriert, dass Messwerte in Prometheus, Cloud Monitoring und Monarch exportiert werden.

Workaround:

otel-collector protokolliert Fehler, wenn Sie Cloud Monitoring nicht konfiguriert oder Messwertfilter angepasst haben und Cloud Monarch nicht konfiguriert ist.
Messwerte 1.15.0

otel-collector stürzt mit benutzerdefinierter Konfiguration ab

Wenn Sie versuchen, eine der Standard-ConfigMaps, otel-collector oder otel-collector-google-cloud, zu ändern oder zu löschen, kann es sein, dass der otel-collector einen Fehler ausgibt oder abstürzt, weil die erforderliche ConfigMap nicht geladen werden kann.

Workaround:

Wenn Sie die Konfiguration für den Messwertexport anpassen möchten, erstellen Sie eine ConfigMap mit dem Namen otel-collector-custom im Namespace config-management-monitoring.
Zeitersparnis

Config Sync-Konflikte

Config Sync befindet sich möglicherweise in einem Controller-Konflikt mit sich selbst. Dieses Problem tritt auf, wenn Sie den Standardwert für ein optionales Feld einer Ressource im Git-Repository festlegen. Wenn Sie beispielsweise apiGroup: "" für das Element eines RoleBinding festlegen, wird dieses Problem ausgelöst, da das Feld apiGroup optional und ein leerer String der Standardwert ist. Die Standardwerte der String-, booleschen und Ganzzahlfelder sind "", false bzw. 0.

Workaround:

Entfernen Sie das Feld aus der Ressourcendeklaration.
Zeitersparnis

Config Sync konkurriert mit Config Connector-Ressourcen

Config Sync scheint mit Config Connector um eine Ressource zu kämpfen, z. B. um einen StorageBucket. Dieses Problem tritt auf, wenn Sie den Wert eines optionalen Felds einer Ressource spec.lifecycleRule.condition.withState in der „Source of Truth“ nicht festlegen.

Workaround:

Sie können dieses Problem vermeiden, indem Sie das Feld withState=ANY in der Ressourcendeklaration hinzufügen. Alternativ können Sie die Ressource aufgeben und dann mit der Annotation cnrm.cloud.google.com/state-into-spec: absent neu erwerben.

Source of Truth 1.13.0 1.20.1

Behoben: Zugriffstoken für OCI-Quelle kann nicht generiert werden

Wenn Config Sync für die Verwendung von OCI als Single Source of Truth konfiguriert ist und die Authentifizierung mit Workload Identity Federation for GKE erfolgt, können bei Config Sync gelegentlich temporäre KNV2004-Fehler auftreten, wenn versucht wird, sich bei der Containerregistrierung zu authentifizieren.

Dieses Problem wird dadurch verursacht, dass die oauth2-Bibliothek das Autorisierungstoken erst aktualisiert, nachdem es bereits abgelaufen ist.

Die Fehlermeldung enthält möglicherweise den folgenden Text: "oauth2/google: unable to generate access token" oder "ID Token issued at (xxx) is stale to sign-in."

Workaround:

Der Fehler sollte beim nächsten Versuch von Config Sync, Daten aus der „Source of Truth“ abzurufen, behoben werden.

Wenn bei Config Sync mehrere Fehler aufgetreten sind, werden Wiederholungsversuche seltener. Wenn Sie erzwingen möchten, dass Config Sync es früher noch einmal versucht, löschen Sie den Reconciler-Pod. Dadurch wird der Reconciler-Pod von Config Sync neu erstellt und sofort aus der „Source of Truth“ abgerufen:

    kubectl delete pod -n config-management-system RECONCILER_NAME
Ersetzen Sie RECONCILER_NAME durch den Namen des Abgleichers des RootSync- oder RepoSync-Objekts.
Source of Truth 1.20.0 1.21.3

git-sync-Container stürzt nach dem Verwaistwerden einer Git-Sperrbildschirmdatei immer wieder ab

Wenn der git-sync-Container mit Fehlern abstürzt, die im git-sync-Containerlog so oder ähnlich aussehen, ist möglicherweise ein vorheriger git-Aufruf fehlgeschlagen und hat eine verwaiste Sperrdatei im Container hinterlassen:

    {"logger":""..."msg":"repo contains lock file","error":null,"path":"/repo/source/.git/shallow.lock"}
    ...runtime error: invalid memory address or nil pointer dereference

Workaround:

Starten Sie den betroffenen Abgleich-Pod neu, um ihm ein neues temporäres Volume zuzuweisen:

    kubectl delete pod -n config-management-system RECONCILER_NAME
Ersetzen Sie RECONCILER_NAME durch den Namen des Abgleichers des RootSync- oder RepoSync-Objekts.
Source of Truth 1.19.0 1.20.0

Behoben: Verweilende Git-Sperrbildschirmdatei

Wenn Sie im git-sync-Container einen Fehler wie den folgenden sehen, ist möglicherweise ein vorheriger git-Aufruf fehlgeschlagen und hat eine laufende Sperrdatei im Container hinterlassen:

    KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...

Workaround:

Starten Sie den betroffenen Abgleich-Pod neu, um ihm ein neues temporäres Volume zuzuweisen:

    kubectl delete pod -n config-management-system RECONCILER_NAME
Ersetzen Sie RECONCILER_NAME durch den Namen des Abgleichers des RootSync- oder RepoSync-Objekts.
Wird synchronisiert 1.7.0 1.21.0

Behoben: Mutationsanmerkung „Ignorieren“ wird nicht berücksichtigt

Ein Fehler im Config Sync-Abstimmer führt dazu, dass Änderungen aus deklarierten Konfigurationen auch dann angewendet werden, wenn die Annotation client.lifecycle.config.k8s.io/mutation vorhanden ist. Dadurch wird möglicherweise der Status des Objekts im Cluster überschrieben.

Workaround:

Sie können die Verwaltung des verwalteten Objekts beenden, indem Sie die Annotation configmanagement.gke.io/managed: disabled hinzufügen. Wenn Sie die Verwaltung jedoch deaktivieren, kann Config Sync das Objekt nicht neu erstellen, wenn es aus dem Cluster gelöscht wird. Außerdem wird verhindert, dass weitere Aktualisierungen in der Single Source of Truth angewendet werden.
Wird synchronisiert 1.5.0 1.20.1

Behoben: API-Erkennungsfehler können dazu führen, dass verwaltete Objekte fälschlicherweise als Not Found gekennzeichnet werden.

Wenn ein API-Dienst-Backend fehlerhaft ist, kann dies zu Fehlern bei der API-Erkennung führen. Wenn dies während des Starts des ResourceGroup-Controllers nach einer Aktualisierung oder Neuplanung geschieht, kann der Ressourcen-Cache nicht initialisiert werden. Dies führt dazu, dass alle verwalteten Objekte im ResourceGroup-Status als Not Found gemeldet werden.

Dieses Problem tritt häufig auf, wenn die metrics-server nicht in gutem Zustand ist.

Workaround:

Starten Sie den resource-group-controller-Pod neu, nachdem metrics-server wieder fehlerfrei ist:

    kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME
Ersetzen Sie RESOURCE_GROUP_CONTROLLER_NAME durch den Namen des ResourceGroup-Controllers, der mit dem RootSync- oder RepoSync-Namen für dieses Paket identisch ist.
Wird synchronisiert 1.15.0

Hohe Anzahl ineffektiver PATCH-Anfragen in den Audit-Logs

Der Config Sync-Remediator verwendet Probelauf, um Abweichungen zu erkennen. Dies kann dazu führen, dass PATCH-Anfragen im Audit-Log angezeigt werden, auch wenn das PATCH nicht beibehalten wird, da das Audit-Log nicht zwischen Probeläufen und normalen Anfragen unterscheidet.

Workaround:

Da das Audit-Log nicht zwischen Probeläufen und normalen Anfragen unterscheiden kann, können Sie die PATCH-Anfragen ignorieren.
Private Registry 1.19.0

Config Sync verwendet keine private Registry für Bereitstellungen von Reconcilern

Config Sync sollte die Images für alle Bereitstellungen ersetzen, wenn eine private Registry konfiguriert ist. Config Sync ersetzt jedoch nicht die Image-Registry für Images in den Reconciler-Bereitstellungen.

Workaround:

Als Behelfslösung können Sie den Image-Registry-Mirror in containerd konfigurieren.

Wird synchronisiert 1.7.0 1.21.0

Behoben: Aktualisiertes Inventar konnte nicht in den Cluster geschrieben werden

Wenn Config Sync den Status eines ResourceGroup-Objekts nicht aktualisieren kann, tritt möglicherweise ein zeitweiliger Fehler in den Abgleichslogs auf, der dem folgenden ähnelt:

    KNV2009: task failed (action: "Inventory", name: "inventory-set-0"): failed to write updated inventory to cluster: Operation cannot be fulfilled on resourcegroups.kpt.dev "root-sync": the object has been modified; please apply your changes to the latest version and try again

Dieser Fehler ist auf eine Wettlaufbedingung zwischen dem Abgleich und dem ResourceGroup-Controller zurückzuführen. Der ResourceGroup-Controller aktualisiert möglicherweise den ResourceGroup-Status, bevor der Reconciler die ResourceGroup-Spezifikation aktualisieren kann. Dies führt zum KNV2009-Fehler.

Workaround:

Für dieses Problem gibt es keine Umgehungslösung. Der Fehler sollte sich von selbst beheben.
Terraform Terraform-Version 5.41.0

Config Sync kann nicht mit Terraform installiert oder aktualisiert werden

In Terraform-Version 5.41.0 wurde der google_gke_hub_feature_membership-Ressource ein neues Feld hinzugefügt: config_sync.enabled. Da der Standardwert dieses Felds false ist, schlägt die Installation oder das Upgrade von Config Sync fehl, wenn dieses Feld nicht explizit auf true gesetzt wird und Terraform Version 5.41.0 oder höher verwendet wird. Möglicherweise wird auch die Fehlermeldung git spec not included in configmanagement spec angezeigt, wenn dieses Problem auftritt.

Workaround:

  • Wenn Sie die Ressource google_gke_hub_feature_membership verwenden, legen Sie config_sync.enabled manuell auf true fest.
  • Wenn Sie das acm-Submodul verwenden, sollten Sie zu einer alternativen Installationsmethode für Config Sync wechseln. Wenn Sie nicht wechseln können, führen Sie ein Upgrade auf v33.0.0 durch.

Google Cloud Console

Fehler durch fehlende Daten im Config Sync-Dashboard in der Google Cloud -Konsole

In Dashboards in der Google Cloud -Konsole werden möglicherweise Fehler wie „Fehlende Daten“ oder „Ungültige Clusteranmeldedaten“ für Config Sync-Cluster angezeigt. Dieses Problem kann auftreten, wenn Sie nicht in Ihren GDC-Clustern (VMware) oder GDC-Clustern (Bare Metal) angemeldet sind.

Workaround:

Wenn diese Arten von Fehlern in der Google Cloud -Konsole Ihrer GDC-Cluster (VMware) oder GDC-Cluster (Bare Metal) angezeigt werden, müssen Sie darauf achten, dass Sie mit GKE Identity Service oder dem Connect-Gateway in Ihren Clustern angemeldet sind.

Wird synchronisiert 1.21.0

Behoben: Config Sync verhindert Aktualisierungen verwaister Ressourcen

Vor Version 1.21.0 können beim Löschen eines RootSync- oder RepoSync-Objekts mehrere Labels und Annotationen zurückbleiben, die von Config Sync zum Nachverfolgen dieser Ressourcenobjekte verwendet werden.

Diese Labels und Annotationen können nach dem Löschen eines RootSync- oder RepoSync-Objekts die folgenden Nebenwirkungen haben:

  • Andere RepoSync-Objekte können nicht die Inhaberschaft von zuvor verwalteten Objekten übernehmen.
  • Wenn die Drift-Prävention aktiviert ist, kann dies dazu führen, dass Config Sync Änderungen an verworfenen Ressourcen ablehnt.
nomos-Befehlszeilentool 1.17.0

Die nomos-CLI unterstützt das oidc-Authentifizierungs-Plug-in nicht.

Wenn Sie das nomos-Befehlszeilentool verwenden, werden möglicherweise Fehler wie no Auth Provider found for name "oidc" angezeigt. Dieses Problem kann auftreten, wenn Sie das Authentifizierungs-Plug-in oidc verwenden.

Workaround:

Es gibt keine Problemumgehung. Das oidc-Authentifizierungs-Plug-in wird in einem späteren Release wieder hinzugefügt.

Nach oben

Nächste Schritte

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Informationen, unter anderem zu den folgenden Themen: