Bekannte Probleme mit Config Sync

Abgleich-Container mit OOMKilled auf AutoPilot

In Autopilot-Clustern sind für die 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:

Führen Sie ein Upgrade auf Version 1.17.0 oder höher durch. In Config Sync Version 1.17.0 wurden die Standard-CPU- und -Arbeitsspeicherlimits angepasst, um in den meisten Anwendungsfällen Fehler aufgrund fehlenden Arbeitsspeichers zu vermeiden.

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

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.

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.

Config Sync kann nicht mit dem KNV2002-Fehler abgeglichen werden

Wenn Config Sync nicht mit einem KNV2002 error abgleichen kann, liegt dies möglicherweise an einem bekannten Problem, 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 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

Workaround:

Aktualisieren Sie Ihren GKE-Cluster auf GKE-Version 1.28 oder höher oder aktualisieren Sie Config Sync auf Version 1.16.0 oder höher, um das Problem zu beheben. Beide Versionen enthalten Fehlerkorrekturen für das Client-Go-Problem.

Export fehlgeschlagen: Unbekannte Messwertlabels

In Version 1.15.0 fügte Config Sync vielen Messwerten die Labels type und commit hinzu. 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 wurde jedoch falsch konfiguriert, was zu Transformationsfehlern in den otel-collector-Logs führt.

Workaround:

Führen Sie ein Upgrade auf Version 1.17.2 oder höher durch.

Hohe Messwert-Kardinalität und -Transformationsfehler

In Version 1.15.0 fügte Config Sync vielen Messwerten die Labels type und commit hinzu. 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 wurde jedoch falsch konfiguriert, was zu Transformationsfehlern in den otel-collector-Logs führt.

Workaround:

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

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.

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 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 werden. In der 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 durch Angabe der Umgebungsvariable KUBECONFIG überschreiben.

Workaround:

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

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.

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.

Quelllink kann nicht regelmäßig ausgewertet werden

Config Sync kann Probleme haben, wenn der Abgleicher startet, wo er die Quelllink 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, daher wird er protokolliert, aber nicht als Fehler gemeldet.

Regelmäßig ungültige Anmeldedaten zur Authentifizierung für Cloud Source Repositories

Config Sync kann regelmäßig Fehler verursachen, wenn das Authentifizierungstoken für Cloud Source Repositories abläuft. Dieses Problem wird dadurch verursacht, dass die Tokenaktualisierung bis zum Ablauf wartet, bevor die Tokenaktualisierung erfolgt.

Workaround:

Aktualisieren Sie Config Sync auf Version 1.18.0 oder höher. In diesen Versionen wird das Token bei der ersten Anfrage innerhalb von fünf Minuten nach Ablauf des Tokens aktualisiert. Dadurch wird der Fehler "Anmeldedaten für die Authentifizierung" verhindert, es sei denn, die Anmeldedaten sind tatsächlich ungültig.

Fehler beim Synchronisieren des Repositorys: Kontextfrist überschritten

In Versionen vor 1.17.0 hat Config Sync standardmäßig den gesamten Git-Repository-Verlauf geprüft. Dies könnte bei großen Repositories mit vielen Commits zu einer Zeitüberschreitung bei der Abrufanfrage führen.

Workaround:

Führen Sie ein Upgrade auf Version 1.17.0 oder höher durch. Ab Version 1.17.0 wird der Git-Abruf mit --depth=1 durchgeführt, wodurch nur der neueste 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.

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:

Config Sync kann den neuesten Commit nicht aus einem Zweig abrufen

In Config Sync Version 1.17.0 und höher 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-Repositorys origin kann demselben Zweig im Remote-Repository upstream vorangestellt sein, aber Config Sync ruft nur das Commit-SHA ab aus der letzten Zeile aus. Möglicherweise ist dies nicht der letzte Commit.

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

Workaround:

Zur Behebung dieses Problems können Sie Ihre Git-Revision (spec.git.revision) auf das neueste Commit-SHA festlegen, unabhängig von dem 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.