Problèmes connus de Config Sync

Cette page répertorie les problèmes connus des versions prises en charge 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.

Si vous faites partie du programme Google Developer, enregistrez cette page pour recevoir des notifications lorsqu'une note de version la concernant est publiée. Pour en savoir plus, consultez Pages enregistrées.

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
Métriques 1.5.0 1.21.0

Corrigé : métriques signalées pour les packages supprimés

Si vous supprimez un objet RootSync ou RepoSync, mais pas l'objet ResourceGroup portant le même nom, Config Sync continue de signaler les métriques suivantes pour cet objet ResourceGroup :

  • rg_reconcile_duration_seconds
  • resource_group_total
  • resource_count
  • ready_resource_count
  • resource_ns_count
  • cluster_scoped_resource_count
  • crd_count
  • kcc_resource_count
  • pipeline_error_observed
L'objet ResourceGroup n'est supprimé automatiquement que si la propagation de la suppression a été activée avant la suppression de l'objet RootSync ou RepoSync.

Solution :

Supprimez l'objet ResourceGroup :

kubectl delete resourcegroup RESOURCE_GROUP_NAME -n config-management-system

Remplacez RESOURCE_GROUP_NAME par le nom de l'objet ResourceGroup à supprimer. Pour en savoir plus sur la dénomination de ResourceGroup, consultez Contrôleur ResourceGroup et objets ResourceGroup.
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.
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.
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.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.13.0 1.20.1

Corrigé : Impossible de générer un jeton d'accès pour la source OCI

Lorsque Config Sync est configuré pour utiliser OCI comme source de vérité et s'authentifier avec Workload Identity Federation pour GKE, il peut parfois rencontrer des erreurs KNV2004 temporaires lorsqu'il tente de s'authentifier auprès du registre de conteneurs.

Ce problème est dû au fait que la bibliothèque oauth2 n'actualise le jeton d'authentification qu'une fois qu'il a déjà expiré.

Le message d'erreur peut inclure le texte suivant : "oauth2/google: unable to generate access token" ou "ID Token issued at (xxx) is stale to sign-in."

Solution :

L'erreur devrait se résoudre la prochaine fois que Config Sync tentera d'extraire des données de la source de vérité.

Lorsque Config Sync a généré des erreurs à plusieurs reprises, les nouvelles tentatives deviennent moins fréquentes. Pour forcer Config Sync à réessayer plus tôt, supprimez le pod du réconciliateur. Cette action oblige Config Sync à recréer le pod de rapprochement et à récupérer immédiatement les données de la source de vérité :

    kubectl delete pod -n config-management-system RECONCILER_NAME
Remplacez RECONCILER_NAME par le nom du rapprochement de l'objet RootSync ou RepoSync.
Source de référence 1.19.0 1.20.0

Corrigé : fichier de verrouillage Git persistant

Si une erreur semblable à la suivante s'affiche dans le conteneur git-sync, 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. ...

Solution :

Pour contourner 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
Remplacez RECONCILER_NAME par le nom du rapprochement de l'objet RootSync ou RepoSync.
Synchronisation 1.7.0 1.21.0

Corrigé : l'annotation d'ignorance de la mutation n'est pas respectée

Un bug dans le réconciliateur Config Sync l'empêche d'appliquer les modifications des configurations déclarées même lorsque l'annotation client.lifecycle.config.k8s.io/mutation est présente. Cela peut entraîner l'écrasement de l'état de l'objet dans le cluster.

Solution :

Vous pouvez arrêter de gérer l'objet géré en ajoutant l'annotation configmanagement.gke.io/managed: disabled. Toutefois, la désactivation de la gestion empêche Config Sync de recréer l'objet s'il est supprimé du cluster. Cela empêche également l'application d'autres mises à jour dans la source de vérité.
Synchronisation 1.5.0 1.20.1

Correction : les erreurs de découverte d'API peuvent entraîner le marquage incorrect des objets gérés comme Not Found

Si un backend de service d'API n'est pas sain, cela peut entraîner une erreur de découverte d'API. Si cela se produit lors du démarrage du contrôleur ResourceGroup, après une mise à jour ou une reprogrammation, le cache de ressources ne pourra pas s'initialiser, ce qui entraînera l'affichage de tous les objets gérés comme Not Found dans l'état ResourceGroup.

Ce problème se produit souvent lorsque le metrics-server est défectueux.

Solution :

Redémarrez le pod resource-group-controller une fois que le metrics-server est redevenu opérationnel :

    kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME
Remplacez RESOURCE_GROUP_CONTROLLER_NAME par le nom du contrôleur ResourceGroup, qui est le même que le nom RootSync ou RepoSync pour ce package.
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.
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, configurez 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
Synchronisation 1.7.0 1.21.0

Correction : échec de l'écriture de l'inventaire mis à jour dans le cluster

Si Config Sync ne parvient pas à mettre à jour l'état d'un objet ResourceGroup, vous pouvez rencontrer une erreur intermittente dans les journaux du rapprocheur, semblable à la suivante :

    KNV2009: task failed (action: "Inventory", name: "inventory-set-0"): failed to write updated inventory to cluster: Operation cannot be fulfilled on resourcegroups.kpt.dev "root-sync": the object has been modified; please apply your changes to the latest version and try again

Cette erreur est due à une condition de concurrence entre le reconciler et le contrôleur ResourceGroup. Le contrôleur ResourceGroup peut mettre à jour l'état ResourceGroup avant que le réconciliateur puisse mettre à jour la spécification ResourceGroup, ce qui provoque l'erreur KNV2009.

Solution :

Il n'existe aucune solution pour ce problème. L'erreur devrait se résoudre d'elle-même.
Terraform Terraform version 5.41.0

Impossible d'installer ni de mettre à niveau Config Sync à l'aide de Terraform

La version 5.41.0 de Terraform a introduit un nouveau champ dans la ressource google_gke_hub_feature_membership : config_sync.enabled. Comme la valeur par défaut de ce champ est false, si ce champ n'est pas explicitement défini sur true, les installations ou mises à niveau de Config Sync échouent lorsque vous utilisez Terraform version 5.41.0 ou ultérieure. Si ce problème se produit, le message d'erreur git spec not included in configmanagement spec peut également s'afficher.

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 de passer à une autre méthode d'installation de Config Sync. Si vous ne parvenez pas à passer à la nouvelle version, mettez à jour votre application vers la version v33.0.0.

ConsoleGoogle Cloud

Erreurs de données manquantes dans le tableau de bord Config Sync de la console Google Cloud

Il est possible que des erreurs telles que "données manquantes" ou "identifiants de cluster non valides" s'affichent pour les clusters Config Sync dans les tableaux de bord de la console Google Cloud . Ce problème peut se produire lorsque vous n'êtes pas connecté à vos clusters GDC (VMware) ou GDC (bare metal).

Solution :

Si ces types d'erreurs s'affichent dans la console Google Cloud de vos clusters GDC (VMware) ou GDC (Bare Metal), assurez-vous d'être connecté à vos clusters avec GKE Identity Service ou Connect Gateway.

Synchronisation 1.21.0

Corrigé : Config Sync empêche la mise à jour des ressources abandonnées

Avant la version 1.21.0, un objet RootSync ou RepoSync supprimé pouvait laisser de côté plusieurs libellés et annotations que Config Sync utilise pour suivre ces objets de ressources.

Ces libellés et annotations peuvent entraîner les effets secondaires suivants après la suppression d'un objet RootSync ou RepoSync :

  • D'autres objets RepoSync ne peuvent pas devenir propriétaires d'objets précédemment gérés.
  • Si la protection contre les dérives est activée, Config Sync peut rejeter les modifications apportées aux ressources abandonnées.
Outil de ligne de commande nomos 1.17.0

La CLI nomos n'est pas compatible avec le plug-in d'authentification oidc

Des erreurs telles que no Auth Provider found for name "oidc" peuvent s'afficher lorsque vous utilisez l'outil de ligne de commande nomos. Ce problème peut se produire lorsque vous utilisez le plug-in d'authentification oidc.

Solution :

Il n'existe aucune solution de contournement. Le plug-in d'authentification oidc sera réintégré dans une prochaine version.

Haut de page

Étapes suivantes