Problèmes connus

Cette page répertorie les problèmes connus liés à Config Connector.

Un grand nombre des problèmes répertoriés sur cette page ont été résolus. La colonne Version corrigée indique la version dans laquelle le correctif a été introduit. Pour bénéficier de ce correctif, effectuez une mise à niveau vers la version répertoriée ou une version ultérieure.

Si vous faites partie du Google Developer Program, enregistrez cette page pour recevoir des notifications lorsqu'une note de version la concernant est publiée. Pour en savoir plus, consultez Pages enregistrées.

Pour filtrer les problèmes connus en fonction d'une version de produit ou d'une catégorie, sélectionnez vos filtres dans les menus déroulants suivants.

Sélectionnez votre version de Config Connector :

Sélectionnez votre catégorie de problème :

Vous pouvez également filtrer les problèmes connus :

Catégorie Plus ancienne version identifiée Version corrigée Problème et solution

Ressources

1,134

1.134.2

Catégorie	Plus ancienne version identifiée	Version corrigée	Problème et solution
Ressources	1,134	1.134.2	Correction : l'instance SQL est bloquée à l'état "Mise à jour" en raison d'une erreur d'annotation "merge" Les ressources `SQLInstance` concernées peuvent rester bloquées à l'état `Updating` avec un message d'erreur concernant l'annotation `state-into-spec`. invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation Ce problème se produit, car une validation plus stricte introduite dans la version 1.134.0 a rejeté à tort la stratégie de "fusion" pour les ressources `SQLInstance`, même lorsqu'elle était appliquée par défaut. Ce problème est résolu dans les versions ultérieures.
Rapprochement direct	1,131	1,134	Correction : problèmes liés aux rapprochements directs La version 1.132.0 de Config Connector a introduit des problèmes affectant les ressources qui utilisent le reconciler direct. Erreur de nom de contrôleur en double Dans la version 1.132.0, il est possible que des ressources telles que `SpannerInstance` et `SecretManagerSecret` ne parviennent pas à se réconcilier et qu'une erreur indique qu'un contrôleur portant le même nom existe déjà : error registering controller: error adding direct controller for SpannerInstance to a manager: error creating new controller: controller with name spannerinstance-controller already exists. Erreur "last-applied-configuration" de SecretManagerSecret Si vous activez le reconciler direct pour un `SecretManagerSecret` (à l'aide de l'annotation `alpha.cnrm.cloud.google.com/reconciler: direct`) dans les versions 1.131.0 à 1.133, la réconciliation peut échouer et générer une erreur d'API : [kubectl.kubernetes.io/last-applied-configuration] must follow pattern [a-z0-9A-Z]+([_\.\-][a-z0-9A-Z]+)), be less than 64 characters, and must have a UTF encoding of less than 128 bytes Cela se produit, car Config Connector tente à tort de transmettre des annotations Kubernetes internes en tant qu'étiquettes à l'API Secret Manager.
Installation, mise en réseau	Kubernetes 1.19	1,43	Corrigé : erreur "Échec de l'appel du webhook x509 : le certificat s'appuie sur l'ancien champ Nom courant" Si une erreur semblable à l'exemple suivant s'affiche, vous rencontrez peut-être un problème avec les certificats : Error from server (InternalError): error when creating "/mnt/set-weaver-dns-record.yml": Internal error occurred: failed calling webhook "annotation-defaulter.cnrm.cloud.google.com": Post "https://cnrm-validating-webhook.cnrm-system.svc:443/annotation-defaulter?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0 Ce problème se produit avec les versions 1.19 et ultérieures de Kubernetes. Les versions 1.43 et ultérieures de Config Connector sont compatibles avec la génération automatique du certificat, ce qui devrait éviter ce problème. Solution : Pour contourner ce problème, vous pouvez supprimer les certificats et les pods concernés : kubectl delete -n cnrm-system secrets cnrm-webhook-cert-abandon-on-uninstall kubectl delete -n cnrm-system secrets cnrm-webhook-cert-cnrm-validating-webhook kubectl delete -n cnrm-system pods -l "cnrm.cloud.google.com/component=cnrm-webhook-manager" Une fois ces ressources supprimées, le bon certificat devrait être régénéré.

Correction : l'instance SQL est bloquée à l'état "Mise à jour" en raison d'une erreur d'annotation "merge"

Les ressources SQLInstance concernées peuvent rester bloquées à l'état Updating avec un message d'erreur concernant l'annotation state-into-spec.

invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation

Ce problème se produit, car une validation plus stricte introduite dans la version 1.134.0 a rejeté à tort la stratégie de "fusion" pour les ressources SQLInstance, même lorsqu'elle était appliquée par défaut. Ce problème est résolu dans les versions ultérieures.

Rapprochement direct

1,131

1,134

Correction : problèmes liés aux rapprochements directs

La version 1.132.0 de Config Connector a introduit des problèmes affectant les ressources qui utilisent le reconciler direct.

Erreur de nom de contrôleur en double

Dans la version 1.132.0, il est possible que des ressources telles que SpannerInstance et SecretManagerSecret ne parviennent pas à se réconcilier et qu'une erreur indique qu'un contrôleur portant le même nom existe déjà :

error registering controller: error adding direct controller for SpannerInstance to a manager: error creating new controller: controller with name spannerinstance-controller already exists.

Erreur "last-applied-configuration" de SecretManagerSecret

Si vous activez le reconciler direct pour un SecretManagerSecret (à l'aide de l'annotation alpha.cnrm.cloud.google.com/reconciler: direct) dans les versions 1.131.0 à 1.133, la réconciliation peut échouer et générer une erreur d'API :

[kubectl.kubernetes.io/last-applied-configuration] must follow pattern [a-z0-9A-Z]+([_\.\-]*[a-z0-9A-Z]+)*), be less than 64 characters, and must have a UTF encoding of less than 128 bytes

Cela se produit, car Config Connector tente à tort de transmettre des annotations Kubernetes internes en tant qu'étiquettes à l'API Secret Manager.

Installation, mise en réseau

Kubernetes 1.19

1,43

Corrigé : erreur "Échec de l'appel du webhook x509 : le certificat s'appuie sur l'ancien champ Nom courant"

Si une erreur semblable à l'exemple suivant s'affiche, vous rencontrez peut-être un problème avec les certificats :

Error from server (InternalError): error when creating "/mnt/set-weaver-dns-record.yml": Internal error occurred: failed calling webhook "annotation-defaulter.cnrm.cloud.google.com": Post "https://cnrm-validating-webhook.cnrm-system.svc:443/annotation-defaulter?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

Ce problème se produit avec les versions 1.19 et ultérieures de Kubernetes. Les versions 1.43 et ultérieures de Config Connector sont compatibles avec la génération automatique du certificat, ce qui devrait éviter ce problème.

Solution :

Pour contourner ce problème, vous pouvez supprimer les certificats et les pods concernés :

kubectl delete -n cnrm-system secrets cnrm-webhook-cert-abandon-on-uninstall
kubectl delete -n cnrm-system secrets cnrm-webhook-cert-cnrm-validating-webhook
kubectl delete -n cnrm-system pods -l "cnrm.cloud.google.com/component=cnrm-webhook-manager"

Une fois ces ressources supprimées, le bon certificat devrait être régénéré.

Haut de page