Bekannte Probleme mit Config Sync

Config Sync-Pods bleiben während des Upgrades auf Version 1.24.0 auf Hub-migrierten Clustern hängen

Nach dem Upgrade auf Config Sync 1.24.0 sind Felder, die entfernt wurden (z. B. readinessProbe und Systemdiagnosen für den otel-agent-Sidecar), möglicherweise weiterhin in Clustern vorhanden, die zur Hub-Verwaltung migriert wurden. Da die Systemdiagnosekomponente hinter readinessProbe entfernt wird, kann der otel-agent-Container nicht gestartet werden, was dazu führt, dass die Config Sync-Pods nicht mehr reagieren.

Dieses Problem betrifft nur Cluster, in denen Config Sync zuvor manuell mit kubectl installiert und später auf Hub-Verwaltung umgestellt 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.

Workaround:

Folgen Sie der Anleitung zum Deinstallieren von Config Sync und installieren Sie Config Sync dann über den Hub neu, um dieses Problem zu beheben.

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

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“.

Abgleich nicht planbar

Config Sync-Abgleicher benötigen je nach Konfiguration von RootSync oder RepoSync 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:

In GKE Autopilot oder Standard mit aktivierter automatischer Knotenbereitstellung sollte zu sehen sein, wie viele Ressourcen angefordert werden, und es sollten entsprechend dimensionierte Knoten erstellt werden, um die Planung zu ermöglichen. Wenn Sie die Knoten oder Knotengrößen jedoch manuell konfigurieren, müssen Sie diese Einstellungen möglicherweise an die Ressourcenanforderungen des Reconciler-Pods anpassen.

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.

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 zu Fehlern oder Abstürzen des otel-collectors kommen, da 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.

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.

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.

git-sync-Container stürzen nach dem Verwaistwerden einer Git-Sperrbildschirmdatei in einer Schleife ab

Wenn der git-sync-Container mit Fehlern wie den folgenden im git-sync-Containerlog abstürzt, 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
    

Behoben: Mutationsanmerkung „Ignorieren“ 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 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 deaktivieren, kann Config Sync das Objekt jedoch nicht neu erstellen, wenn es aus dem Cluster gelöscht wird. Außerdem wird verhindert, dass weitere Updates in der Single Source of Truth angewendet werden.

Hohe Anzahl ineffektiver PATCH-Anfragen in den Audit-Logs

Der Config Sync-Remediator verwendet Dry-Run, 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:

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 Abgleich 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.

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.

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

In Dashboards in der Cloud de Confiance -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 Cloud de Confiance -Konsole in Ihren GDC-Clustern (VMware) oder GDC-Clustern (Bare Metal) angezeigt werden, müssen Sie darauf achten, dass Sie mit GKE Identity Service oder Connect Gateway in Ihren Clustern angemeldet sind.

Behoben: Config Sync verhindert Aktualisierungen verlassener Ressourcen

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

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.

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.