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 verwenden, um den Config Sync-Status nach Repository zu erhalten. Weitere Informationen finden Sie unter Config Sync-Status auf mehreren Clustern ansehen.

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 verwenden, um die verwalteten Config Sync-Ressourcen abzurufen. Weitere Informationen finden Sie unter Verwaltete Config Sync-Ressourcen aufrufen.

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.

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 mit einer Fehlermeldung fehl, die erklärt, welche Felder in Ihrer apply-spec.yaml-Datei falsch sind.

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

Es wird empfohlen, Ihr Git-Repository gemäß der Anleitung in mehrere Repositories aufzuteilen. Wenn es nicht möglich ist, das Git-Repository in Config Sync v1.11.0 und höher aufzuteilen, können Sie dies umgehen. Deaktivieren Sie dazu das Abrufen von Statusdaten. Dazu wird das Feld .spec.override.statusMode des RootSync- oder RepoSync-Objekts auf disabled gesetzt. Dadurch aktualisiert Config Sync den Status der verwalteten Ressourcen im ResourceGroup-Objekt. Damit wird die Größe des ResourceGroup-Objekts reduziert. Sie können den Status für verwaltete Ressourcen jedoch nicht von nomos status oder gcloud alpha anthos config sync aufrufen.

Wenn kein Fehler vom RootSync- oder RepoSync-Objekt angezeigt wird, wird Ihr Git-Repository mit dem Cluster synchronisiert. Um zu prüfen, ob die Ressource vom Typ "ResourceGroup" das etcd-Objektgrößenlimit überschreitet, prüfen Sie sowohl den Ressourcenstatus der 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" }"

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.

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.

Fehlerbehebung

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

Die Container reconciler, hydration-controller und/oder git-sync sind OOMKilled

In Anthos Config Management Version 1.8.2 und höher können Sie die CPU- und/oder Arbeitsspeicherlimits eines Stamm- oder Namespace-Repositorys überschreiben. In Anthos Config Management Version 1.11.0 und höher können Sie auch die CPU- und/oder Arbeitsspeicher-Anfragen eines Stamm- oder Namespace-Repositorys ü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 Speicherlimits des Containers reconciler und die CPU-Anfrage- und Speicherlimits des Containers git-sync eines Root-Abgleichs überschrieben werden. Sie dürfen nur die Container git-sync und reconciler überschreiben. Teilweises Überschreiben ist zulässig: Wenn kein Überschreibungswert für eine Ressourcenanfrage oder -grenze 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.

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

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 der Abgleicher-Bereitstellung möglicherweise nicht aktualisiert werden. Dieser Fehler 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 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

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, sehen Sie möglicherweise, dass sich der otel-collector-Pod unter config-management-monitoring im CrashLoopBackoff-Status befindet, oder Sie erhalten möglicherweise eine Fehlermeldung ähnlich der folgenden:

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.

Dieses Problem tritt normalerweise auf, wenn Workload Identity im 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.