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. DansserviceAccount:PROJECT_ID
, ajoutez l'ID de projet du parc dans lequel votre cluster est enregistré. DansGSA_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 estroot-sync
,KSA_NAME
estroot-reconciler
. Sinon, il est défini surroot-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
estns-reconciler-NAMESPACE
. Sinon, il est défini surns-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ôlesource.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 :
- 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. - Réactivez Config Sync.
- 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 :
- 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.
- 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 :
- É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. - 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
- Découvrez comment résoudre les problèmes liés à Config Sync.
- Découvrez comment surveiller Config Sync.