Cette page explique comment résoudre les problèmes qui se produisent lorsque Config Sync ne peut pas établir de connexion avec votre source de vérité.
Problèmes d'authentification
Si l'authentification échoue, Config Sync ne peut pas se connecter à la source de vérité. Les sections suivantes vous expliquent comment résoudre certains problèmes d'authentification.
Échec de la validation du certificat du serveur pour les serveurs Git
Les connexions aux serveurs Git privés utilisent le protocole TLS pour vérifier l'authenticité du serveur. Pour effectuer cette validation, vous devez fournir un certificat identifiant l'autorité de certification racine et toutes les autorités de certification intermédiaires qui certifient l'identité du serveur Git. Si la vérification du certificat du serveur Git a échoué, cela signifie que la chaîne de confiance ne peut pas être établie.
Si vous recevez un message d'erreur indiquant que la validation du certificat de serveur a échoué, l'un des problèmes suivants peut en être la cause :
- Le certificat de l'autorité de certification (CACert) n'est pas spécifié. Pour résoudre ce problème, ajoutez le certificat CACert en tant que secret et référencez-le dans le champ
spec.git.caCertSecretRef
de vos objetsRootSync
ouRepoSync
. - Le certificat CACert est incomplet. Pour résoudre ce problème, corrigez le secret CACert afin de contenir la chaîne de confiance complète, y compris le certificat racine et tous les certificats intermédiaires.
- Le certificat CACert n'est pas valide. Pour résoudre ce problème, téléchargez la chaîne de certificats à partir du lien spécifié par le certificat présenté par le serveur, puis mettez à jour le secret CACert.
Impossible d'installer le secret Git
Si vous recevez l'erreur suivante lorsque le conteneur git-sync
tente de synchroniser un dépôt avec un secret, le secret Git n'est pas correctement installé dans le conteneur git-sync
:
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
Cela peut être dû au changement de type d'authentification de votre dépôt Git, de none
, gcenode
ou gcpserviceaccount
vers d'autres types nécessitant un secret.
Pour résoudre ce problème, exécutez les commandes suivantes pour redémarrer le gestionnaire de rapprochement et les rapprochements :
# 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
Problèmes de configuration
Souvent, des problèmes liés à votre configuration peuvent empêcher Config Sync de se connecter à votre source de vérité. Dans les sections suivantes, nous expliquons comment identifier et résoudre les problèmes de configuration courants.
Nom de graphique non valide
Lors de la synchronisation à partir d'un dépôt Helm, veillez à définir la valeur correcte pour spec.helm.chart
. Le nom du graphique ne contient pas le nom du dépôt, la version du graphique ni .tgz
. Vous pouvez vérifier le nom de votre graphique à l'aide de la commande helm
template
.
Répertoire de configuration non valide
Recherchez des erreurs dans vos configurations, telles qu'une valeur incorrecte pour policyDir
dans l'objet ConfigManagement
ou spec.git.dir
ou spec.oci.dir
dans l'objet RootSync
ou RepoSync
. La valeur du répertoire est incluse dans tous les messages d'erreur KNV2004
que vous recevez ; vérifier la valeur par rapport à votre dépôt Git ou à votre image OCI.
Branche Git non valide
Recherchez dans les journaux du conteneur git-sync
une erreur de type Remote branch
BRANCH_NAME not found in upstream origin
ou warning: Could
not find remote branch BRANCH_NAME to clone.
. La branche par défaut est définie sur master
si elle n'est pas spécifiée.
Identifiants Git, Helm ou OCI non valides
Recherchez l'une des erreurs suivantes dans les journaux Config Sync du conteneur git-sync
, helm-sync
ou oci-sync
:
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
Pour un dépôt Git, vérifiez que les identifiants Git et le secret git-creds
sont correctement configurés.
Pour un dépôt Helm, vérifiez que les identifiants Helm sont configurés correctement.
Pour les images OCI, vérifiez que les identifiants OCI sont configurés correctement.
URL du dépôt Git non valide
Recherchez dans les journaux du conteneur git-sync
une erreur de type Repository not
found
.
Vérifiez que vous utilisez le bon format d'URL. Par exemple, si vous utilisez une paire de clés SSH pour vous authentifier auprès du dépôt Git, assurez-vous que l'URL que vous saisissez pour votre dépôt Git lorsque vous configurez Config Sync utilise le protocole SSH.
URL du dépôt Helm non valide
Recherchez dans les journaux du conteneur helm-sync
une erreur de type ...not a
valid chart repository
. Vous pouvez vérifier l'URL de votre dépôt Helm à l'aide de la commande helm
template
.
URL de registre OCI non valide
Une valeur non valide dans le champ spec.oci.image
ou spec.oci.dir
d'un objet RootSync
ou RepoSync
peut entraîner des problèmes de connexion. Vérifiez que ces valeurs sont correctes. Par exemple, si vous effectuez une synchronisation à partir d'un registre OCI, l'URL doit commencer par oci://
.
Vous pouvez également consulter les journaux du conteneur oci-sync
pour plus d'informations.
Problèmes de réseau
Si vous pensez que le problème est lié au réseau de votre cluster, commencez par ces étapes de dépannage.
Impossible de résoudre l'hôte : github.com
Lorsque Config Sync tente de se connecter à votre dépôt Git, il utilise le DNS pour résoudre l'adresse IP du nom d'hôte spécifié. Si l'hôte ne peut pas être résolu, cela indique généralement un problème lié au DNS ou à la mise en réseau du cluster.
Pour diagnostiquer le problème, consultez la page Dépannage du DNS dans GKE.
Le dépôt Git est inaccessible depuis le cluster
Le conteneur git-sync
génère parfois une erreur dans ses journaux indiquant qu'il ne peut pas atteindre le dépôt. Exemple :ssh: connect to host
source.developers.google.com port 2022: Network is unreachable
Pour résoudre le problème, ajustez la configuration du pare-feu ou du réseau de votre cluster.
Nombre élevé de requêtes d'API sources
Config Sync utilise une stratégie à plusieurs instances pour effectuer le scaling et l'isolation des locataires et des domaines de défaillance. Par conséquent, chaque objet RootSync
et RepoSync
dispose de sa propre instance de rapprochement. Chaque instance de rapprochement possède son propre side-car, git-sync
, oci-sync
ou helm-sync
spécifique à la source. Ces side-cars interrogent la source de vérité. Lorsque vous ajoutez des objets RootSync
ou RepoSync
supplémentaires, cela entraîne une augmentation linéaire du nombre de requêtes API effectuées par les rapprochements interrogeant la source de vérité. Ainsi, si vous avez de nombreux objets RootSync
et RepoSync
qui interrogent tous la même source de vérité, cela peut parfois entraîner une charge de trafic importante sur le serveur source.
Envisagez l'une des stratégies suivantes pour atténuer ce problème :
- Combinez plusieurs objets
RootSyncs
ouRepoSync
pour réduire le nombre de rapprochements qui envoient des requêtes API sources. - Remplacez votre type de source Git par OCI. Les dépôts OCI, tels qu'Artifact Registry, ont tendance à mieux évoluer que la plupart des serveurs Git, car ils peuvent effectuer un scaling horizontal sans avoir à effectuer de synchronisation entre les instances dupliquées des serveurs.
Étapes suivantes
- Si le problème persiste, vérifiez s'il s'agit d'un problème connu.