Problemas conocidos del Sincronizador de configuración

Reconciler no programable

Los conciliadores del Sincronizador de configuración requieren diferentes cantidades de recursos, según la configuración de RootSync o RepoSync. Algunas configuraciones requieren más recursos que otras.

Si no se puede programar un reconciliador, es posible que se deba a que se solicitan más recursos de los que están disponibles en tus nodos.

Si usas clústeres de GKE en modo estándar, las solicitudes de recursos del conciliador se establecen muy bajas. Se eligió este parámetro de configuración para permitir la programación, incluso si eso provocara una limitación y un rendimiento lento, de modo que Sincronizador de configuración funcione en clústeres y nodos pequeños. Sin embargo, en los clústeres de GKE Autopilot, las solicitudes del conciliador se establecen más altas para representar de forma más realista el uso durante la sincronización.

Solución alternativa:

GKE Autopilot o GKE Standard con el aprovisionamiento automático de nodos habilitado deberían poder ver cuántos recursos se solicitan y crear nodos del tamaño adecuado para permitir la programación. Sin embargo, si configuras manualmente los nodos o los tamaños de las instancias de nodos, es posible que debas ajustar esa configuración para que se adapte a los requisitos de recursos del Pod del reconciliador.

Se corrigió el error de exportación: Etiquetas de métricas no reconocidas

En la versión 1.15.0, el Sincronizador de configuración agregó etiquetas type y commit a muchas métricas. Estas etiquetas aumentaron la cardinalidad de las métricas, lo que aumentó la cantidad de métricas que se exportaban. También se agregó el procesamiento de atributos para filtrar estas etiquetas cuando se exporta a Cloud Monarch, pero este filtrado se configuró de forma incorrecta, lo que generó errores de transformación en los registros de otel-collector.

No se pudo realizar la exportación. Permiso denegado

De forma predeterminada, cuando el reconciler-manager detecta Application Default Credentials, otel-collector se configura para exportar métricas a Prometheus, Cloud Monitoring y Monarch.

Solución alternativa:

otel-collector registra errores si no configuraste Cloud Monitoring ni inhabilitaste Cloud Monitoring ni Cloud Monarch.

otel-collector falla con la configuración personalizada

Si intentas modificar o borrar uno de los ConfigMaps predeterminados, otel-collector o otel-collector-google-cloud, es posible que otel-collector genere un error o falle debido a que no puede cargar el ConfigMap requerido.

Solución alternativa:

Para personalizar la configuración de exportación de métricas, crea un ConfigMap llamado otel-collector-custom en el espacio de nombres config-management-monitoring.

Se corrigió el problema por el que nomos status y nomos bugreport no funcionaban en un Pod.

Antes de la versión 1.17.2 de nomos, nomos bugreport y nomos status solo podían conectarse al clúster local cuando se ejecutaban dentro de un Pod de Kubernetes. En la versión 1.17.2 de Nomos, se cambió el método de autorización para que funcione más como kubectl. Debido a este cambio, el clúster local se segmenta de forma predeterminada. Para anular la configuración, especifica la variable de entorno KUBECONFIG.

El Sincronizador de configuración se está contrarrestando

Es posible que el Sincronizador de configuración esté en una lucha de controladores. a sí mismo. Esto ocurre si configuras el valor predeterminado para un campo opcional de un recurso en el repositorio de Git. Por ejemplo, configurar apiGroup: "" como asunto de una RoleBinding genera este problema porque el campo apiGroup es opcional y el valor predeterminado es una cadena vacía. Los valores predeterminados de los campos de cadena, booleano y número entero son "", false y 0 (respectivamente).

Solución alternativa:

Quita el campo de la declaración de recursos.

El Sincronizador de configuración compite con los recursos de Config Connector

Es posible que parezca que el Sincronizador de configuración está en conflicto con Config Connector por un recurso, por ejemplo, un StorageBucket. Este problema ocurre si no configuras el valor de un campo opcional de un recurso spec.lifecycleRule.condition.withState en la fuente de la verdad.

Solución alternativa:

Para evitar este problema, agrega el campo withState=ANY en la declaración de recursos. Como alternativa, puedes abandonar y, luego, volver a adquirir el recurso con la anotación cnrm.cloud.google.com/state-into-spec: absent.

Se corrigió el error de autenticación de SSH de Git con GitHub

git-sync v4.2.1 tiene un error que quita el nombre de usuario de la URL del repositorio cuando se usa SSH, lo que hace que falle la autenticación cuando se conecta a GitHub, lo que requiere que el usuario sea git.

El mensaje de error de git es el siguiente: git-sync@github.com: Permission denied (publickey).\r\nfatal: Could not read from remote repository.

Solución alternativa:

Usa otro método de autenticación.

Se corrigió el problema de credenciales de autenticación no válidas de forma periódica para Cloud Source Repositories.

El Sincronizador de configuración puede generar errores de forma periódica cuando vence el token de autenticación del Cloud Source Repositories. Este problema se debe a que la actualización del token espera hasta que venza antes de actualizarlo.

En la versión 1.18.0 y versiones posteriores, el token se actualiza en la primera solicitud dentro de los cinco minutos posteriores al vencimiento del token. Esto evita el error de credenciales de autenticación no válidas, a menos que las credenciales no sean válidas.

Se corrigió el error de sincronización del repositorio: se superó el plazo del contexto

En versiones anteriores a la 1.17.0, el Sincronizador de configuración revisaba todo el historial del repositorio de Git de forma predeterminada. Esto podría provocar que se agote el tiempo de la solicitud de recuperación en repositorios grandes con muchos confirmaciones.

En la versión 1.17.0 y versiones posteriores, la recuperación de Git se realiza con --depth=1, que solo recupera la confirmación más reciente. Esto acelera la recuperación de fuentes, evita la mayoría de los tiempos de espera y reduce la carga del servidor de Git.

Si sigues teniendo este problema después de la actualización, es probable que tu fuente de confianza tenga muchos archivos, que el servidor de Git responda con lentitud o que haya algún otro problema de red.

No se pudo generar el token de acceso para la fuente de OCI

Cuando Config Sync está configurado para usar OCI como fuente de información confiable y autenticarse con Workload Identity Federation for GKE, es posible que, en ocasiones, encuentre errores KNV2004 temporales cuando intente autenticarse con el registro de contenedores.

Este problema se produce porque la biblioteca de oauth2 solo actualiza el token de autenticación después de que este ya venció.

El mensaje de error puede incluir el siguiente texto: "oauth2/google: unable to generate access token" o "ID Token issued at (xxx) is stale to sign-in."

Solución alternativa:

El error debería resolverse la próxima vez que el Sincronizador de configuración intente recuperar datos de la fuente de información.

Cuando el Sincronizador de configuración tiene errores varias veces, los reintentos se vuelven menos frecuentes. Para forzar al Sincronizador de configuración a que vuelva a intentarlo antes, borra el Pod del conciliador. Esta acción hace que el Sincronizador de configuración vuelva a crear el Pod del conciliador y recupere inmediatamente desde la fuente de información:

    kubectl delete pod -n config-management-system RECONCILER_NAME
    

Se corrigió el archivo de bloqueo de Git persistente

Si ves un error similar al siguiente en el contenedor git-sync, es posible que una invocación git anterior haya fallado y haya dejado un archivo de bloqueo persistente en el contenedor:

    KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...
    

Solución alternativa:

Para solucionar este problema, reinicia el Pod del conciliador afectado para darle un nuevo volumen efímero:

    kubectl delete pod -n config-management-system RECONCILER_NAME
    

Gran cantidad de solicitudes PATCH ineficaces en los registros de auditoría

El corrector del Sincronizador de configuración usa la prueba sin conexión para detectar el desvío. Esto puede hacer que las solicitudes de PATCH aparezcan en el registro de auditoría, incluso cuando PATCH no se conserva, porque el registro de auditoría no distingue entre pruebas sin conexión y solicitudes normales.

Solución alternativa:

Se corrigió el error por el que el Sincronizador de configuración no extraía la confirmación más reciente de una rama.

En las versiones 1.17.0, 1.17.1 y 1.17.2 del Sincronizador de configuración, es posible que encuentres un problema en el que el Sincronizador de configuración no extraiga la confirmación más reciente del HEAD de una rama específica cuando se hace referencia a la misma rama en varios remotos y no están sincronizados. Por ejemplo, la rama main de un repositorio remoto origin podría estar por delante de la misma rama en el repositorio remoto upstream, pero el Sincronizador de configuración solo recupera el SHA de confirmación de la última línea, que podría no ser la confirmación más reciente.

En el siguiente ejemplo, se muestra cómo podría verse este problema:

git ls-remote -q [GIT_REPOSITORY_URL] main  main^{}
244999b795d4a7890f237ef3c8035d68ad56515d    refs/heads/main               # the latest commit
be2c0aec052e300028d9c6d919787624290505b6    refs/remotes/upstream/main    # the commit Config Sync pulls from

En la versión 1.17.3 y versiones posteriores, la dependencia de git-sync se actualizó con un mecanismo de recuperación diferente.

Si no puedes actualizar, puedes configurar tu revisión de Git (spec.git.revision) en el SHA de confirmación más reciente, independientemente del valor establecido para la rama de Git (spec.git.branch). Para obtener más información sobre los parámetros de configuración de Git, consulta Configuración del repositorio de Git.

El Sincronizador de configuración no usa el registro privado para las implementaciones del reconciliador.

El Sincronizador de configuración debe reemplazar las imágenes de todas las implementaciones cuando se configura un registro privado. Sin embargo, Sincronizador de configuración no reemplaza el registro de imágenes de las imágenes en las implementaciones del reconciliador.

Solución alternativa:

Una solución alternativa a este problema es configurar el espejo del registro de imágenes en containerd.

Se corrigió el error por el que el agente de conciliación del Sincronizador de configuración generaba un bucle de falla

En las versiones 1.17.0 y posteriores del Sincronizador de configuración, es posible que encuentres un problema en el que el agente de conciliación no puede crear una configuración de REST en algunos proveedores de Kubernetes.

En el siguiente ejemplo, se muestra cómo podría verse este problema en los registros del agente de conciliación:

Error creating rest config: failed to build rest config: reading local kubeconfig: loading REST config from "/.kube/config": stat /.kube/config: no such file or directory

No se puede instalar ni actualizar el Sincronizador de configuración con Terraform

La versión 5.41.0 de Terraform introdujo un campo nuevo en google_gke_hub_feature_membership: config_sync.enabled. Debido a que el valor predeterminado de este campo es false, las instalaciones de Sincronizador de configuración fallan cuando Terraform se actualiza a la versión 5.41.0.

Solución alternativa:

• Si usas el recurso google_gke_hub_feature_membership, configura manualmente config_sync.enabled como true.
• Si usas el submódulo acm, te recomendamos que cambies a una forma alternativa de instalar el Sincronizador de configuración. Si no puedes cambiar, actualiza a la v33.0.0.

Errores de datos faltantes en el panel de Sincronizador de configuración en la consola de Google Cloud

Es posible que veas errores, como "datos faltantes" o "credenciales de clúster no válidas" para los clústeres de Sincronizador de configuración en los paneles de la consola de Google Cloud . Este problema puede ocurrir cuando no accediste a tus clústeres de GDC (VMware) o GDC (bare metal).

Solución alternativa:

Si ves este tipo de errores en la consola de Google Cloud en tus clústeres de GDC (VMware) o GDC (bare metal), asegúrate de haber accedido a ellos con GKE Identity Service o la puerta de enlace de conexión.