Problemas conocidos del Sincronizador de configuración

En esta página, se enumeran los problemas conocidos de las versiones compatibles del Sincronizador de configuración.

Se corrigieron muchos de los problemas que se enumeran aquí. La columna Fixed version indica la versión en la que se introdujo la corrección. Para recibir esta corrección, actualiza a la versión que aparece en la lista o a una posterior.

Si formas parte del Programa para desarrolladores de Google, guarda esta página para recibir notificaciones cuando se publique una nota de la versión relacionada con esta página. Para obtener más información, consulta Páginas guardadas.

Para filtrar los problemas conocidos por una versión del producto o una categoría de problema, selecciona tus filtros en los siguientes menús desplegables.

Selecciona tu versión del Sincronizador de configuración:

1.19 1.18 1.17 1.16 1.15 1.13

Selecciona la categoría de tu problema:

Estado de los componentes Errores de KNV Métricas Herramienta de línea de comandos nomos Acciones Fuente de información Sincronizando Registro privado Terraform Consola de Google Cloud

También puedes filtrar los problemas conocidos:

Categoría	Versión identificada	Versión corregida	Problema y solución
Estado de los componentes	1.15.0		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.
Métricas	1.15.0	1.17.2	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.
Métricas	1.15.0		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.
Métricas	1.15.0		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.
CLI de nomos	1.15.0	1.17.2	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.
Acciones			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.
Acciones			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.
Fuente de información	1.17.3	1.18.3	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: [e-mail]: Permission denied (publickey).\r\nfatal: Could not read from remote repository. Solución alternativa: Usa otro método de autenticación.
Fuente de información	1.15.0	1.18.0	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.
Fuente de información	1.15.0	1.17.0	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.
Fuente de información	1.13.0		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 Reemplaza RECONCILER_NAME por el nombre del agente de conciliación del objeto RootSync o RepoSync.
Fuente de información	1.19.0	1.20.0	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 Reemplaza RECONCILER_NAME por el nombre del agente de conciliación del objeto RootSync o RepoSync.
Sincronizando	1.15.0		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: Debido a que el registro de auditoría no puede distinguir entre solicitudes de prueba y no de prueba, puedes ignorar las solicitudes de PATCH.
Sincronizando	1.17.0	1.17.3	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.
Registro privado		1.19.0	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.
Sincronizando	1.17.0	1.18.3	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
Terraform	Versión 5.41.0 de Terraform		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.
consola de			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.

Volver al principio

¿Qué sigue?

• Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.