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 habituales 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 haz una consulta cruzada con 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 si inspeccionas 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, verifica 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 Config Connector instalado en el modo de espacio de nombres, tendrás un pod 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 de 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 Config Connector instalado en el modo de espacio de nombres, el comando anterior muestra los registros de todos los pods de controlador combinados. Puedes verificar los registros del Pod del controlador de un espacio de nombres específico si ejecutas 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 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. Abandonar 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.

Problemas comunes

El recurso se sigue actualizando cada 5 a 15 minutos

Si tu recurso de Config Connector sigue cambiando de un estado UpToDate a un estado Updating cada 5 a 10 minutos, es probable que Config Connector detecte 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, canalización de CI/CD, controladores personalizados, trabajos de cron, etcétera).

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, la mayúscula) de los valores de campo, lo que genera una diferencia entre el estado deseado y el 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 coincidan. En particular, busca los valores que Google Cloudvolvió a dar formato. 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 bloqueen en Terminating si tienes instalado Config Connector en el modo con espacio de nombres y si se borró el ConfigConnectorContext del espacio de nombres antes de borrar 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 de Config Connector restantes en ese espacio de nombres.

Para solucionar este problema, debes realizar una limpieza forzada y, luego, borrar manualmente 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 de su espacio de nombres de Kubernetes. Evita borrar espacios de nombres completos antes de borrar todos los recursos de Config Connector en ese espacio de nombres, ya que es posible que se borre primero el ConfigConnectorContext.

También puedes ver cómo se puede bloquear la eliminación 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 quedaron en "DeleteFailed" después de borrar el proyecto.

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

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, borra solo 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 los metadatos de Compute Engine no están definidos, es probable que la cuenta de servicio de IAM que usa Config Connector no exista.

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

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é habilitada 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 debe 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 la federación de identidades para cargas 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, 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 los 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 Workload Identity Federation for GKE, es probable que eso signifique que a la cuenta de servicio de Kubernetes de Config Connector le faltan los permisos de IAM adecuados para robar la identidad de tu cuenta de servicio de IAM como usuario de Workload Identity Federation for 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 solucionar y mitigar el problema en el futuro, consulta las instrucciones de instalación de Config Connector.

Error 403: Falta el permiso de IAM del llamador

Si tu recurso de Config Connector tiene un 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 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 comprueba 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 centrados en el proyecto.

Si sigues viendo el mismo error, verifica si la federación de identidades para cargas de trabajo para 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 es compatible con 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) pueden bloquearse mientras actualizan un recurso si no manejan errores de admisión.

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

Se produce un error cuando se actualizan 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 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. Abandonar el recurso de Config Connector
4. Imprime el estado activo del Google Cloud recurso 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 el conector de configuración no se esté ejecutando correctamente. Verifica 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 compatible con 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, 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 cada versión de Config Connector (por ejemplo, aquí se muestran los tipos compatibles con la versión 1.44.0 de Config Connector).

Las etiquetas no se propagan al Google Cloud recurso.

Config Connector propaga las etiquetas que se encuentran en metadata.labels al recursoGoogle Cloud subyacente. Sin embargo, ten en cuenta que no todos los recursos Google Cloud admiten etiquetas. Consulta la documentación de la API de REST del recurso (por ejemplo, esta es la documentación de la API de PubSubTopic) para ver si admiten etiquetas.

No se pudo llamar al webhook x509: el certificado depende del campo de 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

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

Para solucionar este problema, borra los certificados y los pods relevantes:

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 volverá a generar 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: [e-mail]
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 "[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 deseas asignarle un nombre a tu recurso que no sea un nombre válido de Kubernetes, pero que sea un nombre de recurso 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 de recursos.

Quitar 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 quita 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.

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

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 de recursos de Config Connector:

• Para el campo de tipo de lista, configura el campo como 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 en 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
  string	""
  bool	"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 en vacío:

  spec:
    workloadIdentityConfig:
      identityNamespace: ""
  

• En el caso de los campos de tipo de objeto, actualmente en Config Connector no hay una manera fácil 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 las instrucciones anteriores y verificar si funcionan.

KNV2005: El sincronizador actualiza el recurso de forma excesiva.

Si usas Config Sync y ves errores KNV2005 para recursos de Config Connector, es probable que Config Sync 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 Config Sync y Config Connector están "luchando" por un recurso si siguen actualizando los mismos campos a 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 que se especifican en el Sincronizador de configuración, mientras que 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 nunca deberían terminar actualizando el mismo campo a diferentes valores.

Hay una excepción: los campos de lista. Al igual que Config Connector puede establecer subcampos predeterminados en los campos de objetos, también puede establecer subcampos predeterminados en objetos dentro de listas. Sin embargo, como 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 completo del valor de la lista.

Por lo tanto, Config Sync y Config Connector terminarán en conflicto si Config Sync establece un campo de lista y Config Connector establece de forma predeterminada cualquier subcampo dentro de esa lista.

Para solucionar este problema, tienes las siguientes opciones:

1. Actualiza el manifiesto de recursos en el repositorio de Config Sync para que coincida con lo que Config Connector intenta configurar en el recurso.

   Una forma de hacerlo es detener temporalmente la sincronización de configuraciones, esperar a que Config Connector termine de conciliar el recurso y, luego, actualizar el manifiesto de recursos para que coincida con el recurso del 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, configura la anotación client.lifecycle.config.k8s.io/mutation como ignore. Obtén más información para hacer que el Sincronizador de configuración omita las mutaciones de objetos.

3. Para evitar que Config Connector actualice por completo las especificaciones del recurso, configura la anotación cnrm.cloud.google.com/state-into-spec como 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 esté en un estado en el que no puedas desinstalarlo. Esto suele ocurrir cuando se usa el complemento de Config Connector y se inhabilita antes de quitar las CRD de Config Connector. Cuando intentas desinstalarlo, 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 desinstalar Config Connector.

Error de actualización con IAMPolicy, IAMPartialPolicy y IAMPolicyMember

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á encontrar la cuenta de servicio a la que se hace referencia en esos recursos de IAM durante la conciliació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 debes limpiar los recursos relacionados de IAM Config Connector. Para IAMPolicyMember, borra todo el recurso. Para IAMPolicy y IAMParitialPolicy, quita solo las vinculaciones que involucren la cuenta de servicio borrada. Sin embargo, esa limpieza no quita las vinculaciones de roles de Google Cloud de inmediato. Las vinculaciones de roles Google Cloud se retienen 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.

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

Google Cloud Google Cloud

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 error 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 notes solicitudes de eliminación del administrador de controladores de Config Connector en ciertos recursos 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 conciliarlas.

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.

A modo de ejemplo, si usas GKE, puedes usar Cloud Logging para consultar los registros de auditoría del clúster 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, 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 (OOM).

Si ves un error OOMKilled en un Pod de controlador de Config Connector, significa que se cerró un contenedor o todo el Pod porque usó más memoria de la permitida. Para verificar esto, ejecuta el comando kubectl describe. El estado del pod puede aparecer como OOMKilled o Terminating. Además, el análisis de los registros de eventos del Pod puede revelar cualquier ocurrencia de eventos relacionados con la OOM.

kubectl describe pod POD_NAME -n cnrm-system

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

Para abordar 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 cnrm.

Para confirmar que PodSecurityPolicies impide 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 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 eliminarlos de tu clúster de Kubernetes, puedes forzar su eliminación borrando sus finalizadores.

Advertencia: Esta operación se debe realizar como último recurso, ya que las eliminaciones de 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 sobre lo que sucede con los Google Cloud recursos

subyacentes.

Para borrar los finalizadores de un recurso, edita el recurso con kubectl edit, borra el campo metadata.finalizers y, luego, guarda el archivo para preservar los cambios en el servidor de la API de Kubernetes.

Dado que borrar los finalizadores de un recurso permite que se borre de inmediato del clúster de Kubernetes, es posible que Config Connector no (pero no siempre) tenga la oportunidad de completar la eliminación del recursoGoogle Cloud subyacente. Esto significa que te recomendamos que borres manualmente tus recursos Google Cloud después.

Supervisión

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.

Para consultar registros de recursos específicos, filtra 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 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:

Nota: La sintaxis de consulta no admite comentarios. En la siguiente consulta, se 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"

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 .