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 aufzurufen.
Service Level Indicators (SLIs) verwenden
Wenn Sie Benachrichtigungen erhalten möchten, wenn Config Sync nicht wie vorgesehen funktioniert, richten Sie Prometheus-Benachrichtigungsregeln auf der Grundlage der 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
undconfigsync.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
Aktivieren Sie die Audit-Logs der GKE Connect/Hub APIs.
Rufen Sie in der Google Cloud Console die IAM-Seite Audit-Logs auf.
Klicken Sie in der Tabelle das Kästchen GKE Connect/Hub APIs an.
Klicken Sie die folgenden Kästchen an:
- Administratortätigkeit
- Daten lesen
- Daten schreiben
Klicken Sie auf Speichern.
Rufen Sie die Seite Log-Explorer auf.
Fügen Sie im Textfeld Query Builder die folgenden Filter hinzu:
resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
Klicken Sie auf Abfrage ausführen.
Wählen Sie im Bereich Abfrageergebnisse Einträge aus, um mehr über die Ereignisse zu erfahren.
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
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 diestatus.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 in mehrere Repositories aufzuteilen. Weitere Informationen dazu finden Sie unter Repository in mehrere Repositories aufteilen.
Wenn Sie das Git-Repository nicht auflösen können, können Sie das Melden von Statusdaten deaktivieren. 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:
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.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 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: 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
Um dieses Problem zu beheben, legen Sie in Anthos Config Management Version 1.12.0 und höher spec.override.enableShellInRendering
als true
fest.
Die Container reconciler
, hydration-controller
und/oder git-sync
sind OOMKilled
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.
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.
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.