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 los filtros de 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 Config Sync 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 provocó 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 falle o genere un error porque 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 entra en conflicto consigo mismo 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 de los repositorios de Cloud Source. 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 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	1.20.1	Se corrigió el problema por el que no se podía generar un 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 debe a que 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.7.0		No se respeta la anotación de ignorar mutación Un error en el aplicador de Config Sync hace que aplique cambios de las configuraciones declaradas, incluso cuando está presente la anotación client.lifecycle.config.k8s.io/mutation. Esto podría provocar que se reemplace el estado del objeto en el clúster. Solución alternativa: Para dejar de administrar el objeto administrado, agrega la anotación configmanagement.gke.io/managed: disabled. Sin embargo, inhabilitar la administración evita que el Sincronizador de configuración vuelva a crear el objeto si se borra del clúster. También evita que se apliquen más actualizaciones en la fuente de la verdad.
Sincronizando	1.5.0	1.20.1	Se corrigió el problema por el que los errores de descubrimiento de la API podían hacer que los objetos administrados se marcaran de forma incorrecta como Not Found. Si el backend de un servicio de API no está en buen estado, es posible que el descubrimiento de la API falle. Si esto ocurre mientras se inicia el controlador de ResourceGroup, después de actualizarse o reprogramarse, la caché de recursos no se inicializará, lo que hará que todos los objetos administrados se informen como Not Found en el estado de ResourceGroup. Este problema suele ocurrir cuando el metrics-server no está en buen estado. Solución alternativa: Reinicia el Pod resource-group-controller después de que metrics-server vuelva a tener un estado bueno: kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME Reemplaza RESOURCE_GROUP_CONTROLLER_NAME por el nombre del controlador de ResourceGroup, que es el mismo que el nombre de RootSync o RepoSync de ese paquete.
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 persiste, 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, Config Sync 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
Sincronizando	1.7.0		No se pudo escribir el inventario actualizado en el clúster Si el Sincronizador de configuración no actualiza el estado de un objeto ResourceGroup, es posible que encuentres un error intermitente en los registros del conciliador similar al siguiente: KNV2009: task failed (action: "Inventory", name: "inventory-set-0"): failed to write updated inventory to cluster: Operation cannot be fulfilled on resourcegroups.kpt.dev "root-sync": the object has been modified; please apply your changes to the latest version and try again Este error se debe a una condición de carrera entre el agente de conciliación y el controlador de ResourceGroup. Es posible que el controlador de ResourceGroup actualice el estado de ResourceGroup antes de que el agente de conciliación pueda actualizar la especificación de ResourceGroup, lo que genera el error KNV2009. Solución alternativa: No hay una solución alternativa para este problema. El error debería resolverse automáticamente.
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 Config Sync 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 Google Cloud			Errores de datos faltantes en el panel de Config Sync 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 Config Sync 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 el servicio de identidad de GKE 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.