Informations de référence sur les 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. Cet article documente chacun de ces messages d'erreur.

KNV1000 : InternalError

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

KNV1001 : ReservedDirectoryNameError

Obsolète dans Config Sync 1.3.

KNV1002 : DuplicateDirectoryNameError

Obsolète dans Config Sync 1.3.

KNV1003 : IllegalNamespaceSubdirectoryError

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. Il peut donc 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.

Pour corriger cette erreur, supprimez la configuration d'espace de noms du répertoire parent ou déplacez le sous-répertoire.

Ce cas peut se présenter si un répertoire contenant un espace de noms contient un sous-répertoire.

namespaces/
└── prod/
    ├── namespace.yaml
    └── us_west_1/

# namespaces/prod/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: prod

Cette structure de répertoire et le contenu du fichier namespace.yaml génèrent l'erreur suivante :

KNV1003: A Namespace directory MUST NOT have subdirectories. Remove the
         Namespace policy from "prod", or move "us_west_1" to an Abstract
         Namespace:

path: namespaces/prod/us_west_1
name: us_west_1

KNV1004 : IllegalSelectorAnnotationError

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.

Pour corriger l'erreur, supprimez configmanagement.gke.io/namespace-selector du champ metadata.annotations.

La configuration de ClusterRole suivante génère l'erreur suivante :

# cluster/namespace-reader-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-reader
  annotations: {
    "configmanagement.gke.io/namespace-selector" : "shipping-dev",
  }
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch"]

Si vous essayez d'inclure cet objet ClusterRole dans votre cluster, nomos vet renvoie l'erreur suivante :

KNV1004: Cluster-scoped objects may not be namespace-selected, and so MUST NOT declare the annotation 'configmanagement.gke.io/namespace-selector'. To fix, remove `metadata.annotations.configmanagement.gke.io/namespace-selector` from:
source: cluster/namespace-reader-clusterrole.yaml
metadata.name: namespace-reader
group: rbac.authorization.k8s.io
version: v1
kind: ClusterRole

Un objet Cluster ne doit pas déclarer l'annotation configmanagement.gke.io/cluster-selector. Pour corriger l'erreur, supprimez configmanagement.gke.io/cluster-selector de metadata.annotations.

Si un objet Cluster déclare configmanagement.gke.io/cluster-selector, nomos vet renvoie l'erreur suivante :

KNV1004: Clusters may not be cluster-selected, and so MUST NOT declare the annotation 'configmanagement.gke.io/cluster-selector'. To fix, remove `metadata.annotations.configmanagement.gke.io/cluster-selector` from:

source: clusterregistry/cluster.yaml
metadata.name: default-name
group: clusterregistry.k8s.io
version: v1alpha1
kind: Cluster

KNV1005 : IllegalManagementAnnotationError

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. Pour en savoir plus, consultez la page Gérer des objets.

Si vous définissez une annotation différente, une erreur semblable à celle-ci s'affichera :

KNV1005: Config has invalid management annotation configmanagement.gke.io/managed=invalid. If set, the value must be "disabled".

source: namespaces/foo/role.yaml
metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1006 : ObjectParseError

Cette erreur se produit lorsqu'un objet déclaré dans le dépôt n'a pas pu être analysé. Pour résoudre cette erreur, validez votre format yaml à l'aide d'un outil tel que kubectl --validate.

Exemple :

KNV1006: The following config could not be parsed as a rbac.authorization.k8s.io/v1, Kind=Role:

source: namespaces/foo/role.yaml
metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1007 : IllegalAbstractNamespaceObjectKindError

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. Pour en savoir plus sur l'utilisation de dépôts non structurés, consultez la page Utiliser un dépôt non structuré.

KNV1007: Config "default-name" illegally declared in an abstract namespace directory. Move this config to a namespace directory:

source: namespaces/foo/bar/role.yaml
metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1009 : IllegalMetadataNamespaceDeclarationError

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

Voici un exemple de configuration de Role qui déclenche l'erreur :

# namespaces/shipping-prod/pod-reader-role.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader
  namespace: shipping-dev
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Si vous déclarez une configuration avec ce type d'espace de noms, l'erreur suivante se produit :

KNV1009: A config MUST either declare a `namespace` field exactly matching the directory containing the config, "shipping-prod", or leave the field blank:

source: namespaces/shipping-prod/pod-reader-role.yaml
namespace: shipping-dev
metadata.name: pod-reader
group: rbac.authorization.k8s.io
version: v1
kind: Role

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

KNV1010 : IllegalAnnotationDefinitionError

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

Les annotations compatibles sont les suivantes :

  • configmanagement.gke.io/managed : pour plus d'informations sur l'utilisation, consultez la section Gérer des objets.

  • configmanagement.gke.io/namespace-selector : pour en savoir plus sur l'utilisation, consultez la section Objets à l'échelle d'un espace de noms.

  • configmanagement.gke.io/cluster-selector : pour plus d'informations sur l'utilisation, consultez la section ClusterSelector.

Exemple d'erreur :

KNV1010: Configs MUST NOT declare unsupported annotations starting with
         "configmanagement.gke.io/". The config has invalid annotations:
         "configmanagement.gke.io/invalid", "configmanagement.gke.io/sync-token"

source: namespaces/foo/role.yaml
metadata.name: role
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1011 : IllegalLabelDefinition

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.

Voici un exemple de ConfigMap qui déclenche cette erreur :

# namespaces/prod/mymap.yaml
kind: ConfigMap
apiVersion: v1
metadata:
  name: my-map
  labels:
    configmanagement.gke.io/bad-label: label-value
data:
  mydata: moredata

Si vous déclarez une configuration avec ce type de libellé, l'erreur suivante se produit :

KNV1011: Configs MUST NOT declare labels starting with "configmanagement.gke.io/". The config has disallowed labels: "configmanagement.gke.io/bad-label"

source: namespaces/prod/mymap.yaml
metadata.name: my-map
group:
version: v1
kind: ConfigMap

KNV1012 : NamespaceSelectorMayNotHaveAnnotation

Obsolète dans Config Sync 1.3.

KNV1013 : ObjectHasUnknownSelector

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.

Si le sélecteur est supprimé, supprimez également toutes les configurations qui y font référence. Dans l'exemple ci-dessous, supposons qu'il n'existe pas de ClusterSelector unknown-cluster-selector dans le répertoire clusterregistry/ du dépôt.

# namespaces/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: foo
  annotations:
    configmanagement.gke.io/cluster-selector: unknown-cluster-selector

Cet exemple génère l'erreur suivante :

KNV1013: Config "foo" MUST refer to an existing ClusterSelector, but has
         annotation
         "configmanagement.gke.io/cluster-selector=unknown-cluster-selector",
         which maps to no declared ClusterSelector

Les annotations de NamespaceSelector comportent une condition supplémentaire : le NamespaceSelector référencé doit être défini dans le même répertoire ou dans un répertoire parent de la référence de configuration. Dans le cas contraire, l'erreur suivante se produira :

KNV1013: Config "default-name" MUST refer to a NamespaceSelector in its directory or a parent directory. Either remove the annotation "configmanagement.gke.io/namespace-selector=default-ns-selector" from "default-name" or move NamespaceSelector "default-ns-selector" to a parent directory of "default-name".

    source: namespaces/bar/selector.yaml
    metadata.name: default-ns-selector
    group: configmanagement.gke.io
    version: v1
    kind: NamespaceSelector

    source: namespaces/foo/role.yaml
    metadata.name: default-name
    group: rbac.authorization.k8s.io
    version: v1
    kind: Role

KNV1014 : InvalidSelectorError

Les configurations de ClusterSelector et de NamespaceSelector utilisent la syntaxe correcte, mais une erreur de syntaxe a été détectée. Pour résoudre ce problème, veillez à spécifier la configuration en fonction du schéma de données approprié :

Par exemple, ce ClusterSelector non valide :

kind: ClusterSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: selector-1
spec:
  selector:
    someUnknownField:  # This field is not defined for a LabelSelector
      foo: bar

Entraîne l'erreur suivante :

KNV1014: ClusterSelector has validation errors that must be corrected: invalid field "someUnknownField"
    source: clusterregistry/cs.yaml
    metadata.name: selector-1
    group: configmanagement.gke.io
    version: v1
    kind: ClusterSelector

En particulier, les définitions de ClusterSelector et NamespaceSelector définissent le champ spec.selector. Dans le cas contraire, l'erreur suivante se produira :

   KNV1014: NamespaceSelectors MUST define `spec.selector`

    source: namespaces/ns.yaml
    metadata.name: ns-selector-1
    group: configmanagement.gke.io
    version: v1
    kind: NamespaceSelector

KNV1016 : PolicyManagementNotInstalledError

Obsolète dans Config Sync 1.3.2.

KNV1017 : MissingRepoError

Lorsque vous utilisez la structure de dépôt hiérarchique, une configuration de Repo doit exister dans le répertoire system/ du dépôt et doit inclure les informations requises, telles que la version sémantique du dépôt.

Si aucune configuration de Repo n'existe, l'erreur suivante se produit :

KNV1017: The system/ directory must declare a Repo Resource.
path: system/

To fix, define at least a minimal Repo config.

# system/repo.yaml
kind: Repo
apiVersion: configmanagement.gke.io/v1
metadata:
  name: repo
spec:
  version: "0.1.0"

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

KNV1018 : IllegalSubdirectoryError

Obsolète dans Config Sync 1.3.

KNV1019 : IllegalTopLevelNamespaceError

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

Voici une configuration qui déclenche l'erreur :

# namespaces/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: namespaces
source: namespaces/namespace.yaml
metadata.name: namespaces
group:
version: v1
kind: Namespace

   KNV1019: Namespaces MUST be declared in subdirectories of 'namespaces/'. Create a subdirectory for the following Namespace configs:

    source: namespaces/namespace.yaml
    metadata.name: namespaces
    group:
    version: v1
    kind: Namespace

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

KNV1020 : InvalidNamespaceNameError

Lorsque vous utilisez la 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. Pour résoudre le problème, corrigez le metadata.name ou le répertoire de l'espace de noms.

Voici une configuration qui déclenche l'erreur :

# namespaces/prod/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: dev

KNV1020: A Namespace MUST declare `metadata.name` that matches the name of its
         directory.

expected `metadata.name`: prod

source: namespaces/prod/namespace.yaml
metadata.name: dev
group:
version: v1
kind: Namespace

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

KNV1021 : UnknownObjectError

KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.
         Resource types that are not native Kubernetes objects must have a
         CustomResourceDefinition.

source: namespaces/foo/role.yaml
metadata.name: role
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1024 : IllegalKindInSystemError

KNV1024: Configs of this Kind may not be declared in the `system/` directory of
         the repo:

source: namespaces/foo/role.yaml
metadata.name: role
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1027 : UnsupportedRepoSpecVersion

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

# system/repo.yaml
kind: Repo
apiVersion: configmanagement.gke.io/v1
metadata:
  name: repo
spec:
  version: "0.0.0"

Cet exemple génère l'erreur suivante :

KNV1027: Unsupported Repo spec.version: "0.0.0". Must use version "main"

source: system/repo.yaml
name: repo
group: configmanagement.gke.io
version: v1
kind: Repo

KNV1028 : InvalidDirectoryNameError

KNV1028: Directory names have fewer than 64 characters, consist of lower case
         alphanumeric characters or '-', and must start and end with an
         alphanumeric character. Rename or remove directory:

path: namespaces/a.b`c
name: a.b`c

KNV1029 : MetadataNameCollisionError

KNV1029: Configs of the same Kind MUST have unique names in the same Namespace
         and their parent abstract namespaces:

source: namespaces/foo/r1.yaml
metadata.name: role
group: rbac.authorization.k8s.io
version: v1
kind: Role

source: namespaces/foo/r2.yaml
metadata.name: role
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1030 : MultipleSingletonsError

KNV1030: Multiple Namespace resources cannot exist in the same directory. To fix, remove the duplicate config(s) such that no more than 1 remains:

source: namespaces/foo/namespace.yaml
metadata.name: foo
group:
version: v1
kind: Namespace

source: namespaces/foo/namespace.yaml
metadata.name: foo
group:
version: v1
kind: Namespace

KNV1031 : MissingObjectNameError

Toutes les configurations doivent déclarer metadata.name. Pour corriger cette erreur, ajoutez le champ metadata.name aux configurations problématiques.

KNV1031: A config must declare metadata.name:

source: namespaces/foo/role.yaml
metadata.name:
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1032 : IllegalHierarchicalKindErrorCode

KNV1032: The type Repo.configmanagement.gke.io is not allowed if `sourceFormat` is set to `unstructured`. To fix, remove the problematic config, or convert your repo to use `sourceFormat: hierarchy`.

source: system/repo.yaml
metadata.name: repo
group: configmanagement.gke.io
version: v1
kind: Repo

KNV1033 : IllegalSystemResourcePlacementError

Certains Kinds ne peuvent être déclarés que dans le répertoire system/. La liste suivante répertorie les Kinds pouvant exister exclusivement dans le répertoire system/ : - HierarchyConfig - Repo

KNV1033: A config of the below Kind MUST NOT be declared outside system/:

source: namespaces/foo/repo.yaml
metadata.name: repo
group: configmanagement.gke.io
version: v1
kind: Repo

KNV1034 : IllegalNamespaceError

Il est interdit de déclarer l'espace de noms config-management-system ou les ressources qu'il contient. Pour corriger cette erreur, supprimez l'espace de noms config-management-system et toutes les configurations qu'il contient.

KNV1034: Configs must not be declared in the "config-management-system" namespace

source: namespaces/config-management-system/role.yaml
namespace: namespaces/config-management-system
metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1034: The "config-management-system" namespace must not be declared

source: namespaces/config-management-system/namespace.yaml
metadata.name: config-management-system
group:
version: v1
kind: Namespace

KNV1036 : InvalidMetadataNameError

Le format du metadata.name fourni n'est pas valide. Un metadata.name valide doit : - comporter moins de 254 caractères ; - contenir des caractères alphanumériques minuscules, "-" ou "." ; - commencer et se terminer par un caractère alphanumérique.

Pour corriger cette erreur, modifiez le metadata.name de sorte qu'il respecte les conditions précédentes.

KNV1036: Configs MUST define a metadata.name that is shorter than 254
        characters, consists of lower case alphanumeric characters, '-' or '.',
         and must start and end with an alphanumeric character. Rename or remove
         the config:

source: namespaces/foo/role.yaml
metadata.name: a`b.c
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1037 : IllegalKindInClusterregistryError

Obsolète dans Config Sync 1.3.

KNV1038 : IllegalKindInNamespacesError

KNV1038: Configs of the below Kind may not be declared in `namespaces/`:

source: cluster/cr.yaml
metadata.name: role
group: rbac.authorization.k8s.io
version: v1
kind: ClusterRole

KNV1039 : IllegalKindInClusterError

Il est interdit de déclarer un objet à l'échelle d'un espace de noms en dehors de namespaces/ ou un objet à l'échelle d'un cluster en dehors de cluster/. Pour corriger cette erreur, 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 la section Objets à l'échelle d'un cluster.

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.

KNV1039: Namespace-scoped configs of the below Kind must not be declared in
         cluster/:

source: namespaces/foo/role.yaml
metadata.name: role
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1040 : UnknownResourceInHierarchyConfigError

Obsolète dans Config Sync 1.3.

KNV1041 : UnsupportedResourceInHierarchyConfigError

KNV1041: This Resource Kind MUST NOT be declared in a HierarchyConfig:

source: system/hc.yaml
group: configmanagement.gke.io
kind: Repo

KNV1042 : IllegalHierarchyModeError

Une valeur non autorisée pour HierarchyMode a été détectée sur une HierarchyConfig. HierarchyMode doit avoir la valeur "none" (aucun) ou "inherit" (hériter).

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

KNV1042: HierarchyMode invalid is not a valid value for the APIResource Role.rbac.authorization.k8s.io. Allowed values are [none,inherit].

source: system/hc.yaml
metadata.name: default-name
group: configmanagement.gke.io
version: v1
kind: HierarchyConfig

KNV1043 : UnsupportedObjectError

KNV1043: Config Sync cannot configure this object. To fix, remove this
         config from the repo.

source: namespaces/foo/role.yaml
metadata.name: role
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1044 : UnsyncableResourcesErrorCode

KNV1044: An Abstract Namespace directory with configs MUST have at least one
Namespace subdirectory. To fix, do one of the following: add a Namespace
directory below "bar", add a Namespace config to "bar", or remove the configs in
"bar":

path: namespaces/foo/bar/

KNV1045 : IllegalFieldsInConfigError

Exemple de message d'erreur :

KNV1045: Configs with "metadata.ownerReference" specified are not allowed. To
fix, either remove the config or remove the "metadata.ownerReference" field in
the config:

source: namespaces/foo/replicaset.yaml
metadata.name: replicaSet
group: apps
version: v1
kind: ReplicaSet

Le champ status est l'un des champs non autorisés à l'origine de cette erreur. Pour en savoir plus sur la résolution du problème, consultez la section KNV1045 : Les configurations avec "status" (état) spécifié ne sont pas autorisées dans la documentation de dépannage.

KNV1046 : ClusterScopedResourceInHierarchyConfigError

KNV1046: This HierarchyConfig references the APIResource "ClusterSelector.configmanagement.gke.io" which has cluster scope. Cluster scoped objects are not permitted in HierarchyConfig.

source: system/hc.yaml
metadata.name: hierarchyconfig
group: configmanagement.gke.io
version: v1
kind: HierarchyConfig

KNV1047 : UnsupportedCRDRemovalError

KNV1047: Removing a CRD and leaving the corresponding Custom Resources in the
repo is disallowed. To fix, remove the CRD along with the Custom Resources.

source: cluster/crd.yaml
metadata.name: customResourceDefinition
group: apiextensions.k8s.io
version: v1beta1
kind: CustomResourceDefinition

KNV1048 : InvalidCRDNameError

KNV1048: The CustomResourceDefinition has an invalid name. To fix, change the
name to `spec.names.plural+"."+spec.group`.

source: cluster/crd.yaml
metadata.name: customResourceDefinition
group: apiextensions.k8s.io
version: v1beta1
kind: CustomResourceDefinition

KNV1050 : DeprecatedGroupKindError

KNV1050: The config is using a deprecated Group and Kind. To fix, set the Group and Kind to "Deployment.apps"

source: namespaces/deployment.yaml
metadata.name: default-name
group: extensions
version: v1beta1
kind: Deployment

KNV1052 : IllegalNamespaceOnClusterScopedResourceError

KNV1052: cluster-scoped resources MUST NOT declare metadata.namespace

namespace: foo
metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: ClusterRole

KNV1053 : MissingNamespaceOnNamespacedResourceError

KNV1053: namespace-scoped resources MUST either declare either metadata.namespace or metadata.annotations.configmanagement.gke.io/namespace-selector

metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1054 : InvalidAnnotationValueError

Cette erreur se produit lorsque les configurations contiennent une valeur non valide pour une annotation.

Exemple d'erreur :

KNV1054: Values in metadata.annotations MUST be strings. To fix, add quotes around the values. Non-string values for:

metadata.annotations.foo
metadata.annotations.bar

metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1055 : InvalidNamespaceError

Cette erreur indique que la valeur de metadata.namespace n'est pas un nom d'espace de noms Kubernetes valide.

Exemple d'erreur :

KNV1055: metadata.namespace MUST be valid Kubernetes Namespace names. Rename "FOO" so that it:

1. has a length of 63 characters or fewer;
2. consists only of lowercase letters (a-z), digits (0-9), and hyphen '-'; and
3. begins and ends with a lowercase letter or digit.

namespace: FOO
metadata.name: repo
group: configmanagement.gke.io
version: v1
kind: Repo

KNV1056 : ManagedResourceInUnmanagedNamespace

Cette erreur indique qu'une ressource est déclarée dans un espace de noms non géré. Pour corriger cette erreur, supprimez l'annotation configmanagement.gke.io/managed: disabled ou ajoutez-la à la ressource déclarée.

Exemple d'erreur :

KNV1056: Managed resources must not be declared in unmanaged Namespaces. Namespace "foo" is declared unmanaged but contains managed resources. Either remove the managed: disabled annotation from Namespace "foo" or declare its resources as unmanaged by adding configmanagement.gke.io/managed:disabled annotation.

metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1057 : IllegalDepthLabel

Cette erreur indique qu'une ressource possède un libellé non autorisé. Pour résoudre ce problème, supprimez les libellés se terminant par .tree.hnc.x-k8s.io/depth.

Exemple d'erreur :

KNV1057: Configs MUST NOT declare labels ending with ".tree.hnc.x-k8s.io/depth". The config has disallowed labels: "label.tree.hnc.x-k8s.io/depth"

metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV1058 : BadScopeError

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. 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, la commande nomos affiche l'erreur suivante.

KNV1058: Resources in the "shipping" repo must either omit metadata.namespace or declare metadata.namespace="shipping"

namespace: billing
metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

KNV 1059 : MultipleKptfilesError

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

Par exemple, si un dépôt d'espaces de noms a déclaré deux fichiers Kptfiles, la commande nomos affiche l'erreur suivante :

KNV1059: Namespace Repos may contain at most one Kptfile

metadata.name: package-a
group: kpt.dev
version: v1alpha1
kind: Kptfile

metadata.name: package-b
group: kpt.dev
version: v1alpha1
kind: Kptfile

For more information, see https://g.co/cloud/acm-errors#knv1059

KNV 1060 : ManagementConflictError

Lorsque vous travaillez avec deux dépôts, des conflits peuvent survenir lorsque le même objet (groupes, types, noms et espaces de noms correspondants) est déclarée à la fois dans le dépôt racine et dans un dépôt d'espaces de noms.

En cas de conflit, Config Sync synchronise la version du dépôt racine de la configuration et l'objet RootSync ne signale aucun problème, car le dépôt racine est prioritaire. L'objet RepoSync signale l'erreur KNV 1060 dans son état, comme illustré dans l'exemple suivant :

KNV1060: The "shipping" reconciler cannot manage resources declared in the Root repository. Remove the declaration for this resource from either the Namespace repository, or the Root repository.

metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

Comme le dépôt racine est toujours prioritaire, vous pouvez résoudre le conflit en mettant à jour le dépôt racine afin qu'il corresponde au dépôt d'espaces de noms ou en supprimant l'objet conflictuel dans le dépôt d'espaces de noms.

KNV 1061 : InvalidRepoSyncError

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. Un InvalidRepoSyncError indique qu'un objet RepoSync n'est pas configuré correctement. Le message indique explicitement comment le résoudre.

Par exemple, si le dépôt shipping doit comporter un objet RepoSync nommé repo-sync, mais que RepoSync s'appelle invalid, la commande nomos affiche l'erreur suivante.

KNV1061: RepoSyncs must be named "repo-sync", but the RepoSync for Namespace "shipping" is named "invalid"

metadata.name: invalid
group: configsync.gke.io
version: v1alpha1
kind: RepoSync

KNV1062 : InvalidKptfileError

Cette erreur se produit lorsque 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. Pour résoudre ce problème, vous devez spécifier les valeurs pour .inventory.identifier et .inventory.namespace dans le fichier Kptfile.

Exemples d'erreurs :

KNV1062: Invalid inventory invalid name

metadata.name: default-name
group: kpt.dev
version: v1alpha1
kind: Kptfile

KNV1063 : KptfileExistError

Cette erreur se produit lorsqu'il existe des fichiers Kptfiles 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.

Pour résoudre ce problème, supprimez les fichiers Kptfiles du dépôt racine.

Exemples d'erreurs :

KNV1063: Found Kptfile(s) in the Root Repo. Kptfile(s) are only supported in Namespace Repos. To fix, remove the Kptfile(s) from the Root Repo.

namespace: namespace
metadata.name: default-name
group: kpt.dev
version: v1alpha1
kind: Kptfile

For more information, see https://g.co/cloud/acm-errors#knv1063

KNV1064 : InvalidAPIResourcesError

Cette erreur indique que le fichier api-resources.txt d'un dépôt n'a pas pu être analysé.

Exemples d'erreurs :

KNV1064: invalid NAMESPACED column value "other" in line:
rbac      other     Role

Re-run "kubectl api-resources > api-resources.txt" in the root policy directory

path: /api-resources.txt

For more information, see https://g.co/cloud/acm-errors#knv1064

KNV1064: unable to find APIGROUP column. Re-run "kubectl api-resources > api-resources.txt" in the root policy directory

path: /api-resources.txt

For more information, see https://g.co/cloud/acm-errors#knv1064

KNV1064: unable to read cached API resources: missing file permissions

path: /api-resources.txt

For more information, see https://g.co/cloud/acm-errors#knv1064

KNV1065 : MalformedCRDError

Cette erreur se produit lorsque le paramètre CustomResourceDefinition n'est pas valide. Pour résoudre le problème, vérifiez le champ spécifié par le message d'erreur et assurez-vous que sa valeur est correctement mise en forme.

Exemples d'erreurs :

KNV1065: malformed CustomResourceDefinition: spec.names.shortNames accessor error: foo is of the type string, expected []interface{}.

path: namespaces/foo/crd.yaml

For more information, see https://g.co/cloud/acm-errors#knv1065

KNV1066 : ClusterSelectorAnnotationConflictError

Un objet de configuration NE DOIT déclarer QU'UNE SEULE annotation de sélecteur de cluster. 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).

Pour résoudre ce problème, supprimez l'une des annotations du champ metadata.annotations.

Par exemple, si une configuration d'objet Namespace déclare ces deux annotations, la commande nomos affiche l'erreur suivante :

KNV1066: Config "my-namespace" MUST declare ONLY ONE cluster-selector annotation, but has both inline annotation "configsync.gke.io/cluster-name-selector" and legacy annotation "configmanagement.gke.io/cluster-selector". To fix, remove one of the annotations from:

metadata.name: my-namespace
group:
version: v1
kind: Namespace

For more information, see https://g.co/cloud/acm-errors#knv1066

KNV1067 : EncodeDeclaredFieldError

Cette erreur se produit lorsque 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. Pour résoudre le problème, vérifiez le champ spécifié par le message d'erreur et assurez-vous qu'il correspond au schéma du genre de ressource.

Exemples d'erreurs :

KNV1067: failed to encode declared fields: .spec.version not defined

metadata.name: my-namespace
group:
version: v1
kind: Namespace

For more information, see https://g.co/cloud/acm-errors#knv1067

KNV1068 : ActionableRenderingError

Cette erreur indique que le processus d'affichage rencontre un problème pouvant être résolu côté utilisateur.

Voici un exemple : le dépôt Git contient des configurations Kustomize, mais aucun fichier kustomization.yaml n'existe dans le répertoire de synchronisation Git :

KNV1068: Kustomization config file is missing from the sync directory 'foo/bar'. To fix, either add kustomization.yaml in the sync directory to trigger the rendering process, or remove kustomizaiton.yaml from all sub directories to skip rendering.

For more information, see https://g.co/cloud/acm-errors#knv1068

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. Pour en savoir plus, consultez les pages Afficher le résultat de toutes les configurations dans le dépôt et Rechercher les erreurs dans le dépôt.

Exemple d'erreur kustomize build :

KNV1068: Error in the hydration-controller container: unable to render the source configs in /repo/source/3b724d1a17314c344fa24512239cb3b22b9d90ec: failed to run kustomize build ...

For more information, see https://g.co/cloud/acm-errors#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 depuis Anthos Config Management version 1.12.0 et ultérieure.

Exemple d'erreur kustomize build :

KNV1068: failed to run kustomize build in /repo/source/0a7fd88d6c66362584131f9dfd024024352916af/remote-base, stdout:...
no 'git' program on path: exec: "git": executable file not found in $PATH

For more information, see https://g.co/cloud/acm-errors#knv1068

KNV2001 : pathError

Cette erreur se produit lorsqu'un appel de système d'exploitation accédant à une ressource de système de fichiers échoue.

KNV2002 : apiServerError

Cette erreur se produit lorsqu'une requête accédant au serveur d'API échoue.

KNV2003 : osError

Cette erreur se produit lorsqu'un appel de système d'exploitation générique échoue.

KNV2004 : SourceError

Cette erreur indique que Config Sync ne peut pas lire les données du dépôt Git source ou de l'image OCI. Cela est généralement dû à l'une des erreurs suivantes :

Répertoire de configuration non valide

Recherchez des erreurs telles qu'une valeur incorrecte pour policyDir dans l'objet ConfigManagement ou spec.git.dir ou spec.oci.dir dans l'objet RootSync ou RepoSync. La valeur du répertoire est incluse dans l'erreur. Vérifiez la valeur par rapport à votre dépôt Git ou à votre image OCI.

Identifiants Git incorrects

Recherchez dans les journaux du conteneur git-sync une erreur de type Could not read from remote repository. Ensure you have the correct access rights and the repository exists. ou Invalid username or password. Authentication failed for ....

Vérifiez que les identifiants Git et le secret git-creds sont correctement configurés.

URL du dépôt Git non valide

Recherchez dans les journaux du conteneur git-sync une erreur de type Repository not found..

Vérifiez que vous utilisez le bon format d'URL. Par exemple, si vous utilisez une paire de clés SSH pour vous authentifier auprès du dépôt Git, assurez-vous que l'URL que vous saisissez pour votre dépôt Git lorsque vous configurez Config Sync utilise le protocole SSH.

Branche Git non valide

Recherchez dans les journaux du conteneur git-sync une erreur de type Remote branch BRANCH_NAME not found in upstream origin ou warning: Could not find remote branch BRANCH_NAME to clone.. Notez que la branche est définie sur master par défaut si elle n'est pas spécifiée.

Le dépôt Git est inaccessible depuis le cluster

Le conteneur git-sync génère une erreur dans ses journaux indiquant qu'il ne peut pas atteindre le dépôt. Exemple :ssh: connect to host source.developers.google.com port 2022: Network is unreachable Pour résoudre le problème, ajustez la configuration du pare-feu ou du réseau de votre cluster.

Problèmes d'autorisations lors de l'utilisation du compte de service Google

Accès lecteur manquant

Lorsque vous utilisez un compte de service Google (spec.git.gcpServiceAccountEmail ou spec.oci.gcpServiceAccountEmail) pour vous authentifier auprès de Cloud Source Repositories, Artifact Registry ou Container Registry, le compte de service Google doit disposer de l'accès lecteur suivant :

  • Cloud Source Repositories : roles/source.reader
  • Artifact Registry : roles/artifactregistry.reader
  • Container Registry : roles/containerregistry.serviceAgent

Sinon, git-sync ou oci-sync échoueront avec l'erreur suivante :

failed to pull image us-docker.pkg.dev/...: GET https://us-docker.pkg.dev/v2/token?scope=repository...: DENIED: Permission \"artifactregistry.repositories.downloadArtifacts\" denied on resource \"projects/.../locations/us/repositories/...\" (or it may not exist)

Pour résoudre ce problème, accordez au compte de service l'accès approprié au lecteur.

Liaison de stratégie IAM manquante avec Workload Identity

Lorsque vous utilisez un compte de service Google pour l'authentification, une liaison de stratégie IAM est requise entre le compte de service Google et le compte de service Kubernetes. Si la liaison de stratégie IAM est manquante, vous obtenez l'erreur suivante :

KNV2004: unable to sync repo Error in the git-sync container: ERROR: failed to call ASKPASS callback URL: auth URL returned status 500, body: "failed to get token from credentials: oauth2/google: status code 403: {\n \"error\": {\n \"code\": 403,\n \"message\": \"The caller does not have permission\",\n \"status\": \"PERMISSION_DENIED\"\n }\n}\n"

Pour résoudre le problème, créez la liaison de stratégie IAM suivante :

gcloud iam service-accounts add-iam-policy-binding \
   --role roles/iam.workloadIdentityUser \
   --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Remplacez les éléments suivants :

  • PROJECT_ID : si vous utilisez GKE Workload Identity, ajoutez l'ID de projet de votre organisation. Si vous utilisez Workload Identity de votre parc, vous pouvez utiliser deux ID de projet différents. Dans serviceAccount:PROJECT_ID, ajoutez l'ID de projet du parc dans lequel votre cluster est enregistré. Dans GSA_NAME@PROJECT_ID, ajoutez un ID de projet pour tout projet disposant d'un accès en lecture au dépôt dans Cloud Source Repositories.

  • KSA_NAME : compte de service Kubernetes pour le rapprochement. Pour les dépôts racines, si le nom de l'objet RootSync est root-sync, KSA_NAME est root-reconciler. Sinon, il est défini sur root-reconciler-ROOT_SYNC_NAME.

    Pour les dépôts d'espaces de noms, si le nom de l'objet RepoSync est repo-sync, KSA_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME.

  • GSA_NAME : compte de service Google personnalisé que vous souhaitez utiliser pour vous connecter à Cloud Source Repositories. Assurez-vous que le compte de service Google que vous sélectionnez dispose du rôle source.reader.

Champ d'application cloud-platform manquant pour accéder à Cloud Source Repositories

Lorsque vous autorisez un compte de service Google à accéder à votre dépôt Git dans Cloud Source Repositories, le champ d'application en lecture seule doit être inclus dans les niveaux d'accès pour les nœuds du cluster.

Le champ d'application en lecture seule peut être ajouté en incluant cloud-source-repos-ro dans la liste --scopes spécifiée lors la création du cluster ou en utilisant le champ d'application cloud-platform au moment de la création du cluster. Exemple :

gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform

Si le champ d'application en lecture seule est manquant, vous verrez une erreur semblable à celle-ci :

Error in the git-sync container: {"Msg":"unexpected error syncing repo, will retry","Err":"Run(git clone -v --no-checkout -b main --depth 1 https://source.developers.google.com/p/PROJECT_ID/r/csr-auth-test /repo/source): exit status 128: { stdout: \"\", stderr: \"Cloning into '/repo/source'...\\nremote: INVALID_ARGUMENT: Request contains an invalid argument\\nremote: [type.googleapis.com/google.rpc.LocalizedMessage]\\nremote: locale: \\\"en-US\\\"\\nremote: message: \\\"Invalid authentication credentials. Please generate a new identifier: https://source.developers.google.com/new-password\\\"\\nremote: \\nremote: [type.googleapis.com/google.rpc.RequestInfo]\\nremote: request_id: \\\"fee01d10ba494552922d42a9b6c4ecf3\\\"\\nfatal: unable to access 'https://source.developers.google.com/p/PROJECT_ID/r/csr-auth-test/': The requested URL returned error: 400\\n\" }","Args":{}}

Champ d'application storage-ro manquant pour accéder à Artifact Registry ou Container Registry

Les couches d'image sont conservées dans des buckets Cloud Storage. Lorsque vous autorisez un compte de service Google à accéder à votre image OCI dans Artifact Registry ou Container Registry, le champ d'application en lecture seule doit être inclus dans les niveaux d'accès pour nœuds du cluster.

Le champ d'application en lecture seule peut être ajouté en incluant storage-ro dans la liste --scopes spécifiée lors la création du cluster ou en utilisant le champ d'application cloud-platform au moment de la création du cluster. Exemple :

gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform

Si le champ d'application en lecture seule est manquant, vous verrez une erreur semblable à celle-ci :

Error in the oci-sync container: {"Msg":"unexpected error fetching package, will retry","Err":"failed to pull image us-docker.pkg.dev/...: GET https://us-docker.pkg.dev/v2/token?scope=repository%3A...%3Apull\u0026service=us-docker.pkg.dev: UNAUTHORIZED: failed authentication","Args":{}}

Le message d'erreur peut ne pas inclure tous les détails sur la cause de l'erreur, mais il fournit une commande qui imprime les journaux du conteneur git-sync qui peuvent contenir plus d'informations.

Si vous utilisez les API RootSync ou RepoSync, procédez comme suit :

kubectl logs -n config-management-system -l app=reconciler -c git-sync

Si vous n'activez pas les API RootSync ou RepoSync :

kubectl logs -n config-management-system -l app=git-importer -c git-sync

KNV2005 : ResourceFightWarning

Cette erreur indique que Config Sync est en conflit avec un autre contrôleur sur une ressource. Ces conflits consomment beaucoup de ressources et peuvent nuire à vos performances. Ils sont également appelés "conflits de ressources".

Si vous utilisez des API RootSync ou RepoSync, pour détecter les conflits, consultez les journaux Config Sync reconciler en exécutant la commande suivante :

kubectl logs -n config-management-system -l app=reconciler -c CONTAINER_NAME

Remplacez CONTAINER_NAME par reconciler, git-sync, oci-sync ou hydration-controller. git-sync clone le dépôt Git distant. oci-sync extrait les configurations du registre d'images distant. hydration-controller affiche les fichiers manifestes Kustomize et Helm. reconciler aplatit la hiérarchie du dépôt et la rapproche du serveur d'API, en recherchant les erreurs.

Si vous n'activez pas les API RootSync ou RepoSync pour détecter les conflits, consultez les journaux Config Sync git-importer en exécutant la commande suivante :

kubectl logs --namespace config-management-system deployment/git-importer CONTAINER_NAME

Remplacez CONTAINER_NAME par importer, fs- watcher ou git-sync. git-importer étant constitué de ces trois composants, vous pouvez utiliser l'un d'entre eux pour vérifier les journaux git-importer. git-sync clone le dépôt Git distant. importer aplatit la hiérarchie du dépôt et la redéfinit à l'aide du serveur d'API pour vérifier les erreurs dans le résultat. fs- watcher exécute le conteneur d'importation dans un mode qui consigne les modifications apportées au système de fichiers de journaux pour le dépôt.

Si KNV2005 apparaît dans les résultats, cela signifie qu'il y a un conflit de ressources.

Pour en savoir plus sur les conflits de ressources, examinez les mises à jour du fichier YAML de la ressource en exécutant la commande suivante :

 kubectl get resource --watch -o yaml

Remplacez resource par le type de ressource faisant l'objet d'un conflit. Vous pouvez voir quelle ressource ajouter en fonction des résultats du journal.

Cette commande renvoie un flux de l'état de la ressource après l'application des mises à jour au serveur d'API. Vous pouvez utiliser un outil de comparaison de fichiers pour comparer le résultat.

Certaines ressources doivent appartenir à d'autres contrôleurs (par exemple, certains opérateurs installent ou gèrent des définitions de ressources personnalisées). Ces autres contrôleurs suppriment automatiquement toutes les métadonnées propres à Config Sync. Si un autre composant de votre cluster Kubernetes supprime les métadonnées Config Sync, arrêtez de gérer la ressource. Pour savoir comment procéder, consultez la section Arrêter la gestion d'un objet géré.

KNV2006 : Config Management Errors

Afin d'é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 dans un seul commit.

Si vous avez validé des modifications afin de supprimer toutes les ressources, vous devez le corriger en l'état d'origine, puis le supprimer en deux étapes.

Si le webhook d'admission Config Sync est désactivé (Anthos Config Management 1.9 et versions antérieures l'ont activé par défaut), vous pouvez annuler 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.

Comment effectuer des suppressions

Si vous souhaitez supprimer l'ensemble complet des ressources sous gestion, vous devez suivre les deux étapes suivantes :

  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.

KNV2008 : APIServerConflictError

Ce type d'erreur se produit lorsqu'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 ressources.

Exemples d'erreurs :

KNV2008: tried to create resource that already exists: already exists

metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

For more information, see https://g.co/cloud/acm-errors#knv2008

KNV2008: tried to update resource which does not exist: does not exist

metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

For more information, see https://g.co/cloud/acm-errors#knv2008

KNV2008: tried to update with stale version of resource: old version

metadata.name: default-name
group: rbac.authorization.k8s.io
version: v1
kind: Role

For more information, see https://g.co/cloud/acm-errors#knv2008

KNV2009 : ApplyError

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

KNV2009: no matches for kind "Anvil" in group "acme.com".

Délai d'expiration des E/S de requête du webhook d'admission

Si vous recevez l'erreur suivante lorsque le processus de rapprochement tente d'appliquer une configuration au cluster :

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout

Cette erreur peut être due au blocage du port du webhook d'admission 8676 par le pare-feu sur le réseau du plan de contrôle. Pour résoudre ce problème, ajoutez une règle de pare-feu pour autoriser le port 8676, utilisé par le webhook d'admission de Config Sync à des fins de prévention contre les dérives.

Connexion du webhook d'admission refusée

L'erreur suivante peut s'afficher lorsque le processus de rapprochement tente d'appliquer une configuration au cluster :

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused

Cela signifie que le webhook d'admission n'est pas encore prêt. Il s'agit d'une erreur temporaire que vous pourriez voir lors de l'amorçage de Config Sync.

Si le problème persiste, examinez le déploiement du webhook d'admission pour voir si ses pods peuvent être programmés et sont opérationnels.

kubectl describe deploy admission-webhook -n config-management-system

kubectl get pods -n config-management-system -l app=admission-webhook

La ressource ResourceGroup dépasse la limite de taille d'objet etcd.

Si vous recevez l'erreur suivante lorsque le rapprochement tente d'appliquer des configurations au cluster :

KNV2009: too many declared resources causing ResourceGroup.kpt.dev, config-management-system/root-sync failed to be applied: task failed (action: "Inventory", name: "inventory-add-0"): Request entity too large: limit is 3145728. To fix, split the resources into multiple repositories.

Cette erreur signifie que la ressource ResourceGroup dépasse la limite de taille de l'objet etcd. Nous vous recommandons de diviser votre dépôt Git en plusieurs dépôts. Si vous ne parvenez pas à scinder le dépôt Git dans Config Sync v1.11.0 et versions ultérieures, vous pouvez le limiter en désactivant les données d'état émergentes. Pour ce faire, définissez le champ .spec.override.statusMode de l'objet RootSync ou RepoSync sur disabled. Ainsi, Config Sync cesse de mettre à jour l'état des ressources gérées dans l'objet ResourceGroup. Cela réduit la taille de l'objet ResourceGroup. Cependant, vous ne pourrez pas afficher l'état des ressources gérées à partir de nomos status ou de gcloud alpha anthos config sync.

Dépendance appliquée avant expiration du rapprochement

Vous pouvez recevoir une erreur semblable à l'exemple suivant lorsque le rapprochement tente d'appliquer des objets avec l'annotation config.kubernetes.io/depends-on au cluster :

KNV2009: skipped apply of Pod, bookstore/pod4: dependency apply reconcile timeout: bookstore_pod3__Pod  For more information, see https://g.co/cloud/acm-errors#knv2009

Cette erreur signifie que l'objet de dépendance n'a pas rapproché le délai de rapprochement par défaut de 5 minutes. Config Sync ne peut pas appliquer l'objet dépendant, car avec l'annotation config.kubernetes.io/depends-on, Config Sync n'applique que les objets dans l'ordre souhaité. Vous pouvez ignorer le délai de rapprochement par défaut en définissant spec.override.reconcileTimeout.

Les informations sur l'inventaire sont "nil"

Si vous recevez l'erreur suivante lorsque le rapprochement tente d'appliquer des configurations au cluster, il est probable que votre inventaire ne dispose d'aucune ressource ou que le fichier manifeste comporte une annotation non gérée :

KNV2009: inventory info is nil\n\nFor more information, see https://g.co/cloud/acm-errors#knv2009

Pour résoudre ce problème, procédez comme suit :

  1. Évitez de configurer des synchronisations où toutes les ressources comportent l'annotation configmanagement.gke.io/managed: disabled, en vous assurant qu'au moins une ressource est gérée par Config Sync.
  2. Ajoutez l'annotation configmanagement.gke.io/managed: disabled uniquement après avoir terminé une synchronisation initiale de la ressource sans cette annotation.

KNV2010 : resourceError

Il s'agit d'une erreur générique signalant un problème lié à une ressource ou un ensemble de ressources. Le message indique les ressources spécifiques qui ont généré l'erreur.

KNV2010: Resources were improperly formatted.

Affected resources:
source: system/hc.yaml
group: configmanagement.gke.io
kind: Repo

KNV2011 : MissingResourceError

Cette erreur indique qu'une ressource spécifique requise pour poursuivre une opération est introuvable. Elle peut par exemple se produire si Config Management Operator tente de mettre à jour une ressource qui a été supprimée lors du calcul de la mise à jour.

KNV2012 : MultipleSingletonsError

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 peut exister sur un cluster.

KNV2013 : InsufficientPermissionError

Cette erreur se produit lorsqu'un processus de rapprochement des espaces de noms ne dispose pas des autorisations nécessaires pour gérer les ressources. Pour corriger le problème, assurez-vous que le rapprochement dispose des autorisations suffisantes.

Exemples d'erreurs :

KNV2013: could not create resources: Insufficient permission. To fix, make sure the reconciler has sufficient permissions.: deployments.apps is forbidden: User 'Bob' cannot create resources

For more information, see https://g.co/cloud/acm-errors#knv2013

KNV2014 : InvalidWebhookWarning

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.

Exemple d'avertissement :

KNV2014: invalid webhook

KNV2015 : InternalRenderingError

Cette erreur indique que le processus d'affichage rencontre un problème interne. Un exemple ne parvient pas à accéder au système de fichiers. Cela peut indiquer que le pod n'est pas opérationnel. Vous pouvez redémarrer le pod de rapprochement en exécutant la commande suivante :

# 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>

Si l'erreur persiste après le redémarrage, créez un rapport de bug.

KNV9997 : RenderingInProgress

Le message KNV9997 indique que l'état de l'affichage n'est pas disponible pour le rapprochement. L'erreur n'est pas exposée dans l'API RootSync/RepoSync ou nomos status et ne s'affiche que dans le journal de rapprochement. Il s'agit d'une erreur temporaire qui se résout automatiquement lorsque l'état de l'affichage est disponible.

Exemples de journaux :

2021-10-04T15:50:46.166961451Z E1004 15:50:46.166756       1 state.go:69] Invalidating reconciler checkpoint: 1 error(s)
2021-10-04T15:50:46.167032152Z [1] KNV9997: rendering in progress for commit 90c1d9e9633a988ee3c3fc4dd145e62af30e9d1f  For more information, see https://g.co/cloud/acm-errors#knv9997
2021-10-04T15:50:48.125422752Z I1004 15:50:48.125223       1 run.go:73] The last reconciliation failed

KNV9998 : InternalError

Le message KNV9998 indique un problème lié à la commande nomos proprement dite. Veuillez créer un rapport de bug avec la commande exacte que vous avez exécutée et le message que vous avez reçu.

Exemples d'erreurs :

KNV9998: we made a mistake: internal error

For more information, see https://g.co/cloud/acm-errors#knv9998

KNV9999 : UndocumentedError

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.

Étape suivante