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