Problèmes connus de Config Sync

Correction: Métriques signalées pour les packages supprimés

Si vous supprimez un objet RootSync ou RepoSync, mais que vous ne supprimez pas l'objet ResourceGroup portant le même nom, Config Sync continue de générer 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

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 l'attribution de noms aux ResourceGroup, consultez Contrôleur ResourceGroup et objets ResourceGroup.

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.

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

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.

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.

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.

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.

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.

Correction: 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 référentiel de conteneurs.

Ce problème est dû au fait que la bibliothèque oauth2 n'actualise le jeton d'authentification qu'après son expiration.

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 à partir de la source de vérité.

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

    kubectl delete pod -n config-management-system RECONCILER_NAME
    

Correction: fichier de verrouillage Git persistant

Si une erreur semblable à celle-ci s'affiche à partir du conteneur git-sync, il est possible qu'un appel git précédent 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
    

Correction: l'annotation d'ignorer la mutation n'est pas respectée

Un bug dans le réconciliateur Config Sync l'amène à 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 le remplacement 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 de nouvelles mises à jour dans la source de vérité.

Correction: les erreurs de découverte d'API peuvent entraîner la mauvaise attribution de la valeur Not Found aux objets gérés

Si le backend d'un service d'API est défaillant, la découverte de l'API peut entraîner une erreur. Si cela se produit pendant le démarrage du contrôleur ResourceGroup, après avoir été mis à jour ou reprogrammé, l'initialisation du cache de ressources échouera, ce qui entraînera la création d'un état Not Found pour tous les objets gérés dans ResourceGroup.

Ce problème se produit souvent lorsque l'metrics-server est défaillant.

Solution :

Redémarrez le pod resource-group-controller une fois que l'metrics-server est de nouveau opérationnel:

    kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME
    

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 :

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.

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 à quoi ce problème peut ressembler 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

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 rapprochement semblable à celle-ci:

    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 réconciliateur et le contrôleur de groupe de ressources. Le contrôleur ResourceGroup peut mettre à jour l'état de ResourceGroup avant que le réconciliateur ne puisse mettre à jour la spécification ResourceGroup, ce qui entraîne l'erreur KNV2009.

Solution :

Il n'existe aucune solution de contournement pour ce problème. L'erreur devrait se résoudre automatiquement.

Vous ne pouvez pas installer ni 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. La valeur par défaut de ce champ étant false, si ce champ n'est pas explicitement défini sur true, les installations ou les mises à niveau de Config Sync échouent lorsque vous utilisez Terraform 5.41.0 ou une version ultérieure. Si ce problème se produit, un 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.

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

Des erreurs telles que "Données manquantes" ou "Identifiants de cluster non valides" peuvent s'afficher 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 vous voyez ces types d'erreurs 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.

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

Avant la version 1.21.0, un objet RootSync ou RepoSync supprimé peut laisser 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:

• Les 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.