Informations de référence sur les erreurs

Cette page décrit les codes d'erreur de Config Sync et les actions recommandées pour les gérer.

Les messages d'erreur de Config Sync se composent d'un ID d'erreur au format KNV1234, où 1234 est un numéro unique, suivi d'une description du problème et d'une suggestion pour le résoudre. K est hérité des conventions Kubernetes, les règles avec le préfixe N sont spécifiques à nomos, V est spécifique aux erreurs détectables dans l'état initial du dépôt et du cluster. Les codes d'erreur détectables dans l'état initial du dépôt et du cluster sont de la forme KNV1XXX. Les codes d'erreur qui ne peuvent être détectés qu'au moment de l'exécution sont de la forme KNV2XXX.

Tableau des erreurs KNV

Code d'erreur Description Action recommandée

L'ID de l'erreur InternalError a été remplacé par KNV9998 avec Config Sync 1.6.1.

N/A

Obsolète dans Config Sync 1.3.

N/A

Obsolète dans Config Sync 1.3.

N/A

Lorsque vous utilisez une structure de dépôt hiérarchique, un répertoire contenant une configuration d'espace de noms ne doit contenir aucun sous-répertoire.

Un répertoire sans configuration d'espace de noms est un répertoire d'espace de noms abstrait dont les répertoires héritent. Par conséquent, les répertoires d'espaces de noms abstraits doivent comporter des sous-répertoires. Un répertoire contenant une configuration d'espace de noms est un répertoire d'espace de noms qui ne peut pas être hérité. Il ne doit donc pas comporter de sous-répertoire.

Supprimez la configuration d'espace de noms du répertoire parent ou déplacez le sous-répertoire.

Un objet à l'échelle d'un cluster ne doit pas déclarer l'annotation configmanagement.gke.io/namespace-selector. Les NamespaceSelectors ne peuvent être déclarés que pour les objets à l'échelle d'un espace de noms.

Supprimez configmanagement.gke.io/namespace-selector du champ metadata.annotations.

Le seul paramètre valide pour l'annotation de gestion est configmanagement.gke.io/managed=disabled. Ce paramètre permet d'arrêter explicitement la gestion d'une ressource dans le dépôt Git tout en laissant la configuration enregistrée. L'annotation configmanagement.gke.io/managed=enabled n'est pas nécessaire.

Assurez-vous que l'annotation de gestion est définie sur configmanagement.gke.io/managed=disabled.

Pour en savoir plus, consultez Gérer des objets.

Un objet déclaré dans le dépôt n'a pas pu être analysé.

Validez votre format YAML. Par exemple, vous pouvez utiliser la commande kubectl --validate.

Si nomos vet renvoie cette erreur sur un type comportant group: configsync.gke.io, par exemple RepoSync, téléchargez v1.6.0-rc.6 ou une version ultérieure depuis la page des téléchargements afin de résoudre le problème.

Lorsque vous utilisez un dépôt non structuré, les configurations ne doivent pas être déclarées dans un répertoire d'espace de noms abstrait.

Déplacez la configuration listée dans le message d'erreur vers un répertoire d'espace de noms.

Pour en savoir plus, consultez Utiliser un dépôt non structuré.

Lorsque vous utilisez une structure de dépôt hiérarchique, les configurations doivent déclarer des espaces de noms correspondant au répertoire d'espace de noms qui les contient ou bien omettre le champ.

Modifiez le champ de l'espace de noms identifié dans le message d'erreur.

Pour en savoir plus, consultez Structure du dépôt hiérarchique.

Les configurations ne doivent pas déclarer d'annotations non compatibles commençant par configmanagement.gke.io.

Assurez-vous d'utiliser l'une des annotations acceptées suivantes :

Les configurations ne doivent pas comporter de libellés ayant des clés commençant par configmanagement.gke.io/. Ce préfixe de clé de libellé est réservé à Config Sync.

Modifiez les libellés identifiés dans le message d'erreur. Par exemple, si vous avez essayé de déclarer un libellé nommé
configmanagement.gke.io/example-label: label-value,
vous pouvez le remplacer par
example-label: label-value.

Obsolète dans Config Sync 1.3.

 N/A

La configuration fait référence à un ClusterSelector ou à un NamespaceSelector qui n'existe pas. Pour pouvoir utiliser un sélecteur dans une annotation pour une configuration, il doit exister.

Créez les sélecteurs manquants ou, si le sélecteur a été supprimé, supprimez les configurations qui y font référence.

Les configurations de ClusterSelector et de NamespaceSelector utilisent la syntaxe correcte, mais une erreur de syntaxe a été détectée.

Veillez à spécifier la configuration en utilisant le schéma de données approprié :

Obsolète dans Config Sync 1.3.2. N/A

Lorsque vous utilisez la structure de dépôt hiérarchique, une configuration pour l'opérateur ConfigManagement doit exister dans le répertoire system/ du dépôt. Cette configuration doit inclure les informations requises, telles que la version sémantique du dépôt.

Définissez au moins une configuration minimale pour Config Management Operator. Pour en savoir plus, consultez Structure du dépôt hiérarchique.

Obsolète dans Config Sync 1.3. N/A

Lorsque vous utilisez la structure de dépôt hiérarchique, les espaces de noms ne doivent pas être déclarés directement dans le répertoire namespaces/.

Créez un sous-répertoire pour les configurations d'espace de noms listées dans le message d'erreur. Pour en savoir plus, consultez Structure du dépôt hiérarchique.

Lorsque vous utilisez une structure de dépôt hiérarchique, une configuration d'espace de noms déclare metadata.name, et sa valeur doit correspondre au nom du répertoire de l'espace de noms. Corrigez le metadata.name ou le répertoire de l'espace de noms.

Aucune CustomResourceDefinition n'est définie pour la ressource dans le cluster.

Créez une CustomResourceDefinition pour la ressource référencée dans le message d'erreur. Les types de ressources qui ne sont pas des objets Kubernetes intégrés doivent disposer d'un objet CustomResourceDefinition.

Lorsque vous utilisez un dépôt hiérarchique, les configurations de ce type ne peuvent pas être déclarées dans le répertoire system/.

Déplacez la ressource référencée dans le message d'erreur hors du répertoire system/. Pour en savoir plus, consultez Structure du dépôt hiérarchique.

Le champ spec.version de la configuration de l'objet Repo représente la version sémantique du dépôt. Cette erreur indique que vous utilisez une version non acceptée.

Si le format de votre dépôt est compatible avec la version acceptée, mettez à jour le champ spec.version. Si vous devez procéder à une mise à jour, suivez les instructions fournies dans les notes de version.

Les noms de répertoire doivent comporter moins de 64 caractères, être composés de caractères alphanumériques minuscules ou de "-", et commencer et se terminer par un caractère alphanumérique.

Renommez ou supprimez le répertoire mal nommé.

Les configurations du même type doivent avoir des noms uniques dans le même espace de noms et dans leurs espaces de noms abstraits parents.

Renommez ou supprimez les configurations mentionnées dans le message d'erreur afin qu'elles aient toutes un nom unique.

Il ne peut pas y avoir plusieurs ressources d'espace de noms dans le même répertoire.

Supprimez les configurations en double afin qu'il ne reste qu'une seule ressource d'espace de noms.

Toutes les configurations doivent déclarer metadata.name.

Ajoutez le champ metadata.name aux configurations problématiques.

Le type Repo.configmanagement.gke.io n'est pas autorisé si sourceFormat est défini sur unstructured.

Supprimez la configuration problématique ou convertissez votre dépôt pour qu'il utilise sourceFormat: hierarchy.

Si vous utilisez un dépôt hiérarchique, vous ne pouvez déclarer les types HierarchyConfig et Repo que dans le répertoire system/.

Assurez-vous que toutes les configurations déclarées dans le répertoire system/ font partie des types autorisés. Si ce n'est pas le cas, déplacez-le vers un autre répertoire.

Il est interdit de déclarer config-management-system, resource-group-system et config-management-monitoring, ou les ressources qu'ils contiennent.

Si vous avez déclaré l'espace de noms config-management-system, supprimez-le ainsi que toutes les configurations qu'il contient.

Si vous avez déclaré les espaces de noms resource-group-system ou config-management-monitoring, annulez la gestion de l'espace de noms du contrôleur :

  1. Mettez à jour Config Sync pour cesser de gérer l'espace de noms et toute ressource déclarée en dessous.
  2. Attendez la synchronisation, puis vérifiez que les ressources correspondantes sont toujours disponibles sur le cluster, mais pas dans nomos status.
  3. Supprimez le fichier YAML de l'espace de noms du contrôleur de la source.
  4. Laissez Config Sync reprendre la gestion des ressources.

Si vous synchronisiez auparavant un dépôt hiérarchique et que vous deviez déclarer l'espace de noms du contrôleur en même temps que les ressources, envisagez de passer à un dépôt non structuré pour plus de flexibilité dans la structure de votre source.

Le format du metadata.name fourni n'est pas valide.

Modifiez le metadata.name de sorte qu'il respecte les conditions suivantes :

  • comporter moins de 254 caractères ;
  • contenir des caractères alphanumériques minuscules, "-" ou "." ;
  • commencer et se terminer par un caractère alphanumérique ;

Si metadata.name n'est pas valide et que la ressource d'origine le permet, envisagez d'utiliser le champ spec.resourceID à la place afin de ne pas être limité par ces limites. Pour en savoir plus, consultez Gérer les ressources avec le champ resourceID.

Obsolète dans Config Sync 1.3. N/A

Il est interdit de déclarer un objet à l'échelle d'un espace de noms en dehors du répertoire namespaces/.

Déplacez les configurations problématiques de sorte qu'elles se trouvent dans un répertoire autorisé. Pour en savoir plus sur les objets à l'échelle d'un espace de noms, consultez Objets à l'échelle d'un espace de noms.

Il est interdit de déclarer un objet à l'échelle d'un cluster en dehors du répertoire cluster/.

Déplacez les configurations problématiques de sorte qu'elles se trouvent dans un répertoire autorisé. Pour en savoir plus sur les objets à l'échelle d'un cluster, consultez Objets à l'échelle d'un cluster.

Obsolète dans Config Sync 1.3. N/A

Ce type de ressource ne doit pas être déclaré dans un HierarchyConfig.

Supprimez la ressource problématique. Pour en savoir plus sur HierarchyConfig, consultez Désactiver l'héritage pour un type d'objet.

Une valeur non autorisée pour HierarchyMode a été détectée sur un HierarchyConfig.

Remplacez HierarchyMode par none ou inherit. Pour en savoir plus sur les HierarchyConfigs, consultez la section Désactiver l'héritage pour un type d'objet.

Config Sync ne peut pas configurer cet objet.

 Supprimez la configuration problématique du dépôt.

Un répertoire d'espace de noms abstrait avec des configurations doit comporter au moins un sous-répertoire d'espace de noms.

Ajoutez un répertoire d'espace de noms sous votre répertoire d'espace de noms abstrait, ajoutez une configuration d'espace de noms à votre répertoire d'espace de noms abstrait ou supprimez les configurations de votre répertoire d'espace de noms abstrait.

Les configurations avec metadata.ownerReference spécifié ne sont pas autorisées.

Supprimez le champ status du dépôt source. Pour les configurations tierces qui ne vous appartiennent pas, utilisez kustomize patches afin de supprimer de façon groupée les champs status spécifiés dans vos fichiers manifestes.

Ce HierarchyConfig fait référence à une ressource dont la portée est limitée au cluster. Les objets à portée de cluster ne sont pas autorisés dans HierarchyConfig.

Mettez à jour le HierarchyConfig afin qu'il ne fasse plus référence à la ressource problématique.

Il n'est pas autorisé de supprimer une définition de ressource personnalisée (CRD) et de laisser les ressources personnalisées correspondantes dans le dépôt.

Supprimez le CRD ainsi que les ressources personnalisées.

Le nom de CustomResourceDefinition n'est pas valide.

Modifiez le nom en suivant la recommandation figurant dans le message d'erreur.

La configuration utilise un groupe et un type obsolètes.

Modifiez le groupe ou le type en fonction de la recommandation figurant dans le message d'erreur.

Les ressources à l'échelle du cluster ne doivent pas déclarer metadata.namespace.

 Supprimez le champ metadata.namespace de votre ressource à l'échelle du cluster.

Les ressources à l'échelle d'un espace de noms doivent déclarer metadata.namespace ou metadata.annotations.configmanagement.gke.io/namespace-selector.

Ajoutez le champ manquant à votre ressource à l'échelle d'un espace de noms.

Les configurations contiennent une valeur non valide pour une annotation.

Suivez les instructions du message d'erreur pour résoudre le problème.

La valeur de metadata.namespace n'est pas un nom d'espace de noms Kubernetes valide.

Mettez à jour la valeur de metadata.namespace pour qu'elle respecte les règles suivantes :

  • comporte 63 caractères ou moins ;
  • Ne contenir que des lettres minuscules (a-z), des chiffres (0-9) et des traits d'union (-)
  • Commence et se termine par une lettre minuscule ou un chiffre

Une ressource est déclarée dans un espace de noms non géré.

Supprimez l'annotation configmanagement.gke.io/managed: disabled ou ajoutez-la à la ressource déclarée.

Une ressource possède un libellé non autorisé.

Supprimez les libellés illégaux listés dans le message d'erreur.

Un dépôt d'espaces de noms ne peut déclarer que des ressources à l'échelle d'un espace de noms dans l'espace de noms auquel le dépôt s'applique.

Assurez-vous que tous les dépôts d'espaces de noms déclarent correctement les ressources à l'échelle d'un espace de noms. Par exemple, le dépôt de l'espace de noms shipping ne peut gérer que les ressources de l'espace de noms shipping. La valeur de metadata.namespace est facultative. Par défaut, Config Sync suppose que toutes les ressources d'un dépôt d'espaces de noms appartiennent à cet espace de noms.

Par exemple, si une configuration du dépôt d'espaces de noms shipping a déclaré metadata.namespace: billing, une erreur se produit.

En plus de vous assurer que les ressources à l'échelle d'un espace de noms sont correctement déclarées, vérifiez que les espaces de noms sont déclarés dans le dépôt racine. Cela est nécessaire, car les espaces de noms sont limités au champ d'application du cluster.

Un dépôt d'espaces de noms peut déclarer au plus une ressource Kptfile.

 Supprimez toutes les ressources Kptfile, sauf une.

Lorsque vous gérez des objets dans plusieurs sources de vérité, des conflits peuvent survenir lorsque le même objet (groupe, type, nom et espace de noms correspondants) est déclaré dans plusieurs sources.

Par exemple, lorsqu'un même objet est géré par un RootSync et un RepoSync, le RootSync est prioritaire. Si RootSync s'applique en premier, RepoSync signale une erreur d'état KNV1060. Si le RepoSync s'applique en premier, le RootSync écrase l'objet du RepoSync, et le RepoSync signale une erreur d'état KNV1060 lorsqu'il voit la mise à jour.

Résolvez le conflit en mettant à jour la configuration pour qu'elle corresponde à l'autre source de vérité, ou en supprimant l'objet en conflit de l'une des sources.

La commande nomos vet recherche les erreurs dans un seul dépôt à la fois et ne peut donc pas détecter ce problème.

Un InvalidRepoSyncError indique qu'un objet RepoSync n'est pas configuré correctement. Les objets RepoSync doivent être correctement configurés pour que Config Sync puisse synchroniser la configuration à partir de dépôts d'espaces de noms.

Suivez les instructions du message d'erreur pour corriger les erreurs de configuration.

Le fichier Kptfile ne possède pas de champ d'inventaire valide. Un fichier Kptfile doit comporter un champ d'inventaire non vide contenant l'identifiant et l'espace de noms spécifiés.

Spécifiez les valeurs pour .inventory.identifier et .inventory.namespace dans le fichier Kptfile.

Des fichiers Kptfiles ont été trouvés dans le dépôt racine. Les fichiers Kptfiles ne sont autorisés que dans les dépôts à l'échelle d'un espace de noms.

Supprimez les fichiers Kptfiles du dépôt racine.

Impossible d'analyser le fichier api-resources.txt dans votre dépôt.

Suivez les instructions du message d'erreur. Par exemple, vous devrez peut-être réexécuter kubectl api-resources > api-resources.txt.

Le paramètre CustomResourceDefinition n'est pas valide.

Vérifiez le champ spécifié par le message d'erreur et assurez-vous que sa valeur est correctement mise en forme.

Un objet de configuration ne doit déclarer qu'une annotation cluster-selector. Cette erreur se produit lorsqu'il existe à la fois une ancienne annotation (configmanagement.gke.io/cluster-selector) et une annotation intégrée (configsync.gke.io/cluster-name-selector).

Supprimez l'une des annotations du champ metadata.annotations.

Le rapprochement ne parvient pas à encoder les champs déclarés dans un format compatible avec l'application côté serveur. Cela peut être dû à un schéma obsolète.

Vérifiez le champ spécifié par le message d'erreur et assurez-vous qu'il correspond au schéma du genre de ressource.

Le processus d'affichage a rencontré un problème pouvant être résolu côté utilisateur.

Si le dépôt Git contient des configurations Kustomize, mais qu'aucun fichier kustomization.yaml n'existe dans le répertoire de synchronisation Git, ajoutez kustomization.yaml dans le répertoire de synchronisation pour déclencher le processus de rendu, ou supprimez kustomization.yaml de tous les sous-répertoires pour ignorer le rendu.

Si l'erreur est provoquée par des échecs kustomize build, vous devrez peut-être mettre à jour les configurations Kustomize dans votre dépôt Git. Vous pouvez prévisualiser et valider les configurations mises à jour localement à l'aide de nomos hydrate et nomos vet respectivement. Si les configurations mises à jour sont bien affichées, vous pouvez envoyer un nouveau commit pour corriger l'erreur KNV1068.

Si une erreur kustomize build se produit lors de l'extraction de bases distantes à partir de dépôts publics, vous devez définir spec.override.enableShellInRendering sur true.

Un rapprochement a rapproché son propre objet RootSync ou RepoSync. Un objet RootSync peut gérer d'autres objets RootSync et RepoSync. Un objet RepoSync peut gérer d'autres objets RepoSync, mais il ne peut pas s'autogérer.

Supprimez l'objet RootSync ou RepoSync de la source de vérité à partir de laquelle il se synchronise.

Un appel de système d'exploitation accédant à une ressource de système de fichiers échoue.

Cette erreur est probablement due à une configuration YAML non valide ou à l'utilisation de caractères spéciaux. Si votre configuration YAML n'est pas valide, un message d'erreur semblable à celui-ci s'affiche : KNV2001: yaml: line 2: did not find expected node content path:.... Pour résoudre ce problème, vérifiez vos fichiers YAML et corrigez les éventuels problèmes de configuration. Cela peut être dû à n'importe quelle configuration YAML dans le dépôt.

Si le nom ou le chemin d'accès de votre fichier contient des caractères spéciaux, un message d'erreur semblable à KNV2001: yaml: control characters are not allowed path:/repo/source/.../._pod.yaml peut s'afficher. Dans cet exemple, ._pod.yaml n'est pas un nom de fichier valide. Pour résoudre ce problème, supprimez les caractères spéciaux des noms de vos fichiers ou chemins d'accès.

Une requête accédant au serveur d'API Kubernetes échoue.

Les requêtes d'API Kubernetes peuvent échouer pour de nombreuses raisons. Les causes les plus courantes sont les suivantes :

  • Erreur de découverte de l'API
  • Délai d'expiration des requêtes ou des réponses côté client ou serveur
  • Erreur d'identité, d'authentification ou d'autorisation
  • Erreur de connectivité réseau
  • Le webhook a refusé la demande
  • Webhook non opérationnel ou inaccessible par le serveur d'API

Config Sync effectue des nouvelles tentatives après la plupart des erreurs du serveur d'API. Certains problèmes peuvent être temporaires et se résoudre d'eux-mêmes, mais la plupart nécessitent l'intervention de l'utilisateur. Les erreurs du serveur d'API sont rarement causées par Config Sync lui-même. Toutefois, si vous pensez que c'est le cas, veuillez signaler un bug.

Un appel de système d'exploitation générique échoue.

Config Sync ne peut pas lire les données de la source de vérité.

Plusieurs problèmes peuvent être à l'origine de cette erreur. Pour résoudre les problèmes de connexion à la source de vérité, consultez Résoudre les problèmes de connexion à la source de vérité. Pour en savoir plus sur les problèmes connus qui entraînent des erreurs KNV2004, consultez Problèmes connus.

Config Sync est en conflit avec un autre contrôleur sur une ressource. Ces conflits consomment beaucoup de ressources et peuvent nuire à vos performances. Pour obtenir des conseils sur le diagnostic et la résolution des conflits de contrôleurs, consultez Résoudre les conflits de contrôleurs.

Afin d'éviter toute suppression accidentelle, Config Sync ne vous permet pas de supprimer tous les espaces de noms ni les ressources à l'échelle d'un cluster dans un seul commit.

Si le webhook d'admission Config Sync est désactivé, annulez le commit qui supprime toutes les ressources.
Si le webhook d'admission Config Sync est activé, votre espace de noms peut être bloqué. Pour résoudre ce problème, procédez comme suit :

  1. Désactivez Config Sync et attendez que toutes les ressources soient nettoyées ou stables. Par exemple, vous pouvez exécuter kubectl get ns pour vous assurer que les espaces de noms sont supprimés.
  2. Réactivez Config Sync.
  3. Annulez le commit qui supprime toutes les ressources.

Si vous souhaitez supprimer l'ensemble complet des ressources sous gestion, procédez comme suit :

  1. Supprimez dans un premier commit toutes les entités sauf un espace de noms ou une ressource à l'échelle d'un cluster, puis autorisez Config Sync à synchroniser ces modifications.
  2. Supprimez la ressource finale dans un second commit.

Une ressource sur le serveur d'API est modifiée ou supprimée alors que Config Sync tente également de la modifier.

Si ce type d'erreur ne s'affiche qu'au démarrage ou rarement, vous pouvez ignorer ces erreurs.

Si ces erreurs ne sont pas temporaires (persistantes plusieurs minutes), cela peut indiquer un problème grave, et nomos status signale un conflit de contrôleurs.

Il s'agit d'une erreur générique indiquant que Config Sync n'a pas réussi à synchroniser certaines configurations avec le cluster.

Plusieurs problèmes peuvent être à l'origine de cette erreur. Pour obtenir des conseils sur la résolution des problèmes de synchronisation courants, consultez Résoudre les problèmes de synchronisation.

Il s'agit d'une erreur générique signalant un problème lié à une ressource ou un ensemble de ressources.

Le message d'erreur indique les ressources spécifiques qui ont généré l'erreur. Examinez ces ressources.

Une ressource spécifique est requise pour poursuivre une opération, mais elle est introuvable. Elle peut par exemple se produire si ConfigManagement Operator tente de mettre à jour une ressource qui a été supprimée lors du calcul de la mise à jour.

Créez ou restaurez la ressource manquante.

Cette erreur indique que plusieurs instances d'un objet APIResource ont été détectées alors qu'une seule de ces instances est autorisée. Par exemple, une seule ressource Repo doit exister sur un cluster.

Supprimez l'APIResource supplémentaire.

Un processus de rapprochement des espaces de noms ne dispose pas des autorisations nécessaires pour gérer les ressources.

Assurez-vous que le rapprochement dispose des autorisations suffisantes.

Cet avertissement s'affiche lorsque la configuration du webhook de Config Sync est modifiée illégalement. Les configurations illégales du webhook sont ignorées.

Supprimez le webhook modifié illégalement.

Le processus de rendu a rencontré un problème interne. Par exemple, Config Sync ne parvient pas à accéder au système de fichiers.

Cette erreur peut indiquer que le pod n'est pas opérationnel. Vous pouvez redémarrer les pods de rapprochement en exécutant les commandes suivantes :

# restart a root reconciler
kubectl delete pod -n config-management-system -l configsync.gke.io/reconciler=root-reconciler

# restart a namespace reconciler
kubectl delete pod -n config-management-system -l configsync.gke.io/reconciler=ns-reconciler-NAMESPACE

Cette erreur représente un problème temporaire qui devrait se résoudre automatiquement ultérieurement. Par exemple, si l'état de rendu ne correspond pas à la configuration source, cette erreur peut s'afficher.

L'erreur devrait se résoudre automatiquement.

Un problème lié à Config Sync lui-même est survenu.

Veuillez remplir un rapport de bug.

Vous avez rencontré une erreur pour laquelle aucun message d'erreur n'est documenté.

Nous n'avons pas encore rédigé de documentation propre à cette erreur.

Haut de page

Messages d'erreur sans code KNV

Les erreurs signalées par les réconciliateurs Config Sync comportent le code d'erreur KNV, mais les erreurs signalées par d'autres composants n'en comportent pas. Par exemple, l'erreur d'autorisation refusée provient du contrôleur de parc, qui est une couche au-dessus de Config Sync.

Le tableau suivant répertorie certaines erreurs courantes sans le préfixe KNV.

Message d'erreur Action recommandée

Error: cannot build exporters: error creating stackdriver exporter: cannot configure Google Cloud metric exporter: stackdriver: google: could not find default credentials.

Error: Permission monitoring.timeSeries.create denied (or the resource may not exist).

Impossible de créer des exportateurs

Lorsqu'un composant du collecteur Open Telemetry ne peut pas accéder au compte de service par défaut sous le même espace de noms, vous remarquerez peut-être que le pod otel-collector sous config-management-monitoring est à l'état CrashLoopBackoff, ou un message d'erreur semblable à ceux listés peut s'afficher.

Ce problème se produit généralement lorsque la fédération d'identité de charge de travail pour GKE est activée dans un cluster.

Pour résoudre ce problème, suivez les instructions de la section Surveiller Config Sync pour accorder l'autorisation en écriture de métriques au compte de service par défaut.

Si l'erreur persiste après la configuration d'IAM, redémarrez le pod otel-collector pour que les modifications soient prises en compte.
Si vous utilisez une solution de surveillance personnalisée, mais que vous avez dupliqué le ConfigMap otel-collector-googlecloud par défaut, vérifiez et rebasez toute différence.

server certificate verification failed. CAfile:/etc/ca-cert/cert CRLfile: none

Échec de la validation du certificat du serveur

Si le conteneur git-sync, helm-sync ou oci-sync ne parvient pas à extraire les artefacts, ce message d'erreur peut s'afficher.

Ce message indique que le serveur est configuré avec des certificats provenant d'une autorité de certification (CA) personnalisée. Toutefois, l'autorité de certification personnalisée n'est pas correctement configurée, ce qui empêche le conteneur d'extraire des données du serveur.

Pour résoudre ce problème, vous pouvez d'abord vérifier si le champ caCertSecretRef a été correctement configuré dans votre objet RootSync ou RepoSync, et également vérifier si l'objet Secret existe.

Ensuite, si le champ a été configuré et que l'objet Secret existe, assurez-vous qu'il contient les certificats complets.
Selon la façon dont la CA personnalisée est provisionnée, les approches pour vérifier les certificats complets peuvent varier.

Voici un exemple de liste des certificats de serveur : 

echo -n | openssl s_client -showcerts -connect HOST:PORT -servername SERVER_NAME 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Vous pouvez demander à l'équipe d'administration de votre réseau d'obtenir les certificats d'autorité de certification pour vous.

Error message: "MESSAGE": "Unable to retrieve pull secret, the image pull may not succeed."

Impossible de récupérer le secret d'extraction. L'extraction de l'image risque d'échouer.

Si vous utilisez un registre privé avec Google Distributed Cloud, l'installation ou la mise à niveau de Config Sync peut se bloquer. Un message d'erreur semblable à celui-ci s'affiche.

Pour résoudre ce problème, suivez les étapes décrites dans Mettre à jour Config Sync à l'aide d'un registre privé avant d'installer ou de mettre à niveau Config Sync.

Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'

Autorisation refusée

Si vous recevez une erreur semblable à l'exemple suivant lorsque vous essayez de configurer Config Sync, vous ne disposez peut-être pas du rôle Administrateur GKE Hub.

Pour vous assurer que vous disposez des autorisations nécessaires, assurez-vous d'avoir attribué les rôles IAM requis.

Haut de page

Étapes suivantes