Résoudre les problèmes de connexion à la source de vérité

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 objets RootSync ou RepoSync.
  • 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 ou RepoSync 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.

Autres problèmes

Cette section contient d'autres problèmes divers qui ne relèvent pas des sections précédentes.

Fichier de verrouillage Git persistant

Si git-sync renvoie l'erreur suivante, il est possible qu'un précédent appel de git ait échoué et qu'un fichier de verrouillage persistant soit resté dans le conteneur :

KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...

Pour résoudre ce problème, redémarrez le pod de rapprochement concerné afin de lui attribuer un nouveau volume éphémère :

kubectl delete pod -n config-management-system RECONCILER_NAME

Étape suivante