Fehlerbehebung bei Config Sync

Auf dieser Seite finden Sie Hinweise zur Fehlerbehebung bei der Installation von Config Sync.

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

nomos status unterstützt Sie

Wir investieren viel Energie, um sicherzustellen, dass Ihnen die meisten mit dem Befehl nomos status zur Verfügung stehen. 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)

kubectl get KRM-Ressourcen für die erweiterte Nutzung

Config Sync besteht aus mehreren benutzerdefinierten Ressourcen, die einzeln mit kubectl abgefragt werden können, um den Status der einzelnen Objekte genau zu verstehen.

Wichtige Informationen zu den von Config Sync verwalteten Kubernetes-Ressourcen:

  • config-management-system: Mit diesem Namespace werden alle zentralen Systemkomponenten von Config Sync ausgeführt
  • 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.

Beispielsweise können Sie in der Ausgabe des nächsten Befehls Ihre RootSync-Objekte überprüfen:

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

Weitere Informationen finden Sie unter RootSync- und RepoSync-Objekte untersuchen.

Audit-Logs verwenden

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

Wenn Sie Config Sync mit der Cloud Console oder dem gcloud-Befehlszeilentool 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 Cloud Console die IAM-Seite Audit-Logs auf.

      Zur Seite „Audit-Logs“

    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.

Unzureichende CPU

Die Ausgabe von kubectl get events kann ein Ereignis vom Typ FailedScheduling enthalten. Das 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.

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

Wenn 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 ConfigManagement-Objekt unter Umständen im Cluster instanziiert, funktioniert jedoch eventuell nicht ordnungsgemäß. In diesem Fall können Sie mit dem Befehl nomos status im ConfigManagement-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 einer RoleBinding-Konfiguration finden Sie im Abschnitt Synchronisierung von Namespace-Repositories konfigurieren.

Große Anzahl von Ressourcen im Git-Repository

Wenn das Git-Repository, das entweder von RepoSync- oder RootSync-Objekten synchronisiert wurde, die Konfiguration für mehr als ein paar tausend Ressourcen enthält, kann es sein, dass die ResourceGroup die maximale Objektgröße von etcd überschreitet. In diesem Fall können Sie den aggregierten Status für Ressourcen in Ihrem Git-Repository nicht sehen. Auch wenn Sie den aggregierten Status nicht sehen können, wird Ihr Repository trotzdem synchronisiert. Wenn in den Objekten "RepoSync" oder "RootSync" keine Fehler auftreten, wurde Ihr Git-Repository erfolgreich mit dem Cluster synchronisiert.

Um zu überprüfen, ob die Ressource vom Typ "ResourceGroup" das etcd-Objektgrößenlimit überschreitet, müssen Sie sowohl den Ressourcenstatus der ResourceGroup als auch das Log des ResourceGroup-Controllers prüfen:

  1. Überprüfen Sie den ResourceGroup-Status mit dem folgenden Befehl:

    • Prüfen Sie RootSync mit dem folgenden Befehl:
     kubectl get resourcegroup.kpt.dev root-sync -n config-management-system
    • Führen Sie den folgenden Befehl aus, um das Repository zu prüfen:
    # For the RepoSync:
kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE

    Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

    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 mit folgendem Befehl:

    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. Teilen Sie beispielsweise das Repository auf und verwenden Sie ein RootSync-Objekt mit mehreren RepoSync-Objekten, anstatt nur ein RootSync-Objekt zu verwenden, um alle Ressourcen zu synchronisieren.

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" }"

Dies ist ein bekanntes Problem bei Config Sync Version 1.8.1 und früheren Versionen. Folgen Sie der Fehlermeldung im Protokoll, um es zu beheben. Möglicherweise müssen Sie entweder Ihr Git-Repository oder die spec.git-Felder in Ihrem RootSync- oder RepoSync-Objekt aktualisieren.

admission-webhook.configsync.gke.io lehnt die Anfrage zum Aktualisieren/Löschen einer Ressource ab, die von einem bereits 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 würde ablehnen Anfragen zum Ändern oder Löschen dieser Ressourcen, 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.

Fehlermeldungen beheben

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'

Lesen Sie im Abschnitt Berechtigungen vorbereiten, wie Sie dafür sorgen, dass Sie die erforderlichen Berechtigungen 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 der Abgleicher versucht, eine Konfiguration auf den Cluster anzuwenden, und folgender Fehler angezeigt wird:

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

kann das daran liegen, dass die Firewall zum Netzwerk der Steuerungsebene den Zulassungs-Webhook-Port 8676blockiert. 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 der Abgleicher versucht, eine Konfiguration auf den Cluster anzuwenden, und folgender Fehler angezeigt wird:

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

Das bedeutet, dass der Zulassungs-Webhook noch nicht verfügbar ist. 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 der Container git-sync versucht, ein Repository mit einem Secret zu synchronisieren, erhalten Sie den folgenden Fehler:

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 bedeutet, dass das Git-Secret nicht erfolgreich im Container git-sync bereitgestellt wird. 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

Die Container reconciler und/oder git-sync sind OOMKilled

Wenn Sie in Anthos Config Management Version 1.8.2 und höher die Synchronisierung aus mehreren Repositories mit kubectl konfigurieren, können Sie die CPU- und/oder Speicherlimits eines Stamms oder Namespace-Repository überschreiben. Verwenden Sie das Feld spec.override.resources eines RootSync- oder RepoSync-Objekts, um diese Werte zu überschreiben.

Das folgende Beispiel zeigt, wie die CPU- und Arbeitsspeicherlimits des Containers reconciler und das Speicherlimit des Containers git-sync eines Root-Reconciler überschrieben werden. Sie dürfen nur die Container git-sync und reconciler überschreiben. Teilweises Überschreiben ist zulässig: Wenn kein Überschreibungswert für ein Ressourcenlimit angegeben ist, wird das Standardressourcenlimit verwendet.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: "unstructured"
  override:
    resources:
    - containerName: "reconciler"
      cpuLimit: "888m"
      memoryLimit: "444Mi"
    - containerName: "git-sync"
      memoryLimit: "333Mi"
  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.

KNV2004: Repository-Fehler im Git-Synchronisierungscontainer konnte nicht synchronisiert werden (git fetch mit dem Fehler remote did not send all necessary objects)

Config Sync erstellt einen oberflächlichen Klon Ihres Git-Repositorys. In seltenen Fällen kann es vorkommen, dass das Commit nicht im "oberflächlichen" Klon gefunden werden kann, und dass die Anzahl der abzurufenden Git-Commits erhöht werden muss.

In Anthos Config Management Version 1.8.2 und höher können Sie die Anzahl der Git-Commits festlegen, die abgerufen werden sollen. Legen Sie dazu 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 durch, 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.

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 werden:

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

Sie können die Anzahl der Git-Commits, die in einem Namespace-Abgleicher abgerufen werden sollen, ebenfalls überschreiben.

Fehler: Reconciler-Bereitstellungen konnten nicht aktualisiert werden

Beim Aktualisieren von Config Sync von Versionen zwischen 1.6.2 und 1.7.0 auf Versionen zwischen 1.7.x und 1.8.x kann die Image-Version des Reconciler-Deployments möglicherweise nicht aktualisiert werden. Dies wird durch Änderungen am Feld .spec.selector.labels der Deployment-Vorlage verursacht. Ein neues matchLabel wurde in 1.6.2 hinzugefügt und dann in 1.7.0 entfernt. Die Labelauswahl ist unveränderlich, sodass der Reconciler-Manager die Reconciler nicht aktualisieren kann.

Sie können den Fehler anhand der Reconciler-Logs prüfen:

kubectl logs -n config-management-system deployment/reconciler-manager -c reconciler-manager

Hier ein Beispiel für einen Fehler im Log:

Deployment.apps "root-reconciler" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"reconciler"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

Löschen Sie die aktuellen Reconciler, um das Problem zu beheben:

kubectl delete deployment -n config-management-system -l app=reconciler

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

Dies ist der Fall, 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 möglicherweise Config Sync neu installieren.

Damit der Fehler nicht noch einmal auftritt, sollten Sie darauf achten, dass das Namespace-Repository entfernt wird. Hier finden Sie die Anleitung zum Entfernen eines Namespace-Repositorys, 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, sollten Sie die Ressourcenlimits erhöhen.