Auf dieser Seite erfahren Sie, wie Sie Probleme beheben, die auftreten, wenn Config Sync keine Verbindung zur 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.
Fehler bei der Überprüfung des Serverzertifikats für Git-Server
Verbindungen zu privaten Git-Servern verwenden TLS, um die Serverauthentizität zu überprüfen. Für diese Validierung müssen Sie ein Zertifikat angeben, das die Stammzertifizierungsstelle und alle Zwischenzertifizierungsstellen identifiziert, die die Identität des Git-Servers zertifizieren. Wenn die Überprüfung des Git-Serverzertifikats fehlgeschlagen ist, kann die Vertrauenskette nicht hergestellt werden.
Wenn Sie eine Fehlermeldung erhalten, die darauf hinweist, dass die Überprüfung des Serverzertifikats fehlgeschlagen ist, kann dies einen der folgenden Gründe haben:
- 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. Um dieses Problem zu beheben, muss das CACert-Secret die vollständige Vertrauenskette enthalten, einschließlich des Stammzertifikats und aller Zwischenzertifikate.
- Das CACert ist ungültig. Laden Sie die Zertifikatskette über den Link herunter, der im vom Server präsentierten Zertifikat angegeben ist, und aktualisieren Sie dann das CACert-Secret, um dieses Problem zu beheben.
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 Ihrer Konfiguration dazu führen, dass Config Sync keine Verbindung zur Source of Truth herstellen kann. In den folgenden Abschnitten wird beschrieben, wie Sie häufige Konfigurationsprobleme erkennen und beheben können.
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 noch die Diagrammversion oder .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-Registrierungs-URL
Ein ungültiger Wert im Feld spec.oci.image
oder spec.oci.dir
eines RootSync
- oder RepoSync
-Objekts kann zu Verbindungsproblemen führen. 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, führen Sie zuerst diese Schritte zur Fehlerbehebung aus.
github.com host konnte nicht aufgelöst werden
Wenn Config Sync versucht, eine Verbindung zu Ihrem Git-Repository herzustellen, wird anhand von DNS die IP-Adresse des angegebenen Hostnamens aufgelöst. Wenn der Host nicht aufgelöst werden kann, deutet dies in der Regel auf ein Problem mit dem DNS oder der Clusternetzwerk hin.
Informationen zur Diagnose des Problems finden Sie unter Fehlerbehebung bei Cloud DNS in GKE oder Fehlerbehebung bei kube-dns in GKE, je nachdem, welchen Dienst Sie als DNS-Anbieter verwenden.
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 Reconciler-Instanz. Jede Abgleichsinstanz hat ein eigenes quellspezifisches Sidecar: 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, steigt die Anzahl der API-Anfragen, die von den Abgleichern zum Abrufen der „Source of Truth“ gestellt werden, linear an. Wenn Sie also viele RootSync
- und RepoSync
-Objekte haben, die alle dieselbe zentrale Datenquelle abfragen, kann dies manchmal zu einer erheblichen Traffic-Belastung des Quellservers führen.
Sie können das Problem mit einer der folgenden Strategien beheben:
- Kombinieren Sie mehrere
RootSyncs
- oderRepoSync
-Objekte, um die Anzahl der Abgleichsfunktionen zu reduzieren, die Quell-API-Anfragen stellen. - Ändern Sie den 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.
Nächste Schritte
Wenn weiterhin Probleme auftreten, sieh nach, ob dein Problem ein bekanntes Problem ist.
Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Informationen, unter anderem zu den folgenden Themen:
- Sie können eine Supportanfrage erstellen, indem Sie sich an den Cloud Customer Care wenden.
- Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen.
Wenn Sie kpt oder Kustomize verwenden, suchen Sie mit dem Tag
kpt
oderkustomize
nach ähnlichen Problemen. - Sie können Fehler oder Funktionsanfragen über die öffentliche Problemverfolgung auf GitHub melden.