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.

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 Ihre Problemkategorie aus:

Sie können auch nach bekannten Problemen filtern:

Kategorie Ermittelte Version Korrigierte Version Problem und Problemumgehung
Komponentenzustand 1.15.0 1.17.0

Problem behoben: Abgleichcontainer wird in Autopilot aufgrund von Arbeitsspeichermangel beendet

In Autopilot-Clustern sind für Config Sync-Komponentencontainer Ressourcenlimits für CPU und Arbeitsspeicher festgelegt. Unter Last können diese Container vom Kubelet oder Kernel beendet werden, wenn sie zu viel Arbeitsspeicher belegen.

Workaround:

Wenn Sie kein Upgrade auf Version 1.17.0 oder höher ausführen können, geben Sie mithilfe von Ressourcenüberschreibungen ein höheres Speicherlimit an.

In Version 1.17.0 wurden die Standard-CPU- und Arbeitsspeicherlimits angepasst, um bei den meisten Anwendungsfällen Fehler aufgrund von unzureichendem Arbeitsspeicher zu vermeiden.
Komponentenzustand 1.15.0

Abgleich nicht planbar

Config Sync-Abgleicher benötigen je nach Konfiguration von RootSync oder RepoSync unterschiedliche Ressourcen. Bestimmte Konfigurationen erfordern mehr Ressourcen als andere.

Wenn ein Abgleich nicht planbar ist, kann dies daran liegen, dass mehr Ressourcen angefordert werden, als auf Ihren Knoten verfügbar sind.

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

Workaround:

GKE Autopilot oder GKE Standard mit aktivierter automatischer Knotenbereitstellung sollten sehen können, wie viele Ressourcen angefordert werden, und Knoten in der richtigen Größe erstellen, um eine Planung zu ermöglichen. Wenn Sie jedoch die Knoten oder Knoteninstanzgrößen manuell konfigurieren, müssen Sie diese Einstellungen möglicherweise an die Ressourcenanforderungen des Abgleich-Pods anpassen.
KNV-Fehler 1.15.0 Kubernetes-Version 1.27

Behoben: KNV1067-Fehler, obwohl die Konfiguration erfolgreich angewendet wurde

Aufgrund eines Problems mit OpenAPI v2 wird möglicherweise der Fehler KNV1067 angezeigt, auch wenn Ihre Konfiguration erfolgreich angewendet wurde.

Workaround:

Wenn in Ihrem Cluster eine Kubernetes-Version vor 1.27 ausgeführt wird, achten Sie darauf, dass das Feld protocol explizit unter spec: containers: ports: festgelegt ist, auch wenn Sie die Standardeinstellung TCP verwenden.

KNV-Fehler 1.15.0 1.16.0, Kubernetes-Version 1.28

Behoben: Config Sync kann die KNV2002-Fehler nicht abgleichen

Wenn Config Sync keine Abgleichung mit einer KNV2002 error vornehmen kann, kann das an einem bekannten Problem liegen, das durch ein Problem mit client-go verursacht wird. Das Problem führt zu einer leeren Liste von Ressourcen in der external.metrics.k8s.io/v1beta1 API-Gruppe mit einer Fehlermeldung aus dem RootSync- oder RepoSync-Objekt oder den Abgleichslogs:

KNV2002: API discovery failed: APIServer error: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: received empty response for:
external.metrics.k8s.io/v1beta1
Messwerte 1.15.0 1.17.2

Problem behoben: Export fehlgeschlagen: Nicht erkannte Messwertlabels

In Version 1.15.0 wurden in Config Sync vielen Messwerten die Labels type und commit hinzugefügt. Diese Labels haben die Messwertkardinalität erhöht, was die Anzahl der exportierten Messwerte erhöht. Außerdem wurde die Attributverarbeitung hinzugefügt, um diese Labels beim Exportieren nach Cloud Monarch zu filtern. Diese Filterung war jedoch falsch konfiguriert, was zu Transformationsfehlern in den otel-collector-Protokollen führte.
Messwerte 1.15.0 1.16.1

Behoben: Fehler bei hoher Kardinalität von Messwerten und Transformationen

In Version 1.15.0 wurden in Config Sync vielen Messwerten die Labels type und commit hinzugefügt. Diese Labels haben die Messwertkardinalität erhöht, was die Anzahl der exportierten Messwerte erhöht. Außerdem wurde die Attributverarbeitung hinzugefügt, um diese Labels beim Exportieren nach Cloud Monarch zu filtern. Diese Filterung war jedoch falsch konfiguriert, was zu Transformationsfehlern in den otel-collector-Protokollen führte.

In Version 1.16.1 wurde das Typfeld entfernt, die Filterung korrigiert und das Commit-Feld zusätzlich aus Cloud Monitoring herausgefiltert. Dadurch wurden die Fehler behoben und die Kardinalität der Messwerte reduziert.
Messwerte 1.15.0

Export fehlgeschlagen. Berechtigung verweigert

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

Workaround:

otel-collector protokolliert Fehler, wenn Sie Cloud Monitoring nicht konfiguriert oder Cloud Monitoring deaktiviert und Cloud Monarch nicht deaktiviert haben.
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, verursacht der otel-collector einen Fehler oder stürzt ab, weil er die erforderliche ConfigMap nicht laden kann.

Workaround:

Erstellen Sie eine ConfigMap mit dem Namen otel-collector-custom im Namespace config-management-monitoring, um die Konfiguration des Messwertexports anzupassen.
Nomos-CLI 1.15.0 1.17.2

Behoben: nomos status und nomos bugreport funktionieren nicht in einem Pod

Vor nomos Version 1.17.2 konnten nomos bugreport und nomos status nur dann eine Verbindung zum lokalen Cluster herstellen, wenn sie in einem Kubernetes-Pod ausgeführt wurden. In Nomos-Version 1.17.2 wurde die Autorisierungsmethode so geändert, dass sie eher wie kubectl funktioniert. Aufgrund dieser Änderung wird der lokale Cluster standardmäßig als Ziel ausgewählt. Sie können die Konfiguration überschreiben, indem Sie die Umgebungsvariable KUBECONFIG angeben.
Zeitersparnis

Config Sync im Konflikt mit sich selbst

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-Konflikte mit Config Connector-Ressourcen

Config Sync wirkt sich möglicherweise so aus, als würde es Config Connector um eine Ressource bekämpfen, z. B. einen StorageBucket. Dieses Problem tritt auf, wenn Sie den Wert eines optionalen Felds einer Ressource spec.lifecycleRule.condition.withState nicht in der „Source of Truth“ festlegen.

Workaround:

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

Source of Truth 1.17.3 1.18.3

Korrigiert: Fehler bei der Git-SSH-Authentifizierung mit GitHub

In git-sync v4.2.1 gibt es einen Fehler, durch den der Nutzername bei Verwendung von SSH aus der Repository-URL entfernt wird. Dies führt dazu, dass die Authentifizierung bei der Verbindung zu GitHub fehlschlägt. Der Nutzer muss also git sein.

Die Fehlermeldung von git lautet: git-sync@github.com: Permission denied (publickey).\r\nfatal: Could not read from remote repository.

Workaround:

Verwenden Sie eine andere Authentifizierungsmethode.
Source of Truth 1.16.1 1.16.2

Fixed: Quelllink kann nicht regelmäßig ausgewertet werden

Bei Config Sync können Probleme auftreten, wenn der Resolver gestartet wird und der Quelllink regelmäßig nicht ausgewertet werden kann. Dieses Problem tritt auf, weil git-sync das Quell-Repository noch nicht geklont hat.

In Version 1.16.2 und höher ist dies ein vorübergehender Fehler. Er wird daher protokolliert, aber nicht als Fehler gemeldet.
Source of Truth 1.15.0 1.18.0

Behoben: Ungültige Anmeldedaten für Cloud Source Repositories

Bei Config Sync kann es regelmäßig zu Fehlern kommen, wenn das Authentifizierungstoken für Cloud-Quell-Repositories abläuft. Dieses Problem wird dadurch verursacht, dass das Token erst aktualisiert wird, wenn es abgelaufen ist.

In Version 1.18.0 und höher wird das Token bei der ersten Anfrage innerhalb von fünf Minuten nach Ablauf des Tokens aktualisiert. So wird verhindert, dass der Fehler „Ungültige Anmeldedaten“ auftritt, es sei denn, die Anmeldedaten sind tatsächlich ungültig.
Source of Truth 1.15.0 1.17.0

Behoben: Fehler beim Synchronisieren des Repositories: Kontextfrist überschritten

In Versionen vor 1.17.0 hat Config Sync standardmäßig den vollständigen Git-Repository-Verlauf herausgecheckt. Dies kann dazu führen, dass die Abrufanfrage bei großen Repositories mit vielen Commits zu lange dauert.

In Version 1.17.0 und höher wird der Git-Abruf mit --depth=1 ausgeführt, wodurch nur der letzte Commit abgerufen wird. Dies beschleunigt den Quellabruf, vermeidet die meisten Zeitüberschreitungen und reduziert die Git-Serverlast.

Wenn dieses Problem nach dem Upgrade weiterhin auftritt, enthält Ihre Source of Truth wahrscheinlich viele Dateien, Ihr Git-Server reagiert langsam oder es liegt ein anderes Netzwerkproblem vor.
Synchronisierung 1.15.0

Hohe Anzahl ineffektiver PATCH-Anfragen in den Audit-Logs

Das Config Sync-Remediator verwendet einen 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 Probelauf- und Nicht-Probelauf-Anfragen unterscheiden kann, können Sie die PATCH-Anfragen ignorieren.
Synchronisierung 1.17.0 1.17.3

Behoben: Config Sync ruft den neuesten Commit aus einem Branch nicht ab

In Config Sync Version 1.17.0, 1.17.1 und 1.17.2 kann ein Problem auftreten, bei dem Config Sync nicht den neuesten Commit vom HEAD eines bestimmten Zweigs abruft, wenn auf denselben Zweig in mehreren Remotes verwiesen wird und sie nicht synchron sind. Beispiel: Der Zweig main eines Remote-Repositories origin ist möglicherweise weiter als derselbe Zweig im Remote-Repository upstream. Config Sync ruft jedoch nur die SHA des Commits aus der letzten Zeile ab, was möglicherweise nicht der neueste Commit ist.

Das folgende Beispiel zeigt, wie dies aussehen könnte:

git ls-remote -q [GIT_REPOSITORY_URL] main  main^{}
244999b795d4a7890f237ef3c8035d68ad56515d    refs/heads/main               # the latest commit
be2c0aec052e300028d9c6d919787624290505b6    refs/remotes/upstream/main    # the commit Config Sync pulls from

In Version 1.17.3 und höher wurde die Abhängigkeit von git-sync durch einen anderen Abrufmechanismus aktualisiert.

Wenn Sie das Upgrade nicht durchführen können, können Sie Ihre Git-Revision (spec.git.revision) auf den SHA des letzten Commits festlegen, unabhängig vom Wert, der für den Git-Branch (spec.git.branch) festgelegt ist. Weitere Informationen zu den Git-Konfigurationen finden Sie unter Konfiguration für das Git-Repository.
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-Deployments.

Workaround:

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

Synchronisierung 1.17.0 1.18.3

Behoben: Der Config Sync-Abgleich verursacht einen Crashloop

In Config Sync Version 1.17.0 und höher kann ein Problem auftreten, bei dem der Reconciler bei einigen Kubernetes-Anbietern keine REST-Konfiguration erstellt.

Das folgende Beispiel zeigt, wie sich dieses Problem in den Protokollen des Abgleichs darstellen könnte:

Error creating rest config: failed to build rest config: reading local kubeconfig: loading REST config from "/.kube/config": stat /.kube/config: no such file or directory
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 ein neues Feld hinzugefügt: config_sync.enabled. Da der Standardwert dieses Felds false ist, schlägt die Installation von Config Sync fehl, wenn Terraform auf Version 5.41.0 aktualisiert wird.

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.

Nach oben

Nächste Schritte