Bekannte Probleme mit Config Sync

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 des RootSync- oder RepoSync-Objekts 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 nicht angepasst haben und Cloud Monarch nicht verwenden.

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 sein, dass der otel-collector einen Fehler ausgibt oder abstürzt, weil 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 konkurriert möglicherweise mit Config Connector um 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 „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.

Behoben: Zugriffstoken für OCI-Quelle kann nicht generiert werden

Wenn Config Sync für die Verwendung von OCI als Single Source of Truth konfiguriert ist und die Authentifizierung mit Workload Identity Federation for GKE erfolgt, können bei Config Sync gelegentlich temporäre KNV2004-Fehler auftreten, wenn versucht wird, sich bei der Containerregistrierung zu authentifizieren.

Dieses Problem wird dadurch verursacht, dass die oauth2-Bibliothek das Autorisierungstoken erst aktualisiert, wenn es bereits abgelaufen ist.

Die Fehlermeldung enthält möglicherweise den folgenden Text: "oauth2/google: unable to generate access token" oder "ID Token issued at (xxx) is stale to sign-in."

Workaround:

Der Fehler sollte beim nächsten Versuch von Config Sync, Daten aus der „Source of Truth“ abzurufen, behoben werden.

Wenn bei Config Sync mehrere Fehler aufgetreten sind, werden Wiederholungsversuche seltener. Wenn Sie erzwingen möchten, dass Config Sync es früher noch einmal versucht, löschen Sie den Reconciler-Pod. Durch diese Aktion wird der Reconciler-Pod von Config Sync neu erstellt und sofort aus der „Source of Truth“ abgerufen:

    kubectl delete pod -n config-management-system RECONCILER_NAME
    

git-sync-Container stürzt nach dem Verweisen einer Git-Sperrbildschirmdatei immer wieder 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: Verweilende Git-Sperrbildschirmdatei

Wenn Sie einen Fehler wie den folgenden aus dem git-sync-Container sehen, ist möglicherweise ein vorheriger git-Aufruf fehlgeschlagen und hat eine laufende Sperrdatei im Container hinterlassen:

    KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...
    

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-Abstimmungsmodul führt dazu, dass Änderungen aus deklarierten Konfigurationen angewendet werden, auch wenn die Annotation client.lifecycle.config.k8s.io/mutation vorhanden ist. Dadurch wird der Status des Objekts im Cluster möglicherweise ü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.

Behoben: API-Erkennungsfehler können dazu führen, dass verwaltete Objekte fälschlicherweise als Not Found gekennzeichnet werden.

Wenn ein API-Dienst-Backend fehlerhaft ist, kann dies zu Fehlern bei der API-Erkennung führen. Wenn dies während des Starts des ResourceGroup-Controllers nach einer Aktualisierung oder Neuplanung geschieht, kann der Ressourcen-Cache nicht initialisiert werden. Dies führt dazu, dass alle verwalteten Objekte im ResourceGroup-Status als Not Found gemeldet werden.

Dieses Problem tritt häufig auf, wenn die metrics-server nicht in gutem Zustand ist.

Workaround:

Starten Sie den resource-group-controller-Pod neu, nachdem metrics-server wieder fehlerfrei ist:

    kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME
    

Hohe Anzahl ineffektiver PATCH-Anfragen in den Audit-Logs

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

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 Ihrer GDC-Cluster (VMware) oder GDC-Cluster (Bare Metal) angezeigt werden, müssen Sie darauf achten, dass Sie mit GKE Identity Service oder dem Connect-Gateway in Ihren Clustern angemeldet sind.

Behoben: Config Sync verhindert Aktualisierungen verlassener Ressourcen

Vor Version 1.21.0 können 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.