Problèmes connus de Config Sync

Cette page répertorie les problèmes connus des versions compatibles de Config Sync.

Un grand nombre des problèmes répertoriés sur cette page ont été résolus. La colonne Version corrigée indique la version dans laquelle le correctif a été introduit. Pour bénéficier de ce correctif, effectuez une mise à niveau vers la version répertoriée ou une version ultérieure.

Pour filtrer les problèmes connus en fonction d'une version de produit ou d'une catégorie de problème, sélectionnez vos filtres dans les menus déroulants suivants.

Sélectionnez votre version de Config Sync :

Sélectionnez votre catégorie de problème :

Vous pouvez également filtrer les problèmes connus :

Catégorie Version identifiée Version corrigée Problème et solution
Intégrité du composant 1.15.0 1.17.0

Corrigé : conteneur de rapprochement OOMKilled sur AutoPilot

Sur les clusters Autopilot, les conteneurs de composants Config Sync sont soumis à des limites de ressources définies pour le processeur et la mémoire. Quand une charge est présente, ces conteneurs peuvent être supprimés par le kubelet ou le noyau s'ils utilisent trop de mémoire.

Solution :

Si vous ne pouvez pas passer à la version 1.17.0 ou ultérieure, spécifiez une limite de mémoire plus élevée à l'aide des remplacements de ressources.

Dans la version 1.17.0, les limites par défaut de processeur et de mémoire ont été ajustées pour éviter les erreurs de mémoire insuffisante dans la plupart des cas d'utilisation.
Intégrité du composant 1.15.0

Rapprochement non programmable

Les rapprochements Config Sync nécessitent différentes quantités de ressources, en fonction de la configuration de RootSync ou RepoSync. Certaines configurations nécessitent plus de ressources que d'autres.

Si un rapprochement n'est pas programmable, cela peut être dû à une demande de ressources supérieure aux quantités disponibles sur vos nœuds.

Si vous utilisez des clusters GKE en mode standard, les demandes de ressources du rapprochement sont très faibles. Ce paramètre a été choisi afin de permettre la programmation, même si cela entraînerait une limitation et un ralentissement des performances. Ainsi, Config Sync fonctionne sur de petits clusters et des nœuds de petite taille. Toutefois, sur les clusters GKE Autopilot, les requêtes de rapprochement sont définies sur une valeur plus élevée, pour représenter de manière plus réaliste l'utilisation lors de la synchronisation.

Solution :

GKE Autopilot ou GKE Standard avec le provisionnement automatique des nœuds activé devrait voir la quantité de ressources demandée et créer des nœuds de taille adaptée pour permettre la programmation. Toutefois, si vous configurez manuellement les nœuds ou les tailles d'instance de nœud, vous devrez peut-être ajuster ces paramètres pour répondre aux besoins en ressources des pods de rapprochement.
Erreurs KNV 1.15.0 Version 1.27 de Kubernetes

Corrigé : erreur KNV1067 même si la configuration a bien été appliquée

En raison d'un problème lié à OpenAPI v2, une erreur KNV1067 peut s'afficher même si votre configuration a bien été appliquée.

Solution :

Si votre cluster exécute une version de Kubernetes antérieure à la version 1.27, assurez-vous que le champ protocol est explicitement défini sous spec: containers: ports:, même si vous utilisez le TCP par défaut.

Erreurs KNV 1.15.0 1.16.0, Kubernetes version 1.28

Corrigé : échec de rapprochement Config Sync avec l'erreur KNV2002

Si Config Sync ne parvient pas à effectuer le rapprochement avec un KNV2002 error, cela peut être dû à un problème connu causé par un problème de client-go. Le problème entraîne une liste vide de ressources dans le groupe d'API external.metrics.k8s.io/v1beta1 avec un message d'erreur provenant de l'objet RootSync ou RepoSync, ou des journaux de rapprochement :

KNV2002: API discovery failed: APIServer error: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: received empty response for:
external.metrics.k8s.io/v1beta1
Métriques 1.15.0 1.17.2

Corrigé : échec de l'exportation : étiquettes de métriques non reconnues

Dans la version 1.15.0, Config Sync a ajouté les étiquettes type et commit à de nombreuses métriques. Ces étiquettes ont augmenté la cardinalité des métriques, ce qui a augmenté le nombre de métriques exportées. Un traitement des attributs a également été ajouté pour filtrer ces étiquettes lors de l'exportation vers Cloud Monarch, mais ce filtrage a été mal configuré, ce qui entraîne des erreurs de transformation dans les journaux otel-collector.
Métriques 1.15.0 1.16.1

Corrigé : cardinalité élevée des métriques et erreurs de transformation

Dans la version 1.15.0, Config Sync a ajouté les étiquettes type et commit à de nombreuses métriques. Ces étiquettes ont augmenté la cardinalité des métriques, ce qui a augmenté le nombre de métriques exportées. Un traitement des attributs a également été ajouté pour filtrer ces étiquettes lors de l'exportation vers Cloud Monarch, mais ce filtrage a été mal configuré, ce qui entraîne des erreurs de transformation dans les journaux otel-collector.

Dans la version 1.16.1, le champ de type a été supprimé, le filtrage a été corrigé et le champ de commit a également été filtré à partir de Cloud Monitoring. Cela a permis de corriger les erreurs et de réduire la cardinalité des métriques.
Métriques 1.15.0

Échec de l'exportation. Autorisation refusée

Par défaut, lorsque le gestionnaire de rapprochement détecte les identifiants par défaut de l'application, otel-collector est configuré pour exporter des métriques vers Prometheus, Cloud Monitoring et Monarch.

Solution :

otel-collector consigne les erreurs si vous n'avez pas configuré Cloud Monitoring ou désactivé Cloud Monitoring et Cloud Monarch.
Métriques 1.15.0

Plantage d'otel-collector avec la configuration personnalisée

Si vous essayez de modifier ou de supprimer l'une des ConfigMaps par défaut, otel-collector ou otel-collector-google-cloud, otel-collector peut entraîner une erreur ou subir un plantage et ne pas pouvoir charger la ConfigMap requise.

Solution :

Pour personnaliser la configuration de l'exportation des métriques, créez une ConfigMap nommée otel-collector-custom dans l'espace de noms config-management-monitoring.
nomos cli 1.15.0 1.17.2

Corrigé : nomos status et nomos bugreport ne fonctionnent pas dans un pod

Avant la version 1.17.2 de nomos, nomos bugreport et nomos status ne pouvaient se connecter au cluster local que lorsqu'ils étaient exécutés dans un pod Kubernetes. Dans la version 1.17.2 de nomos, la méthode d'autorisation a été modifiée pour fonctionner plus comme kubectl. En raison de cette modification, le cluster local est ciblé par défaut. Vous pouvez remplacer la configuration en spécifiant la variable d'environnement KUBECONFIG.
Correction

Config Sync en conflit avec lui-même

Config Sync peut sembler subir un conflit de contrôleur. avec lui-même. Cela se produit si vous définissez la valeur par défaut d'un champ facultatif d'une ressource dans le dépôt Git. Par exemple, la définition de apiGroup: "" pour l'objet d'une RoleBinding déclenche cette action, car le champ apiGroup est facultatif et une chaîne vide est la valeur par défaut. Les valeurs par défaut des champs de type chaîne, booléen et entier sont "", false et 0 (respectivement).

Solution :

Supprimez le champ de la déclaration de ressources.
Correction

Conflit entre Config Sync et les ressources Config Connector

Config Sync peut sembler entrer en conflit avec Config Connector sur une ressource, par exemple un StorageBucket. Ce problème se produit si vous ne définissez pas la valeur d'un champ facultatif d'une ressource spec.lifecycleRule.condition.withState dans la source de référence.

Solution :

Vous pouvez éviter ce problème en ajoutant le champ withState=ANY à la déclaration de ressources. Vous pouvez également abandonner, puis récupérer la ressource avec l'annotation cnrm.cloud.google.com/state-into-spec: absent.

Source de référence 1.17.3 1.18.3

Corrigé : échec de l'authentification SSH Git avec GitHub

git-sync v4.2.1 présente un bug qui supprime le nom d'utilisateur de l'URL du dépôt lors de l'utilisation de SSH, ce qui entraîne l'échec de l'authentification lors de la connexion à GitHub. L'utilisateur doit donc être git.

Le message d'erreur de git est le suivant : git-sync@github.com: Permission denied (publickey).\r\nfatal: Could not read from remote repository.

Solution :

Utilisez une autre méthode d'authentification.
Source de référence 1.16.1 1.16.2

Corrigé : il est périodiquement impossible d'évaluer le lien source

Config Sync peut rencontrer des problèmes lorsque le rapprochement démarre et qu'il est périodiquement impossible d'évaluer le lien source. Ce problème se produit car git-sync n'a pas encore cloné le dépôt source.

Dans les versions 1.16.2 et ultérieures, il s'agit d'une erreur temporaire. Elle est donc consignée, mais n'est pas signalée comme une erreur.
Source de référence 1.15.0 1.18.0

Corrigé : identifiants d'authentification périodiquement invalides pour Cloud Source Repositories

Config Sync peut générer des erreurs régulièrement lorsque le jeton d'authentification expire pour Cloud Source Repositories. Ce problème est causé par l'attente d'actualisation du jeton avant son expiration.

Dans les versions 1.18.0 et ultérieures, le jeton est actualisé lors de la première requête dans les cinq minutes suivant son expiration. Cela permet d'éviter l'erreur des identifiants d'authentification non valides, sauf si les identifiants sont réellement non valides.
Source de référence 1.15.0 1.17.0

Corrigé : erreur lors de la synchronisation du dépôt : délai de contexte dépassé

Dans les versions antérieures à 1.17.0, Config Sync testait par défaut l'historique complet du dépôt Git. Cela peut entraîner l'expiration du délai de la requête de récupération sur les dépôts volumineux comportant de nombreux commits.

Dans les versions 1.17.0 et ultérieures, la récupération Git est effectuée avec --depth=1, qui ne récupère que le dernier commit. Cela accélère la récupération de la source, évite la plupart des délais d'expiration et réduit la charge du serveur Git.

Si vous rencontrez toujours ce problème après la mise à niveau, il est probable que votre source de référence contient de nombreux fichiers, que votre serveur Git répond lentement ou qu'il existe un autre problème de mise en réseau.
Synchronisation 1.15.0

Nombre élevé de requêtes PATCH inefficaces dans les journaux d'audit

Le correcteur Config Sync utilise un dry-run (test à blanc) pour détecter les dérives. Cela peut entraîner l'affichage de requêtes PATCH dans le journal d'audit, même si le champ PATCH n'est pas conservé, car le journal d'audit ne fait pas la distinction entre les dry-run et les requêtes normales.

Solution :

Étant donné que le journal d'audit ne fait pas la distinction entre les dry-run et les requêtes normales, vous pouvez ignorer les requêtes PATCH.
Synchronisation 1.17.0 1.17.3

Corrigé : Config Sync ne parvient pas à extraire le dernier commit d'une branche

Dans les versions 1.17.0, 1.17.1 et 1.17.2 de Config Sync, vous pouvez rencontrer un problème où Config Sync ne parvient pas à extraire le dernier commit du HEAD d'une branche spécifique lorsque la même branche est référencée dans plusieurs hôtes distants et qu'ils ne sont pas synchronisés. Par exemple, la branche main d'un dépôt distant origin peut être en avance sur la même branche dans le dépôt distant upstream, mais Config Sync n'extrait que le SHA du commit de la dernière ligne, qui peut ne pas correspondre au dernier commit.

L'exemple suivant montre comment ce problème peut se manifester :

git ls-remote -q [GIT_REPOSITORY_URL] main  main^{}
244999b795d4a7890f237ef3c8035d68ad56515d    refs/heads/main               # the latest commit
be2c0aec052e300028d9c6d919787624290505b6    refs/remotes/upstream/main    # the commit Config Sync pulls from

Dans la version 1.17.3 et les suivantes, la dépendance git-sync a été mise à jour avec un mécanisme de récupération différent.

Si vous ne pouvez pas effectuer la mise à niveau, vous pouvez définir votre révision Git (spec.git.revision) sur le SHA du dernier commit, quelle que soit la valeur définie pour la branche Git (spec.git.branch). Pour en savoir plus sur les configurations Git, consultez la section Configuration du dépôt Git.
Registre privé 1.19.0

Config Sync n'utilise pas de registre privé pour les déploiements de rapprochement

Config Sync doit remplacer les images de tous les déploiements lorsqu'un registre privé est configuré. Toutefois, il ne remplace pas le registre d'images pour les images dans les déploiements de rapprochement.

Solution :

Pour contourner ce problème, vous pouvez configurer le miroir du registre d'images dans containerd.

Synchronisation 1.17.0 1.18.3

Corrigé : le programme de rapprochement Config Sync subit des plantages en boucle

Dans les versions 1.17.0 et ultérieures de Config Sync, vous pouvez rencontrer un problème où le réconciliateur ne parvient pas à créer une configuration rest dans certains fournisseurs Kubernetes.

L'exemple suivant montre comment ce problème peut se manifester dans les journaux du réconciliateur :

Error creating rest config: failed to build rest config: reading local kubeconfig: loading REST config from "/.kube/config": stat /.kube/config: no such file or directory
Terraform Terraform version 5.41.0

Config Sync ne peut pas être installé ni mis à niveau à l'aide de Terraform

La version 5.41.0 de Terraform a introduit un nouveau champ dans google_gke_hub_feature_membership : config_sync.enabled. Comme la valeur par défaut de ce champ est false, les installations de Config Sync échouent lorsque Terraform est mis à niveau vers la version 5.41.0.

Solution :

  • Si vous utilisez la ressource google_gke_hub_feature_membership, définissez manuellement config_sync.enabled sur true.
  • Si vous utilisez le sous-module acm, nous vous recommandons d'utiliser une autre méthode pour installer Config Sync. Si vous ne parvenez pas à passer à la nouvelle version, mettez à jour votre application vers la version v33.0.0.

Haut de page

Étapes suivantes