Résoudre les problèmes liés à Config Connector

Cette page décrit les techniques de dépannage que vous pouvez utiliser pour résoudre les problèmes liés à Config Connector, ainsi que les problèmes courants que vous pouvez rencontrer lors de l'utilisation du produit.

Vérifier l'état et les conditions de Config Connector

Vérifier la version de Config Connector

Exécutez la commande suivante pour obtenir la version de Config Connector installée, puis consultez les notes de version pour vérifier que la version en cours d'exécution est compatible avec les fonctionnalités et les ressources que vous souhaitez utiliser :

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

Vérifier l'état et les événements de la ressource

En général, vous pouvez identifier le problème lié à vos ressources Config Connector en inspectant l'état de vos ressources dans Kubernetes. La vérification de l'état et des événements d'une ressource est particulièrement utile pour déterminer si Config Connector n'a pas réussi à rapprocher la ressource et pourquoi le rapprochement a échoué.

Vérifier que Config Connector est en cours d'exécution

Pour vérifier que Config Connector est en cours d'exécution, vérifiez que tous ses pods sont READY :

kubectl get pod -n cnrm-system

Exemple de résultat :

NAME                                            READY   STATUS    RESTARTS   AGE
cnrm-controller-manager-0                       1/1     Running   0          1h
cnrm-deletiondefender-0                         1/1     Running   0          1h
cnrm-resource-stats-recorder-77dc8cc4b6-mgpgp   1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-pqwhz           1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-wdcn4           1/1     Running   0          1h

Si Config Connector est installé en mode espace de noms, vous disposez d'un pod de contrôleur (cnrm-controller-manager) pour chaque espace de noms. Ce pod est responsable de la gestion des ressources Config Connector dans cet espace de noms.

Vous pouvez vérifier l'état du pod du contrôleur responsable d'un espace de noms spécifique en exécutant la commande suivante :

kubectl get pod -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager

Remplacez NAMESPACE par le nom de l'espace de noms.

Vérifier les journaux du contrôleur

Le pod du contrôleur consigne les informations et les erreurs liées au rapprochement des ressources Config Connector.

Vous pouvez consulter les journaux du pod du contrôleur en exécutant la commande suivante :

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Si Config Connector est installé en mode espace de noms, la commande précédente affiche les journaux de tous les pods de contrôleur combinés. Vous pouvez vérifier les journaux du pod du contrôleur pour un espace de noms spécifique en exécutant la commande suivante :

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Remplacez NAMESPACE par le nom de l'espace de noms.

Découvrez comment inspecter et interroger les journaux de Config Connector.

Abandonner et acquérir la ressource

Dans certains cas, vous devrez peut-être mettre à jour un champ immuable dans une ressource. Comme vous ne pouvez pas modifier les champs immuables, vous devez abandonner la ressource, puis l'acquérir :

  1. Mettez à jour la configuration YAML de la ressource Config Connector et définissez l'annotation cnrm.cloud.google.com/deletion-policy sur abandon.
  2. Appliquez la configuration YAML mise à jour pour mettre à jour la règle de suppression de la ressource Config Connector.
  3. Abandonner la ressource Config Connector.
  4. Mettez à jour les champs immuables qui doivent être modifiés dans la configuration YAML.
  5. Appliquez la configuration YAML mise à jour pour acquérir la ressource abandonnée.

Résoudre par type de problème

Utilisez le tableau suivant pour résoudre votre problème en fonction du type de symptôme.

Type de problème Problèmes courants
Réconciliation
Suppression
Autorisations
Installation et mises à niveau
Configuration

Rapprochement

La section suivante répertorie les problèmes courants liés au rapprochement des ressources par Config Connector.

La ressource est mise à jour toutes les 5 à 15 minutes

Problème constaté

Votre ressource Config Connector passe constamment de l'état UpToDate à l'état Updating toutes les 5 à 10 minutes.

Cause

Il est probable que Config Connector détecte des différences involontaires entre l'état souhaité et l'état réel de la ressource, ce qui l'amène à mettre constamment à jour la ressource.

Solution

Tout d'abord, vérifiez qu'aucun système externe ne modifie constamment Config Connector ou la ressource Google Cloud (par exemple, des pipelines CI/CD, des contrôleurs personnalisés, des jobs Cron, etc.).

Si le comportement n'est pas dû à un système externe, vérifiez si Google Cloud modifie l'une des valeurs spécifiées dans votre ressource Config Connector. Par exemple, dans certains cas, Google Cloud modifie la mise en forme (par exemple, la mise en majuscules) des valeurs de champ, ce qui entraîne une différence entre l'état souhaité et l'état réel de votre ressource.

Obtenez l'état de la ressource Google Cloud à l'aide de l'API REST (par exemple, pour ContainerCluster) ou de la Google Cloud CLI. Ensuite, comparez cet état à votre ressource Config Connector. Recherchez les champs dont les valeurs ne correspondent pas, puis mettez à jour votre ressource Config Connector pour qu'elle corresponde. Recherchez en particulier les valeurs qui ont été reformatées par Google Cloud. Pour en savoir plus, consultez les problèmes GitHub #578 et #294.

Notez que cette méthode n'est pas parfaite, car les modèles de ressources Config Connector etGoogle Cloud sont différents, mais elle devrait vous permettre de détecter la plupart des cas de différences involontaires.

Si vous ne parvenez pas à résoudre votre problème, consultez la section Aide supplémentaire.

Échec ou boucle de rapprochement en raison de mises à jour automatiques des champs

Ce problème se produit lorsque Google Cloud met automatiquement à jour un champ sur une ressource qui utilise l'annotation cnrm.cloud.google.com/state-into-spec: merge.

Problème constaté

Votre ressource Config Connector passe à l'état UpdateFailed ou passe à l'état Updating à plusieurs reprises après que Google Cloud a mis à jour automatiquement un champ que vous n'avez pas spécifié dans votre fichier manifeste YAML.

Par exemple, après que Cloud SQL a effectué une mise à jour de maintenance automatique sur une ressource SQLInstance, le rapprochement peut échouer avec une erreur semblable à celle-ci :

Update call failed: error updating: patching SQLInstance ... maintenanceVersion failed: googleapi: Error 400: Invalid request: The requested maintenance version is not an available maintenance version to upgrade. Please refer to the availableMaintenanceVersions on the instance resource to see the available maintenance versions.., invalid

Cause

La ressource comporte l'annotation cnrm.cloud.google.com/state-into-spec: merge. Cette annotation était la valeur par défaut pour les ressources créées avant la version 1.123.1 de Config Connector pour les CustomResourceDefinitions (CRD) ajoutées dans la version 1.113.0 et les versions antérieures. Votre ressource peut également comporter cette annotation si le champ spec.stateIntoSpec est défini sur Merge dans votre ressource personnalisée ConfigConnector ou ConfigConnectorContext.

Lorsque l'annotation cnrm.cloud.google.com/state-into-spec est définie sur merge, Config Connector renseigne les champs non spécifiés, tels que le champ spec.maintenanceVersion, dans le champ spec de la ressource Kubernetes lors du rapprochement initial. Lorsque Google Cloud met à jour automatiquement ce champ sur la ressource sous-jacente, Config Connector considère l'ancienne valeur stockée dans le champ spec comme l'état cible et tente d'annuler la modification. Si l'API Google Cloud rejette les rétrogradations (comme le fait Cloud SQL pour le champ spec.maintenanceVersion), le rapprochement échoue.

Solution

Pour résoudre ce problème, migrez la ressource du comportement Merge vers le comportement Absent afin que Config Connector cesse de renseigner les champs non spécifiés dans le champ spec :

  1. Dans le fichier manifeste YAML de votre ressource, omettez le champ mis à jour automatiquement (tel que le champ spec.maintenanceVersion) et définissez l'annotation cnrm.cloud.google.com/state-into-spec sur absent.
  2. Suivez la procédure décrite dans Migrer des ressources de Merge vers Absent pour abandonner la ressource Kubernetes et la récupérer avec le fichier manifeste YAML mis à jour.

La ressource n'a pas d'état

Problème constaté

Vos ressources ne comportent pas de champ status.

Cause

Il est probable que Config Connector ne fonctionne pas correctement.

Solution

Vérifiez que Config Connector est en cours d'exécution.

KNV2005 : le synchroniseur met à jour la ressource de manière excessive

Problème constaté

Vous utilisez Config Sync et vous voyez des erreurs KNV2005 pour les ressources Config Connector, semblables à ce qui suit :

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

Cause

Il est probable que Config Sync et Config Connector soient en conflit pour la ressource.

On dit que Config Sync et Config Connector sont en "conflit" sur une ressource s'ils mettent à jour les mêmes champs avec des valeurs différentes. La mise à jour de l'un déclenche l'action de l'autre et la mise à jour de la ressource, ce qui provoque l'action de l'autre et la mise à jour de la ressource, et ainsi de suite sans fin.

La lutte n'est pas un problème pour la plupart des champs. Les champs spécifiés dans Config Sync ne sont pas modifiés par Config Connector. De même, les champs qui ne sont pas spécifiés dans Config Sync et qui sont définis par défaut par Config Connector sont ignorés par Config Sync. Par conséquent, pour la plupart des champs, Config Sync et Config Connector ne devraient pas avoir besoin de mettre à jour le même champ.

à l'exception des champs de liste. Tout comme Config Connector peut définir des sous-champs par défaut dans les champs d'objet, il peut également définir des sous-champs par défaut dans les objets à l'intérieur des listes. Toutefois, étant donné que les champs de liste des ressources Config Connector sont atomiques, la définition de valeurs par défaut pour les sous-champs est considérée comme modifiant entièrement la valeur de la liste.

Par conséquent, Config Sync et Config Connector "s'affronteront" pour une ressource si Config Sync définit un champ de liste et que Config Connector définit par défaut les sous-champs de cette liste.

Solution

Pour contourner ce problème, vous avez les options suivantes :

  1. Mettez à jour le fichier manifeste de ressources dans le dépôt Config Sync pour qu'il corresponde à la valeur que Config Connector tente de définir pour la ressource.

    Pour ce faire, vous pouvez arrêter temporairement la synchronisation des configurations, attendre que Config Connector ait fini de rapprocher la ressource, puis mettre à jour le fichier manifeste de votre ressource pour qu'il corresponde à la ressource sur le serveur d'API Kubernetes.

  2. Empêchez Config Sync de réagir aux mises à jour de la ressource sur le serveur d'API Kubernetes en définissant l'annotation client.lifecycle.config.k8s.io/mutation sur ignore. Découvrez comment faire en sorte que Config Sync ignore les mutations d'objets.

  3. Empêchez Config Connector de mettre à jour entièrement la spécification de la ressource en définissant l'annotation cnrm.cloud.google.com/state-into-spec sur absent sur la ressource. Cette annotation n'est pas compatible avec toutes les ressources. Pour savoir si votre ressource est compatible avec l'annotation, consultez la page de référence de la ressource correspondante. En savoir plus sur l'annotation

Ressource supprimée par Config Connector

Problème constaté

Une ressource a été supprimée de votre cluster, et vous pensez que Config Connector l'a supprimée.

Cause

Config Connector ne supprime jamais vos ressources sans cause externe. Par exemple, l'exécution de kubectl delete, l'utilisation d'outils de gestion de la configuration comme Argo CD ou l'utilisation d'un client API personnalisé peuvent entraîner la suppression de ressources.

Une idée fausse courante est que Config Connector a initié et supprimé certaines ressources de votre cluster. Par exemple, si vous utilisez Config Connector, vous remarquerez peut-être des requêtes de suppression du gestionnaire de contrôleurs Config Connector sur certaines ressources, soit à partir des messages de journal du conteneur, soit à partir des journaux d'audit du cluster Kubernetes. Ces demandes de suppression sont le résultat de déclencheurs externes, et Config Connector tente de les réconcilier.

Solution

Pour déterminer pourquoi une ressource a été supprimée, vous devez examiner la première demande de suppression qui lui a été envoyée. La meilleure façon d'examiner ce problème consiste à examiner les journaux d'audit du cluster Kubernetes.

Par exemple, si vous utilisez GKE, vous pouvez utiliser Cloud Logging pour interroger les journaux d'audit des clusters GKE. Par exemple, si vous souhaitez rechercher les demandes de suppression initiales pour une ressource BigQueryDataset nommée foo dans l'espace de noms bar, vous devez exécuter une requête semblable à la suivante :

resource.type="k8s_cluster"
resource.labels.project_id="my-project-id"
resource.labels.cluster_name="my-cluster-name"
protoPayload.methodName="com.google.cloud.cnrm.bigquery.v1beta1.bigquerydatasets.delete"
protoPayload.resourceName="bigquery.cnrm.cloud.google.com/v1beta1/namespaces/bar/bigquerydatasets/foo"

À l'aide de cette requête, vous rechercherez la première demande de suppression, puis vous vérifierez authenticationInfo.principalEmail de ce message de journal de suppression pour déterminer la cause de la suppression.

Arrêt OOMKilled du pod de contrôleur

Problème constaté

Une erreur OOMKilled s'affiche sur un pod de contrôleur Config Connector. L'état du pod peut être OOMKilled ou Terminating.

Cause

Un conteneur ou l'intégralité du pod a été arrêté, car il utilisait plus de mémoire que ce qui était autorisé. Vous pouvez le vérifier en exécutant la commande kubectl describe :

kubectl describe pod POD_NAME -n cnrm-system

Remplacez POD_NAME par le pod que vous dépannez.

De plus, l'examen des journaux d'événements du pod peut révéler des occurrences d'événements liés à une insuffisance de mémoire.

Solution

Pour résoudre ce problème, vous pouvez utiliser la ressource personnalisée ControllerResource afin d'augmenter la demande de mémoire et la limite de mémoire pour le pod.

Suppression

La section suivante répertorie les problèmes courants liés aux opérations de suppression initiées par l'utilisateur qui peuvent entraîner des conflits avec Config Connector.

Suppression de l'espace de noms bloquée à l'état "Arrêt en cours"

Problème constaté

La suppression d'un espace de noms est bloquée à l'étape Terminating.

Cause

Ce problème peut se produire si Config Connector est installé en mode espace de noms et si l'objet ConfigConnectorContext de l'espace de noms a été supprimé avant que toutes les ressources Config Connector de cet espace de noms ne soient supprimées. Lorsque l'objet ConfigConnectorContext d'un espace de noms est supprimé, Config Connector est désactivé pour cet espace de noms, ce qui empêche la suppression des ressources Config Connector restantes dans cet espace de noms.

Solution

Pour résoudre ce problème, vous devez effectuer un nettoyage forcé, puis supprimer manuellement les ressources Google Cloud sous-jacentes.

Pour éviter ce problème à l'avenir, ne supprimez le ConfigConnectorContext qu'une fois que toutes les ressources Config Connector de son espace de noms ont été supprimées de Kubernetes. Évitez de supprimer des espaces de noms entiers avant que toutes les ressources Config Connector de cet espace de noms aient été supprimées, car le ConfigConnectorContext pourrait être supprimé en premier.

La suppression des ressources est bloquée sur "DeleteFailed" après la suppression du projet

Problème constaté

La suppression d'une ressource Config Connector échoue avec l'état DeleteFailed.

Cause

Ce problème peut se produire si un projet Google Cloud est supprimé avant la ressource.

Solution

Pour résoudre ce problème, restaurez le projet surGoogle Cloud afin de permettre à Config Connector de supprimer les ressources enfants restantes de Kubernetes. Vous pouvez également effectuer un nettoyage forcé.

Pour éviter ce problème à l'avenir, ne supprimez les projets Google Cloud qu'après avoir supprimé toutes leurs ressources Config Connector enfants de Kubernetes. Évitez de supprimer des espaces de noms entiers qui peuvent contenir à la fois une ressource Project et ses ressources Config Connector enfants, car la ressource Project peut être supprimée en premier.

Autorisations et authentification

La section suivante liste les problèmes courants liés aux autorisations et à l'authentification.

Métadonnées Compute Engine non définies

Problème constaté

L'état de votre ressource Config Connector est UpdateFailed et un message indique que les métadonnées Compute Engine ne sont pas définies, comme dans l'erreur suivante :

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
metadata: Compute Engine metadata "instance/service-accounts/default/token?
scopes=https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)compute%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSIN
G)auth%!F(MISSING)cloud-platform%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)cloud-identity%!C(MISSING)https%!A(MISSING)%!F(MISS
ING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)ndev.clouddns.readwrite%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSIN
G)devstorage.full_control%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)userinfo.email%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F
(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)drive.readonly" not
defined, detail:

Cause

Il est probable que le compte de service IAM utilisé par Config Connector n'existe pas.

Solution

Pour résoudre le problème, assurez-vous que le compte de service IAM utilisé par Config Connector existe.

Pour éviter ce problème à l'avenir, veillez à suivre les instructions d'installation de Config Connector.

Erreur 403 : La requête ne disposait pas d'un nombre suffisant de champs d'application d'authentification

Problème constaté

Votre ressource Config Connector présente l'état UpdateFailed avec un message indiquant une erreur 403 en raison de champs d'application d'authentification insuffisants, semblable à l'erreur suivante :

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner-instance": googleapi: Error 403: Request had
insufficient authentication scopes.

Cause

Il est probable que Workload Identity Federation for GKE ne soit pas activé sur votre cluster GKE.

Pour vérifier que Workload Identity Federation for GKE n'est pas activée, procédez comme suit :

  1. Enregistrez la configuration de pod suivante sous wi-test.yaml :

    apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
  namespace: cnrm-system
spec:
  containers:
  - image: google/cloud-sdk:slim
    name: workload-identity-test
    command: ["sleep","infinity"]
  serviceAccountName: cnrm-controller-manager

    Si vous avez installé Config Connector en mode espace de noms, serviceAccountName doit être cnrm-controller-manager-NAMESPACE. Remplacez NAMESPACE par l'espace de noms que vous avez utilisé lors de l'installation.

  2. Créez le pod dans votre cluster GKE :

    kubectl apply -f wi-test.yaml

  3. Ouvrez une session interactive dans le pod :

    kubectl exec -it workload-identity-test \
    --namespace cnrm-system \
    -- /bin/bash

  4. Affichez votre identité :

    gcloud auth list

  5. Vérifiez que l'identité listée correspond au compte de service Google lié à vos ressources.

    Si vous voyez le compte de service Compute Engine par défaut, cela signifie que la fédération d'identité de charge de travail pour GKE n'est pas activée sur votre cluster et/ou pool de nœuds GKE.

  6. Quittez la session interactive, puis supprimez le pod de votre cluster GKE :

    kubectl delete pod workload-identity-test \
    --namespace cnrm-system

Solution

Pour résoudre ce problème, assurez-vous que Workload Identity Federation for GKE est activée sur votre cluster.

Si la même erreur s'affiche toujours, assurez-vous d'avoir également activé la fédération d'identité de charge de travail pour GKE sur les pools de nœuds du cluster.

403 Interdit : l'appelant n'est pas autorisé

Problème constaté

La ressource Config Connector présente un état UpdateFailed avec un message indiquant une erreur 403 due à Workload Identity Federation for GKE, semblable à l'erreur suivante :

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
compute: Received 403 `Unable to generate access token; IAM returned 403
Forbidden: The caller does not have permission
This error could be caused by a missing IAM policy binding on the target IAM
service account.
For more information, refer to the Workload Identity documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

Cause

Le compte de service Kubernetes de Config Connector ne dispose pas des autorisations IAM appropriées pour emprunter l'identité de votre compte de service IAM en tant qu'utilisateur de Workload Identity Federation for GKE.

Solution

Pour résoudre le problème et l'éviter à l'avenir, consultez les instructions d'installation de Config Connector.

Erreur 403 : l'appelant ne dispose pas de l'autorisation IAM

Problème constaté

Votre ressource Config Connector présente l'état UpdateFailed avec un message indiquant qu'il manque une autorisation IAM à l'appelant, semblable à l'erreur suivante :

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": googleapi: Error 403: Caller is missing IAM
permission spanner.instances.get on resource
projects/my-project/instances/my-spanner-instance., detail:

Cause

Le compte de service IAM utilisé par Config Connector ne dispose pas de l'autorisation IAM indiquée dans le message, qui est nécessaire pour gérer la ressource Google Cloud .

Solution

Si vous voyez toujours la même erreur après avoir accordé les autorisations IAM appropriées à votre compte de service IAM, vérifiez que votre ressource est créée dans le bon projet. Vérifiez le champ spec.projectRef de la ressource Config Connector (ou son annotation cnrm.cloud.google.com/project-id si la ressource n'est pas compatible avec un champ spec.projectRef) et vérifiez que la ressource fait référence au bon projet. Notez que Config Connector utilise le nom de l'espace de noms comme ID de projet si ni la ressource, ni l'espace de noms ne spécifient de projet cible. Découvrez comment configurer le projet cible pour les ressources à l'échelle du projet.

Si l'erreur persiste, vérifiez si Workload Identity Federation pour GKE est activé sur votre cluster GKE.

Pour éviter ce problème à l'avenir, veillez à suivre les instructions d'installation de Config Connector.

Erreur de mise à jour avec IAMPolicy, IAMPartialPolicy et IAMPolicyMember

Problème constaté

L'état UpdateFailed s'affiche avec un message d'erreur indiquant une erreur 400, car le compte de service n'existe pas :

Update call failed: error setting policy member: error applying changes: summary: Request `Create IAM Members roles/[MYROLE] serviceAccount:[NAME]@[PROJECT_ID].iam.gserviceaccount.com for project \"projects/[PROJECT_ID]\"` returned error: Error applying IAM policy for project \"projects/[PROJECT_ID]\": Error setting IAM policy for project \"projects/[PROJECT_ID]\": googleapi: Error 400: Service account [NAME]@[PROJECT_ID].iam.gserviceaccount.com does not exist., badRequest

Cause

Si vous supprimez une ressource Config Connector IAMServiceAccount avant de nettoyer les ressources IAMPolicy, IAMPartialPolicy et IAMPolicyMember qui dépendent de ce compte de service, Config Connector ne pourra pas localiser le compte de service référencé dans ces ressources IAM lors du rapprochement.

Solution

Pour résoudre ce problème, vérifiez vos comptes de service et déterminez si le compte de service requis pour ces ressources IAM a été supprimé. Si le compte de service est supprimé, nettoyez également les ressources Config Connector IAM associées. Pour IAMPolicyMember, supprimez l'intégralité de la ressource. Pour IAMPolicy et IAMParitialPolicy, ne supprimez que les liaisons qui impliquent le compte de service supprimé. Toutefois, ce nettoyage ne supprime pas immédiatement les liaisons de rôleGoogle Cloud . Les liaisons de rôle Google Cloud sont conservées pendant 60 jours en raison de la conservation du compte de service supprimé. Pour en savoir plus, consultez la documentation IAM sur la suppression d'un compte de service. Google Cloud

Pour éviter ce problème, vous devez toujours nettoyer les ressources Config Connector IAMPolicy, IAMPartialPolicy et IAMPolicyMember avant de supprimer la ressource IAMServiceAccount référencée.

La ressource ServiceIdentity échoue avec Invalid service producer

Problème constaté

L'état de votre ressource ServiceIdentity est UpdateFailed, avec un message d'erreur semblable à ce qui suit :

Update call failed: error applying desired state: summary: Error creating Service Identity: Invalid service producer: ...

Cause

Cette erreur signifie que la ressource spécifiée n'est pas compatible avec la création d'identité de service à la demande.

Solution

La ressource ServiceIdentity ne peut générer des identités de service que pour les services compatibles. Pour vérifier si un service accepte la création d'identité de service à la demande avant d'appliquer votre configuration, exécutez la commande suivante :

gcloud beta services identity create --service SERVICE_NAME.googleapis.com

Remplacez SERVICE_NAME par le nom du service, par exemple spanner.

Si la commande aboutit, Config Connector peut créer une identité pour ce service. Si la commande échoue, cela signifie que Config Connector ne peut pas créer d'identité pour ce service.

Installation et mises à niveau

La section suivante répertorie les problèmes courants liés à l'installation ou à la mise à niveau de la version de Config Connector.

Version non compatible avec les installations du module complémentaire Config Connector

Problème constaté

Si vous ne parvenez pas à activer le module complémentaire Config Connector, le message d'erreur suivant s'affiche : Node version 1.15.x-gke.x s unsupported.

Le message d'erreur s'affiche également si la fédération d'identité de charge de travail pour GKE ou GKE Monitoring sont désactivés.

Cause

La version du cluster GKE ne répond pas aux exigences ou les fonctionnalités requises sont désactivées.

Solution

Pour résoudre cette erreur, vérifiez que la version du cluster GKE répond aux exigences de version et de fonctionnalité. Assurez-vous que Workload Identity Federation for GKE et GKE Monitoring sont activés.

Pour obtenir toutes les versions valides de vos clusters, exécutez la commande suivante :

gcloud container get-server-config --format "yaml(validMasterVersions)" \
    --zone ZONE

Remplacez ZONE par la zone Compute Engine.

Choisissez une version répondant aux exigences dans la liste.

failed calling webhook

Problème constaté

Vous ne pouvez pas désinstaller Config Connector et vous recevez une erreur semblable à celle-ci :

error during reconciliation: error building deployment objects: error finalizing the deletion of Config Connector system components deployed by ConfigConnector controller: error waiting for CRDs to be deleted: error deleting CRD accesscontextmanageraccesslevels.accesscontextmanager.cnrm.cloud.google.com: Internal error occurred: failed calling webhook "abandon-on-uninstall.cnrm.cloud.google.com": failed to call webhook: Post "https://abandon-on-uninstall.cnrm-system.svc:443/abandon-on-uninstall?timeout=3s": service "abandon-on-uninstall" not found

Cause

Ce problème peut se produire lorsque vous utilisez le module complémentaire Config Connector et que vous désactivez Config Connector avant de supprimer les CRD Config Connector.

Solution

Pour résoudre cette erreur, vous devez d'abord supprimer manuellement les Webhooks :

kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

Vous pouvez ensuite désinstaller Config Connector.

PodSecurityPolicy empêche les mises à niveau

Problème constaté

Après être passé du module complémentaire Config Connector à une installation manuelle et avoir mis à niveau Config Connector vers une nouvelle version, les pods cnrm ne parviennent pas à se mettre à jour.

Cause

L'utilisation de PodSecurityPolicies peut empêcher la mise à jour des pods cnrm.

Pour confirmer que les PodSecurityPolicies empêchent la mise à niveau, vérifiez les événements de config-connector-operator et recherchez une erreur semblable à celle-ci :

create Pod configconnector-operator-0 in StatefulSet configconnector-operator failed error: pods "configconnector-operator-0" is forbidden: PodSecurityPolicy: unable to admit pod: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: Forbidden: seccomp may not be set]

Solution

Pour résoudre ce problème, vous devez spécifier l'annotation sur la PodSecurityPolicy qui correspond à l'annotation mentionnée dans l'erreur. Dans l'exemple précédent, l'annotation est seccomp.security.alpha.kubernetes.io.

Configuration

La section suivante répertorie les problèmes courants liés à la configuration des ressources.

Impossible de modifier des champs immuables

Config Connector rejette les mises à jour des champs immuables au moment de l'admission.

Par exemple, la mise à jour d'un champ immuable avec kubectl apply entraîne l'échec immédiat de la commande.

Cela signifie que les outils qui réappliquent continuellement des ressources (par exemple, GitOps) peuvent se retrouver bloqués lors de la mise à jour d'une ressource s'ils ne gèrent pas les erreurs d'admission.

Étant donné que Config Connector n'autorise pas les mises à jour des champs immuables, la seule façon d'effectuer une telle mise à jour consiste à supprimer et à recréer la ressource.

Erreur lors de la mise à jour des champs immuables en l'absence de mise à jour

Les erreurs suivantes peuvent s'afficher dans l'état de la ressource Config Connector peu de temps après la création ou l'acquisition d'une ressource Google Cloud à l'aide de Config Connector :

  • Update call failed: error applying desired state: infeasible update: ({true \<nil\>}) would require recreation (exemple)

  • Update call failed: cannot make changes to immutable field(s) (exemple)

Cela ne signifie pas forcément que vous avez réellement mis à jour la ressource. La raison peut être que l'API Google Cloud a modifié un champ immuable que vous gériez dans la ressource Config Connector. Cela a entraîné une incohérence entre l'état souhaité et l'état réel des champs immuables.

Pour résoudre le problème, vous pouvez modifier les valeurs de ces champs immuables dans la ressource Config Connector afin qu'elles correspondent à l'état actuel. Pour ce faire, procédez comme suit :

  1. Mettez à jour la configuration YAML de la ressource Config Connector et définissez l'annotation cnrm.cloud.google.com/deletion-policy sur abandon.
  2. Appliquez la configuration YAML mise à jour pour modifier la règle de suppression de la ressource Config Connector.
  3. Abandonnez la ressource Config Connector.
  4. Imprimez l'état actuel de la ressource Google Cloud correspondante à l'aide de gcloud CLI.
  5. Recherchez l'incohérence entre la sortie de gcloud CLI et la configuration YAML de la ressource Config Connector, puis mettez à jour ces champs dans la configuration YAML.
  6. Appliquez la configuration YAML mise à jour pour acquérir la ressource abandonnée.

Aucune correspondance pour le genre "Foo"

Problème constaté

L'erreur No matches for kind "Foo" s'affiche.

Cause

La CRD pour le type de ressource Foo n'est pas installée sur votre cluster Kubernetes.

Solution

Vérifiez que le type est un type de ressource compatible avec Config Connector.

Si le genre est compatible, cela signifie que votre installation de Config Connector est obsolète ou non valide.

Si vous avez installé Config Connector à l'aide du module complémentaire GKE, votre installation devrait être mise à niveau automatiquement. Si vous avez installé Config Connector manuellement, vous devez effectuer une mise à niveau manuelle.

Consultez le dépôt GitHub pour déterminer quels types de ressources sont compatibles avec quelles versions de Config Connector (par exemple, voici les types compatibles avec Config Connector v1.44.0).

Les libellés ne sont pas propagés à la ressource Google Cloud .

Problème constaté

Les libellés de votre fichier YAML ne s'affichent pas sur la ressource Google Cloud .

Cause

Les libellés ne sont pas compatibles avec toutes les ressources Google Cloud .

Solution

Config Connector propage les étiquettes trouvées dans metadata.labels vers la ressourceGoogle Cloud sous-jacente. Consultez la documentation de l'API REST de la ressource (par exemple, la documentation de l'API pour PubSubTopic) pour voir si elle accepte les libellés.

Erreur due à des caractères spéciaux dans le nom de la ressource

Problème constaté

Vous voyez une erreur liée à des caractères non valides dans metadata.name :

a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Cause

Les caractères spéciaux ne sont pas valides dans le champ metadata.name de Kubernetes.

Solution

Si vous souhaitez attribuer à votre ressource un nom qui n'est pas un nom Kubernetes valide, mais qui est un nom de ressource Google Cloud valide, vous pouvez utiliser le champ resourceID, comme illustré dans l'exemple suivant :

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: 'test'
spec:
  instanceRef:
    name: sqlinstance-sample-postgresql
  host: "%"
  type: CLOUD_IAM_USER
  resourceID: test.example@example-project.iam

Cette configuration entraîne l'utilisation de resourceID par Config Connector au lieu de metadata.name comme nom de la ressource.

Impossible de supprimer des champs de la spécification de la ressource

Problème constaté

La suppression d'un champ de la spécification d'une ressource Config Connector ne le supprime pas de la ressource.

Cause

Si vous supprimez un champ de la spécification d'une ressource gérée par Config Connector, ce champ ne devient pas vide et ne revient pas à une valeur par défaut. Au lieu de cela, ce champ devient géré en externe.

Solution

Si vous souhaitez remplacer la valeur d'un champ par une valeur vide ou par défaut dans la ressourceGoogle Cloud sous-jacente, vous devez définir la valeur du champ sur zéro dans la spécification de la ressource Config Connector :

  • Pour un champ de type liste, définissez-le sur une liste vide à l'aide de [].

    L'exemple suivant montre le champ targetServiceAccounts que nous voulons supprimer :

    spec:
  targetServiceAccounts:
    - external: "foo-bar@foo-project.iam.gserviceaccount.com"
    - external: "bar@foo-project.iam.gserviceaccount.com"

    Pour supprimer ce champ, définissez la valeur sur "vide" :

    spec:
  targetServiceAccounts: []

  • Pour un champ de type primitif, définissez-le sur "vide" en utilisant l'une des méthodes suivantes :

    Type Valeur vide
    string ""
    Bool "false"
    entier 0

    L'exemple suivant montre le champ identityNamespace que nous voulons supprimer :

    spec:
  workloadIdentityConfig:
    identityNamespace: "foo-project.svc.id.goog"

    Pour supprimer ce champ, définissez la valeur sur "vide" :

    spec:
  workloadIdentityConfig:
    identityNamespace: ""

  • Pour les champs de type objet, vous pouvez essayer de définir les sous-champs du type objet comme vides ou par défaut en suivant les instructions de la section précédente, puis vérifier si cela fonctionne. Toutefois, cela ne garantit pas que le problème sera résolu.

Valeur "merge" non valide pour l'annotation state-into-spec

Ce problème se produit lorsqu'une ressource utilise l'annotation cnrm.cloud.google.com/state-into-spec: merge, mais que le type de ressource ou la version de Config Connector rejette la valeur merge.

Problème constaté

Le rapprochement de votre ressource Config Connector échoue avec un message d'erreur semblable à celui-ci :

Update call failed: error applying desired state: invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation

Cause

Cette erreur se produit pour l'une des raisons suivantes :

  • Le type de ressource n'est pas compatible avec le comportement Merge, mais la ressource comporte l'annotation cnrm.cloud.google.com/state-into-spec: merge. Cette annotation peut être définie directement sur la ressource ou héritée du paramètre spec.stateIntoSpec: Merge dans votre CR ConfigConnector ou ConfigConnectorContext. Les CRD ajoutées dans Config Connector version 1.114.0 et ultérieures ne sont compatibles qu'avec le comportement Absent.
  • Vous avez effectué la mise à niveau vers Config Connector version 1.134.0 ou 1.134.1 et vous disposez d'une ressource SQLInstance existante qui comportait l'annotation cnrm.cloud.google.com/state-into-spec: merge par défaut à partir d'une version antérieure. Les versions 1.134.0 et 1.134.1 présentaient un problème connu qui rejetait la valeur merge sur les ressources SQLInstance.

Solution

Pour résoudre ce problème, suivez les étapes correspondant à votre situation :

  • Votre type de ressource n'est pas compatible avec le comportement Merge : définissez l'annotation cnrm.cloud.google.com/state-into-spec: absent dans le fichier manifeste YAML de votre ressource et définissez le champ spec.stateIntoSpec sur Absent dans votre CR ConfigConnector ou ConfigConnectorContext. Pour vérifier si votre genre de ressource est compatible avec le comportement Merge, consultez Genres compatibles avec Merge. Si l'annotation est déjà présente sur une ressource existante du cluster, suivez la procédure décrite dans Migrer des ressources de Merge vers Absent.
  • Vous utilisez une ressource SQLInstance existante dans Config Connector version 1.134.0 ou 1.134.1 : mettez à niveau Config Connector vers la version 1.134.2 ou ultérieure. Vous pouvez également migrer la ressource SQLInstance vers l'annotation cnrm.cloud.google.com/state-into-spec: absent en suivant les étapes décrites dans Migrer des ressources de Merge vers Absent.

Échec du démarrage de Config Connector sur les nœuds Arm

Si votre cluster contient des pools de nœuds utilisant l'architecture Arm (comme les séries de machines C4A, N4A ou Tau T2A), il est possible que les composants Config Connector ne s'exécutent pas. Il s'agit d'une limitation connue, car Config Connector n'est pas compatible avec les systèmes basés sur Arm.

Symptômes

Si votre instance Config Connector est concernée par ce problème, vous pouvez rencontrer les symptômes suivants :

  • Les pods de l'espace de noms cnrm-system restent à l'état Pending.
  • Les pods peuvent afficher un CrashLoopBackOff avec un message d'erreur dans les journaux semblable à : exec user process caused "exec format error".
  • La description du pod révèle des échecs de planification ou des incompatibilités d'architecture.

Solution

Pour résoudre ce problème, assurez-vous que les composants Config Connector sont planifiés sur des nœuds avec une architecture x86 :

  • Ajoutez un pool de nœuds x86 : si votre cluster ne contient que des nœuds Arm, ajoutez au moins un pool de nœuds utilisant un type de machine x86 (tel que e2-standard-2) pour héberger les pods du contrôleur Config Connector.
  • Vérifiez les rejets de nœuds : les nœuds GKE Arm sont généralement rejetés avec kubernetes.io/arch=arm64:NoSchedule pour empêcher la planification de charges de travail x86 uniquement sur ces nœuds. Assurez-vous de ne pas avoir ajouté de tolérances aux déploiements Config Connector qui leur permettraient de s'exécuter sur ces nœuds.

Nettoyage forcé

Si vos ressources Config Connector sont bloquées lors de la suppression et que vous souhaitez simplement les supprimer de votre cluster Kubernetes, vous pouvez forcer leur suppression en supprimant leurs finaliseurs.

Vous pouvez supprimer les finaliseurs d'une ressource en la modifiant à l'aide de kubectl edit, en supprimant le champ metadata.finalizers, puis en enregistrant le fichier pour conserver vos modifications sur le serveur d'API Kubernetes.

Étant donné que la suppression des finalizers d'une ressource permet de supprimer immédiatement la ressource du cluster Kubernetes, il est possible (mais pas certain) que Config Connector n'ait pas la possibilité de terminer la suppression de la ressourceGoogle Cloud sous-jacente. Cela signifie que vous devrez peut-être supprimer manuellement vos ressources Google Cloud par la suite.

Surveillance

La surveillance de Config Connector et l'exploration de ses journaux peuvent vous aider à déterminer la source des problèmes et à mieux comprendre tout comportement inattendu.

Métriques

Vous pouvez utiliser Prometheus pour collecter et afficher les métriques de Config Connector.

Journalisation

Tous les pods Config Connector génèrent des journaux structurés au format JSON.

Les journaux des pods de contrôleur sont particulièrement utiles pour déboguer les problèmes liés à la réconciliation des ressources.

Vous pouvez interroger les journaux pour des ressources spécifiques en filtrant les champs suivants dans les messages de journal :

  • logger : contient le type de ressource en minuscules. Par exemple, les ressources PubSubTopic ont un logger de pubsubtopic-controller.
  • resource.namespace : contient l'espace de noms de la ressource.
  • resource.name : contient le nom de la ressource.

Utiliser la journalisation pour interroger les journaux de manière avancée

Si vous utilisez GKE, vous pouvez utiliser Cloud Logging pour interroger les journaux d'une ressource spécifique à l'aide de la requête suivante :

# Filter to include only logs coming from the controller Pods
resource.type="k8s_container"
resource.labels.container_name="manager"
resource.labels.namespace_name="cnrm-system"
labels.k8s-pod/cnrm_cloud_google_com/component="cnrm-controller-manager"

# Filter to include only logs coming from a particular GKE cluster
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.location="GKE_CLUSTER_LOCATION"

# Filter to include only logs for a particular Config Connector resource
jsonPayload.logger="RESOURCE_KIND-controller"
jsonPayload.resource.namespace="RESOURCE_NAMESPACE"
jsonPayload.resource.name="RESOURCE_NAME"

Remplacez les éléments suivants :

  • GKE_CLUSTER_NAME par le nom du cluster GKE exécutant Config Connector
  • GKE_CLUSTER_LOCATION avec l'emplacement du cluster GKE exécutant Config Connector. Exemple :us-central1
  • RESOURCE_KIND par le type de ressource en minuscules. Par exemple, pubsubtopic.
  • RESOURCE_NAMESPACE par l'espace de noms de la ressource.
  • RESOURCE_NAME par le nom de la ressource.

Aide supplémentaire

Pour obtenir de l'aide supplémentaire, vous pouvez signaler un problème sur GitHub ou contacter l'assistanceGoogle Cloud .