Probleme mit Config Sync beheben

Auf dieser Seite erfahren Sie, wie Sie Probleme mit Config Sync beheben.

Wir bemühen uns, Config Sync immer optimal für Sie einzurichten. Unter Umständen kann es jedoch vorkommen, dass Sie Fehler bei der Einrichtung beheben müssen. Dieser Leitfaden führt Sie durch einige gängige Mechanismen, die Ihnen unter Umständen bei der Lösung möglicher Probleme helfen.

Allgemeine Best Practices

Config Sync-Status ansehen

Der Befehl nomos status bietet Ihnen zusammengefasste Daten und aufgetretene Fehler. So können Sie verstehen, welches Problem Ihre Config Sync-Installation hat. Die folgenden Informationen sind mit nomos status verfügbar:

• Installationsstatus pro Cluster
• Synchronisierungsfehler (sowohl Lesen von Git-Werten als auch Ausgleichen von Änderungen)

Installieren Sie den Befehl nomos, um nomos status zu verwenden.

Sie können auch den Befehl gcloud alpha anthos config sync repo oder das Config Sync-Dashboard verwenden, um den Config Sync-Status nach Repository anzusehen.

Service Level Indicators (SLIs) verwenden

Wenn Sie Benachrichtigungen erhalten möchten, wenn Config Sync nicht wie vorgesehen funktioniert, richten Sie Prometheus-Benachrichtigungsregeln basierend auf den Config Sync-SLIs ein. Weitere Informationen finden Sie unter Config Sync-SLIs verwenden.

kubectl zum Prüfen von Ressourcen verwenden

Config Sync besteht aus mehreren benutzerdefinierten Ressourcen, die Sie mit kubectl-Befehlen abfragen können. Mit diesen Befehlen können Sie den Status der einzelnen Config Sync-Objekte verstehen.

Sie sollten die folgenden Informationen zu den von Config Sync verwalteten Kubernetes-Ressourcen kennen:

• config-management-system ist der Namespace, mit dem alle zentralen Systemkomponenten von Config Sync ausgeführt werden.
• configmanagement.gke.io/v1 und configsync.gke.io sind die Versionspräfixe, die wir für alle benutzerdefinierten Ressourcen verwenden.

Mit dem folgenden Befehl können Sie eine vollständige Liste der benutzerdefinierten Ressourcen abrufen:

kubectl api-resources | grep -E "configmanagement.gke.io|configsync.gke.io"

Einzelne benutzerdefinierte Ressourcen können mit dem Befehl kubectl get RESOURCE -o yaml verwendet werden.

Mit der Ausgabe des folgenden Befehls können Sie beispielsweise den Status eines RootSync-Objekts prüfen:

kubectl get rootsync -n config-management-system -o yaml

Sie können auch den Befehl gcloud alpha anthos config sync resources oder das Config Sync-Dashboard verwenden, um die von Config Sync verwalteten Ressourcen aufzurufen.

RootSync- und RepoSync-Objekte untersuchen

Wenn Sie Config Sync mit kubectl installieren, erstellen Sie ein RootSync-Objekt, das Details zur Konfiguration Ihres Root-Repositorys enthält. Wenn Sie Config Sync mithilfe der Google Cloud Console oder dem Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt. Wenn Sie Synchronisierung aus mehreren Repositories konfigurieren, erstellen Sie RepoSync-Objekte, die Konfigurationsinformationen zu Ihren Namespace-Repositories enthalten.

Die Untersuchung dieser Objekte kann wertvolle Informationen über den Status von Config Sync aufzeigen. Weitere Informationen finden Sie unter RootSync- und RepoSync-Objekte überwachen.

Audit-Logs verwenden

Audit-Logs können ein hilfreiches Debugging-Tool sein.

Wenn Sie Config Sync mit der Google Cloud Console oder dem Google Cloud CLI installiert haben, führen Sie die folgenden Schritte aus, um Config Sync mithilfe von Audit-Logs zu untersuchen.

Console

1. Aktivieren Sie die Audit-Logs der GKE Connect/Hub APIs.

   1. Rufen Sie in der Google Cloud Console die IAM-Seite Audit-Logs auf.

      Zur Audit-Logs-Seite

   2. Klicken Sie in der Tabelle das Kästchen GKE Connect/Hub APIs an.

   3. Klicken Sie die folgenden Kästchen an:

      • Administratortätigkeit
      • Daten lesen
      • Daten schreiben

   4. Klicken Sie auf Speichern.

2. Rufen Sie die Seite Log-Explorer auf.

   Zur Seite „Log-Explorer“

3. Fügen Sie im Textfeld Query Builder die folgenden Filter hinzu:

   resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
   

4. Klicken Sie auf Abfrage ausführen.

5. Wählen Sie im Bereich Abfrageergebnisse Einträge aus, um mehr über die Ereignisse zu erfahren.

Abgleich-Logebene konfigurieren

Die Containerlogs (z. B. Abgleichs- oder Git-Sync-Logs) in einem RootSync- oder RepoSync-Abgleich können manchmal nützliche Informationen für die Fehlerbehebung bei Config Sync enthalten. Wenn Sie weitere Informationen in die Logs aufnehmen möchten, können Sie die Logausführlichkeit konfigurieren. Dazu legen Sie .spec.override.logLevels wie im folgenden Beispiel fest:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  override:
    logLevels:
    - containerName: "reconciler"
      logLevel: 8
    - containerName: "git-sync"
      logLevel: 10

Containername muss einer der folgenden sein: reconciler, git-sync, hydration-controller, oci-sync oder helm-sync.

Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Logausführlichkeit konfiguriert ist:

kubectl get deployment.apps/root-reconciler -n config-management-system -o yaml

Die Logausführlichkeit kann als eine der args in spec.template.spec.containers[] ermittelt werden und sieht so aus: -v=0, wobei „0“ die aktuelle Logausführlichkeit ist.

Fehlerbericht erstellen

Wenn Sie ein Problem mit Config Sync haben, für das Sie die Unterstützung des Google Cloud-Supports benötigen, können Sie mit dem Befehl nomos bugreport wertvolle Debugging-Informationen für den Support bereitstellen. Sie können diesen Befehl für ein einzelnes Repository und für mehrere Repositories verwenden.

nomos bugreport

Dieser Befehl generiert eine zeitgestempelte Zip-Datei mit Informationen zum Kubernetes-Cluster, der in Ihrem kubectl-Kontext festgelegt ist. Die Datei enthält auch Logs aus den Config Sync-Pods. Sie enthält keine Informationen aus den mit Config Sync synchronisierten Ressourcen. Weitere Informationen zum Inhalt der ZIP-Datei finden Sie in der Referenz zu nomos bugreport.

Architektur von Config Sync verstehen

Bei der Fehlerbehebung von Config Sync ist es hilfreich, die von Config Sync in einem Cluster erstellten Objekte und Ressourcen zu verstehen und ihre Beziehung zueinander zu verstehen. Die meisten dieser Objekte und Ressourcen werden bei der Installation von Config Sync automatisch erstellt und müssen nicht geändert werden. Das folgende Diagramm zeigt die Architektur von Config Sync in einem Cluster und die zugehörigen Ressourcen:

Wenn Config Sync in einem Cluster installiert ist, wird dem Cluster der Config Management-Operator hinzugefügt. Der Operator erstellt oder verwaltet die anderen Komponenten, die für Config Sync erforderlich sind. Der Operator besteht aus einer benutzerdefinierten Ressourcendefinition für ConfigManagement und der benutzerdefinierten Ressource. Ein Beispiel für diese Ressource finden Sie unter Beispiel für ein ConfigManagement-Objekt. Der Operator erstellt und verwaltet die folgenden Ressourcen:

• Abgleichsmanager: Erstellt und verwaltet die Stamm- oder Namespace-Abgleicher. Außerdem wird für jedes erstellte RootSync- und RepoSync-Objekt ein Abgleich erstellt. Der RootSync- oder RepoSync-Abgleicher ruft in der „Source of Truth“ gespeicherte Konfigurationen ab, wodurch die von Config Sync im Cluster verwalteten Ressourcen und Objekte erstellt oder aktualisiert werden.
• RootSync- oder RepoSync-Benutzerdefinierte Ressourcendefinition und benutzerdefinierte Ressource: Konfiguriert Config Sync so, dass die „Source of Truth“ überwacht und Objekte aus dieser Quelle auf einen Cluster für RootSync-Objekte oder einen Namespace in einem Cluster für RepoSync-Objekte angewendet werden. Wenn Sie Config Sync installieren, wird vom Config Management-Operator automatisch eine RootSync-Datei erstellt. Sie können sie jedoch ändern oder zusätzliche RootSync- oder RepoSync-Objekte erstellen. Weitere Informationen zu diesen Ressourcen finden Sie unter RootSync- und RepoSync-Felder.
• ResourceGroup-Controller und benutzerdefinierte Ressourcendefinition: Wird von Config Sync verwendet, um das Inventar der zuvor angewendeten und verwalteten Objekte beizubehalten. Config Sync erstellt ein ResourceGroup-Objekt für jede RootSync- oder RepoSync-Datei im Cluster.

Wenn Sie Ihre „Source of Truth“ hinzufügen oder Änderungen daran vornehmen, vergleicht Config Sync Ihre Cluster kontinuierlich anhand dieser Konfigurationen.

Allgemeine Probleme beheben

Ereignis mit FailedScheduling

Die Ausgabe von kubectl get events kann ein Ereignis vom Typ FailedScheduling enthalten. Dieses Ereignis sieht in etwa so aus:

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

Dieses Ereignis kann auftreten, wenn Pods auf Ihren Knoten nicht geplant werden können. Dies bedeutet in der Regel, dass auf Ihren Knoten nicht genügend CPU oder Arbeitsspeicher vorhanden ist. Wählen Sie eine der folgenden Optionen, um diesen Fehler zu beheben:

• Fügen Sie einem vorhandenen GKE-Knotenpool einen Knoten hinzu.
• Erstellen Sie einen Knotenpool mit größeren Knoten.

Gültiges, aber falsches ConfigManagement-Objekt

Hinweis: Dieser Abschnitt gilt nur, wenn Sie ein ConfigManagement-Objekt erstellt haben. Wenn Sie eine falsche apply-spec.yaml-Datei erstellen und versuchen, sie anzuwenden, schlägt der Befehl sofort fehl und es wird eine Fehlermeldung angezeigt, die angibt, welche Felder in der apply-spec.yaml-Datei falsch sind. Da die spec.git-Felder des ConfigManagement-Objekts verworfen wurden, sollten Sie das ConfigManagement-Objekt migrieren.

Wenn Sie Config Sync mit kubectl-Befehlen installieren und die Installation aufgrund eines Problems mit dem ConfigManagement-Objekt fehlschlägt, das nicht auf einen YAML- oder JSON-Syntaxfehler zurückzuführen ist, wird das Objekt zwar im Cluster instanziiert, funktioniert aber möglicherweise nicht ordnungsgemäß. In diesem Fall können Sie mit dem Befehl nomos status im Objekt nach Fehlern suchen.

Eine gültige Installation ohne Probleme hat den Status PENDING oder SYNCED.

Eine ungültige Installation hat den Status NOT CONFIGURED und führt einen der folgenden Fehler auf:

• missing git-creds Secret
• missing required syncRepo field
• git-creds Secret is missing the key specified by secretType

Beheben Sie den Konfigurationsfehler, um das Problem zu lösen. Je nach Art des Fehlers müssen Sie möglicherweise das ConfigManagement-Manifest noch einmal auf den Cluster anwenden.

Wenn das Problem darin bestand, dass Sie das git-creds-Secret nicht erstellt haben, wird es nach seiner Erstellung von Config Sync sofort erkannt. Sie müssen die Konfiguration nicht noch einmal anwenden.

ResourceGroup-Felder ändern sich ständig

Für ein Git-Repository, das mit dem Cluster synchronisiert wird, wird der Abgleichsstatus aller Ressourcen in einer Ressource namens ResourceGroup zusammengefasst. Für jedes RootSync- oder RepoSync-Objekt wird eine ResourceGroup generiert, um die Ressourcen zu erfassen, die auf den Cluster angewendet werden, und ihren Status zusammenzufassen.

Gelegentlich kann Ihre ResourceGroup eine Schleife erreichen, die das spec der ResourceGroup aktualisiert. In diesem Fall können die folgenden Probleme auftreten:

• Der metadata.generation einer ResourceGroup wird innerhalb kurzer Zeit weiter erhöht.
• Die ResourceGroup spec ändert sich ständig.
• Die ResourceGroup spec enthält nicht die status.resourceStatuses der Ressourcen, die mit dem Cluster synchronisiert werden.

Wenn Sie diese Probleme beobachten, wurden einige Ressourcen in Ihren Git-Repositories nicht auf den Cluster angewendet. Der Grund für diese Probleme ist, dass Ihnen die Berechtigungen fehlen, die Sie zum Anwenden dieser Ressourcen benötigen.

Sie können überprüfen, ob die Berechtigungen fehlen, indem Sie den Repository-Ressourcenstatus abrufen:

kubectl get reposync repo-sync -n NAMESPACE -o yaml

Ersetzen Sie NAMESPACE durch den Namespace, in dem Sie Ihr Namespace-Repository erstellt haben.

Sie können aber auch nomos status verwenden.

Wenn die folgenden Nachrichten im Status angezeigt werden, bedeutet das, dass der Abgleicher in NAMESPACE nicht berechtigt ist, die Ressource anzuwenden:

errors:
  - code: "2009"
    errorMessage: |-
      KNV2009: deployments.apps "nginx-deployment" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler-     default" cannot get resource "deployments" in API group "apps" in the namespace "default"

      For more information, see https://g.co/cloud/acm-errors#knv2009

Um dieses Problem zu beheben, müssen Sie eine RoleBinding-Konfiguration deklarieren, die dem Dienstkonto ns-reconciler-NAMESPACE die Berechtigung zur Verwaltung der fehlgeschlagenen Ressource in diesem Namespace gewährt. Weitere Informationen zum Hinzufügen eines RoleBinding finden Sie unter Synchronisierung aus mehreren Repositories konfigurieren.

Große Anzahl von Ressourcen im Git-Repository

Wenn das Git-Repository, das von einem RepoSync- oder RootSync-Objekt synchronisiert wurde, mehr als 1.000 Ressourcen enthält, kann dies dazu führen, dass die ResourceGroup das Limit für die Objektgröße von etcd überschreitet. In diesem Fall können Sie den aggregierten Status für Ressourcen in Ihrem Git-Repository nicht sehen. Sie können den aggregierten Status zwar nicht sehen, Ihr Repository ist jedoch möglicherweise noch synchronisiert.

Wenn der folgende Fehler aus dem RootSync-, RepoSync-Objekt oder den Abgleichslogs angezeigt wird, bedeutet dies, dass die ResourceGroup-Ressource das etcd-Objektgrößenlimit überschreitet.

KNV2009: etcdserver: request is too large

Zur Lösung dieses Problems empfehlen wir, Ihr Git-Repository in mehrere Repositories aufzuteilen. Weitere Informationen finden Sie unter Repository in mehrere Repositories aufteilen.

Wenn Sie das Git-Repository in Config Sync v1.11.0 und höher nicht aufteilen können, können Sie das Problem beheben, indem Sie die Anzeige von Statusdaten deaktivieren. Setzen Sie dazu das Feld .spec.override.statusMode des RootSync- oder RepoSync-Objekts auf disabled. Dadurch beendet Config Sync die Aktualisierung des Status der verwalteten Ressourcen im ResourceGroup-Objekt. Es reduziert die Größe des ResourceGroup-Objekts. Allerdings können Sie den Status für verwaltete Ressourcen weder aus nomos status noch aus gcloud alpha anthos config sync aufrufen.

Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installiert haben, erstellen Sie ein bearbeitbares RootSync-Objekt, damit Sie spec.override.statusMode festlegen können. Weitere Informationen finden Sie unter Config Sync mit kubectl-Befehlen konfigurieren.

Wenn kein Fehler vom RootSync- oder RepoSync-Objekt angezeigt wird, wurde Ihr Git-Repository mit dem Cluster synchronisiert. Wenn Sie prüfen möchten, ob die ResourceGroup-Ressource die Objektgrößenbeschränkung etcd überschreitet, prüfen Sie sowohl den Ressourcenstatus von ResourceGroup als auch das Log des ResourceGroup-Controllers:

1. Prüfen Sie den Status der ResourceGroup:

   • Prüfen Sie das RootSync-Objekt mit dem folgenden Befehl:

    kubectl get resourcegroup.kpt.dev root-sync -n config-management-system
   

   • Führen Sie den folgenden Befehl aus, um das RepoSync-Objekt zu prüfen:

   kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE
   

   Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.

   NAME        RECONCILING   STALLED   AGE
   root-sync   True          False     35m
   

   Wenn der Wert in der Spalte RECONCILING True lautet, bedeutet dies, dass die Ressource vom Typ "ResourceGroup" noch abgeglichen wird.

2. Prüfen Sie die Logs für den ResourceGroup-Controller:

   kubectl logs deployment/resource-group-controller-manager -c manager -n resource-group-system
   

   Wenn Sie in der Ausgabe den folgenden Fehler sehen, ist die Ressource "ResourceGroup" zu groß und überschreitet das Limit der Objektgröße etcd:

   "error":"etcdserver: request is too large"
   

Verringern Sie die Anzahl der Ressourcen im Git-Repository, um zu verhindern, dass die ResourceGroup zu groß wird. Folgen Sie der Anleitung, um ein Stamm-Repository in mehrere Stamm-Repositories aufzuteilen.

Nicht aus dem Git-Repository synchronisiert

Wenn neue Commits per Push in Ihr Git-Repository übertragen werden, der Config Sync-Status für Ihren Cluster jedoch über einen längeren Zeitraum (länger als spec.git.period) immer noch Synced ist, müssen Sie die Protokolle des git-sync-Containers überprüfen:

# check git-sync logs for a root reconciler
kubectl logs -n config-management-system deployment/root-reconciler -c git-sync

# check git-sync logs for a namespace reconciler
kubectl logs -n config-management-system deployment/ns-reconciler-NAMESPACE -c git-sync

Es ist wahrscheinlich, dass git-sync nicht aus dem Git-Repository synchronisiert, der Abgleich jedoch mit dem zuvor synchronisierten Commit synchronisiert. Die folgende Beispielausgabe zeigt an, dass ein Problem mit git-sync vorliegt:

"msg"="unexpected error syncing repo, will retry" "error"="Run(git fetch -f
--tags --depth 1 origin develop): exit status 128: { stdout: "", stderr: "fatal:
couldn't find remote ref develop\n" }"

Webhook lehnt die Anfrage zum Aktualisieren/Löschen einer Ressource ab, die von einem gelöschten RootSync/RepoSync verwaltet wurde.

Durch das Löschen eines RootSync- oder RepoSync-Objekts werden die Annotationen und Labels von Config Sync nicht bereinigt. Der Config Sync-Zulassungs-Webhook lehnt Anfragen zum Ändern oder Löschen dieser Ressourcen ab, wenn Config Sync noch im Cluster aktiviert ist.

Wenn Sie diese verwalteten Ressourcen behalten möchten, können Sie zuerst die Verwaltung der Ressourcen aufheben, indem Sie die Annotation configmanagement.gke.io/managed für jede im Git-Repository deklarierte verwaltete Ressource auf disabled festlegen. Dadurch werden die Config Sync-Annotationen und -Labels aus verwalteten Ressourcen entfernt, diese Ressourcen werden jedoch nicht gelöscht. Nach Abschluss der Synchronisierung können Sie das RootSync- oder RepoSync-Objekt entfernen.

Wenn Sie diese verwalteten Ressourcen löschen möchten, können Sie zuerst die verwalteten Ressourcen löschen. Dazu ändern Sie das RootSync- oder RepoSync-Objekt, das aus einem leeren Git-Verzeichnis synchronisiert wird. Nach Abschluss der Synchronisierung können Sie das RootSync- oder RepoSync-Objekt entfernen.

Wenn das RootSync- oder RepoSync-Objekt vor dem Aufheben der Verwaltung oder dem Löschen verwalteter Ressourcen gelöscht wurde, können Sie das RootSync- oder RepoSync-Objekt wieder hinzufügen, die Verwaltung verwalteter Ressourcen aufheben oder sie löschen und dann das RootSync- oder RepoSync-Objekt wieder löschen.

Horizontales Pod-Autoscaling funktioniert nicht

Config Sync verwaltet alle Felder, die Sie in den Manifesten in Ihrem Git-Repository angeben. Es können Ressourcenkonflikte auftreten, wenn zwei Controller versuchen, dasselbe Feld zu steuern. Diese Ressourcenkonflikte treten auf, wenn Sie versuchen, das horizontale Pod-Autoscaling mit Config Sync zu verwenden.

Wenn Sie horizontales Pod-Autoscaling verwenden möchten, sollte der horizontale Pod-Autoscaler das Feld spec.replicas verwalten können. Entfernen Sie dazu das Feld aus allen Manifesten in Ihrem Git-Repository. Andernfalls versucht Config Sync, alle Änderungen im Repository rückgängig zu machen.

PersistentVolumeClaim hat den Status „Lost“

Beim Upgrade eines Kubernetes-Clusters auf Version 1.22 und höher besteht die Möglichkeit, dass verwaltete PersistentVolumeClaims den Status Lost verursachen können. Dies tritt auf, wenn die Bindung von PersistentVolumes und PersistentVolumeClaims mithilfe des Felds claimRef in einer PersistentVolume-Ressource definiert wird. Vorgelagerte Kubernetes-Änderungen haben das Feld claimRef atomar atomar, was diesen Fehler verursacht, da er unterschiedliche Feldinhaber für die verschiedenen claimRef-Unterfelder verhindert, wenn Server-Side Apply verwendet wird.

Bis dieses Problem im vorgelagerten Kubernetes behoben wurde (GitHub-Problemverfolgung, Pull-Anfrage für Fehlerkorrektur), sollten Sie Ihre PersistentVolume- und PersistentVolumeClaim-Ressourcen aktualisierenm um eine alternative Bindungsmethode zu verwenden. Die Bindung kann stattdessen innerhalb der spec.volumeName der PersistentVolumeClaim-Ressource festgelegt werden. Dies kann in den Kubernetes-Versionen 1.21 und früheren Versionen erfolgen, um Unterbrechungen beim Upgrade auf 1.22 zu vermeiden.

Das folgende Beispiel zeigt ein Mindestbeispiel für eine Bindung von staging-pvc an staging-pv:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: staging-pvc
  namespace: staging
spec:
  volumeName: staging-pv
  ...

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: staging-pv
spec:
  ...

Die Verwendung von volumeName anstelle von claimRef für die Bindung sorgt für mehr keine Bindungsberechtigungen für das PersistentVolume.

Fehlerbehebung

KNV1045: Konfigurationen mit dem angegebenen Status sind nicht zulässig

Wenn Sie im Quell-Repository ein status-Feld angeben, kommt es zu KNV1045: Konfigurationen mit angegebenem „Status“ sind nicht zulässig. Die Synchronisierung des Felds status mit Config Sync ist nicht zulässig. Ein anderer Controller sollte das Feld status im Cluster dynamisch verwalten und aktualisieren. Wenn Config Sync versucht, den gewünschten Status des Felds status zu steuern, konkurriert es mit dem Controller, der für die Verwaltung des Felds status verantwortlich ist.

Entfernen Sie das Feld status aus dem Quell-Repository, um diesen Fehler zu beheben. Verwenden Sie für Konfigurationen von Drittanbietern, die Ihnen nicht gehören, kustomize-Patches, um die in Ihren Manifesten angegebenen status-Felder im Bulk zu entfernen.

KNV2004: Repository-Fehler im Container von git-sync konnte nicht synchronisiert werden

Config Sync erstellt einen oberflächlichen Klon Ihres Git-Repositorys. In seltenen Fällen kann es vorkommen, dass Config Sync das Commit nicht im "oberflächlichen" Klon findet. In diesem Fall erhöht Config Sync die Anzahl der Git-Commits, die abgerufen werden sollen.

Sie können die Anzahl der abzurufenden Git-Commits festlegen. Dazu legen Sie das Feld spec.override.gitSyncDepth in einem RootSync- oder RepoSync-Objekt fest:

• Wenn dieses Feld nicht angegeben ist, wird es von Config Sync automatisch konfiguriert.
• Config Sync führt einen vollständigen Klon aus, wenn dieses Feld 0 ist, und einen flachen Klon, wenn dieses Feld größer als 0 ist.

• Das Festlegen dieses Feldes auf einen negativen Wert ist nicht zulässig.

  Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installiert haben, erstellen Sie ein bearbeitbares RootSync-Objekt, damit Sie spec.override.gitSyncDepth festlegen können. Weitere Informationen finden Sie unter Config Sync mit kubectl-Befehlen konfigurieren.

Hier ist ein Beispiel für das Festlegen der Anzahl der Git-Commits, die auf 88 abgerufen werden sollen:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  override:
    gitSyncDepth: 88
  git:
    ...

Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Änderung wirksam wird (GIT_SYNC_DEPTH sollte im Feld data der ConfigMap root-reconciler-git-sync auf 88 gesetzt sein):

kubectl get cm root-reconciler-git-sync -n config-management-system -o yaml

Sie können die Anzahl der abzurufenden Git-Commits in einem Namespace-Abgleich auf ähnliche Weise überschreiben.

Fehler: Berechtigung verweigert

Wenn Sie beim Konfigurieren von Config Sync einen Fehler wie das folgende Beispiel erhalten, haben Sie möglicherweise nicht die Rolle GKE-Hub-Administrator:

Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'

Prüfen Sie, ob Sie die erforderlichen IAM-Rollen gewährt haben, um die erforderlichen Berechtigungen zu haben.

Fehler: Annahme des Webhooks hat eine Anfrage abgelehnt

Wenn Sie beim Versuch, eine Änderung auf ein Feld anzuwenden, das von Config Sync verwaltet wird, den folgenden Fehler erhalten, hat Ihre Änderung möglicherweise einen Konflikt verursacht:

error: OBJECT could not be patched: admission webhook "v1.admission-webhook.configsync.gke.io"
denied the request: fields managed by Config Sync can not be modified

Wenn Sie ein Feld in einer Konfiguration deklarieren und Ihr Repository mit einem Cluster synchronisiert wird, verwaltet Config Sync dieses Feld. Jede Änderung, die Sie an diesem Feld vornehmen möchten, ist eine konfliktbehaftete Änderung.

Wenn Sie beispielsweise eine Deployment-Konfiguration in Ihrem Repository mit dem Label environment:prod haben und versuchen, dieses Label in Ihrem Cluster in environment:dev zu ändern, würde ein Konflikt entstehen und Sie erhalten die vorherige Fehlermeldung. Wenn Sie jedoch dem Deployment ein neues Label hinzufügen, z. B. tier:frontend, entsteht kein Konflikt.

Wenn Config Sync alle Änderungen an einem Objekt ignorieren soll, können Sie die in Objektmutationen ignorieren beschriebene Annotation hinzufügen.

Fehler: E/A-Zeitüberschreitung bei Zulassungs-Webhook-Anfrage

Wenn Sie die folgende Fehlermeldung erhalten, wenn der Abgleicher versucht, eine Konfiguration auf den Cluster anzuwenden, ist der Webhook-Zugangsport 8676 möglicherweise durch die Firewall zum Netzwerk der Steuerungsebene blockiert:

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout

Um dieses Problem zu beheben, fügen Sie eine Firewallregel hinzu, um Port 8676 zuzulassen, der vom Config Sync-Zulassungs-Webhook zur Vermeidung von Abweichungen verwendet wird.

Fehler: Verbindung zu Zugangs-Webhook abgelehnt

Wenn Sie die folgende Fehlermeldung erhalten, wenn der Abgleicher versucht, eine Konfiguration auf den Cluster anzuwenden, dann ist der Zulassungs-Webhook noch nicht bereit:

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused

Dies ist ein vorübergehender Fehler, den Sie möglicherweise beim Bootstrapping von Config Sync sehen. Wenn das Problem weiterhin besteht, prüfen Sie anhand der Bereitstellung des Zugangs-Webhooks, ob dessen Pods geplant werden können und fehlerfrei sind.

kubectl describe deploy admission-webhook -n config-management-system

kubectl get pods -n config-management-system -l app=admission-webhook

Fehler: Git-Secret kann nicht bereitgestellt werden

Wenn Sie die folgende Fehlermeldung erhalten, wenn der Container git-sync versucht, ein Repository mit einem Secret zu synchronisieren, dann wurde das Git Secret nicht erfolgreich in den Container git-sync eingebunden:

KNV2004: unable to sync repo Error in the git-sync container: ERROR: can't configure SSH: can't access SSH key: stat /etc/git-secret/ssh: no such file or directory: lstat /repo/root/rev: no such file or directory

Dies kann darauf zurückzuführen sein, dass der Authentifizierungstyp Ihres Git-Repositorys von none, gcenode oder gcpserviceaccount in andere Typen geändert wurde, die ein Secret benötigen.

Führen Sie die folgenden Befehle aus, um dieses Problem zu beheben und den Reconciler Manager und die Reconciler neu zu starten:

# Stop the reconciler-manager Pod. The reconciler-manager Deployment will spin
# up a new Pod which can pick up the latest `spec.git.auth`.
kubectl delete po -l app=reconciler-manager -n config-management-system

# Delete the reconciler Deployments. The reconciler-manager will recreate the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system

Fehler: Remotebases können nicht aus öffentlichen Repositories abgerufen werden

Wenn beim Versuch, Remotebases aus öffentlichen Repositories abzurufen, der folgende Fehler angezeigt wird, ist der Renderingprozess nicht erfolgreich:

KNV1068: failed to run kustomize build in /repo/source/0a7fd88d6c66362584131f9dfd024024352916af/remote-base, stdout:...
no 'git' program on path: exec: "git": executable file not found in $PATH

For more information, see https://g.co/cloud/acm-errors#knv1068

Legen Sie spec.override.enableShellInRendering auf true fest, um dieses Problem zu beheben.

Container im Abgleichs-Pod werden mit dem Status „OOMKilled“ versehen

Sie können die CPU- und/oder Speicheranforderungen und -limits eines Root- oder Namespace-Repositorys überschreiben. Verwenden Sie das Feld spec.override.resources eines RootSync- oder RepoSync-Objekts, um diese Werte zu überschreiben. Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installiert haben, erstellen Sie ein bearbeitbares RootSync-Objekt, damit Sie spec.override.resources festlegen können. Weitere Informationen finden Sie unter Config Sync mit kubectl-Befehlen konfigurieren.

Das folgende Beispiel zeigt, wie die CPU- und Speicherlimits des Containers reconciler und die CPU-Anfrage- und Speicherlimits des Containers git-sync eines Root-Abgleichs überschrieben werden. Die Container git-sync, oci-sync, helm-sync, hydration-controller und reconciler dürfen überschrieben werden. Das teilweise Überschreiben ist zulässig: Wenn kein Überschreibungswert für eine Ressourcenanfrage oder ein Limit angegeben ist, wird der Standardressourcenwert für die Anfrage oder das Limit verwendet.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: "unstructured"
  override:
    resources:
    - containerName: "reconciler"
      cpuLimit: "800m"
      memoryLimit: "500Mi"
    - containerName: "git-sync"
      cpuRequest: "100m"
      memoryLimit: "400Mi"
  git:
     ...

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die neuen Ressourcenlimits wirksam werden:

kubectl get deployment.apps/root-reconciler -n config-management-system -o yaml

Sie können die Ressourcenlimits eines Namespace-Reconciler ähnlich überschreiben.

Fehler: Ein Namespace bleibt in der Phase Terminating hängen.

Ein Namespace, der in der Phase Terminating festhängt, sollte die folgende Bedingung haben:

    message: 'Failed to delete all resource types, 1 remaining: admission webhook
      "v1.admission-webhook.configsync.gke.io" denied the request: system:serviceaccount:kube-system:namespace-controller
      is not authorized to delete managed resource "_configmap_bookstore_cm1"'
    reason: ContentDeletionFailed
    status: "True"
    type: NamespaceDeletionContentFailure

Dieser Fehler passiert, wenn Sie versuchen, einen Namespace aus einem Stamm-Repository zu löschen, einige Objekte unter dem Namespace werden jedoch weiterhin aktiv von einem Namespace-Abgleicher verwaltet. Wenn ein Namespace gelöscht wird, versucht der Namespace-Controller mit dem Dienstkonto system:serviceaccount:kube-system:namespace-controller, alle Objekte in diesem Namespace zu löschen. Der Config Sync-Zulassungs-Webhook ermöglicht jedoch nur dem Root- oder Namespace-Abgleicher, diese Objekte zu löschen. Außerdem wird dem Namespace-Controller das Löschen dieser Objekte verweigert.

Sie können ihn umgehen, indem Sie den Config Sync-Zulassungs-Webhook löschen:

kubectl delete deployment.apps/admission-webhook -n config-management-system

Der Config Management Operator erstellt den Config Sync-Zulassungs-Webhook neu.

Wenn diese Problemumgehung nicht funktioniert, müssen Sie Config Sync möglicherweise neu installieren.

Um zu vermeiden, dass der Fehler erneut auftritt, entfernen Sie das Namespace-Repository, bevor Sie den Namespace entfernen.

Fehler: Feld webhooks in ValidatingWebhookConfiguration nicht gefunden

Wenn beim Ausführen von kubectl logs -n config-management-system -l app=admission-webhook die folgenden Fehler aus den Config Sync-Zulassungs-Webhook-Logs auftreten:

cert-rotation "msg"="Unable to inject cert to webhook." "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "gvk"={"Group":"admissionregistration.k8s.io","Version":"v1","Kind":"ValidatingWebhookConfiguration"} "name"="admission-webhook.configsync.gke.io"
controller-runtime/manager/controller/cert-rotator "msg"="Reconciler error" "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "name"="admission-webhook-cert" "namespace"="config-management-system"

Dies bedeutet, dass root-reconciler keine Ressource mit dem Cluster synchronisiert hat. Dies kann daran liegen, dass root-reconciler noch nicht bereit ist oder im Git-Repository keine zu synchronisierenden Daten vorhanden sind (beispielsweise kann das Synchronisierungsverzeichnis leer sein). Wenn das Problem weiterhin besteht, sollten Sie den Status von root-reconciler prüfen:

kubectl get pods -n config-management-system -l configsync.gke.io/reconciler=root-reconciler

Wenn root-reconciler einen Absturz oder einen OOMKilled verursacht, erhöhen Sie die Ressourcenlimits.

Fehler: Stackdriver/GoogleCloud-Exporteur konnte nicht erstellt werden

Wenn eine Komponente in Open Telemetry Collector nicht auf das Standarddienstkonto im selben Namespace zugreifen kann, stellen Sie möglicherweise fest, dass sich der Pod otel-collector unter config-management-monitoring im CrashLoopBackoff-Status befindet, oder es wird eine Fehlermeldung wie diese angezeigt:

Error: cannot build exporters: error creating stackdriver exporter: cannot configure Google Cloud metric exporter: stackdriver: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

Error: Permission monitoring.timeSeries.create denied (or the resource may not exist).

Dieses Problem tritt normalerweise auf, wenn Workload Identity in einem Cluster aktiviert ist.

Folgen Sie zur Behebung des Problems der Anleitung unter Monitoring von Config Sync, um dem Standarddienstkonto die Schreibberechtigung für Messwerte zu erteilen.

Wenn der Fehler nach dem Einrichten von IAM weiter besteht, starten Sie den otel-collector-Pod neu, damit die Änderungen wirksam werden.

Wenn Sie eine benutzerdefinierte Monitoringlösung verwenden, aber die Standard-ConfigMap otel-collector-googlecloud verzweigt haben, sollten Sie alle Unterschiede prüfen und neu erstellen.

Fehler: Prüfung des Serverzertifikats fehlgeschlagen

Wenn der git-sync-Container das Git-Repository nicht klonen kann und die folgende Fehlermeldung server certificate verification failed. CAfile: /etc/ca-cert/cert CRLfile: none anzeigt, bedeutet dies, dass der Git-Server mit Zertifikaten einer benutzerdefinierten Zertifizierungsstelle konfiguriert ist. Die benutzerdefinierte Zertifizierungsstelle ist jedoch nicht richtig konfiguriert, was dazu führt, dass der git-sync-Container das Git-Repository nicht klonen kann.

Prüfen Sie zuerst, ob das Feld spec.git.caCertSecretRef.name in Ihrem RootSync- oder RepoSync-Objekt angegeben wurde, und prüfen Sie auch, ob das Secret-Objekt vorhanden ist.

Wenn das Feld konfiguriert wurde und das Secret-Objekt vorhanden ist, muss das Secret-Objekt die vollständigen Zertifikate enthalten.

Je nachdem, wie die benutzerdefinierte Zertifizierungsstelle bereitgestellt wird, können die Ansätze zur Überprüfung der vollständigen Zertifikate variieren.

Hier ein Beispiel für das Auflisten der Serverzertifikate:

echo -n | openssl s_client -showcerts -connect HOST:PORT -servername SERVER_NAME 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Sie können Ihr Netzwerkverwaltungsteam bitten, die CA-Zertifikate für Sie anzufordern.