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 associée à cette page 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.126.0 1.134.1

Lorsque vous tentez de créer ou d'appliquer de nouvelles ressources Config Connector, le serveur d'API Kubernetes rejette la requête et bloque la création des ressources. Vous ne pouvez pas déployer de nouvelles ressources, mais les ressources existantes peuvent continuer à se rapprocher normalement. Ce problème est dû à une condition de concurrence connue dans le composant cnrm-webhook-manager des versions de Config Connector antérieures à la version 1.134.1.

Une erreur semblable à celle-ci peut s'afficher dans les résultats de votre déploiement ou dans les journaux du serveur d'API :

failed calling webhook "container-annotation-handler.cnrm.cloud.google.com": failed to call webhook: Post "https://cnrm-validating-webhook.cnrm-system.svc:443/...": tls: failed to verify certificate: x509: certificate signed by unknown authority
      

De plus, les journaux du pod cnrm-webhook-manager peuvent afficher les éléments suivants :

http: TLS handshake error ... remote error: tls: bad certificate.
      

Solution :

Pour débloquer immédiatement la création de ressources, vous pouvez forcer les pods du gestionnaire de webhook à se synchroniser et à extraire les données de certificat correctes en redémarrant le déploiement à l'aide de la commande suivante :

kubectl rollout restart deployment cnrm-webhook-manager -n cnrm-system
      
Ressources 1,134 1.134.2

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 est dû au fait qu'une validation plus stricte introduite dans la version 1.134.0 a rejeté à tort la stratégie "merge" pour les ressources SQLInstance, même lorsqu'elle était appliquée par défaut. Ce problème est corrigé dans les versions ultérieures.

Outil de rapprochement direct 1,131 1,134

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

Erreur : Nom de contrôleur en double

Dans la version 1.132.0, les ressources telles que SpannerInstance et SecretManagerSecret peuvent ne pas se rapprocher, avec une erreur indiquant 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 SecretManagerSecret "last-applied-configuration"

Si vous activez le rapprochement direct pour un SecretManagerSecret (à l'aide de l'annotation alpha.cnrm.cloud.google.com/reconciler: direct) dans les versions 1.131.0 à 1.133, le rapprochement peut échouer avec 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 de manière incorrecte de transmettre des annotations Kubernetes internes en tant qu'étiquettes à l'API Secret Manager.

Installation, mise en réseau Kubernetes 1.19 1,43

Si un message d'erreur semblable à l'exemple suivant s'affiche, vous rencontrez peut-être un problème de 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 Kubernetes 1.19 et les versions ultérieures. 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 certificat approprié devrait se régénérer.

Haut de page