Problèmes connus de Config Sync

Cette page répertorie les problèmes connus des versions compatibles de Config Sync. 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

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 :

Effectuer une mise à niveau vers la version 1.17.0 ou une version ultérieure. Dans Config Sync 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.

Si vous ne pouvez pas effectuer de mise à niveau, spécifiez une limite de mémoire plus élevée à l'aide des remplacements de ressources.

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

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

É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

Solution :

Pour résoudre le problème, procédez comme suit : mettez à niveau votre cluster GKE vers la version 1.28 ou une version ultérieure de GKE ou mettez à niveau Config Sync vers la version 1.16.0 ou ultérieure. Ces deux versions contiennent des correctifs pour le problème client-go.
Métriques 1.15.0 1.17.2

Échec de l'exportation : libellés de métriques non reconnus

Dans la version 1.15.0, Config Sync a ajouté les libellés type et commit à de nombreuses métriques. Ces libellés 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 libellés 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.

Solution :

Effectuer une mise à niveau vers la version 1.17.2 ou une version ultérieure.
Métriques 1.15.0 1.16.1

Cardinalité élevée des métriques et erreurs de transformation

Dans la version 1.15.0, Config Sync a ajouté les libellés type et commit à de nombreuses métriques. Ces libellés 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 libellés 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.

Solution :

Effectuer une mise à niveau vers la version 1.16.1 ou une version ultérieure. Dans la version 1.16.1, le champ de type a été supprimé, le filtrage a été corrigé et le champ de commit a été également filtré de Cloud Monitoring. Cela a corrigé les erreurs et réduit 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

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.

Solution :

Passer à la version 1.17.2 de nomos.

Mesures

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.
Mesures

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.16.1 1.16.2

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.

Solution :

Mettre à jour Config Sync vers la version 1.16.2 ou une version ultérieure. Dans ces versions, il s'agit d'une erreur temporaire. Elle est donc journalisée, mais pas signalée comme erreur.
Source de référence 1.15.0 1.18.0

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.

Solution :

Mettre à jour Config Sync vers la version 1.18.0 ou une version ultérieure. Dans ces versions, le jeton est actualisé lors de la première requête dans les cinq minutes suivant son expiration. Cela évite l'erreur d'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

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.

Solution :

Effectuer une mise à niveau vers la version 1.17.0 ou une version ultérieure. 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

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

Dans les versions 1.17.0 et ultérieures 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

Solution :

Pour atténuer ce problème, vous pouvez définir votre version 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.

Haut de page

Étapes suivantes