Auf dieser Seite erfahren Sie, wie Sie Probleme beheben, die auftreten, wenn Config Sync keine Verbindung zu Ihrer Source of Truth herstellen kann.
Authentifizierungsprobleme
Wenn die Authentifizierung fehlschlägt, kann Config Sync keine Verbindung zur "Source of Truth" herstellen. In den folgenden Abschnitten wird beschrieben, wie Sie einige Authentifizierungsprobleme beheben können.
Serverzertifikatüberprüfung für Git-Server fehlgeschlagen
Verbindungen zu privaten Git-Servern verwenden TLS, um die Authentizität des Servers zu prüfen. Für diese Validierung müssen Sie ein Zertifikat bereitstellen, das die Root-Zertifizierungsstelle und alle zwischengeschalteten Zertifizierungsstellen identifiziert, die die Identität des Git-Servers bestätigen. Wenn die Git-Serverzertifikatüberprüfung fehlgeschlagen ist, kann die Vertrauenskette nicht eingerichtet werden.
Wenn Sie eine Fehlermeldung erhalten, die angibt, dass die Überprüfung des Serverzertifikats fehlgeschlagen ist, könnte eines der folgenden Probleme die Ursache sein:
- Das Zertifikat der Zertifizierungsstelle (CACert) ist nicht angegeben. Um dieses Problem zu beheben, fügen Sie CACert als Secret hinzu und verweisen auf das Secret im Feld
spec.git.caCertSecretRef
IhrerRootSync
- oderRepoSync
-Objekte. - Das CACert ist unvollständig. Beheben Sie dieses Problem, indem Sie das CACert-Secret so korrigieren, dass es die vollständige Vertrauenskette enthält, einschließlich des Root- und aller Zwischenzertifikate.
- Das CACert ist ungültig. Um dieses Problem zu beheben, laden Sie die Zertifikatskette von dem Link herunter, der durch das vom Server bereitgestellte Zertifikat angegeben wird, und aktualisieren Sie dann das CACert-Secret.
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 spins
# 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 recreates the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system
Probleme bei der Konfiguration
Häufig können Probleme mit der Konfiguration dazu führen, dass Config Sync keine Verbindung zu Ihrer "Source of Truth" herstellen kann. In den folgenden Abschnitten wird erläutert, wie Sie häufige Konfigurationsprobleme identifizieren und beheben.
Ungültiger Diagrammname
Achten Sie bei der Synchronisierung aus einem Helm-Repository darauf, dass Sie den richtigen Wert für spec.helm.chart
festlegen. Der Diagrammname enthält weder den Repository-Namen, die Diagrammversion noch .tgz
. Sie können den Diagrammnamen mit dem Befehl helm
template
prüfen.
Ungültiges Konfigurationsverzeichnis
Prüfen Sie Ihre Konfigurationen auf Fehler, z. B. einen falschen Wert für policyDir
im ConfigManagement
-Objekt oder spec.git.dir
oder spec.oci.dir
im RootSync
- oder RepoSync
-Objekt. Der Wert des Verzeichnisses ist in allen KNV2004
-Fehlermeldungen enthalten, die Sie erhalten. Prüfen Sie den Wert anhand Ihres Git-Repositorys oder OCI-Images.
Ungültiger Git-Zweig
Prüfen Sie die Logs für den Container git-sync
auf Fehler wie Remote branch
BRANCH_NAME not found in upstream origin
oder warning: Could
not find remote branch BRANCH_NAME to clone.
. Wenn nichts angegeben ist, wird der Standard-Branch auf master
gesetzt.
Ungültige Git-, Helm- oder OCI-Anmeldedaten
Prüfen Sie die Config Sync-Logs für den Container git-sync
, helm-sync
oder oci-sync
auf einen der folgenden Fehler:
Could not read from remote repository. Ensure you have the correct access rights and the repository exists.
Invalid username or password. Authentication failed for ...
401 Unauthorized
Prüfen Sie bei einem Git-Repository, ob die Git-Anmeldedaten und das Secret git-creds
richtig konfiguriert sind.
Prüfen Sie bei einem Helm-Repository, ob Helm-Anmeldedaten richtig konfiguriert sind.
Prüfen Sie bei OCI-Images, ob die OCI-Anmeldedaten richtig konfiguriert sind.
Ungültige Git-Repository-URL
Prüfen Sie die Logs für den Container git-sync
auf einen Fehler wie Repository not
found
hin.
Prüfen Sie, ob Sie das richtige URL-Format verwenden. Wenn Sie beispielsweise ein SSH-Schlüsselpaar zur Authentifizierung beim Git-Repository verwenden, achten Sie darauf, dass die URL, die Sie beim Konfigurieren von Config Sync für Ihr Git-Repository eingeben haben, das SSH-Protokoll verwendet.
Ungültige Helm-Repository-URL
Prüfen Sie die Logs für den Container helm-sync
auf einen Fehler wie ...not a
valid chart repository
hin. Sie können die URL des Helm-Repositorys mit dem Befehl helm
template
prüfen.
Ungültige OCI-Registry-URL
Ein ungültiger Wert im Feld spec.oci.image
oder spec.oci.dir
eines RootSync
- oder RepoSync
-Objekts kann Verbindungsprobleme verursachen. Prüfen Sie, ob diese Werte korrekt sind. Wenn Sie beispielsweise aus einer OCI-Registry synchronisieren, sollte die URL mit oci://
beginnen.
Sie können auch die Logs für den Container oci-sync
auf weitere Informationen prüfen.
Netzwerkprobleme
Wenn Sie vermuten, dass das Problem mit dem Netzwerk Ihres Clusters zusammenhängt, beginnen Sie mit diesen Schritten zur Fehlerbehebung.
github.com host konnte nicht aufgelöst werden
Wenn Config Sync versucht, eine Verbindung zu Ihrem Git-Repository herzustellen, wird die IP-Adresse des angegebenen Hostnamens mithilfe von DNS aufgelöst. Wenn der Host nicht aufgelöst werden kann, deutet dies in der Regel auf ein Problem mit dem DNS- oder dem Clusternetzwerk hin.
Informationen zur Diagnose des Problems finden Sie unter Fehlerbehebung bei DNS in GKE.
Git-Repository ist innerhalb des Clusters nicht erreichbar
Der Container git-sync
gibt manchmal in seinen Logs einen Fehler aus, der darauf hinweist, dass er das Repository nicht erreichen kann. Beispiel: ssh: connect to host
source.developers.google.com port 2022: Network is unreachable
. Passen Sie zum Beheben des Problems die Firewall- oder Netzwerkkonfiguration des Clusters an.
Hohe Anzahl von Quell-API-Anfragen
Config Sync verwendet eine Mehr-Instanz-Strategie, um Mandanten und Fehlerdomains zu skalieren und zu isolieren. Aus diesem Grund erhält jedes RootSync
- und RepoSync
-Objekt eine eigene Abgleichsinstanz. Jede Abgleicherinstanz hat eine eigene quellenspezifische Sidecar-Datei, git-sync
, oci-sync
oder helm-sync
. Diese Sidecar-Dateien fragen die "Source of Truth" ab. Wenn Sie zusätzliche RootSync
- oder RepoSync
-Objekte hinzufügen, erhöht sich die Anzahl der API-Anfragen der Abgleicher, die die "Source of Truth" abfragen, linear. Wenn also viele RootSync
- und RepoSync
-Objekte dieselbe "Source of Truth" abfragen, kann dies zu einer erheblichen Trafficlast auf dem Quellserver führen.
Ziehen Sie eine der folgenden Strategien in Betracht, um dieses Problem zu beheben:
- Kombinieren Sie mehrere
RootSyncs
- oderRepoSync
-Objekte, um die Anzahl der Abgleicher zu reduzieren, die Quell-API-Anfragen stellen. - Ändern Sie Ihren Quelltyp von Git in OCI. OCI-Repositories wie Artifact Registry lassen sich in der Regel besser skalieren als die meisten Git-Server, da sie horizontal skaliert werden können, ohne dass eine Synchronisierung zwischen Serverrepliken erforderlich ist.
Sonstige Probleme
In diesem Abschnitt finden Sie weitere verschiedene Probleme, die nicht in die vorherigen Abschnitte fallen.
Verweilende Git-Sperrbildschirmdatei
Wenn der folgende Fehler von git-sync
angezeigt wird, ist möglicherweise eine vorherige git
-Aufruf fehlgeschlagen und hat eine laufende Sperrdatei im Container hinterlassen:
KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...
Starten Sie den betroffenen Abgleich-Pod neu, um ihm ein neues temporäres Volume zuzuweisen:
kubectl delete pod -n config-management-system RECONCILER_NAME
Nächste Schritte
- Wenn weiterhin Probleme auftreten, prüfen Sie, ob es sich bei Ihrem Problem um ein bekanntes Problem handelt.