Fehlerbehebung bei Controller-Konflikten

Auf dieser Seite erfahren Sie, wie Sie Probleme mit Controller-Konflikten beheben. Solche Streits verbrauchen ein hohes Maß an Ressourcen und können die Leistung beeinträchtigen. Streits werden auch als Ressourcenkonflikte bezeichnet.

Config Sync überwacht die Objekte, die es auf den Cluster anwendet, und macht Änderungen an den in der „Source of Truth“ deklarierten Werten rückgängig. Wenn diese Änderungen von einem anderen Controller vorgenommen werden, wechselt die Ressource möglicherweise zwischen den von den konkurrierenden Controllern gewünschten Status hin und her. Ein Symptom dieses Verhaltens ist, dass die Felder metadata.generation und metadata.resourceVersion schnell ansteigen. Wenn ein verwaltetes Objekt also mehr als fünf Mal pro Minute aktualisiert wird, erkennt Config Sync den Konflikt, protokolliert die Abweichung und meldet den Fehler im Objektstatus RootSync oder RepoSync.

Config Sync hat eine spezielle Logik, um Konflikte zwischen mehreren RootSync- und RepoSync-Objekten zu erkennen. Bei RepoSync-Objekten werden weitere Aktualisierungen übersprungen, wenn der Abgleicher feststellt, dass das Objekt bereits von einem anderen Abgleicher verwaltet wird. Bei RootSync-Objekten versucht der Abgleicher, jedes Objekt zu verwenden, für dessen Verwaltung er konfiguriert ist, es sei denn, es wird von einem anderen RootSync-Objekt verwaltet. Dadurch wird verhindert, dass Config Sync-Abgleicher untereinander konkurrieren und es werden Fehler im Status aller beteiligten RootSync- und RepoSync-Objekte gemeldet.

Controller-Konflikte erkennen

Sie können die Kampffehler mit dem Befehl nomos status oder durch Prüfen des Statusfelds im Objekt RootSync oder RepoSync ansehen.

Wenn Sie das nomos-Befehlszeilentool nicht installiert haben, können Sie die Logs für den RootSync-Abgleich mit dem folgenden Befehl aufrufen:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-name=root-sync" \
    --container reconciler

Führen Sie den folgenden Befehl aus, um nach bestimmten RepoSync-Abstimmungsfunktionen zu filtern:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-namespace=NAMESPACE" \
    --container reconciler

Ersetzen Sie NAMESPACE durch den Namespace, in dem Sie die Namespace-bezogene „Source of Truth“ erstellt haben.

Wenn in den Ergebnissen KNV2005 angezeigt wird, gibt es einen Controllerkonflikt.

Die folgende Fehlermeldung ist ein Beispiel für den Fehlertyp, der in Ihren Protokollen angezeigt werden kann:

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

Controller-Konflikte untersuchen

Für weitere Informationen zu Controller-Konflikten verwenden Sie den folgenden Befehl, um die Aktualisierung der YAML-Datei der Ressource zu verfolgen:

 kubectl get RESOURCE OBJECT_NAME \
     --namespace NAMESPACE \
     --watch -o yaml

Ersetzen Sie Folgendes:

  • RESOURCE: Die Art der Ressource, um die es geht.
  • OBJECT_NAME: Der Name des Objekts, um das gekämpft wird.
  • NAMESPACE: der Namespace, in dem sich die umkämpfte Ressource befindet.

In den Protokollergebnissen werden die Ressource, der Objektname und der Namespace angegeben, die Sie hinzufügen müssen.

Dieser Befehl gibt einen Stream des Status der Ressource zurück, nachdem Updates auf den API-Server angewendet wurden. Sie können ein Tool zum Dateivergleich verwenden, um die Ausgabe zu vergleichen.

Controller-Konflikte lösen

Es gibt mehrere Möglichkeiten, Controller-Konflikte zu beheben. Wählen Sie die Option aus, die am besten für Ihre Config Sync-Einrichtung geeignet ist:

  • Aktualisieren Sie das Ressourcenmanifest in der Quelle, damit es dem Wert entspricht, den der andere Controller benötigt.
  • Entfernen Sie das entsprechende Feld aus der Quelle, damit der andere Controller es verwalten kann.
  • Deaktiviere oder deinstalliere den anderen Controller.
  • Entfernen Sie die Ressource aus der Quelle und verwalten Sie sie manuell oder mit einem benutzerdefinierten Controller, der bestimmte Änderungen oder die gemeinsame Verwaltung toleriert.
  • Wenn Sie der Eigentümer des Controllers sind, der die Ressourcenkonflikte verursacht, und das geänderte Feld nicht die Quelle der Wahrheit ist, aktualisieren Sie den Controller so, dass er Patching anstelle von Aktualisierungen ausführt. So wird die Änderung von Config Sync zugelassen und nicht rückgängig gemacht.

Einige Ressourcen sollten zu anderen Controllern gehören (Beispiel: Einige Operatoren installieren oder verwalten CRDs). Diese anderen Controller entfernen automatisch alle Config Sync-spezifischen Metadaten. Wenn eine andere Komponente in Ihrem Kubernetes-Cluster Config Sync-Metadaten entfernt, beenden Sie die Verwaltung der Ressource mit Config Sync. Weitere Informationen dazu finden Sie unter Verwaltung eines Objekts beenden.

Wenn Sie nicht möchten, dass Config Sync Änderungen an verwalteten Objekten im Cluster rückgängig macht, können Sie dem Objekt die Annotation client.lifecycle.config.k8s.io/mutation: ignore hinzufügen, bei dem Config Sync Mutationen ignorieren soll. Weitere Informationen dazu finden Sie unter Objektmutationen ignorieren.

Konflikte zwischen Controllern für implizite Namespaces beheben

Standardmäßig erstellt Config Sync einen impliziten Namespace, wenn ein RootSync ein Namespace-bezogenes Objekt verwaltet, der Namespace selbst aber noch nicht vorhanden ist. Wenn ein anderer Controller versucht, den Namespace zu übernehmen, kann es zu einem Konflikt zwischen Controllern und Config Sync kommen. Sie können bestätigen, dass ein Namespace implizit erstellt wurde, wenn er nie im Root-Repository deklariert wurde und der Live-Namespace die prevent deletion annotation hat.

Es gibt mehrere Möglichkeiten, Konflikte über einen impliziten Namespace zu lösen. Wählen Sie die Option aus, die für Ihre Config Sync-Einrichtung am besten geeignet ist:

  • Verwenden Sie die explizite Namespace-Strategie für Ihr RootSync-Objekt. Mit dieser Strategie wird der Controller-Konflikt behoben und verhindert, dass Config Sync zusätzliche implizite Namespaces erstellt.
  • Fügen Sie Ihrem Stamm-Repository den Namespace mit der management disabled annotation hinzu. Mit dieser Annotation wird Config Sync angewiesen, die Verwaltung des Namespaces einzustellen. Config Sync kann jedoch weiterhin implizite Namespaces erstellen.

Nächste Schritte

  • Wenn weiterhin Probleme auftreten, sieh nach, ob dein Problem ein bekanntes Problem ist.

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Informationen, unter anderem zu den folgenden Themen: