Solucionar 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 problemas habituales que pueden surgir al usar el producto.

Técnicas básicas para solucionar problemas

Comprobar 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 comprobar que la versión que estás usando admite las funciones y los recursos que quieres usar:

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

Consultar el estado y los eventos de un recurso

Normalmente, puedes determinar el problema de tus recursos de Config Connector inspeccionando el estado de tus recursos en Kubernetes. Comprobar el estado y los eventos de un recurso es especialmente útil para determinar si Config Connector no ha podido reconciliar el recurso y por qué no lo ha hecho.

Comprobar que Config Connector se está ejecutando

Para comprobar que Config Connector se está ejecutando, verifica que todos sus pods tengan el estado READY:

kubectl get pod -n cnrm-system

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) por cada espacio de nombres, que será el responsable de gestionar los recursos de Config Connector en ese espacio de nombres.

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

Sustituye NAMESPACE por el nombre del espacio de nombres.

Consultar los registros del controlador

El pod del controlador registra información y errores relacionados con la conciliación de recursos de Config Connector.

Para consultar 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 Config Connector instalado en el modo de espacio de nombres, el comando anterior muestra los registros de todos los pods de controlador combinados. Puedes consultar los registros del pod del controlador de 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

Sustituye NAMESPACE por el nombre del espacio de nombres.

Consulta más información sobre cómo inspeccionar y consultar los registros de Config Connector.

Abandonar y adquirir el recurso

En algunos casos, es posible que tengas que actualizar un campo inmutable de un recurso. Como no puedes editar los campos inmutables, debes abandonar el recurso y, después, adquirirlo:

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

Problemas más comunes

El recurso se actualiza cada 5-15 minutos

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

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

Si el comportamiento no se debe a un sistema externo, comprueba 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 provoca una diferencia entre el estado deseado y el estado real del recurso.

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

Ten en cuenta que 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.

Las eliminaciones de espacios de nombres se quedan en el estado "Terminating"

Es posible que las eliminaciones de espacios de nombres se queden atascadas en Terminating si tienes Config Connector instalado en el modo de espacio de nombres y si se ha eliminado el ConfigConnectorContext del espacio de nombres antes de que se eliminen todos los recursos de Config Connector de ese espacio de nombres. Cuando se elimina el ConfigConnectorContext de un espacio de nombres, Config Connector se inhabilita en ese espacio de nombres, lo que impide que se eliminen los recursos de Config Connector que queden en él.

Para solucionar este problema, debes hacer una limpieza forzada y, después, eliminar manualmente los recursos subyacentes. Google Cloud

Para mitigar este problema en el futuro, elimine ConfigConnectorContext solo después de que se hayan eliminado de Kubernetes todos los recursos de Config Connector de su espacio de nombres. No elimines espacios de nombres completos antes de que se hayan eliminado todos los recursos de Config Connector de ese espacio de nombres, ya que es posible que se elimine primero ConfigConnectorContext.

Consulta también cómo se puede bloquear la eliminación de un espacio de nombres que contenga un proyecto y sus elementos secundarios o una carpeta y sus elementos secundarios.

Las eliminaciones de recursos se quedan en el estado "DeleteFailed" después de eliminar el proyecto

Las eliminaciones de recursos de Config Connector pueden quedarse atascadas en DeleteFailed si se ha eliminado su proyecto Google Cloud previamente.

Para solucionar este problema, restaura el proyecto en Google Cloud para que Config Connector pueda eliminar los recursos secundarios restantes de Kubernetes. También puedes hacer una limpieza forzada.

Para evitar este problema en el futuro, solo debes eliminar los proyectos Google Cloud una vez que se hayan eliminado todos sus recursos secundarios de Config Connector de Kubernetes. Evita eliminar espacios de nombres completos que puedan contener un recurso Project y sus recursos secundarios de Config Connector, ya que el recurso Project podría eliminarse primero.

Metadatos de Compute Engine no definidos

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

Mensaje de ejemplo de 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 solucionar el problema, comprueba que la cuenta de servicio de gestión de identidades y accesos que usa Config Connector existe.

Para evitar que vuelva a ocurrir, asegúrate de seguir las instrucciones de instalación de Config Connector.

Error 403: la solicitud no tenía suficientes ámbitos de autenticación

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

Mensaje de ejemplo de 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 el problema, sigue estos pasos:

1. Guarda la siguiente configuración de 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 has instalado Config Connector en modo con espacio de nombres, serviceAccountName debe ser cnrm-controller-manager-NAMESPACE. Sustituye 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 la federación de identidades de carga de trabajo para GKE no está habilitada en tu clúster o grupo de nodos de GKE.

6. Sal de la sesión interactiva y, a continuación, elimina 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 Workload Identity Federation para GKE habilitado.

Si sigues viendo el mismo error en un clúster de GKE con Workload Identity Federation for GKE habilitado, asegúrate de que no te hayas olvidado de habilitar también Workload Identity Federation for GKE en los grupos de nodos del clúster. Consulta más información sobre cómo habilitar Workload Identity Federation para GKE en los grupos de nodos que ya tienes. Recomendamos habilitar Workload Identity Federation for 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 llamante no tiene permiso. Consulta la documentación de Workload Identity Federation para GKE.

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

Mensaje de ejemplo de 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 solucionar el problema y evitar que vuelva a ocurrir, consulta las instrucciones de instalación de Config Connector.

Error 403: falta el permiso de gestión de identidades y accesos

Si tu recurso de Config Connector tiene el estado UpdateFailed y un mensaje que indica que falta un permiso de gestión de identidades y accesos, es probable que la cuenta de servicio de gestión de identidades y accesos que usa Config Connector no tenga el permiso de gestión de identidades y accesos que se indica en el mensaje y que se necesita para gestionar el recurso Google Cloud .

Mensaje de ejemplo de 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 conceder los permisos de gestión de identidades y accesos adecuados a tu cuenta de servicio de gestión de identidades y accesos, comprueba que el recurso se esté creando en el proyecto correcto. Comprueba el campo spec.projectRef del recurso de Config Connector (o su anotación cnrm.cloud.google.com/project-id si el recurso no admite el 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 ID de proyecto si ni el recurso ni el espacio de nombres especifican un proyecto de destino. Consulte más información sobre cómo configurar el proyecto de destino para los recursos de ámbito de proyecto.

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

Para evitar que vuelva a ocurrir, asegúrate de seguir las instrucciones de instalación de Config Connector.

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

Si no puedes habilitar el complemento Config Connector correctamente, aparece el siguiente mensaje de error: Node version 1.15.x-gke.x s unsupported. Para solucionar este error, comprueba que la versión del clúster de GKE cumpla los requisitos de versión y de funciones.

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

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

Sustituye ZONE por la zona de Compute Engine.

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

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

No se pueden hacer cambios en los campos inmutables

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

Por ejemplo, si se actualiza un campo inmutable con kubectl apply, el comando falla inmediatamente.

Esto significa que las herramientas que vuelven a aplicar recursos continuamente (por ejemplo, GitOps) pueden quedarse bloqueadas al actualizar un recurso si no gestionan los errores de admisión.

Como Config Connector no permite actualizar los campos inmutables, la única forma de hacerlo es eliminar el recurso y volver a crearlo.

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 con Config Connector: Google Cloud

• 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 ha cambiado un campo inmutable que gestionabas en el recurso de Config Connector. Google Cloud Esto ha provocado que no coincidan el estado deseado y el estado real 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 publicado. Para conseguirlo, debes seguir estos pasos:

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

El recurso no tiene ningún estado

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

No hay coincidencias para el tipo "Foo"

Cuando se produce este error, significa que tu clúster de Kubernetes no tiene instalado el CRD del 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 no está actualizada o no es válida.

Si has instalado Config Connector mediante el complemento de GKE, la instalación se actualizará automáticamente. Si has instalado Config Connector manualmente, debes realizar una actualización manual.

Consulta el repositorio de GitHub para determinar qué tipos de recursos admite cada versión de Config Connector (por ejemplo, aquí puedes ver los tipos que admite 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 recursoGoogle Cloud subyacente. Sin embargo, tenga en cuenta que no todos los recursos admiten etiquetas. Google Cloud Consulta la documentación de la API REST del recurso (por ejemplo, aquí tienes la documentación de la API de PubSubTopic) para ver si admite etiquetas.

No se ha podido llamar al webhook x509: el certificado se basa en el campo Nombre común antiguo

Si aparece un error similar al del ejemplo siguiente, es posible que haya 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

Nota: Este problema solo se produce con las versiones de Kubernetes 1.19 o posteriores. Las versiones de Config Connector 1.43 y posteriores admiten la generación automática del certificado, lo que debería evitar que se produzca este problema.

Para solucionar este problema, elimina los certificados y los pods correspondientes:

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"

Una vez que hayas eliminado estos recursos, se volverá a generar el certificado correcto.

Para obtener más información sobre este error, consulta la incidencia 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 aparece un error similar al del ejemplo siguiente, es probable que el recurso metadata.name 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: [e-mail]
spec:
  instanceRef:
    name: test-cloudsql-db
  type: "CLOUD_IAM_USER"

Si intentas crear este recurso, se produce el siguiente error:

Error from server (Invalid): error when creating "sqlusercrd.yaml": SQLUser.sql.cnrm.cloud.google.com "[e-mail]" is invalid: metadata.name: Invalid value: "[e-mail]": 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 quieres asignar a tu recurso un nombre que no sea válido para Kubernetes, pero sí para Google Cloud recursos, 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 nombre del recurso.

No se pueden quitar campos de la especificación de recursos

Si quitas un campo de la especificación de un recurso de Config Connector (actualizando el archivo .yaml del recurso y volviendo a aplicarlo, o usando kubectl edit para editar la especificación del recurso), no se quitará ese campo de la especificación del recurso de Config Connector ni del recurso Google Cloud subyacente. En su lugar, si quitas un campo de la especificación, ese campo se gestionará externamente.

Nota: Hay una excepción: los campos de las listas. Las listas son atómicas, lo que significa que Config Connector intentará definir la lista en el Google Cloudsubyacente para que sea equivalente a la especificada en el spec.

Si quiere cambiar el valor de un campo a vacío o predeterminado en el recursoGoogle Cloud subyacente, tendrá que poner a cero el campo en la especificación del recurso de Config Connector:

• En el caso de los campos de tipo lista, asigna al campo una lista vacía mediante [].

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

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

  Para quitar este campo, asigna el valor "":

  spec:
    targetServiceAccounts: []
  

• En el caso de los campos de tipo primitivo, deje el campo vacío con una de las siguientes opciones:

  Tipo	Valor vacío
  cadena	""
  bool	"false"
  entero	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, asigna el valor "":

  spec:
    workloadIdentityConfig:
      identityNamespace: ""
  

• En el caso de los campos de tipo de objeto, actualmente no hay una forma sencilla de definir un campo de tipo de objeto completo como "NULL" en Config Connector. Puedes intentar definir los subcampos del tipo de objeto como vacíos o predeterminados siguiendo las indicaciones anteriores y comprobar si funciona.

KNV2005: el sincronizador actualiza el recurso en exceso

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

Mensaje de registro de ejemplo:

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 Config Sync y Config Connector están "luchando" por un recurso si actualizan los mismos campos con valores diferentes. Una actualización activa la otra para que actúe y actualice el recurso, lo que provoca que la otra 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 Config Sync, mientras que Config Sync ignora los campos que no se especifican en Config Sync y que Config Connector establece de forma predeterminada. Por lo tanto, en la mayoría de los campos, Config Sync y Config Connector nunca deberían actualizar el mismo campo con valores diferentes.

Hay una excepción: los campos de lista. Al igual que Config Connector puede asignar valores predeterminados a los subcampos de los campos de objeto, también puede asignar valores predeterminados a los subcampos de los objetos que se encuentran en listas. Sin embargo, como los campos de lista de los recursos de Config Connector son atómicos, el valor predeterminado de los subcampos se considera como un cambio del valor de la lista por completo.

Por lo tanto, Config Sync y Config Connector acabarán enfrentándose si Config Sync define un campo de lista y Config Connector establece valores predeterminados para los subcampos de esa lista.

Para solucionar este problema, tiene las siguientes opciones:

1. Actualiza el manifiesto de recursos en el repositorio de Config Sync para que coincida con el valor que Config Connector intenta asignar al recurso.

   Una forma de hacerlo es detener temporalmente la sincronización de las configuraciones, esperar a que Config Connector termine de reconciliar el recurso y, a continuación, actualizar el manifiesto del recurso para que coincida con el recurso del servidor de la API de Kubernetes.

2. Impide que Config Sync reaccione a las actualizaciones del recurso en el servidor de la API de Kubernetes configurando la anotación client.lifecycle.config.k8s.io/mutation en ignore. Consulta más información sobre cómo hacer que Config Sync ignore las mutaciones de objetos.

3. Para evitar que Config Connector actualice por completo la especificación de un recurso, defina la anotación cnrm.cloud.google.com/state-into-spec como absent en el recurso. Esta anotación no se admite en todos los recursos. Para ver si tu recurso admite la anotación, consulta la página de referencia del recurso correspondiente. 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 Config Connector y se inhabilita Config Connector antes de eliminar los CRDs de Config Connector. Al intentar 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 eliminar 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

A continuación, puedes desinstalar Config Connector.

Error de actualización con IAMPolicy, IAMPartialPolicy y IAMPolicyMember

Si eliminas un recurso de IAMServiceAccount Config Connector antes de limpiar los recursos de IAMPolicy, IAMPartialPolicy y IAMPolicyMember que dependen de esa cuenta de servicio, Config Connector no podrá localizar la cuenta de servicio a la que se hace referencia en esos recursos de gestión de identidades y accesos durante la conciliación. Esto da como resultado el 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, comprueba tus cuentas de servicio y mira si se ha eliminado la cuenta de servicio necesaria para esos recursos de gestión de identidades y accesos. Si se elimina la cuenta de servicio, también debes limpiar los recursos de Config Connector de gestión de identidades y accesos relacionados. En el caso de IAMPolicyMember, elimina todo el recurso. En el caso de IAMPolicy y IAMParitialPolicy, solo debes quitar las vinculaciones que incluyan la cuenta de servicio eliminada. Sin embargo, esta limpieza no elimina las vinculaciones de roles de Google Cloud de inmediato. Los enlaces de rol de Google Cloud se conservan durante 60 días debido a la retención de la cuenta de servicio eliminada. Para obtener más información, consulta la documentación de gestión de identidades y accesos sobre eliminar una cuenta de servicio. Google Cloud

Nota: Si tienes algún problema durante la eliminación, es posible que tengas que hacer una limpieza forzada. Si quieres eliminar los enlaces de Google Cloud IAM de inmediato, debes eliminar manualmente los recursos subyacentes con gcloud.

Google Cloud

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

Recurso eliminado por Config Connector

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

Un error habitual es pensar que Config Connector ha iniciado y eliminado algunos de los recursos de tu clúster. Por ejemplo, si usas Config Connector, es posible que veas solicitudes de eliminación del gestor de controladores de Config Connector en determinados recursos en los mensajes de registro de contenedores 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 está intentando reconciliar las solicitudes de eliminación.

Para determinar por qué se ha eliminado un recurso, debes consultar la primera solicitud de eliminación que se envió al recurso correspondiente. La mejor forma de investigar este problema 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 de clústeres de GKE. Por ejemplo, si quieres 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, a continuación, comprobarías el authenticationInfo.principalEmail de ese mensaje de registro de eliminación para determinar la causa de la eliminación.

Controller Pod OOMKilled

Si ves un error OOMKilled en un pod de controlador de Config Connector, significa que se ha terminado un contenedor o todo el pod porque han usado más memoria de la permitida. Para verificarlo, ejecuta el comando kubectl describe. El estado del Pod puede ser OOMKilled o Terminating. Además, si analizas los registros de eventos del pod, podrás ver si se han producido eventos relacionados con OOM.

kubectl describe pod POD_NAME -n cnrm-system

Sustituye POD_NAME por el pod en el que estás buscando la causa del problema.

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 Config Connector a una instalación manual y actualizar Config Connector a una nueva versión, el uso de PodSecurityPolicies puede impedir que se actualicen los pods de cnrm.

Para confirmar que las PodSecurityPolicies 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 solucionar este problema, debes especificar la anotación en PodSecurityPolicy que corresponda 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 eliminan y solo quieres deshacerte de ellos en tu clúster de Kubernetes, puedes forzar su eliminación suprimiendo sus finalizadores.

Advertencia: Esta operación debe realizarse como último recurso, ya que la eliminación de finalizadores no forma parte del uso normal de Config Connector y podría tener consecuencias no deseadas. En concreto, no hay garantías sobre lo que ocurre con los Google Cloud recursos

subyacentes.

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

Como al eliminar los finalizadores de un recurso, este se puede eliminar inmediatamente del clúster de Kubernetes, es posible (pero no necesario) que Config Connector no tenga la oportunidad de completar la eliminación del recursoGoogle Cloud subyacente. Por lo tanto, es posible que quieras eliminar manualmente tus recursos de Google Cloud después.

Supervisión

Métricas

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

Almacenamiento de registros

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.

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

Usar Cloud Logging para realizar consultas de registros avanzadas

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

Nota: La sintaxis de las consultas no admite comentarios. La siguiente consulta usa una convención de comentarios, # comentario, 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"

Haz los cambios siguientes:

• GKE_CLUSTER_NAME con 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 con el espacio de nombres del recurso.
• RESOURCE_NAME con el nombre del recurso.

Ayuda adicional

Si necesitas más ayuda, puedes notificar un problema en GitHub o ponerte en contacto con el equipo de Asistencia deGoogle Cloud .