Problèmes connus de Config Sync

Les pods Config Sync sont bloqués lors de la mise à niveau vers la version 1.24.0 sur les clusters migrés vers le hub

Après la mise à niveau vers Config Sync 1.24.0, les champs qui ont été supprimés (tels que readinessProbe et les vérifications d'état pour le side-car otel-agent) peuvent persister sur les clusters qui ont été migrés vers la gestion du hub. Étant donné que le composant de vérification de l'état derrière readinessProbe est supprimé, le conteneur otel-agent ne démarre pas, ce qui entraîne le blocage des pods Config Sync.

Ce problème n'affecte que les clusters dans lesquels Config Sync a été précédemment installé manuellement à l'aide de kubectl, puis est passé à la gestion du hub. Cet échec se produit, car le processus de migration gère la gestion des champs différemment d'une nouvelle installation. Pour les clusters installés manuellement ou les clusters initialement installés par le hub, les champs sont supprimés comme prévu.

Solution :

Pour résoudre ce problème, suivez les instructions pour désinstaller Config Sync, puis réinstallez Config Sync via le hub.

Corrigé : 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 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

Solution :

Supprimez l'objet ResourceGroup :

kubectl delete resourcegroup RESOURCE_GROUP_NAME -n config-management-system

Remplacez RESOURCE_GROUP_NAME par le nom de l' ResourceGroup objet à supprimer. Pour en savoir plus sur ResourceGroup la dénomination, 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 personnalisé les filtres de métriques 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.

Boucles de plantage du conteneur git-sync après l'orphelinat d'un fichier de verrouillage Git

Si le conteneur git-sync subit des boucles de plantage avec des erreurs semblables à celles qui suivent dans le journal du conteneur git-sync, il est possible qu'un précédent appel de git ait échoué et qu'un fichier de verrouillage orphelin soit resté dans le conteneur :

    {"logger":""..."msg":"repo contains lock file","error":null,"path":"/repo/source/.git/shallow.lock"}
    ...runtime error: invalid memory address or nil pointer dereference
    

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
    

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

Un bug dans le rapprochement Config Sync l'oblige à 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 la gestion de l'objet géré en ajoutant l'configmanagement.gke.io/managed: disabled annotation. Toutefois, la désactivation de la gestion empêche Config Sync de recréer l'objet s'il est supprimé du cluster. Elle empêche également l'application d'autres mises à jour dans la source de référence.

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 :

Corrigé : é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, une erreur intermittente peut s'afficher dans les journaux de rapprochement, 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 rapprochement et le contrôleur ResourceGroup. Le contrôleur ResourceGroup peut mettre à jour l'état ResourceGroup avant que le rapprochement ne puisse mettre à jour la spécification ResourceGroup, ce qui entraîne l'erreur KNV2009.

Solution :

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

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

Terraform version 5.41.0 a introduit un nouveau champ dans la ressource google_gke_hub_feature_membership : config_sync.enabled. Étant donné que la valeur par défaut de ce champ est 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 version 5.41.0 ou une version ultérieure. Un message d'erreur indiquant git spec not included in configmanagement spec peut également s'afficher si ce problème se produit.

Solution :

• Si vous utilisez la ressource google_gke_hub_feature_membership, définissez manuellement config_sync.enabled sur true.
• Si vous utilisez le acm sous-module, il est recommandé 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 Cloud de Confiance console

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 Cloud de Confiance console. 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 Cloud de Confiance console sur vos clusters GDC (VMware) ou GDC (Bare Metal), assurez-vous d'être connecté à vos clusters avec GKE Identity Service ou la passerelle de connexion.

Corrigé : Config Sync empêche les mises à jour des ressources abandonnées

Avant la version 1.21.0, un objet RootSync ou RepoSync peut 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, cela peut entraîner le rejet par Config Sync des modifications apportées aux ressources abandonnées.

L'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. Le plug-in d'authentification oidc sera ajouté dans une version ultérieure.