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 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 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. Vérifier l'état et les é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 la réconciliation a échoué.
Vérifier que Config Connector est en cours d'exécution
Pour vérifier que Config Connector s'exécute, 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 chargé de gérer les 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:
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 des informations et des erreurs liées à la mise en correspondance 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. Étant donné que vous ne pouvez pas modifier les champs immuables, vous devez abandonner, puis acquérir la ressource:
- Mettez à jour la configuration YAML de la ressource Config Connector et définissez l'annotation
cnrm.cloud.google.com/deletion-policysurabandon. - Appliquez la configuration YAML mise à jour pour mettre à jour la règle de suppression de la ressource Config Connector.
- Abandonnez la ressource Config Connector.
- Modifiez les champs immuables qui doivent être modifiés dans la configuration YAML.
- Appliquez la configuration YAML mise à jour pour acquérir la ressource abandonnée.
Problèmes courants
La ressource continue de s'actualiser toutes les 5 à 15 minutes
Si votre ressource Config Connector passe constamment d'un état UpToDate à un état Updating toutes les 5 à 10 minutes, il est probable que Config Connector détecte des différences involontaires entre l'état souhaité de la ressource et son état réel, ce qui entraîne la mise à jour constante de la ressource.
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 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 capitalisation) des valeurs de champ, ce qui entraîne une différence entre l'état souhaité de votre ressource et son état réel.
Obtenez l'état de la ressource Google Cloud à l'aide de l'API REST (par exemple, pour ContainerCluster) ou de la CLI Google Cloud. Comparez ensuite 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é mises en forme 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 sont différents pour Config Connector etGoogle Cloud , 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.
Suppression d'espaces de noms bloquée à l'état "Arrêt en cours"
La suppression d'espaces de noms peut se bloquer à Terminating si Config Connector est installé en mode espace de noms et si l'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'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 atténuer ce problème à l'avenir, ne supprimez le ConfigConnectorContext qu'après avoir supprimé toutes les ressources Config Connector de son espace de noms 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 ConfigConnectorContext risque d'ê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 se bloquer.
Suppression des ressources bloquée sur "DeleteFailed" après la suppression du projet
La suppression des ressources Config Connector peut se bloquer à DeleteFailed si leur projet Google Cloud a été supprimé au préalable.
Pour résoudre ce problème, restaurez le projet surGoogle Cloud pour 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'après avoir supprimé toutes leurs ressources Config Connector enfants de Kubernetes. Évitez de supprimer des espaces de noms entiers pouvant contenir à la fois une ressource Project et ses ressources Config Connector enfants, car la ressource Project risque d'être supprimée en premier.
Métadonnées Compute Engine non définies
Si l'état de votre ressource Config Connector est 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 éviter ce problème à l'avenir, assurez-vous de 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
Si l'état de votre ressource Config Connector est UpdateFailed et qu'un message indique une erreur 403 en raison d'étendues d'authentification insuffisantes, 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 :
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-managerSi vous avez installé Config Connector à l'aide du mode espace de noms,
serviceAccountNamedoit êtrecnrm-controller-manager-NAMESPACE. RemplacezNAMESPACEpar l'espace de noms que vous avez utilisé lors de l'installation.Créez le pod dans votre cluster GKE :
kubectl apply -f wi-test.yamlOuvrez une session interactive dans le pod :
kubectl exec -it workload-identity-test \ --namespace cnrm-system \ -- /bin/bashAffichez votre identité :
gcloud auth listVérifiez que l'identité répertoriée correspond au compte de service Google associé à vos ressources.
Si le compte de service Compute Engine par défaut s'affiche à la place, cela signifie que la fédération d'identité de charge de travail pour GKE n'est pas activée sur votre cluster GKE et/ou votre pool de nœuds.
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 avec la fédération d'identité de charge de travail pour GKE activée.
Si vous rencontrez toujours la même erreur sur un cluster GKE avec la fédération d'identité de charge de travail pour GKE activée, assurez-vous de ne pas avoir oublié d'activer également la fédération d'identité de charge de travail pour GKE sur les pools de nœuds du cluster. Découvrez comment activer la fédération d'identité de charge de travail pour GKE sur des pools de nœuds existants. Nous vous recommandons d'activer la fédération d'identité de charge de travail pour GKE 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 Forbidden: l'appelant n'est pas autorisé. Consultez la documentation sur Workload Identity Federation for GKE.
Si l'état de votre ressource Config Connector est UpdateFailed et qu'un message indique une erreur 403 due à la fédération d'identité de charge de travail pour GKE, cela signifie probablement que le compte de service Kubernetes de Config Connector ne dispose pas des autorisations IAM appropriées pour usurper l'identité de votre compte de service IAM en tant qu'utilisateur de la fédération d'identité de charge de travail pour 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": 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 Federation for GKE 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 l'état de votre ressource Config Connector est UpdateFailed et qu'un message indique qu'une autorisation IAM est manquante pour l'appelant, 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, qui est 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 accordé à votre compte de service IAM les autorisations IAM appropriées, 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 assurez-vous qu'elle 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 de portée projet.
Si l'erreur persiste, vérifiez si Workload Identity Federation for GKE est activé sur votre cluster GKE.
Pour éviter ce problème à l'avenir, assurez-vous de suivre les instructions d'installation de Config Connector.
Version non compatible avec les installations du module complémentaire 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 de version et de fonctionnalité.
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 Federation for GKE 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 rejette les mises à jour des 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 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, 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 en l'absence de mise à jour
Vous pouvez voir les erreurs suivantes dans l'état de la ressource Config Connector peu de temps après avoir créé ou acquis 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 nécessairement que vous avez réellement mis à jour la ressource. En effet, l'API Google Cloud a peut-être modifié un champ immuable que vous avez géré dans la ressource Config Connector. Cela a entraîné un décalage entre l'état souhaité et l'état réel des champs immuables.
Pour résoudre le problème, mettez à jour les valeurs de ces champs immuables dans la ressource Config Connector afin qu'elles correspondent à l'état en ligne. Pour ce faire, procédez comme suit:
- Mettez à jour la configuration YAML de la ressource Config Connector et définissez l'annotation
cnrm.cloud.google.com/deletion-policysurabandon. - Appliquez la configuration YAML mise à jour pour mettre à jour la règle de suppression de la ressource Config Connector.
- Abandonnez la ressource Config Connector.
- Imprimez l'état actuel de la ressource Google Cloud correspondante à l'aide de la CLI gcloud.
- Recherchez l'incohérence entre la sortie de la ligne de commande gcloud et la configuration YAML de la ressource Config Connector, puis mettez à jour ces champs dans la configuration YAML.
- 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.
Aucune correspondance pour le type "Foo"
Lorsque cette erreur se produit, cela signifie que le CRD pour le type de ressource Foo n'est pas installé sur votre cluster Kubernetes.
Vérifiez que le type est un type de ressource compatible avec Config Connector.
Si le type est compatible, cela signifie que votre installation Config Connector est obsolète ou incorrecte.
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 types de ressources compatibles avec les versions de Config Connector (par exemple, voici les types compatibles avec Config Connector v1.44.0).
Les libellés ne sont pas propagés vers la ressource Google Cloud .
Config Connector propage les libellés trouvés dans metadata.labels vers la ressourceGoogle Cloud sous-jacente. Notez toutefois que toutes les ressources Google Cloudne 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 PubSubTopic) pour savoir si elle est compatible avec les libellés.
Échec de l'appel du webhook x509: le certificat s'appuie sur l'ancien champ "Nom commun"
Si un message d'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
Pour contourner ce problème, supprimez 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 est régénéré.
Pour en savoir plus sur cette erreur, consultez ce problème sur 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 un message d'erreur semblable à l'exemple suivant s'affiche, la valeur de metadata.name de la ressource contient probablement 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: test.example@example-project.iam
spec:
instanceRef:
name: test-cloudsql-db
type: "CLOUD_IAM_USER"
Si vous essayez de créer cette ressource, le message d'erreur suivant s'affiche:
Error from server (Invalid): error when creating "sqlusercrd.yaml": SQLUser.sql.cnrm.cloud.google.com "test.example@example-project.iam" is invalid: metadata.name: Invalid value: "test.example@example-project.iam": 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 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 au lieu de metadata.name comme nom de la ressource.
Impossible de supprimer des champs de la spécification de la ressource
Supprimer un champ de la spécification d'une ressource Config Connector (en mettant à jour le fichier .yaml de la ressource et en l'appliquant à nouveau, ou en utilisant kubectl edit pour modifier la spécification de la ressource) ne le supprime pas réellement de la spécification de la ressource Config Connector ni de la ressource sous-jacente. Google Cloud
En revanche, supprimer un champ de la spécification le rend géré en externe.
Si vous souhaitez définir la valeur d'un champ sur vide ou par défaut dans la ressourceGoogle Cloud sous-jacente, vous devez définir le champ sur zéro dans la spécification de la ressource Config Connector:
Pour le champ "Type de liste", définissez-le sur une liste vide à l'aide de
[].L'exemple suivant montre le champ
targetServiceAccountsque nous souhaitons 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 le champ de type primitif, définissez-le sur vide à l'aide de l'une des méthodes suivantes:
Type Valeur vide chaîne "" Bool "false" entier 0 L'exemple suivant montre le champ
identityNamespaceque nous souhaitons 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 d'objet, il n'existe actuellement aucun moyen simple de définir l'ensemble d'un champ de type d'objet sur "NULL" dans Config Connector. 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, puis vérifier si cela fonctionne.
KNV2005: mise à jour excessive de la ressource par le synchroniseur
Si vous utilisez Config Sync et que des erreurs KNV2005 s'affichent pour les ressources Config Connector, il est probable que Config Sync et Config Connector soient en conflit sur la ressource.
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.
On dit que Config Sync et Config Connector "s'affrontent" pour une ressource s'ils continuent de mettre à jour le ou 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 déclenche l'action de l'autre et la mise à jour de la ressource, et ainsi de suite.
Les combats ne sont pas un problème pour la plupart des domaines. 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 toutefois une exception: les 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 de listes. Toutefois, comme les champs de liste des ressources Config Connector sont atomiques, la valeur 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 finiront par se battre si Config Sync définit un champ de liste et que Config Connector définit par défaut des sous-champs dans cette liste.
Pour contourner ce problème, vous avez les options suivantes:
Mettez à jour le fichier manifeste de ressources dans le dépôt Config Sync pour qu'il corresponde à ce que Config Connector tente de définir sur la ressource.
Pour ce faire, vous pouvez arrêter temporairement la synchronisation des configurations, attendre que Config Connector ait terminé la mise en correspondance de la ressource, puis mettre à jour votre fichier manifeste de ressources pour qu'il corresponde à la ressource sur le serveur d'API Kubernetes.
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/mutationsurignore. Découvrez comment ignorer les mutations d'objets avec Config Sync.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-specsurabsentsur 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 soit dans un état où vous ne pouvez pas le désinstaller. Cela se produit généralement lorsque vous utilisez le module complémentaire Config Connector et que vous le désactivez avant de supprimer les CRD Config Connector. Lorsque vous essayez de désinstaller l'application, vous recevez un message d'erreur semblable à celui-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
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 IAMServiceAccount Config Connector 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 de la mise en correspondance. 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 Config Connector IAM 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ôle Google Cloud . Les liaisons de rôle Google Cloud sont conservées pendant 60 jours en raison de la période de conservation du compte de service supprimé.
Pour en savoir plus, consultez la Google Cloud documentation IAM sur la suppression d'un compte de service.
Pour éviter ce problème, vous devez toujours nettoyer les ressources Config Connector IAMPolicy, IAMPartialPolicy et IAMPolicyMember avant de supprimer l'IAMServiceAccount référencé.
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 la configuration tels que 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 lancé et supprimé certaines des ressources de votre cluster. Par exemple, si vous utilisez Config Connector, vous pouvez remarquer des requêtes de suppression du gestionnaire de contrôleurs Config Connector pour certaines ressources à partir de messages de journal de conteneur ou de journaux d'audit du cluster Kubernetes. Ces requêtes de suppression sont le résultat de déclencheurs externes, et Config Connector tente de les concilier.
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 cela est d'examiner les journaux d'audit du cluster Kubernetes.
Par exemple, si vous utilisez GKE, vous pouvez interroger Cloud Logging pour obtenir les journaux d'audit du cluster 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 comme 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, vous recherchez la première requête de suppression, puis vérifiez la valeur authenticationInfo.principalEmail de ce message de journal de suppression pour déterminer la cause de la suppression.
Pod du contrôleur OOMKilled
Si une erreur OOMKilled s'affiche sur un pod de contrôleur Config Connector, cela signifie qu'un conteneur ou l'ensemble du pod a été arrêté, car ils ont utilisé plus de mémoire que l'autorisation.
Vous pouvez le vérifier en exécutant la commande kubectl describe. L'état du pod peut être OOMKilled ou Terminating.
En outre, l'examen des journaux des événements du pod peut révéler toute occurrence d'événements liés à l'OOM.
kubectl describe pod POD_NAME -n cnrm-system
Remplacez POD_NAME par le pod que vous essayez de résoudre.
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 PodSecurityPolicies peut empêcher la mise à jour des pods cnrm.
Pour confirmer que les PodSecurityPolicies empêchent votre 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]
Pour résoudre ce problème, vous devez spécifier l'annotation sur 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 la suppression de vos ressources Config Connector est bloquée et que vous souhaitez simplement vous en débarrasser de votre cluster Kubernetes, vous pouvez forcer leur suppression en supprimant leurs finaliseurs.
sous-jacentes.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 apportées au serveur d'API Kubernetes.
Étant donné que la suppression des finaliseurs d'une ressource permet de la supprimer immédiatement du cluster Kubernetes, Config Connector peut (mais pas nécessairement) ne pas avoir la possibilité de terminer la suppression de la ressourceGoogle Cloud sous-jacente. Vous devrez donc peut-être supprimer manuellement vos ressources Google Cloud par la suite.
Surveillance
Métriques
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 déboguer les problèmes de rapprochement des ressources.
Vous pouvez interroger les journaux de ressources spécifiques en filtrant les champs suivants dans les messages de journal:
logger: contient le type de la ressource en minuscules. Par exemple, les ressourcesPubSubTopicont unloggerdepubsubtopic-controller.resource.namespace: contient l'espace de noms de la ressource.resource.name: contient le nom de la ressource.
Utiliser Cloud Logging pour des requêtes avancées sur les journaux
Si vous utilisez GKE, vous pouvez utiliser Cloud Logging pour interroger les journaux d'une ressource spécifique en exécutant 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_NAMEpar le nom du cluster GKE exécutant Config ConnectorGKE_CLUSTER_LOCATIONavec l'emplacement du cluster GKE exécutant Config Connector. Exemple :us-central1RESOURCE_KINDavec le type de la ressource en minuscules. Par exemple,pubsubtopic.RESOURCE_NAMESPACEpar l'espace de noms de la ressource.RESOURCE_NAMEpar 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 .