Soluciona problemas de Config Connector

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

Verifica el estado y las condiciones del Config Connector

Verifica la versión de Config Connector

Ejecuta el siguiente comando para obtener la versión instalada del Config Connector y compara mediante referencia cruzada 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 muy ú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 comprobar que el Config Connector se esté ejecutando, verifica que todos sus Pods estén 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 Config Connector instalado en modo de espacio de nombres, tendrás un Pod de controlador (cnrm-controller-manager) para cada espacio de nombres que se encargue 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 lo siguiente:

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 conciliación de los recursos del Config Connector.

Para verificar los registros del Pod del controlador, ejecuta lo siguiente:

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

Si tienes instalado el Config Connector en namespaced-mode, 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 lo siguiente:

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 campos inmutables, debes abandonar y, luego, adquirir el recurso:

1. Actualiza la configuración de 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 se deben cambiar en la configuración de YAML.
5. Aplica la configuración de YAML actualizada para adquirir el recurso abandonado.

Soluciona problemas por tipo de problema

Usa la siguiente tabla para solucionar problemas según el tipo de síntoma.

Tipo de problema	Problemas habituales
Conciliación	El recurso se actualiza cada 5 o 15 minutos La conciliación falla o se repite debido a las actualizaciones automáticas de los campos Los intentos frecuentes de reintentar en recursos con errores agotan las cuotas de la API El recurso no tiene estado KNV2005: El sincronizador actualiza el recurso de forma excesiva Recurso borrado por Config Connector Controller Pod OOMKilled
Eliminación	Las eliminaciones de espacios de nombres se detienen en Terminating Las eliminaciones de recursos se detienen en DeleteFailed después de que se borra el proyecto
Permisos	No se definieron los metadatos de Compute Engine Error 403: La solicitud tenía permisos de autenticación insuficientes 403 Prohibido: El emisor no tiene permiso Error 403: El emisor no tiene el permiso de IAM Error de actualización con IAMPolicy, IAMPartialPolicy y IAMPolicyMember
Instalación y actualizaciones	Versión no compatible en instalaciones de complementos de Config Connector failed calling webhook PodSecurityPolicy impide las actualizaciones
Configuration	No se pueden realizar cambios en los campos inmutables No hay coincidencias para el tipo "RESOURCE_KIND" Las etiquetas no se propagan al recurso Google Cloud Error debido a caracteres especiales en el nombre del recurso No se pueden quitar campos de la especificación del recurso Valor no válido "merge" para la anotación state-into-spec

Conciliación

En la siguiente sección, se enumeran los problemas habituales relacionados con la conciliación de recursos por parte de Config Connector.

El recurso se actualiza cada 5-15 minutos

Síntoma

Tu recurso de Config Connector cambia de un estado UpToDate a un estado Updating cada 5 o 10 minutos.

Causa

Es probable que el Config Connector detecte diferencias no intencionales entre el estado deseado y el estado real del recurso, lo que hace que el Config Connector actualice el recurso de forma constante.

Solución

Primero, confirma que no tienes ningún sistema externo que modifique de forma constante el recurso de Config Connector o Google Cloud (por ejemplo, canalizaciones de CI/CD, controladores personalizados, trabajos 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, mayúsculas) de los valores de campo, 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 y Google 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.

La conciliación falla o se repite debido a las actualizaciones automáticas de los campos

Este problema se produce cuando Google Cloud actualiza automáticamente un campo en un recurso que usa la anotación cnrm.cloud.google.com/state-into-spec: merge.

Síntoma

Tu recurso de Config Connector entra en un estado UpdateFailed o cambia de forma repetida al estado Updating después de que Google Cloud actualiza automáticamente un campo que no especificaste en tu manifiesto YAML.

Por ejemplo, después de que Cloud SQL realiza una actualización de mantenimiento automática en un recurso SQLInstance, la conciliación puede fallar con un error similar al siguiente:

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

Causa

El recurso tiene la anotación cnrm.cloud.google.com/state-into-spec: merge. Esta anotación era la predeterminada para los recursos creados antes de la versión 1.123.1 de Config Connector para las CustomResourceDefinitions (CRD) agregadas en la versión 1.113.0 y anteriores. Es posible que tu recurso también tenga esta anotación si el campo spec.stateIntoSpec está configurado como Merge en tu recurso personalizado (CR) ConfigConnector o ConfigConnectorContext.

Cuando la anotación cnrm.cloud.google.com/state-into-spec se establece en merge, Config Connector propaga los campos no especificados, como el campo spec.maintenanceVersion, en el campo spec del recurso de Kubernetes durante la conciliación inicial. Cuando Google Cloud actualiza automáticamente ese campo en el recurso subyacente, Config Connector trata el valor anterior almacenado en el campo spec como el estado de destino y, luego, intenta revertir el cambio. Si la API de Google Cloud rechaza las versiones anteriores (como lo hace Cloud SQL para el campo spec.maintenanceVersion), la conciliación falla.

Solución

Para resolver este problema, migra el recurso del comportamiento Merge al comportamiento Absent para que Config Connector deje de propagar campos no especificados en el campo spec:

1. En el manifiesto YAML de tu recurso, omite el campo que se actualiza automáticamente (como el campo spec.maintenanceVersion) y establece la anotación cnrm.cloud.google.com/state-into-spec en absent.
2. Sigue los pasos que se indican en Migra recursos de Merge a Absent para abandonar el recurso de Kubernetes y volver a adquirirlo con el manifiesto YAML actualizado.

Los intentos frecuentes de reintentar en recursos con errores agotan las cuotas de la API

Este problema se produce cuando los recursos experimentan fallas de conciliación persistentes, como cuando un recurso depende de un recurso externo de Google Cloud que falta o tiene una configuración no válida.

Síntoma

Un recurso de Config Connector tiene el estado UpdateFailed o DependencyNotFound, y los reintentos de conciliación repetidos generan un tráfico excesivo de la API de Google Cloud o agotan las cuotas de la API de Google Cloud .

Causa

Cuando falla la conciliación, Config Connector vuelve a intentar el recurso con una retirada exponencial con un retraso máximo predeterminado de 2 minutos.

Solución

Para los recursos administrados por controladores directos en la versión 1.160.0 y posteriores de Config Connector, configura la anotación cnrm.cloud.google.com/backoff-max-delay-in-seconds para aumentar la demora máxima de reintentos o establece la anotación en "0" para detener los reintentos automáticos.

Los recursos administrados por controladores basados en Terraform o DCL no admiten esta anotación. Para reducir los reintentos de estos recursos, prueba las siguientes opciones en orden:

1. Si hay un controlador directo disponible para el recurso, cambia al controlador directo y usa la anotación.
2. Corrige la falla subyacente.
3. Como último recurso, quita temporalmente el recurso de la administración configurando la anotación cnrm.cloud.google.com/deletion-policy: "abandon" y borrando el objeto de Kubernetes. Como alternativa, establece spec.actuationMode: Paused en ConfigConnectorContext.

Precaución: Configurar spec.actuationMode: Paused en ConfigConnectorContext pausa la ejecución de acciones para todos los recursos del espacio de nombres, no solo para el que falla.

El recurso no tiene estado

Síntoma

Tus recursos no tienen un campo status.

Causa

Es probable que Config Connector no se esté ejecutando correctamente.

Solución

Verifica que Config Connector se esté ejecutando.

KNV2005: El sincronizador actualiza el recurso de forma excesiva

Síntoma

Usas el Sincronizador de configuración y ves errores KNV2005 para los recursos de Config Connector, similares a los siguientes:

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

Causa

Es probable que el Sincronizador de configuración y Config Connector estén compitiendo por el recurso.

Se dice que el Sincronizador de configuración y Config Connector están "peleando" por un recurso si siguen actualizando 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 esto se repite sin fin.

Las peleas no son un problema para la mayoría de los campos. Config Connector no modifica los campos que se especifican en el Sincronizador de configuración. Del mismo modo, el Sincronizador de configuración ignora los campos que no se especifican en él 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 no deberían necesitar actualizar el mismo campo.

Una excepción son los campos de lista. De manera similar a cómo Config Connector puede establecer subcampos predeterminados en campos de objetos, Config Connector también puede establecer subcampos predeterminados en objetos dentro de listas. Sin embargo, dado que los campos de lista en los recursos de Config Connector son atómicos, la configuración predeterminada de los subcampos se considera como un cambio del valor de la lista por completo.

Por lo tanto, el Sincronizador de configuración y Config Connector "lucharán" por un recurso si el Sincronizador de configuración establece un campo de lista y Config Connector establece de forma predeterminada cualquier subcampo dentro de esa lista.

Solución

Para solucionar este problema, tienes las siguientes opciones:

1. Actualiza el manifiesto del recurso en el repositorio del Sincronizador de configuración para que coincida con el valor 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. Detén el Sincronizador de configuración para que no reaccione a las actualizaciones del recurso en el servidor de la API de Kubernetes. Para ello, configura la anotación client.lifecycle.config.k8s.io/mutation como ignore. Obtén más información sobre cómo 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, establece 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 del recurso correspondiente. Obtén más información sobre la anotación.

Recurso borrado por Config Connector

Síntoma

Se borró un recurso de tu clúster y sospechas que Config Connector lo borró.

Causa

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 causar la eliminación de recursos.

Una idea errónea común es que el Config Connector inició y borró algunos de los recursos de tu clúster. Por ejemplo, si usas Config Connector, es posible que notes solicitudes de eliminación del administrador del controlador de Config Connector en relación con ciertos recursos, ya sea de los mensajes de registro del contenedor o de 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.

Solución

Para determinar por qué se borró un recurso, debes analizar la primera solicitud de eliminación que se envió al recurso correspondiente. La mejor manera de analizar 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 my-dataset en el espacio de nombres my-namespace, ejecuta 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/my-namespace/bigquerydatasets/my-dataset"

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.

OOMKilled del Pod del controlador

Síntoma

Ves un error OOMKilled en un Pod del controlador de Config Connector. El estado del Pod puede aparecer como OOMKilled o Terminating.

Causa

Se finalizó un contenedor o todo el Pod porque usaron más memoria de la permitida. Esto se puede verificar con la ejecución del comando kubectl describe:

kubectl describe pod POD_NAME -n cnrm-system

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

Además, examinar los registros de eventos del Pod puede revelar cualquier caso de eventos relacionados con OOM.

Solución

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

Eliminación

En la siguiente sección, se enumeran los problemas habituales relacionados con las operaciones de eliminación iniciadas por el usuario que pueden causar conflictos con el Config Connector.

La eliminación del espacio de nombres se detuvo en "Terminating"

Síntoma

La eliminación de un espacio de nombres se detiene en la etapa Terminating.

Causa

Este problema puede ocurrir si tienes Config Connector instalado en modo de espacio de nombres y si se borró el ConfigConnectorContext del espacio de nombres antes de que se borren todos los recursos de Config Connector en ese espacio de nombres. Cuando se borra el ConfigConnectorContext de un espacio de nombres, Config Connector se inhabilita para ese espacio de nombres, lo que evita que se borren los recursos restantes de Config Connector en ese espacio de nombres.

Solución

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

Para mitigar este problema en el futuro, solo borra el ConfigConnectorContext después de que se hayan borrado de Kubernetes todos los recursos de Config Connector en su espacio de nombres. 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 el ConfigConnectorContext se borre primero.

La eliminación de recursos se detuvo en "DeleteFailed" después de que se borró el proyecto

Síntoma

No se puede borrar un recurso de Config Connector con el estado DeleteFailed.

Causa

Este problema puede ocurrir si se borra un proyecto de Google Cloud antes que el recurso.

Solución

Para solucionar este problema, restablece el proyecto en Google 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 de 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 el recurso Project podría borrarse primero.

Permisos y autenticación

En la siguiente sección, se enumeran los problemas comunes relacionados con los permisos y la autenticación.

No se definieron los metadatos de Compute Engine

Síntoma

Tu recurso de Config Connector tiene un estado UpdateFailed con un mensaje que indica que los metadatos de Compute Engine no están definidos, similar al siguiente error:

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:

Causa

Es probable que no exista la cuenta de servicio de IAM que usa Config Connector.

Solución

Para solucionar 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

Síntoma

Tu recurso de Config Connector tiene un estado UpdateFailed con un mensaje que indica un error 403 debido a permisos de autenticación insuficientes, similar al siguiente error:

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.

Causa

Es probable que la federación de identidades para cargas de trabajo para GKE no esté habilitada en tu clúster de GKE.

Para confirmar que Workload Identity Federation for GKE no está habilitada, 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, en cambio, ves la cuenta de servicio predeterminada de Compute Engine, significa que Workload Identity Federation for GKE no está habilitada en tu clúster de GKE o grupo de nodos.

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
   

Solución

Para solucionar este problema, asegúrate de que Workload Identity Federation for GKE esté habilitada en tu clúster.

Si sigues viendo el mismo error, asegúrate de haber habilitado la federación de identidades para cargas de trabajo para GKE en los grupos de nodos del clúster.

403 Prohibido: El emisor no tiene permiso

Síntoma

Tu recurso de Config Connector tiene un estado UpdateFailed con un mensaje que indica un error 403 debido a Workload Identity Federation for GKE, similar al siguiente error:

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

Causa

A la cuenta de servicio de Kubernetes de Config Connector le faltan los permisos de IAM adecuados para actuar en nombre de tu cuenta de servicio de IAM como usuario de la federación de identidades para cargas de trabajo para GKE.

Solución

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

Error 403: El emisor no tiene el permiso de IAM

Síntoma

Tu recurso de Config Connector tiene un estado UpdateFailed con un mensaje que indica que al emisor le falta un permiso de IAM, similar al siguiente error:

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:

Causa

A la cuenta de servicio de IAM que usa el Config Connector le falta el permiso de IAM que se indica en el mensaje que se necesita para administrar el recurso de Google Cloud .

Solución

Si sigues viendo el mismo error después de otorgar a tu cuenta de servicio de IAM los permisos de IAM adecuados, verifica que tu recurso se cree 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 el 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 de proyecto.

Si sigues viendo el mismo error, verifica si la 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.

Error de actualización con IAMPolicy, IAMPartialPolicy y IAMPolicyMember

Síntoma

Verás un estado UpdateFailed con un mensaje de error que indica un error 400 porque la cuenta de servicio no existe:

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

Causa

Si borras un recurso de Config Connector IAMServiceAccount 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 conciliación.

Solución

Para resolver este problema, verifica tus cuentas de servicio y comprueba si se borró la cuenta de servicio necesaria para esos recursos de IAM. Si se borra la cuenta de servicio, también limpia los recursos de IAM de Config Connector relacionados. En el caso de IAMPolicyMember, borra todo el recurso. Para IAMPolicy y IAMParitialPolicy, solo quita las vinculaciones que involucren la cuenta de servicio borrada. Sin embargo, esa limpieza no quita las vinculaciones de roles deGoogle 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 documentación de IAM sobre Google Cloud Borra una cuenta de servicio.

Nota: Si tienes problemas durante la eliminación, es posible que debas realizar una limpieza forzada. Si deseas borrar las vinculaciones de IAM de Google Cloud de inmediato, debes borrar de forma manual los recursos Google Cloud subyacentes con gcloud.

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.

El recurso ServiceIdentity falla con Invalid service producer

Síntoma

Tu recurso ServiceIdentity tiene un estado UpdateFailed, con un mensaje de error similar al siguiente:

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

Causa

Este error significa que el recurso especificado no admite la creación de identidades de servicio on demand.

Solución

El recurso ServiceIdentity puede generar identidades de servicio solo para los servicios compatibles. Para verificar si un servicio admite la creación de identidades de servicio on demand antes de aplicar la configuración, ejecuta el siguiente comando:

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

Reemplaza SERVICE_NAME por el nombre del servicio, por ejemplo, spanner.

Si el comando se ejecuta de forma correcta, Config Connector puede crear una identidad para ese servicio. Si el comando falla, significa que el Config Connector no puede crear una identidad para ese servicio.

Instalación y actualizaciones

En la siguiente sección, se enumeran los problemas habituales relacionados con la instalación o la actualización de la versión del Config Connector.

Versión no compatible en las instalaciones del complemento de Config Connector

Síntoma

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.

El mensaje de error también aparece si la federación de identidades para cargas de trabajo para GKE o GKE Monitoring están inhabilitados.

Causa

La versión del clúster de GKE no cumple con los requisitos o las funciones requeridas están inhabilitadas.

Solución

Para resolver este error, verifica que la versión del clúster de GKE cumpla con los requisitos de versión y función. Asegúrate de que Workload Identity Federation for GKE y la supervisión de GKE estén habilitadas.

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.

failed calling webhook

Síntoma

No puedes desinstalar Config Connector y 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

Causa

Este problema puede ocurrir cuando se usa el complemento de Config Connector y se inhabilita Config Connector antes de quitar las CRD de Config Connector.

Solución

Para resolver este error, primero debes borrar los webhooks de forma manual:

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.

PodSecurityPolicy impide las actualizaciones

Síntoma

Después de cambiar del complemento de Config Connector a una instalación manual y actualizar Config Connector a una versión nueva, los Pods de cnrm no se actualizan.

Causa

El uso de PodSecurityPolicies puede impedir que se actualicen los Pods de cnrm.

Para confirmar que las PodSecurityPolicies impiden la actualización, verifica 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]

Solución

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

Configuración

En la siguiente sección, se enumeran los problemas habituales relacionados con la configuración de recursos.

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) pueden quedarse bloqueadas 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 cuando se actualizaban los campos inmutables cuando no hay actualizaciones

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 podría no significar que realmente actualizaste el recurso, pero el motivo podría ser que la API de Google Cloud realizó un cambio en un campo inmutable que administraste en el recurso de Config Connector. Esto causó 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 de 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 en vivo 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.

No hay coincidencias para el tipo "RESOURCE_KIND"

Síntoma

Verás el error No matches for kind "RESOURCE_KIND".

Causa

Tu clúster de Kubernetes no tiene instalada la CRD para el tipo de recurso RESOURCE_KIND.

Solución

Verifica que el tipo sea un tipo de recurso compatible con Config Connector.

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

Si instalaste Config Connector con el complemento de GKE, tu 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 del Config Connector (por ejemplo, aquí se muestran los tipos compatibles con Config Connector v1.44.0).

Las etiquetas no se propagan al recurso Google Cloud

Síntoma

Las etiquetas de tu archivo YAML no aparecen en el recurso Google Cloud .

Causa

No todos los recursos de Google Cloud admiten etiquetas.

Solución

Config Connector propaga las etiquetas que se encuentran en metadata.labels al recurso Google Cloud subyacente. Consulta la documentación de la API de REST del recurso (por ejemplo, aquí tienes la documentación de la API para PubSubTopic) para ver si admiten etiquetas.

Error debido a caracteres especiales en el nombre del recurso

Síntoma

Verás un error relacionado con caracteres no válidos en metadata.name:

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

Causa

Los caracteres especiales no son válidos en el campo metadata.name de Kubernetes.

Solución

Si deseas asignarle a tu recurso un nombre que no sea un nombre de Kubernetes válido, pero que sea un nombre de recurso de Google Cloud válido, 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: [e-mail]

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

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

Síntoma

Quitar un campo de la especificación de un recurso de Config Connector no lo quita del recurso.

Causa

Quitar un campo de la especificación de un recurso administrado por Config Connector no hace que ese campo quede vacío ni que se revierta a un valor predeterminado. En cambio, hace que ese campo se administre de forma externa.

Nota: Hay una excepción: los campos dentro de las listas. Las listas son atómicas, lo que significa que el Config Connector intentará establecer la lista en el Google Cloud subyacente para que sea equivalente a la que se especifica en la especificación.

Solución

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

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

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

  spec:
    targetServiceAccounts:
      - external: "[e-mail]"
      - external: "[e-mail]"
  

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

  spec:
    targetServiceAccounts: []
  

• Para el campo de tipo primitivo, establece el campo 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: "example-project.svc.id.goog"
  

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

  spec:
    workloadIdentityConfig:
      identityNamespace: ""
  

• En el caso de los campos de tipo de objeto, puedes intentar establecer los subcampos del tipo de objeto como vacíos o predeterminados siguiendo las instrucciones de la sección anterior y verificar si funciona. Sin embargo, no se garantiza que esto funcione.

Valor no válido "merge" para la anotación state-into-spec

Este problema se produce cuando un recurso usa la anotación cnrm.cloud.google.com/state-into-spec: merge, pero el tipo de recurso o la versión de Config Connector rechazan el valor merge.

Síntoma

Tu recurso de Config Connector no se concilia con un mensaje de error similar al siguiente:

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

Causa

Este error ocurre por uno de los siguientes motivos:

• El tipo de recurso no admite el comportamiento Merge, pero el recurso tiene la anotación cnrm.cloud.google.com/state-into-spec: merge. Esta anotación se puede establecer directamente en el recurso o heredarse del parámetro de configuración spec.stateIntoSpec: Merge en tu CR de ConfigConnector o ConfigConnectorContext. Los CRD agregados en la versión 1.114.0 y posteriores del Config Connector solo admiten el comportamiento Absent.
• Actualizaste a la versión 1.134.0 o 1.134.1 de Config Connector y tienes un recurso SQLInstance existente que tenía la anotación cnrm.cloud.google.com/state-into-spec: merge de forma predeterminada de una versión anterior. Las versiones 1.134.0 y 1.134.1 tenían un problema conocido que rechazaba el valor merge en los recursos de SQLInstance.

Solución

Para resolver este problema, completa los pasos que se aplican a tu situación:

• Tu tipo de recurso no admite el comportamiento Merge: establece la anotación cnrm.cloud.google.com/state-into-spec: absent en el manifiesto YAML de tu recurso y establece el campo spec.stateIntoSpec en Absent en tu CR ConfigConnector o ConfigConnectorContext. Para verificar si tu tipo de recurso admite el comportamiento Merge, consulta Tipos con compatibilidad con Merge. Si la anotación ya está presente en un recurso existente en el clúster, sigue los pasos que se indican en Migra recursos de Merge a Absent.
• Si usas un recurso SQLInstance existente en la versión 1.134.0 o 1.134.1 de Config Connector, actualiza Config Connector a la versión 1.134.2 o una posterior. Como alternativa, migra el recurso SQLInstance a la anotación cnrm.cloud.google.com/state-into-spec: absent siguiendo los pasos que se indican en Migra recursos de Merge a Absent.

Config Connector no se inicia en los nodos basados en Arm

Si tu clúster contiene grupos de nodos que usan la arquitectura Arm (como las series de máquinas C4A, N4A o Tau T2A), es posible que los componentes de Config Connector no se ejecuten. Esta es una limitación conocida, ya que el Config Connector no admite sistemas basados en Arm.

Síntomas

Si tu instancia de Config Connector se ve afectada por este problema, es posible que experimentes los siguientes síntomas:

• Los Pods en el espacio de nombres cnrm-system permanecen en el estado Pending.
• Los Pods pueden mostrar un CrashLoopBackOff con un mensaje de error en los registros similar al siguiente: exec user process caused "exec format error".
• La descripción del Pod revela fallas de programación o discrepancias en la arquitectura.

Solución

Para resolver este problema, asegúrate de que los componentes de Config Connector estén programados en nodos con arquitectura x86:

• Agrega un grupo de nodos x86: Si tu clúster solo contiene nodos Arm, agrega al menos un grupo de nodos con un tipo de máquina x86 (como e2-standard-2) para alojar los Pods del controlador de Config Connector.
• Verifica los taints de los nodos: Los nodos de GKE Arm suelen tener taints con kubernetes.io/arch=arm64:NoSchedule para evitar que se programen en ellos cargas de trabajo solo para x86. Asegúrate de no haber agregado tolerancias a las implementaciones de Config Connector que les permitirían ejecutarse en estos nodos.

Limpieza forzada

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

Advertencia: Esta operación debe realizarse como último recurso, ya que las eliminaciones de los finalizadores están fuera de los límites del uso normal de Config Connector y podrían tener consecuencias no deseadas. En particular, no hay garantías de lo que sucede con los recursos de Google Cloud subyacentes.

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 necesario) que Config Connector no tenga la oportunidad de completar la eliminación del recurso Google Cloud subyacente. Esto significa que, después, es posible que quieras borrar tus recursos de Google Cloud de forma manual.

Supervisión

Supervisar el Config Connector y explorar sus registros puede ayudarte a determinar el origen de los problemas y a comprender mejor cualquier comportamiento inesperado.

Métricas

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

Logging

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

Los registros de los Pods del controlador son particularmente ú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 de 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 Logging para realizar consultas de registros avanzadas

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

Nota: La sintaxis de consulta no admite comentarios. En la siguiente consulta, se usa una convención de comentarios, # comment, para proporcionar texto explicativo, pero estos comentarios no se pueden incluir en las consultas.

# 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 por la ubicación del clúster de GKE que ejecuta Config Connector. Por ejemplo, us-central1
• RESOURCE_KIND por 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 presentar un problema en GitHub o comunicarte con el equipo de asistencia deGoogle Cloud .