Bekannte Probleme mit Config Sync

Auf dieser Seite werden bekannte Probleme für unterstützte Versionen von Config Sync aufgeführt. Um die bekannten Probleme nach einer Produktversion oder Problemkategorie zu filtern, wählen Sie Ihre Filter aus den folgenden Drop-down-Menüs aus.

Wählen Sie Ihre Config Sync-Version aus:

Wählen Sie die Problemkategorie aus:

Oder filtern Sie nach bekannten Problemen:

Kategorie Ermittelte Version Korrigierte Version Problem und Problemumgehung
Komponentenzustand 1.15.0 1.17.0

Abgleichscontainer bei AutoPilot „OOMKilled“

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 wegen zu hoher Arbeitsspeichernutzung beendet werden.

Workaround:

Führen Sie ein Upgrade auf Version 1.17.0 oder höher aus. In Config Sync Version 1.17.0 wurden die standardmäßigen CPU- und Arbeitsspeicherlimits angepasst, um in den meisten Anwendungsfällen Fehler aufgrund von unzureichendem Arbeitsspeicher zu vermeiden.

Wenn Sie kein Upgrade durchführen können, geben Sie mithilfe von Ressourcenüberschreibungen ein höheres Arbeitsspeicherlimit an.

Komponentenzustand 1.15.0

Abgleich nicht planbar

Config Sync-Abgleiche erfordern 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 Ressourcenanfragen für den Abgleich sehr niedrig eingestellt. Mit dieser Einstellung wurde versucht, die Planung auch dann zu ermöglichen, wenn dies zu einer Drosselung und verlangsamten Leistung führen würde. Dadurch wird Config Sync auf kleinen Clustern und kleinen Knoten ausgeführt. In GKE Autopilotclusters sind die Anfragen für den Abgleich höher eingestellt, um die Nutzung während der Synchronisierung realistischer darzustellen.

Workaround:

GKE Autopilot oder GKE Standard mit aktivierter automatischer Knotenbereitstellung sollte sehen können, wie viele Ressourcen angefordert werden, und Knoten der passenden Größe erstellen, um die Planung zu ermöglichen. Wenn Sie die Knoten oder Knoteninstanzgrößen jedoch manuell konfigurieren, müssen Sie diese Einstellungen möglicherweise anpassen, um die Anforderungen an Pod-Ressourcen zu erfüllen.
KNV-Fehler 1.15.0 Kubernetes-Version 1.27

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 auf Ihrem Cluster eine Kubernetes-Version vor 1.27 ausgeführt wird, muss das Feld protocol explizit unter spec: containers: ports: festgelegt sein, auch wenn Sie die Standardeinstellung TCP verwenden.

KNV-Fehler 1.15.0 1.16.0

Config Sync konnte nicht mit dem KNV2002-Fehler abgeglichen werden

Wenn Config Sync nicht mit einem KNV2002 error abgeglichen werden kann, ist dies möglicherweise auf ein bekanntes Problem zurückzuführen, das durch ein client-go-Problem verursacht wird. Das Problem führt zu einer leeren Liste von Ressourcen in der API-Gruppe external.metrics.k8s.io/v1beta1 mit einer Fehlermeldung vom 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

Workaround:

Aktualisieren Sie Ihren GKE-Cluster auf GKE-Version 1.28 oder höher oder führen Sie ein Upgrade von Config Sync auf Version 1.16.0 oder höher aus, um das Problem zu beheben. Beide Versionen enthalten Fehlerkorrekturen für das client-go-Problem.
Messwerte 1.15.0 1.17.2

Export fehlgeschlagen: Unbekannte Messwertlabels

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

Workaround:

Führen Sie ein Upgrade auf Version 1.17.2 oder höher aus.
Messwerte 1.15.0 1.16.1

Hohe Messwertkardinalität und Umwandlungsfehler

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

Workaround:

Führen Sie ein Upgrade auf Version 1.16.1 oder höher aus. In Version 1.16.1 wurde das Typfeld entfernt, die Filterung korrigiert und das Commit-Feld zusätzlich aus Cloud Monitoring gefiltert. Dadurch wurden die Fehler behoben und die Kardinalität der Messwerte verringert.
Messwerte 1.15.0

Export fehlgeschlagen. Berechtigung verweigert

Wenn der Abgleichsmanager 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 und Cloud Monarch deaktiviert haben.
Messwerte 1.15.0

Otel-Collector stürzt bei benutzerdefinierter Konfiguration ab

Wenn Sie versuchen, eine der Standard-ConfigMaps otel-collector oder otel-collector-google-cloud zu ändern oder zu löschen, tritt möglicherweise ein Fehler auf oder stürzt ab, weil die erforderliche ConfigMap nicht geladen werden kann.

Workaround:

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

Summenwerte für fehlende Messwerte

In Config Sync Version 1.14.0 wurden die folgenden Messwerte entfernt: resource_count_total, ready_resource_count_total und kcc_resource_count_total.

Workaround:

Verwenden Sie zum Verfolgen von Gesamtwerten in Cloud Monitoring den Aggregationstyp "Summe".
Messwerte 1.14.1

Fehlende Pod-Messwerte

In Config Sync Version 1.14.1 wurden die meisten Config Sync-Messwerte so geändert, dass sie den Typ k8s_container anstelle des Typs k8s_pod verwenden. Dadurch konnte ermittelt werden, aus welchem Container der Messwert stammt, was besonders für die Abgleich-Pods nützlich ist, die viele Container haben. Aufgrund dieser Änderung funktionieren Dashboards und Benachrichtigungen, mit denen diese Messwerte erfasst wurden, möglicherweise nicht mehr.

Workaround:

Aktualisieren Sie die Messwerte, um den Messwert vom Typ k8s_container zu erfassen.

Nomos Cli 1.15.0 1.17.2

nomos status und nomos bugreport funktionieren nicht in einem Pod

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

Workaround:

Führen Sie ein Upgrade auf die nomos-Version 1.17.2 aus.

Zeitersparnis

Config Sync kämpft mit sich selbst

Config Sync befindet sich möglicherweise in einem Controller-Kampf. 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 Subjekt einer RoleBinding festlegen, wird dies 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

Es kann so aussehen, als ob Config Sync Config Connector mit einer Ressource, z. B. einem StorageBucket, gekämpft. Dieses Problem tritt auf, wenn Sie den Wert eines optionalen Felds der Ressource spec.lifecycleRule.condition.withState nicht in der „Source of Truth“ festlegen.

Workaround:

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

Datenquelle 1.16.1 1.16.2

Quelllink kann regelmäßig nicht ausgewertet werden

Bei Config Sync können Probleme auftreten, wenn der Abgleicher startet, wo er die Quellverknüpfung regelmäßig nicht auswerten kann. Dieses Problem tritt auf, weil git-sync das Quell-Repository noch nicht geklont hat.

Workaround:

Aktualisieren Sie Config Sync auf Version 1.16.2 oder höher. In diesen Versionen ist dies ein vorübergehender Fehler, der zwar protokolliert, aber nicht als Fehler gemeldet wird.
Datenquelle 1.15.0 1.17.0

Fehler beim Synchronisieren des Repositorys: Zeitlimit für Kontext überschritten

In Versionen vor 1.17.0 nutzte Config Sync standardmäßig den vollständigen Verlauf des Git-Repositorys. Dies kann bei großen Repositories mit vielen Commits zu einer Zeitüberschreitung der Abrufanfrage führen.

Workaround:

Führen Sie ein Upgrade auf Version 1.17.0 oder höher aus. 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 das Abrufen der Quelle, 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.
Wird synchronisiert 1.15.0

Hohe Anzahl inaktiver PATCH-Anfragen in den Audit-Logs

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

Workaround:

Da im Audit-Log nicht zwischen Probelauf- und Nicht-Probelaufanfragen unterschieden werden kann, können Sie die PATCH-Anfragen ignorieren.
Wird synchronisiert 1.17.0

Config Sync kann den letzten Commit nicht aus einem Zweig abrufen

In Config Sync-Versionen 1.17.0 und höher kann ein Problem auftreten, bei dem Config Sync nicht den neuesten Commit aus dem HEAD eines bestimmten Zweigs abrufen kann, wenn in mehreren Remotes auf denselben Zweig verwiesen wird und diese nicht synchron sind. Beispiel: Der main-Zweig des Remote-Repositorys origin kann demselben Zweig im Remote-Repository upstream voraus sein. Config Sync ruft jedoch nur den Commit-SHA aus der letzten Zeile ab, was möglicherweise nicht der neueste Commit ist.

Das folgende Beispiel zeigt, wie dieses Problem 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

Workaround:

Zur Behebung dieses Problems können Sie Ihre Git-Version (spec.git.revision) auf den neuesten Commit-SHA festlegen, unabhängig vom für den Git-Zweig (spec.git.branch) festgelegten Wert. Weitere Informationen zu den Git-Konfigurationen finden Sie unter Konfiguration für das Git-Repository.

Nach oben

Nächste Schritte