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 et les problèmes courants que vous pouvez rencontrer lors de l'utilisation du produit.

Techniques de dépannage de base

Vérifier la version de Config Connector

Exécutez la commande suivante pour obtenir la version installée de Config Connector, puis comparez 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 règle générale, vous pouvez déterminer 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 si 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 à l'état 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 chargé de gérer les ressources Config Connector dans cet espace de noms.

Vous pouvez vérifier l'état du pod de 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 de contrôleur consigne des informations et des erreurs liées au rapprochement des ressources de Config Connector.

Vous pouvez consulter les journaux du pod de 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ôleurs combinés. Pour rechercher un espace de noms spécifique dans les journaux du pod du contrôleur, exécutez 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, puis acquérir la ressource:

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

Problèmes courants

La ressource se met à jour toutes les 5 à 15 minutes.

Si votre ressource Config Connector passe de l'état UpToDate à l'état Updating toutes les 5 à 10 minutes, 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 oblige Config Connector à mettre à jour la ressource en permanence.

Tout d'abord, vérifiez que vous ne disposez d'aucun système externe qui modifie constamment le connecteur Config Connector ou la ressource Google Cloud (par exemple, pipelines CI/CD, contrôleurs personnalisés, tâches 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 casse) 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 en conséquence. Recherchez en particulier les valeurs qui ont été reformatées par Google Cloud. Par exemple, consultez les problèmes GitHub #578 et #294.

Notez qu'il ne s'agit pas d'une méthode parfaite, car les modèles de ressources Config Connector et Google Cloud sont différents, mais elle devrait vous permettre d'identifier la plupart des cas de différences inattendues.

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

Suppressions d'espaces de noms bloquées sur "Arrêt"

Les suppressions d'espaces de noms peuvent rester bloquées sur Terminating si Config Connector est installé en mode espace de noms et si le ConfigConnectorContext de l'espace de noms a été supprimé avant que toutes les ressources de Config Connector de cet espace de noms ne soient supprimées. Lorsque le 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.

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

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

Découvrez également comment la suppression d'un espace de noms contenant un projet et ses enfants ou un dossier et ses enfants peut être bloquée.

Suppressions de ressources bloquées sur "DeleteFailed" après la suppression du projet

Les suppressions de ressources Config Connector peuvent rester bloquées sur DeleteFailed si leur projet Google Cloud a été supprimé préalablement.

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

Pour atténuer ce problème à l'avenir, ne supprimez les projets Google Cloud qu'une fois que toutes leurs ressources Config Connector enfants ont été supprimées de Kubernetes. Évitez de supprimer des espaces de noms entiers susceptibles de contenir à la fois une ressource Project et ses ressources Config Connector enfants, car la ressource Project peut être supprimée en premier.

Métadonnées Compute Engine non définies

Si votre ressource Config Connector est à l'état UpdateFailed et qu'un message indique que les métadonnées Compute Engine ne sont pas définies, cela signifie probablement que le compte de service IAM utilisé par Config Connector n'existe pas.

Exemple de message UpdateFailed:

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:

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

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

Erreur 403: les champs d'application d'authentification de la requête étaient insuffisants

Si votre ressource Config Connector est à l'état UpdateFailed et qu'un message indique une erreur 403 en raison de champs d'application d'authentification insuffisants, cela signifie probablement que Workload Identity n'est pas activé sur votre cluster GKE.

Exemple de message UpdateFailed:

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.

Pour examiner le problème, 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é répertoriée correspond au compte de service Google lié à vos ressources.

    Si le compte de service Compute Engine par défaut s'affiche à la place, cela signifie que Workload Identity n'est pas activé sur votre cluster GKE et/ou votre pool de nœuds.

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

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

Pour résoudre ce problème, utilisez un cluster GKE sur lequel Workload Identity est activé.

Si vous rencontrez toujours la même erreur sur un cluster GKE avec Workload Identity activé, assurez-vous de ne pas oublier d'activer également Workload Identity sur les pools de nœuds du cluster. En savoir plus sur l'activation de Workload Identity sur des pools de nœuds existants Nous vous recommandons d'activer Workload Identity sur tous les pools de nœuds de votre cluster, car Config Connector peut s'exécuter sur n'importe lequel d'entre eux.

403 Interdit: l'appelant ne dispose pas des autorisations nécessaires ; consultez la documentation Workload Identity

Si votre ressource Config Connector est à l'état UpdateFailed avec un message indiquant une erreur 403 en raison de Workload Identity, cela signifie probablement que le compte de service Kubernetes de Config Connector ne dispose pas des autorisations IAM appropriées pour usurper votre compte de service IAM en tant qu'utilisateur Workload Identity.

Exemple de message UpdateFailed:

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

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

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

Si votre ressource Config Connector est à l'état UpdateFailed avec un message indiquant que l'appelant ne dispose pas d'une autorisation IAM, cela signifie probablement que le compte de service IAM utilisé par Config Connector ne dispose pas de l'autorisation IAM indiquée dans le message nécessaire pour gérer la ressource Google Cloud.

Exemple de message UpdateFailed:

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:

Si vous rencontrez toujours la même erreur après avoir attribué les autorisations IAM appropriées à votre compte de service IAM, vérifiez que votre ressource est créée dans le projet approprié. Vérifiez le champ spec.projectRef de la ressource Config Connector (ou son annotation cnrm.cloud.google.com/project-id si la ressource n'accepte pas 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 un projet cible. Découvrez comment configurer le projet cible pour les ressources à l'échelle du projet.

Si vous rencontrez toujours la même erreur, vérifiez si Workload Identity est activé sur votre cluster GKE.

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

Version non compatible avec les installations de modules complémentaires Config Connector

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. Pour résoudre cette erreur, vérifiez que la version du cluster GKE répond aux exigences concernant la version et les fonctionnalité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.

Le message d'erreur s'affiche également si Workload Identity ou GKE Monitoring sont désactivés. Assurez-vous que ces fonctionnalités sont activées pour corriger l'erreur.

Impossible de modifier des champs immuables

Config Connector refuse les mises à jour de champs immuables lors 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 des ressources en continu (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 la mise à jour des champs immuables, le seul moyen d'effectuer une telle mise à jour consiste à supprimer et à recréer la ressource.

Erreur lors de la mise à jour des champs immuables lorsqu'il n'y a pas de mise à jour

Les erreurs suivantes peuvent s'afficher dans l'état de la ressource Config Connector peu 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 peut-être pas que vous avez mis à jour la ressource, mais il est possible que l'API Google Cloud ait modifié un champ immuable que vous gérez dans la ressource Config Connector. Cela entraînait une incohérence entre l'état souhaité et l'état actif des champs immuables.

Vous pouvez résoudre le problème en mettant à jour les valeurs de ces champs immuables dans la ressource Config Connector pour 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 mettre à jour 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 la différence entre la sortie de la 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.

La ressource n'a pas d'état

Si vos ressources ne comportent pas de champ status, il est probable que Config Connector ne fonctionne pas correctement. Vérifiez que Config Connector est en cours d'exécution.

Aucun résultat pour le genre "Foo"

Lorsque cette erreur se produit, cela signifie que l'objet CRD du genre de ressource Foo n'est pas installé sur votre cluster Kubernetes.

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

Si le genre est compatible, cela signifie que votre installation 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 les genres de ressources compatibles avec les versions de Config Connector (par exemple, voici les genres compatibles avec la version 1.44.0 de Config Connector).

Les étiquettes ne sont pas propagées vers la ressource Google Cloud

Config Connector propage les étiquettes trouvées dans metadata.labels vers la ressource Google Cloud sous-jacente. Notez toutefois que toutes les ressources Google Cloud ne sont pas compatibles avec les libellés. Consultez la documentation de l'API REST de la ressource (par exemple, voici la documentation de l'API pour PubSubTopic) pour savoir si elles sont compatibles avec les libellés.

Échec de l'appel du webhook x509: le certificat repose sur l'ancien champ de nom commun

Si vous rencontrez une erreur semblable à l'exemple suivant, 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

Pour contourner ce problème, supprimez les pods et les certificats 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é est à nouveau généré.

Pour en savoir plus sur cette erreur, consultez le problème GitHub.

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

Les caractères spéciaux ne sont pas valides dans le champ metadata.name de Kubernetes. Si une erreur semblable à l'exemple suivant s'affiche, le metadata.name de la ressource comporte probablement une valeur comportant des caractères spéciaux:

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])?)*')

Par exemple, la ressource SQLUser suivante contient un caractère non valide dans metadata.name:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: [email protected]
spec:
  instanceRef:
    name: test-cloudsql-db
  type: "CLOUD_IAM_USER"

Si vous essayez de créer cette ressource, vous obtenez l'erreur suivante:

Error from server (Invalid): error when creating "sqlusercrd.yaml": SQLUser.sql.cnrm.cloud.google.com "[email protected]" is invalid: metadata.name: Invalid value: "[email protected]": 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])?)*')

Si vous souhaitez attribuer à votre ressource un nom qui n'est pas un nom Kubernetes valide, mais qui correspond à un nom de ressource Google Cloud valide, vous pouvez utiliser le champ resourceID, comme indiqué 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: [email protected]

Cette configuration oblige Config Connector à utiliser resourceID au lieu de metadata.name comme nom de ressource.

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

La suppression d'un champ de la spécification d'une ressource Config Connector (en mettant à jour le fichier .yaml de la ressource et en l'appliquant de nouveau, ou en utilisant kubectl edit pour modifier la spécification de la ressource) ne supprime pas réellement ce champ de la spécification de la ressource Config Connector ou de la ressource Google Cloud sous-jacente. À la place, la suppression d'un champ de la spécification le rend géré en externe.

Si vous souhaitez que la valeur d'un champ soit vide ou définie par défaut dans la ressource Google Cloud sous-jacente, vous devez mettre à zéro le champ dans la spécification de la ressource Config Connector:

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

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

    spec:
  targetServiceAccounts:
    - external: "[email protected]"
    - external: "[email protected]"

    Pour supprimer ce champ, laissez la valeur vide:

    spec:
  targetServiceAccounts: []

  • Définissez le champ de type primitif sur vide à l'aide de l'une des méthodes suivantes:

    Type Valeur vide
    chaîne ""
    bool "faux"
    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, laissez la valeur vide:

    spec:
  workloadIdentityConfig:
    identityNamespace: ""

  • Pour les champs de type d'objet, il n'existe actuellement aucun moyen simple de définir un champ de type d'objet entier dans Config Connector sur "NULL". Vous pouvez essayer de définir les sous-champs du type d'objet comme vides ou par défaut en suivant les instructions ci-dessus et vérifier qu'ils fonctionnent.

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

Si vous utilisez Config Sync et que des erreurs KNV2005 s'affichent pour les ressources de Config Connector, il est probable que Config Sync et Config Connector soient en conflit.

Exemple de message de journal:

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

Config Sync et Config Connector sont dits "en conflit" sur une ressource s'ils continuent à mettre à jour les mêmes champs avec des valeurs différentes. L'une d'elles déclenche l'action et la mise à jour de la ressource par l'autre, ce qui amène l'autre à agir et à mettre à jour la ressource, et ainsi de suite.

Dans la plupart des domaines, la lutte n'est pas un problème. Les champs spécifiés dans Config Sync ne sont pas modifiés par Config Connector, tandis que les champs qui ne sont pas spécifiés dans Config Sync et 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 doivent jamais mettre à jour le même champ avec des valeurs différentes.

Il existe une exception: les champs de liste. De la même manière que Config Connector peut définir des sous-champs dans les champs d'objet par défaut, Config Connector peut également définir des sous-champs par défaut dans les objets de listes. Toutefois, étant donné que les champs de liste dans les ressources Config Connector sont atomiques, la définition par défaut des sous-champs est considérée comme une modification complète de la valeur de la liste.

Par conséquent, Config Sync et Config Connector se disputeront si Config Sync définit un champ de liste et que Config Connector utilise par défaut tous les sous-champs de cette liste.

Pour contourner ce problème, vous disposez des options suivantes:

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

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

  2. Arrêtez 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. Arrêtez 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

failed calling webhook

Il est possible que Config Connector se trouve dans un état qui vous empêche de désinstaller Config Connector. Cela se produit généralement lorsque vous utilisez le module complémentaire Config Connector et que vous désactivez Config Connector avant de supprimer les CRD Config Connector. Lorsque vous essayez de désinstaller l'application, un message d'erreur semblable à celui-ci s'affiche:

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

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.

Erreur de mise à jour avec IAMPolicy, IAMPartialPolicy et IAMPolicyMember

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 peut pas localiser le compte de service référencé dans ces ressources IAM lors du rapprochement. L'état UpdateFailed est alors renvoyé avec un message d'erreur semblable à celui-ci:

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

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

Pour éviter ce problème, vous devez toujours nettoyer les ressources IAMPolicy, IAMPartialPolicy etIAMPolicyMember Config Connector avant de supprimer les IAMServiceAccount référencés.

Ressource supprimée par Config Connector

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 configuration tels qu'Argo CD ou l'utilisation d'un client API personnalisé peut entraîner la suppression de ressources.

On croit souvent à tort 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 à partir de messages de journal de conteneurs ou de journaux d'audit de cluster Kubernetes. Ces requêtes de suppression sont le résultat de déclencheurs externes et Config Connector tente de les rapprocher.

Pour déterminer pourquoi une ressource a été supprimée, vous devez examiner la première requête de suppression envoyée à la ressource correspondante. Le meilleur moyen d'examiner ce problème est d'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 requêtes de suppression initiales d'une ressource BigQueryDataset nommée foo dans l'espace de noms bar, exécutez une requête semblable à celle-ci:

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, recherchez la première requête de suppression, puis vérifiez l'élément authenticationInfo.principalEmail de ce message de journal de suppression pour déterminer la cause de la suppression.

Capsule du contrôleur hors connexion

Si une erreur "OOMKilled" s'affiche sur un pod de contrôleur Config Connector, cela signifie qu'un conteneur ou l'ensemble du pod ont été arrêtés, car ils ont utilisé plus de mémoire que ne le permet. Vous pouvez le vérifier en exécutant la commande kubectl describe. L'état du pod peut être OOMKilled ou Terminating. De plus, l'examen des journaux d'événements du pod peut révéler toute occurrence d'événements OOM.

kubectl describe pod POD_NAME -n cnrm-system

Remplacez POD_NAME par le pod que vous dépannez.

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

PodSecurityPolicy empêche les mises à niveau

Après avoir passé du module complémentaire Config Connector à une installation manuelle et mis à niveau Config Connector vers une nouvelle version, l'utilisation de règles PodSecurityPolicies peut empêcher la mise à jour des pods cnrm.

Pour vérifier que les règles PodSecurityPolicy empêchent votre mise à niveau, vérifiez les événements de config-connector-operator et recherchez une erreur semblable à la suivante:

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]

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

Nettoyage forcé

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

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

Étant donné que la suppression des finalisateurs d'une ressource permet de supprimer immédiatement la ressource du cluster Kubernetes, Config Connector peut (mais pas nécessairement) ne pas avoir la possibilité d'effectuer la suppression de la ressource Google Cloud sous-jacente. Cela signifie que vous devrez peut-être supprimer manuellement vos ressources Google Cloud par la suite.

Surveillance

de régression

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 du contrôleur sont particulièrement utiles pour résoudre les problèmes de rapprochement des ressources.

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

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

Utiliser Cloud Logging pour l'interrogation avancée des journaux

Si vous utilisez GKE, vous pouvez utiliser Cloud Logging pour rechercher 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 par l'emplacement du cluster GKE exécutant Config Connector. Exemple :us-central1
  • RESOURCE_KIND par le genre de la ressource en minuscules ; 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 une aide supplémentaire, vous pouvez signaler un problème sur GitHub ou contacter l'assistance Google Cloud.