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 gérer ces erreurs.

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, tandis que V est spécifique aux erreurs détectables dans l'état initial du dépôt et du cluster. Les codes des erreurs détectables dans l'état initial du dépôt et du cluster se présentent sous la forme KNV1XXX. Les codes des erreurs qui ne peuvent être détectées qu'au moment de l'exécution sont au format KNV2XXX.

Table des erreurs KNV

Code d'erreur Description Action recommandée

L'ID d'InternalError a été remplacé par KNV9998 pour Config Sync version 1.6.1.

Non disponible

Obsolète dans Config Sync 1.3.

Non disponible

Obsolète dans Config Sync 1.3.

Non disponible

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 en 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 contenir aucun 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 objets Espace de noms ne peuvent être déclarés que pour des 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 configmanagement.gke.io/managed=disabled.

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

Impossible d'analyser un objet déclaré dans le dépôt.

Validez votre format YAML. Par exemple, vous pouvez exécuter la commande kubectl --validate.

Si nomos vet renvoie cette erreur sur un type avec group: configsync.gke.io, tel qu'un RepoSync, téléchargez v1.6.0-rc.6 ou une version ultérieure à partir de la page des téléchargements pour 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 indiquée dans le message d'erreur vers un répertoire d'espace de noms.

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

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

Mettez à jour le champ d'espace de noms identifié dans le message d'erreur.

Pour en savoir plus, consultez la section 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 compatibles suivantes:

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

Mettez à jour tous les libellés identifiés dans le message d'erreur. Par exemple, si vous essayez 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.

 Non disponible

La configuration fait référence à un objet Cluster propre à l'objet Cluster propre à cet objet ou à un objet Espace de noms qui n'existe pas. Pour que vous puissiez utiliser un sélecteur dans une annotation pour une configuration, celui-ci doit exister.

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

Les configurations de ClusterSélecteur et de Espace de noms emploient la syntaxe correcte, mais une erreur de syntaxe a été détectée.

Veillez à spécifier la configuration à l'aide du schéma de données approprié:

Obsolète dans Config Sync 1.3.2. Non disponible

Lorsque vous utilisez la structure hiérarchique du dépôt, une configuration pour ConfigManagement Operator 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 l'opérateur ConfigManagement Operator. Pour en savoir plus, consultez la section Structure du dépôt hiérarchique.

Obsolète dans Config Sync 1.3. Non disponible

Lorsque vous utilisez la structure hiérarchique du dépôt, 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 répertoriées dans le message d'erreur. Pour en savoir plus, consultez la section 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.

Aucun élément CustomResourceDefinition n'est défini pour la ressource dans le cluster.

Créez un objet 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 élément CustomResourceDefinition.

Lorsque vous utilisez un dépôt hiérarchique, les configurations de ce genre 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 la section Structure du dépôt hiérarchique.

Le champ spec.version de la configuration de 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 compatible, mettez à jour le champ spec.version. Si vous devez effectuer une mise à niveau, suivez les instructions fournies dans les notes de version.

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

Renommez ou supprimez le répertoire dont le nom est incorrect.

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

Renommez ou supprimez toutes les configurations référencées dans le message d'erreur afin qu'elles aient toutes des noms uniques.

Le répertoire ne peut pas contenir plusieurs ressources d'espace de noms.

Supprimez les configurations en double afin qu'il ne reste plus qu'une 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 utiliser sourceFormat: hierarchy.

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

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

Il est interdit de déclarer l'espace de noms config-management-system ou les ressources qu'il contient.

À partir de la version 1.17.0 de Config Sync, les espaces de noms resource-group-system et config-management-monitoring ne peuvent pas non plus être déclarés dans une source fiable. Il est également déconseillé de déclarer des ressources dans les espaces de noms resource-group-system et config-management-monitoring.

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 arrêter de gérer l'espace de noms et toute ressource déclarée sous-jacente.
  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 réactiver la gestion des ressources.

Si vous étiez précédemment synchronisé avec un dépôt hiérarchique et que vous avez dû déclarer l'espace de noms du contrôleur avec toutes les ressources, envisagez de passer à un dépôt non structuré pour plus de flexibilité dans votre structure source.

Le format de l'élément metadata.name fourni n'est pas valide.

Modifiez metadata.name pour qu'il remplisse les conditions suivantes:

  • Ne pas dépasser 254 caractères
  • L'ID est composé de caractères alphanumériques en minuscules, ainsi que des traits d'union "-" ou ".".
  • Le nom doit 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 plutôt d'utiliser le champ spec.resourceID pour ne pas être limité par ces limites. Pour en savoir plus, consultez la section Gérer les ressources avec le champ resourceID.

Obsolète dans Config Sync 1.3. Non disponible

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 afin qu'elles se trouvent dans un répertoire légal. Pour en savoir plus sur les objets à l'échelle d'un espace de noms, consultez la section 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 afin qu'elles se trouvent dans un répertoire légal. Pour en savoir plus sur les objets à l'échelle d'un cluster, consultez la section Objets à l'échelle d'un cluster.

Obsolète dans Config Sync 1.3. Non disponible

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

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

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

Remplacez HierarchyMode par none ou inherit. Pour en savoir plus sur 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 contenant des configurations doit comporter au moins un sous-répertoire d'espace de noms.

Ajoutez un répertoire d'espace de noms dans 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 pour supprimer de manière groupée les champs status spécifiés dans vos fichiers manifestes.

Cet objet HierarchyConfig fait référence à une ressource ayant un champ d'application en cluster. Les objets à l'échelle d'un cluster ne sont pas autorisés dans HierarchyConfig.

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

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

Supprimez l'objet CRD ainsi que les ressources personnalisées.

Le nom de la CustomResourceDefinition n'est pas valide.

Remplacez le nom par celui de la recommandation dans le message d'erreur.

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

Remplacez le groupe ou le genre par la recommandation 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 de l'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 d'annotation non valide.

Suivez les instructions fournies dans le message d'erreur pour la résoudre.

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

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

  • ne doit pas dépasser 63 caractères ;
  • Le nom ne doit contenir que des lettres minuscules (a-z), des chiffres (0-9) et des traits d'union "-".
  • Il 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 l'annotation à la ressource déclarée.

Une ressource comporte une étiquette non autorisée.

Supprimez les libellés non autorisés répertoriés dans le message d'erreur.

Un dépôt d'espace de noms ne peut déclarer des ressources à l'échelle d'un espace de noms que dans l'espace de noms auquel il 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 du dépôt d'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'espace de noms appartiennent à cet espace de noms.

Par exemple, si une configuration dans le dépôt d'espaces de noms shipping déclare metadata.namespace: billing, une erreur est renvoyée.

En plus de vous assurer que les ressources à l'échelle d'un espace de noms sont déclarées correctement, assurez-vous que les espaces de noms sont déclarés dans le dépôt racine. Cette étape est nécessaire, car les espaces de noms sont à l'échelle d'un cluster.

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

 Supprimez toutes les ressources Kptfile sauf une.

Lors de la gestion d'objets dans plusieurs sources de référence, des conflits peuvent survenir lorsque le même objet (groupe, genre, nom et espace de noms correspondant) est déclaré dans plusieurs sources.

Par exemple, lorsque le même objet est géré par RootSync et un RepoSync, ce dernier l'emporte. Si RootSync s'applique en premier, RepoSync signale une erreur d'état KNV1060. Si RepoSync s'applique en premier, RootSync écrase l'objet de RepoSync et 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 fiable, 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. Elle ne peut donc pas détecter ce problème.

Un InvalidRepoSyncError signale qu'un objet RepoSync est mal configuré. Les objets RepoSync doivent être correctement configurés pour que Config Sync synchronise la configuration à partir des dépôts d'espaces de noms.

Suivez les instructions figurant dans le message d'erreur pour corriger les erreurs de configuration.

Le fichier Kptfile n'a pas de champ d'inventaire valide. Un fichier Kptfile doit comporter un champ d'inventaire non vide avec un identifiant et un espace de noms spécifiés.

Spécifiez les valeurs de .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 compatibles qu'avec 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 de votre dépôt.

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

Dans nomos version 1.16.1 et antérieures, l'erreur suivante s'affiche également : KNV1064: unable to find APIGROUP column. Cette erreur est causée par le changement du nom de la colonne APIGROUP en APIVERSION. Pour atténuer ce problème, remplacez manuellement APIVERSION dans api-resources.txt par APIGROUP.

Le format de l'élément CustomResourceDefinition est incorrect.

Vérifiez le champ spécifié par le message d'erreur et assurez-vous que le format de sa valeur est correct.

Un objet de configuration ne doit déclarer que l'annotation de sélecteur de cluster. Cette erreur se produit lorsque l'ancienne annotation (configmanagement.gke.io/cluster-selector) et l'annotation intégrée (configsync.gke.io/cluster-name-selector) existent.

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 server-side apply. 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 de rendu a rencontré un problème exploitable par l'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 l'affichage.

Si l'erreur est causée par des échecs de 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 s'affichent correctement, 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 ils ne peuvent pas les gérer eux-mêmes.

Supprimez l'objet RootSync ou RepoSync de la source fiable à partir de laquelle l'objet est synchronisé.

Un appel système au niveau du 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 résolvez les problèmes de configuration. Cela peut être dû à n'importe quelle configuration YAML dans le dépôt.

Si le nom de fichier ou le chemin d'accès 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 de vos noms de fichiers ou de chemins d'accès.

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

Vous rencontrez peut-être une erreur de découverte d'API. Pour en savoir plus, consultez la section Erreurs de détection d'API.

Échec d'un appel système générique au niveau du système d'exploitation.

Config Sync ne peut pas lire à partir de la source de référence.

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

Config Sync est en conflit avec un autre contrôleur sur une ressource. De tels combats consomment beaucoup de ressources et peuvent dégrader vos performances. Pour obtenir des conseils sur le diagnostic et la résolution des conflits de manettes, consultez l'article Résoudre les problèmes liés aux manettes.

Pour éviter toute suppression accidentelle, Config Sync ne vous permet pas de supprimer tous les espaces de noms ou les ressources à l'échelle d'un cluster en 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 risque d'être bloqué en cours d'arrêt. 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 que leur état soit stable. 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 des ressources gérées, procédez comme suit:

  1. Dans un premier commit, supprimez toutes les ressources (sauf un espace de noms ou à l'échelle d'un cluster) et 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 n'apparaît qu'au démarrage ou rarement, vous pouvez les ignorer.

Si ces erreurs ne sont pas temporaires (elles durent plusieurs minutes), cela peut indiquer un problème grave, et nomos status signale des combats entre les 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 courants de synchronisation, consultez Résoudre les problèmes de synchronisation.

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

Le message d'erreur indique les ressources spécifiques à l'origine de l'erreur. Examinez ces ressources.

Une ressource spécifique est requise pour continuer, mais la ressource est introuvable. Par exemple, ConfigManagement Operator a essayé de mettre à jour une ressource, mais celle-ci 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'une 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 rapprochement d'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 Config Sync est modifiée illégalement. Les configurations illégales du webhook sont ignorées.

Supprimez le webhook modifié illégalement.

Un problème interne s'est produit lors du processus de rendu. Par exemple, Config Sync ne peut 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 plus tard. Par exemple, cette erreur peut se produire si l'état de rendu ne correspond pas à la configuration source.

L'erreur devrait se résoudre automatiquement.

Un problème lié à l'outil de ligne de commande nomos lui-même a été détecté.

Veuillez remplir un rapport de bug avec la commande exacte que vous avez exécutée et le message que vous avez reçu.

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 contiennent le code d'erreur KNV, mais les erreurs signalées par d'autres composants ne comportent pas de code KNV. Par exemple, l'erreur d'autorisation refusée provient du contrôleur de parc, qui est une couche située 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 OpenTelemetry 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. Vous pouvez également voir un message d'erreur semblable à ceux listés.

Ce problème se produit généralement lorsque Workload Identity est activé dans un cluster.

Pour résoudre ce problème, suivez les instructions de la section Monitoring Config Sync pour accorder une autorisation d'é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 par défaut otel-collector-googlecloud, vérifiez et recompilez les différences.

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

Échec de la vérification du certificat du serveur

Ce message d'erreur peut s'afficher si le conteneur git-sync ne parvient pas à cloner le dépôt Git.

Ce message indique que le serveur Git est configuré avec des certificats provenant d'une autorité de certification personnalisée. Cependant, l'autorité de certification personnalisée n'est pas correctement configurée, ce qui empêche le conteneur git-sync de cloner le dépôt Git.

Pour résoudre ce problème, commencez par vérifier si le champ spec.git.caCertSecretRef.name a été spécifié dans votre objet RootSync ou RepoSync, puis vérifiez si l'objet Secret existe.

Si le champ a été configuré et que l'objet Secret existe, vérifiez ensuite que cet objet contient tous les certificats complets.
Selon le mode de provisionnement de l'autorité de certification personnalisée, les approches de vérification des certificats complets peuvent varier.

Voici un exemple de procédure à suivre pour répertorier les 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 à votre équipe d'administration réseau d'obtenir les certificats CA 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 GKE sur VMware, 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 la procédure décrite dans la section 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 à cet exemple lorsque vous essayez de configurer Config Sync, il est possible que vous ne disposiez pas du rôle Administrateur GKE Hub.

Pour vous assurer de disposer des autorisations requises, assurez-vous d'avoir attribué les rôles IAM requis.

Haut de page

Étapes suivantes