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 Developer Program teilnehmen, speichern Sie diese Seite, um Benachrichtigungen zu erhalten, wenn Versionshinweise zu dieser Seite veröffentlicht werden. 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 die Problemkategorie aus:

Sie können auch nach bekannten Problemen filtern:

Kategorie Identifizierte Version Korrigierte Version Problem und Problemumgehung
Komponentenzustand 1.24.0

Config Sync-Pods bleiben während des Upgrades auf Version 1.24.0 in Clustern, die zu Hub migriert wurden, hängen

Nach dem Upgrade auf Config Sync 1.24.0 bleiben Felder, die entfernt wurden (z. B. readinessProbe und Systemdiagnosen für den otel-agent-Sidecar), möglicherweise in Clustern bestehen, die zu Hub migriert wurden. Da die Systemdiagnosekomponente hinter readinessProbe entfernt wurde, kann der otel-agent-Container nicht gestartet werden, wodurch die Config Sync-Pods hängen bleiben.

Dieses Problem betrifft nur Cluster, in denen Config Sync zuvor manuell mit kubectl installiert und später zu Hub migriert wurde. Dieser Fehler tritt auf, weil die Feldverwaltung im Migrationsprozess anders als bei einer Neuinstallation erfolgt. Bei manuell installierten Clustern oder Clustern, die ursprünglich von Hub installiert wurden, werden die Felder wie erwartet entfernt.

Problemumgehung :

Folgen Sie der Anleitung zum Deinstallieren von Config Sync und installieren Sie Config Sync dann über Hub neu.
Messwerte 1.5.0 1.21.0

Behoben: Messwerte für gelöschte Pakete werden gemeldet

Wenn Sie ein RootSync oder RepoSync Objekt löschen, aber das ResourceGroup Objekt mit demselben Namen nicht löschen, 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 automatisch gelöscht, wenn die Löschweitergabe vor dem Löschen des RootSync oder RepoSync Objekts aktiviert wurde.

Problemumgehung :

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 kann nicht geplant werden

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

Wenn ein Abgleich 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 für den Abgleich sehr niedrig. Diese Einstellung wurde gewählt, um die Planung zu ermöglichen, auch wenn dies zu Drosselung und langsamer Leistung führt, damit Config Sync auf kleinen Clustern und kleinen Knoten funktioniert. Bei GKE Autopilot-Clustern sind die Abgleichsanforderungen jedoch höher festgelegt, um die Nutzung während der Synchronisierung realistischer darzustellen.

Problemumgehung :

GKE Autopilot oder Standard mit aktivierter automatischer Knotenbereitstellung sollte erkennen können, wie viele Ressourcen angefordert werden, und entsprechend dimensionierte Knoten erstellen, um die Planung zu ermöglichen. Wenn Sie die Knoten oder die Knotengrößen jedoch manuell konfigurieren, müssen Sie diese Einstellungen möglicherweise an die Ressourcenanforderungen des Abgleich-Pods anpassen.
Messwerte 1.15.0

Export fehlgeschlagen. Berechtigung verweigert

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

Problemumgehung :

otel-collector protokolliert Fehler, wenn Sie Cloud Monitoring nicht konfiguriert oder Messwertfilter und Cloud Monarch nicht angepasst 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, kann der otel-collector einen Fehler ausgeben oder abstürzen, weil die erforderliche ConfigMap nicht geladen werden kann.

Workaround:

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

Config Sync befindet sich in einem 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 befindet sich in einem Konflikt mit Config Connector-Ressourcen

Config Sync befindet sich möglicherweise in einem Konflikt mit Config Connector über eine Ressource, z. B. einen StorageBucket. Dieses Problem tritt auf, wenn Sie den Wert eines optionalen Felds einer Ressource spec.lifecycleRule.condition.withState in der verlässlichen Quelle nicht festlegen.

Workaround:

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

Source of Truth 1.20.0 1.21.3

git-sync-Container verursachen Crashloops, nachdem eine Git-Sperrdatei verwaist ist

Wenn der git-sync Container Crashloops mit Fehlern ähnlich den folgenden im git-sync Containerlog verursacht, 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

Problemumgehung :

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 Abgleichs des RootSync- oder RepoSync-Objekts.
Wird synchronisiert 1.7.0 1.21.0

Behoben: Annotation zum Ignorieren von Mutationen wird nicht berücksichtigt

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

Problemumgehung :

Sie können die Verwaltung des verwalteten Objekts beenden, indem Sie die configmanagement.gke.io/managed: disabled Annotation hinzufügen. Wenn Sie die Verwaltung deaktivieren, kann Config Sync das Objekt jedoch nicht neu erstellen, wenn es aus dem Cluster gelöscht wird. Außerdem werden keine weiteren Aktualisierungen in der verlässlichen Quelle angewendet.
Wird synchronisiert 1.15.0

Hohe Anzahl ineffektiver PATCH-Anfragen in den Audit-Logs

Der Config Sync-Remediator verwendet Probeläufe , 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 Nicht-Probeläufen unterscheiden kann können Sie die PATCH Anfragen ignorieren.
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 Race-Bedingung zwischen dem Abgleich und dem ResourceGroup-Controller zurückzuführen. Der ResourceGroup-Controller aktualisiert möglicherweise den ResourceGroup-Status, bevor der Abgleich die ResourceGroup-Spezifikation aktualisieren kann, was zu dem Fehler KNV2009 führt.

Problemumgehung :

Für dieses Problem gibt es keine Problemumgehung. 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 Ressource google_gke_hub_feature_membership 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 ist und Terraform-Version 5.41.0 oder höher verwendet wird. Möglicherweise wird auch eine Fehlermeldung angezeigt, die besagt, dass git spec not included in configmanagement spec.

Problemumgehung :

  • 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 wegen fehlender Daten im Config Sync-Dashboard in der Google Cloud Console

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

Problemumgehung :

Wenn diese Arten von Fehlern in der Google Cloud Console in Ihren GDC-Clustern (VMware) oder GDC-Clustern (Bare-Metal) angezeigt werden, prüfen Sie, ob Sie mit GKE Identity Service oder Connect Gateway in Ihren Clustern angemeldet sind.

Wird synchronisiert 1.21.0

Behoben: Config Sync verhindert Aktualisierungen von aufgegebenen Ressourcen

Vor Version 1.21.0 können durch ein gelöschtes RootSync- oder RepoSync Objekt mehrere Labels und Annotationen zurückbleiben, mit denen Config Sync diese Ressourcenobjekte verfolgt.

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 Eigentümer von zuvor verwalteten Objekten werden.
  • Wenn die Drift-Prävention aktiviert ist, kann Config Sync Änderungen an aufgegebenen Ressourcen ablehnen.
nomos-Befehlszeilentool 1.17.0

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

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

Problemumgehung :

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 Artikel Support erhalten Dort finden Sie weitere Informationen, einschließlich Ratschlägen zu den folgenden Themen: