Soluciona problemas de Config Connector

En esta página, se describen las técnicas de solución de problemas que puedes usar para solucionar problemas de Config Connector y los problemas comunes que puedes encontrar cuando usas el producto.

Técnicas básicas de solución de problemas

Verifica la versión de Config Connector

Ejecuta el siguiente comando para obtener la versión instalada de Config Connector y consulta las notas de la versión para verificar que la versión en ejecución admita las funciones y los recursos que deseas usar:

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

Verifica el estado y los eventos del recurso

Por lo general, puedes determinar el problema con tus recursos de Config Connector inspeccionando el estado de tus recursos en Kubernetes. Verificar el estado y los eventos de un recurso es particularmente útil para determinar si Config Connector no pudo conciliar el recurso y por qué falló la conciliación.

Verifica que Config Connector se esté ejecutando

Para verificar que Config Connector se esté ejecutando, comprueba que todos sus Pods sean READY:

kubectl get pod -n cnrm-system

Resultado de ejemplo:

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 tienes instalado Config Connector en el modo de espacio de nombres, tendrás un Pod de controlador (cnrm-controller-manager) para cada espacio de nombres que sea responsable de administrar los recursos de Config Connector en ese espacio de nombres.

Para verificar el estado del Pod del controlador responsable de un espacio de nombres específico, ejecuta el siguiente comando:

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

Reemplaza NAMESPACE por el nombre del espacio de nombres.

Verifica los registros del controlador

El Pod del controlador registra información y errores relacionados con la reconciliación de los recursos de Config Connector.

Para verificar los registros del Pod del controlador, ejecuta el siguiente comando:

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

Si tienes instalado Config Connector en el modo de espacio de nombres, el comando anterior muestra los registros de todos los Pods del controlador combinados. Puedes verificar los registros del Pod del controlador para un espacio de nombres específico ejecutando el siguiente comando:

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

Reemplaza NAMESPACE por el nombre del espacio de nombres.

Obtén más información para inspeccionar y consultar los registros de Config Connector.

Abandona y adquiere el recurso

En algunos casos, es posible que debas actualizar un campo inmutable en un recurso. Como no puedes editar los campos inmutables, debes abandonar y, luego, adquirir el recurso:

  1. Actualiza la configuración YAML del recurso de Config Connector y establece la anotación cnrm.cloud.google.com/deletion-policy en abandon.
  2. Aplica la configuración de YAML actualizada para actualizar la política de eliminación del recurso de Config Connector.
  3. Abandona el recurso de Config Connector.
  4. Actualiza los campos inmutables que deben cambiarse en la configuración de YAML.
  5. Aplica la configuración de YAML actualizada para adquirir el recurso abandonado.

Problemas comunes

El recurso se actualiza cada 5 a 15 minutos.

Si tu recurso de Config Connector cambia constantemente de un estado UpToDate a un estado Updating cada 5 a 10 minutos, es probable que Config Connector esté detectando diferencias no intencionales entre el estado deseado y el estado real del recurso, lo que hace que Config Connector actualice constantemente el recurso.

Primero, confirma que no tienes ningún sistema externo que modifique constantemente el recurso de Config Connector o Google Cloud (por ejemplo, canalizaciones de CI/CD, controladores personalizados, trabajos de cron, etcétera).

Si el comportamiento no se debe a un sistema externo, verifica si Google Cloud cambia alguno de los valores especificados en tu recurso de Config Connector. Por ejemplo, en algunos casos, Google Cloud cambia el formato (por ejemplo, el uso de mayúsculas) de los valores de los campos, lo que genera una diferencia entre el estado deseado y el estado real de tu recurso.

Obtén el estado del recurso Google Cloud con la API de REST (por ejemplo, para ContainerCluster) o Google Cloud CLI. Luego, compara ese estado con tu recurso de Config Connector. Busca los campos cuyos valores no coincidan y, luego, actualiza tu recurso de Config Connector para que coincida. En particular, busca los valores que Google Cloudhaya reformateado. Por ejemplo, consulta los problemas de GitHub #578 y #294.

Ten en cuenta que este no es un método perfecto, ya que los modelos de recursos de Config Connector yGoogle Cloud son diferentes, pero debería permitirte detectar la mayoría de los casos de diferencias no deseadas.

Si no puedes resolver el problema, consulta Ayuda adicional.

Eliminaciones de espacios de nombres atascados en "Finalizando"

Es posible que las eliminaciones de espacios de nombres se detengan en Terminating si tienes instalado Config Connector en el modo de espacio de nombres y si se borró el ConfigConnectorContext del espacio de nombres antes de que se borraran todos los recursos de Config Connector en ese espacio de nombres. Cuando se borra el ConfigConnectorContext de un espacio de nombres, se inhabilita Config Connector para ese espacio de nombres, lo que evita que se borren los recursos restantes de Config Connector en ese espacio de nombres.

Para solucionar este problema, debes realizar una limpieza forzada y, luego, borrar de forma manual los recursos Google Cloud subyacentes.

Para mitigar este problema en el futuro, solo borra el ConfigConnectorContext después de que se hayan borrado todos los recursos de Config Connector en su espacio de nombres de Kubernetes. Evita borrar espacios de nombres completos antes de que se hayan borrado todos los recursos de Config Connector en ese espacio de nombres, ya que es posible que primero se borre el ConfigConnectorContext.

También consulta cómo se puede bloquear el borrado de un espacio de nombres que contiene un proyecto y sus elementos secundarios o una carpeta y sus elementos secundarios.

Las eliminaciones de recursos se atascan en "DeleteFailed" después de que se borra el proyecto

Es posible que las eliminaciones de recursos de Config Connector se queden atascadas en DeleteFailed si su proyecto Google Cloud se borró con anterioridad.

Para solucionar este problema, restablece el proyecto enGoogle Cloud para permitir que Config Connector borre los recursos secundarios restantes de Kubernetes. Como alternativa, puedes realizar una limpieza forzada.

Para mitigar este problema en el futuro, solo borra los proyectos Google Cloud después de que se hayan borrado todos sus recursos secundarios de Config Connector de Kubernetes. Evita borrar espacios de nombres completos que puedan contener un recurso Project y sus recursos secundarios de Config Connector, ya que es posible que el recurso Project se borre primero.

No se definieron los metadatos de Compute Engine

Si tu recurso de Config Connector tiene un estado UpdateFailed con un mensaje que indica que no se definieron los metadatos de Compute Engine, es probable que no exista la cuenta de servicio de IAM que usa Config Connector.

Ejemplo de mensaje 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:

Para corregir el problema, asegúrate de que exista la cuenta de servicio de IAM que usa Config Connector.

Para mitigar este problema en el futuro, asegúrate de seguir las instrucciones de instalación de Config Connector.

Error 403: La solicitud tenía permisos de autenticación insuficientes

Si tu recurso de Config Connector tiene un estado UpdateFailed con un mensaje que indica un error 403 debido a que no hay suficientes alcances de autenticación, es probable que Workload Identity no esté habilitado en tu clúster de GKE.

Ejemplo de mensaje 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.

Para investigar, completa los siguientes pasos:

  1. Guarda la siguiente configuración del Pod como 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 instalaste Config Connector con el modo de espacio de nombres, serviceAccountName debería ser cnrm-controller-manager-NAMESPACE. Reemplaza NAMESPACE por el espacio de nombres que usaste durante la instalación.

  2. Crea el Pod en tu clúster de GKE:

    kubectl apply -f wi-test.yaml

  3. Abre una sesión interactiva en el Pod:

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

  4. Indica tu identidad:

    gcloud auth list

  5. Verifica que la identidad que aparece coincida con la cuenta de servicio de Google vinculada a tus recursos.

    Si ves la cuenta de servicio predeterminada de Compute Engine, significa que Workload Identity Federation for GKE no está habilitada en tu clúster o grupo de nodos de GKE.

  6. Sal de la sesión interactiva y, luego, borra el Pod de tu clúster de GKE:

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

Para solucionar este problema, usa un clúster de GKE con la federación de identidades para cargas de trabajo para GKE habilitada.

Si sigues viendo el mismo error en un clúster de GKE con la federación de identidades para cargas de trabajo para GKE habilitada, asegúrate de no haber olvidado habilitar también la federación de identidades para cargas de trabajo para GKE en los grupos de nodos del clúster. Obtén más información para habilitar la federación de identidades para cargas de trabajo para GKE en grupos de nodos existentes. Te recomendamos que habilites la federación de identidades para cargas de trabajo para GKE en todos los grupos de nodos de tu clúster, ya que Config Connector podría ejecutarse en cualquiera de ellos.

403 Forbidden: El llamador no tiene permiso. Consulta la documentación de Workload Identity Federation for GKE.

Si tu recurso de Config Connector tiene un estado UpdateFailed con un mensaje que indica un error 403 debido a la federación de identidades para cargas de trabajo de GKE, es probable que a la cuenta de servicio de Kubernetes de Config Connector le falten los permisos de IAM adecuados para suplantar tu cuenta de servicio de IAM como usuario de la federación de identidades para cargas de trabajo de GKE.

Ejemplo de mensaje 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

Para corregir y mitigar el problema en el futuro, consulta las instrucciones de instalación de Config Connector.

Error 403: El llamador no tiene permiso de IAM

Si tu recurso de Config Connector tiene el estado UpdateFailed con un mensaje que indica que al llamador le falta un permiso de IAM, es probable que a la cuenta de servicio de IAM que usa Config Connector le falte el permiso de IAM que se indica en el mensaje y que se necesita para administrar el recurso Google Cloud .

Ejemplo de mensaje 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 sigues viendo el mismo error después de otorgarle a tu cuenta de servicio de IAM los permisos de IAM adecuados, verifica que tu recurso se esté creando en el proyecto correcto. Verifica el campo spec.projectRef del recurso de Config Connector (o su anotación cnrm.cloud.google.com/project-id si el recurso no admite un campo spec.projectRef) y verifica que el recurso haga referencia al proyecto correcto. Ten en cuenta que Config Connector usa el nombre del espacio de nombres como el ID del proyecto si ni el recurso ni el espacio de nombres especifican un proyecto de destino. Obtén más información para configurar el proyecto de destino para los recursos con alcance en el proyecto.

Si sigues viendo el mismo error, verifica si Workload Identity Federation for GKE está habilitada en tu clúster de GKE.

Para mitigar este problema en el futuro, asegúrate de seguir las instrucciones de instalación de Config Connector.

La versión no se admite en las instalaciones de complementos de Config Connector

Si no puedes habilitar de forma correcta el complemento de Config Connector, aparecerá el siguiente mensaje de error: Node version 1.15.x-gke.x s unsupported. Para corregir el error, verifica que la versión del clúster de GKE cumpla con los requisitos de versión y funciones.

Para obtener todas las versiones válidas de los clústeres, ejecuta el siguiente comando.

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

Reemplaza ZONE por la zona de Compute Engine.

Elige una versión de la lista que cumpla con los requisitos.

El mensaje de error también aparece si están inhabilitados Workload Identity Federation for GKE o GKE Monitoring. Asegúrate de que estén habilitadas estas funciones para corregir el error.

No se pueden realizar cambios en los campos inmutables

Config Connector rechaza las actualizaciones de los campos inmutables en la admisión.

Por ejemplo, actualizar un campo inmutable con kubectl apply hace que el comando falle de inmediato.

Esto significa que las herramientas que vuelven a aplicar recursos de forma continua (por ejemplo, GitOps) podrían quedarse atascadas mientras actualizan un recurso si no controlan los errores de admisión.

Dado que Config Connector no permite actualizaciones en campos inmutables, la única forma de realizar una actualización de este tipo es borrar y volver a crear el recurso.

Se produjo un error al actualizar los campos inmutables cuando no hay ninguna actualización.

Es posible que veas los siguientes errores en el estado del recurso de Config Connector poco después de crear o adquirir un recurso de Google Cloud con Config Connector:

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

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

Esto no significa que hayas actualizado el recurso, sino que la API de Google Cloud puede haber realizado un cambio en un campo inmutable que tú administrabas en el recurso de Config Connector. Esto provocó la discrepancia entre el estado deseado y el estado activo de los campos inmutables.

Para resolver el problema, actualiza los valores de esos campos inmutables en el recurso de Config Connector para que coincidan con el estado activo. Para lograrlo, debes completar los siguientes pasos:

  1. Actualiza la configuración YAML del recurso de Config Connector y establece la anotación cnrm.cloud.google.com/deletion-policy en abandon.
  2. Aplica la configuración de YAML actualizada para actualizar la política de eliminación del recurso de Config Connector.
  3. Abandona el recurso de Config Connector.
  4. Imprime el estado activo del recurso Google Cloud correspondiente con gcloud CLI.
  5. Busca la discrepancia entre el resultado de gcloud CLI y la configuración de YAML del recurso de Config Connector, y actualiza esos campos en la configuración de YAML.
  6. Aplica la configuración de YAML actualizada para adquirir el recurso abandonado.

El recurso no tiene estado

Si tus recursos no tienen un campo status, es probable que Config Connector no se esté ejecutando correctamente. Comprueba que Config Connector se esté ejecutando.

No se encontraron coincidencias para el tipo "Foo"

Cuando se produce este error, significa que tu clúster de Kubernetes no tiene instalado el CRD para el tipo de recurso Foo.

Verifica que el tipo sea un tipo de recurso admitido por Config Connector.

Si el tipo es compatible, significa que la instalación de Config Connector está desactualizada o no es válida.

Si instalaste Config Connector con el complemento de GKE, la instalación debería actualizarse automáticamente. Si instalaste Config Connector de forma manual, debes realizar una actualización manual.

Consulta el repositorio de GitHub para determinar qué tipos de recursos son compatibles con qué versiones de Config Connector (por ejemplo, aquí se encuentran los tipos compatibles con Config Connector v1.44.0).

Las etiquetas no se propagan al recurso Google Cloud

Config Connector propaga las etiquetas que se encuentran en metadata.labels al recurso subyacenteGoogle Cloud . Sin embargo, ten en cuenta que no todos los recursos de Google Cloudadmiten etiquetas. Consulta la documentación de la API de REST del recurso (por ejemplo, aquí se encuentra la documentación de la API de PubSubTopic) para ver si admite etiquetas.

No se pudo llamar al webhook x509: el certificado depende del campo Nombre común heredado

Si ves un error similar al siguiente ejemplo, es posible que tengas un problema con los certificados:

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

Para solucionar este problema, borra los certificados pertinentes y los Pods:

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"

Después de borrar estos recursos, se regenerará el certificado correcto.

Para obtener más información sobre este error, consulta el problema de GitHub.

Error debido a caracteres especiales en el nombre del recurso

Los caracteres especiales no son válidos en el campo metadata.name de Kubernetes. Si ves un error similar al siguiente ejemplo, es probable que el metadata.name del recurso tenga un valor con caracteres especiales:

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

Por ejemplo, el siguiente recurso SQLUser contiene un carácter no válido en 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 intentas crear este recurso, recibirás el siguiente error:

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 deseas asignar a tu recurso un nombre que no sea válido para Kubernetes, pero sí para el recurso Google Cloud , puedes usar el campo resourceID, como se muestra en el siguiente ejemplo:

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

Esta configuración hace que Config Connector use resourceID en lugar de metadata.name como nombre del recurso.

No se pueden quitar campos de la especificación del recurso

Quitar un campo de la especificación de un recurso de Config Connector (actualizando el archivo .yaml del recurso y volviendo a aplicarlo, o bien usando kubectl edit para editar la especificación del recurso) no quita realmente ese campo de la especificación del recurso de Config Connector ni del recurso Google Cloud subyacente. En cambio, quitar un campo de la especificación solo hace que ese campo se administre de forma externa.

Si deseas cambiar el valor de un campo a vacío o predeterminado en el recursoGoogle Cloud subyacente, deberás establecer el campo en cero en la especificación del recurso de Config Connector:

  • Para el campo de tipo de lista, configura el campo en una lista vacía con [].

    En el siguiente ejemplo, se muestra el campo targetServiceAccounts que queremos quitar:

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

    Para quitar este campo, establece el valor como vacío:

    spec:
  targetServiceAccounts: []

  • Para un campo de tipo primitivo, configúralo como vacío con una de las siguientes opciones:

    Tipo Valor vacío
    cadena ""
    booleano "false"
    integer 0

    En el siguiente ejemplo, se muestra el campo identityNamespace que queremos quitar:

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

    Para quitar este campo, establece el valor como vacío:

    spec:
  workloadIdentityConfig:
    identityNamespace: ""

  • Actualmente, en Config Connector, no hay una forma sencilla de establecer un campo de tipo de objeto completo como "NULL". Puedes intentar establecer los subcampos del tipo de objeto como vacíos o predeterminados siguiendo la guía anterior y verificar si funciona.

KNV2005: El sincronizador actualiza el recurso en exceso

Si usas Config Sync y ves errores KNV2005 para los recursos de Config Connector, es probable que Sincronizador de configuración y Config Connector estén compitiendo por el recurso.

Ejemplo de mensaje de registro:

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

Se dice que el Sincronizador de configuración y Config Connector están "compitiendo" por un recurso si actualizan los mismos campos con valores diferentes. La actualización de uno activa al otro para que actúe y actualice el recurso, lo que hace que el otro actúe y actualice el recurso, y así sucesivamente.

La lucha no es un problema para la mayoría de los campos. Config Connector no cambia los campos especificados en Sincronizador de configuración, mientras que Config Sync ignora los campos que no se especifican en Sincronizador de configuración y que Config Connector establece de forma predeterminada. Por lo tanto, para la mayoría de los campos, el Sincronizador de configuración y Config Connector nunca deberían terminar actualizando el mismo campo a valores diferentes.

Hay una excepción: los campos de lista. De manera similar a cómo Config Connector puede establecer valores predeterminados para los subcampos en los campos de objetos, también puede establecer valores predeterminados para los subcampos en los objetos dentro de las listas. Sin embargo, dado que los campos de lista en los recursos de Config Connector son atómicos, el establecimiento de valores predeterminados para los subcampos se considera como un cambio en el valor de la lista por completo.

Por lo tanto, Sincronizador de configuración y Config Connector terminarán peleando si Sincronizador de configuración establece un campo de lista y Config Connector establece valores predeterminados para cualquier subcampo dentro de esa lista.

Para solucionar este problema, tienes las siguientes opciones:

  1. Actualiza el manifiesto de recursos en el repositorio de Sincronizador de configuración para que coincida con lo que Config Connector intenta establecer para el recurso.

    Una forma de hacerlo es detener temporalmente la sincronización de los archivos de configuración, esperar a que Config Connector termine de conciliar el recurso y, luego, actualizar el manifiesto del recurso para que coincida con el recurso en el servidor de la API de Kubernetes.

  2. Para evitar que Config Sync reaccione a las actualizaciones del recurso en el servidor de la API de Kubernetes, establece la anotación client.lifecycle.config.k8s.io/mutation en ignore. Obtén más información para hacer que el Sincronizador de configuración ignore las mutaciones de objetos.

  3. Para evitar que Config Connector actualice por completo la especificación del recurso, configura la anotación cnrm.cloud.google.com/state-into-spec en absent en el recurso. Esta anotación no es compatible con todos los recursos. Para ver si tu recurso admite la anotación, consulta la página de referencia de recursos correspondiente. Obtén más información sobre la anotación.

failed calling webhook

Es posible que Config Connector se encuentre en un estado en el que no se pueda desinstalar. Esto suele ocurrir cuando se usa el complemento de Config Connector y se inhabilita Config Connector antes de quitar las CRD de Config Connector. Cuando intentas desinstalar, recibes un error similar al siguiente:

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

Para resolver este error, primero debes borrar manualmente los 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

Luego, puedes continuar con la desinstalación de Config Connector.

Error de actualización con IAMPolicy, IAMPartialPolicy y IAMPolicyMember

Si borras un recurso IAMServiceAccount de Config Connector antes de limpiar los recursos IAMPolicy, IAMPartialPolicy y IAMPolicyMember que dependen de esa cuenta de servicio, Config Connector no podrá ubicar la cuenta de servicio a la que se hace referencia en esos recursos de IAM durante la reconciliación. Esto genera un estado UpdateFailed con un mensaje de error como el siguiente:

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

Para resolver este problema, verifica tus cuentas de servicio y comprueba si se borró la cuenta de servicio requerida para esos recursos de IAM. Si se borra la cuenta de servicio, también se deben limpiar los recursos relacionados de Config Connector de IAM. En el caso de IAMPolicyMember, borra todo el recurso. En el caso de IAMPolicy y IAMParitialPolicy, solo quita las vinculaciones que involucren a la cuenta de servicio borrada. Sin embargo, esta limpieza no quita las vinculaciones de roles de Google Cloud de inmediato. Las vinculaciones de roles de Google Cloud se conservan durante 60 días debido a la retención en la cuenta de servicio borrada. Para obtener más información, consulta la Google Cloud documentación de IAM sobre cómo borrar una cuenta de servicio.

Para evitar este problema, siempre debes limpiar los recursos de Config Connector IAMPolicy, IAMPartialPolicy y IAMPolicyMember antes de borrar el IAMServiceAccount al que se hace referencia.

Recurso borrado por Config Connector

Config Connector nunca borra tus recursos sin una causa externa. Por ejemplo, ejecutar kubectl delete, usar herramientas de administración de configuración como Argo CD o usar un cliente de API personalizado puede provocar la eliminación de recursos.

Un concepto erróneo común es que Config Connector inició y borró algunos de los recursos de tu clúster. Por ejemplo, si usas Config Connector, es posible que observes solicitudes de eliminación del administrador de controladores de Config Connector en relación con ciertos recursos en los mensajes de registro del contenedor o en los registros de auditoría del clúster de Kubernetes. Estas solicitudes de eliminación son el resultado de activadores externos, y Config Connector intenta conciliar las solicitudes de eliminación.

Para determinar por qué se borró un recurso, debes consultar la primera solicitud de eliminación que se envió al recurso correspondiente. La mejor manera de investigar esto es examinar los registros de auditoría del clúster de Kubernetes.

Por ejemplo, si usas GKE, puedes usar Cloud Logging para consultar los registros de auditoría del clúster de GKE. Por ejemplo, si deseas buscar las solicitudes de eliminación iniciales de un recurso BigQueryDataset llamado foo en el espacio de nombres bar, ejecutarías una consulta como la siguiente:

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"

Con esta consulta, buscarías la primera solicitud de eliminación y, luego, verificarías authenticationInfo.principalEmail de ese mensaje de registro de eliminación para determinar la causa de la eliminación.

El Pod del controlador se cerró por falta de memoria (OOMKilled)

Si ves un error OOMKilled en un Pod del controlador de Config Connector, significa que se finalizó un contenedor o todo el Pod porque usaron más memoria de la permitida. Esto se puede verificar ejecutando el comando kubectl describe. El estado del Pod puede aparecer como OOMKilled o Terminating. Además, analizar los registros de eventos del Pod puede revelar cualquier ocurrencia de eventos relacionados con OOM.

kubectl describe pod POD_NAME -n cnrm-system

Reemplaza POD_NAME por el Pod para el que estás solucionando problemas.

Para solucionar este problema, puedes usar el recurso personalizado ControllerResource para aumentar la solicitud de memoria y el límite de memoria del Pod.

PodSecurityPolicy impide las actualizaciones

Después de cambiar del complemento de Config Connector a una instalación manual y actualizar Config Connector a una versión nueva, el uso de PodSecurityPolicies puede impedir que se actualicen los Pods de cnrm.

Para confirmar que las políticas de PodSecurity impiden la actualización, consulta los eventos de config-connector-operator y busca un error similar al siguiente:

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]

Para resolver este problema, debes especificar la anotación en la PodSecurityPolicy que corresponde a la anotación mencionada en el error. En el ejemplo anterior, la anotación es seccomp.security.alpha.kubernetes.io.

Limpieza forzada

Si tus recursos de Config Connector no se borran y solo quieres deshacerte de ellos en tu clúster de Kubernetes, puedes forzar su eliminación borrando sus finalizadores.

Puedes borrar los finalizadores de un recurso editándolo con kubectl edit, borrando el campo metadata.finalizers y, luego, guardando el archivo para conservar los cambios en el servidor de la API de Kubernetes.

Dado que borrar los finalizadores de un recurso permite que este se borre de inmediato del clúster de Kubernetes, es posible (pero no necesariamente) que Config Connector no tenga la oportunidad de completar el borrado del recursoGoogle Cloud subyacente. Esto significa que es posible que desees borrar manualmente tus recursos de Google Cloud después.

Supervisión

Métricas

Puedes usar Prometheus para recopilar y mostrar métricas desde Config Connector.

Logging

Todos los Pods de Config Connector generan registros estructurados en formato JSON.

Los registros de los Pods del controlador son especialmente útiles para depurar problemas con la conciliación de recursos.

Puedes consultar los registros de recursos específicos filtrando los siguientes campos en los mensajes de registro:

  • logger: Contiene el tipo del recurso en minúsculas. Por ejemplo, los recursos PubSubTopic tienen un logger de pubsubtopic-controller.
  • resource.namespace: Contiene el espacio de nombres del recurso.
  • resource.name: Contiene el nombre del recurso.

Usa Cloud Logging para realizar consultas de registros avanzadas

Si usas GKE, puedes usar Cloud Logging para consultar registros de un recurso específico con la siguiente consulta:

# 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"

Reemplaza lo siguiente:

  • GKE_CLUSTER_NAME por el nombre del clúster de GKE que ejecuta Config Connector
  • GKE_CLUSTER_LOCATION con la ubicación del clúster de GKE que ejecuta Config Connector Por ejemplo, us-central1
  • RESOURCE_KIND con el tipo de recurso en minúsculas Por ejemplo, pubsubtopic.
  • RESOURCE_NAMESPACE por el espacio de nombres del recurso.
  • RESOURCE_NAME por el nombre del recurso

Ayuda adicional

Para obtener ayuda adicional, puedes informar un problema en GitHub o comunicarte con el equipo de asistencia deGoogle Cloud .