En esta página, se presenta la arquitectura del Sincronizador de configuración, incluidos los componentes alojados que se ejecutan en Google Cloud y los componentes de código abierto que se ejecutan en tu clúster de Google Kubernetes Engine. Conocer la arquitectura puede ayudarte a comprender mejor el Sincronizador de configuración y a depurar y corregir los problemas que encuentres.
En la siguiente sección, se muestra la arquitectura del Sincronizador de configuración, incluidos sus componentes y dependencias, tanto en Google Cloud como en tu clúster de GKE:
El servicio de Fleet administra los componentes de Sincronizador de configuración en tu clúster directamente, sin el operador ConfigManagement heredado ni el objeto ConfigManagement. Debes actualizar el Sincronizador de configuración de forma manual según sea necesario.
Existen varios pasos para instalar el Sincronizador de configuración, y cada uno de ellos implementa componentes adicionales en tu clúster:
Cuando habilitas el Sincronizador de configuración en tu clúster, se agregan los siguientes componentes:
- La definición de recurso personalizado (CRD)
ConfigSync - Un objeto
ConfigSyncllamadoconfig-sync. - El administrador de conciliadores en una implementación llamada
reconciler-manager - El controlador de ResourceGroup en una implementación llamada
resource-group-controller-manager - El recopilador de OpenTelemetry en una implementación llamada
otel-collector - Opcional: El webhook de admisión de Sincronizador de configuración en una Deployment llamada
admission-webhookEl webhook de admisión del Sincronizador de configuración solo se instala si habilitas la prevención de desvíos.
Estos recursos y objetos se crean automáticamente cuando instalas el Sincronizador de configuración y no se deben modificar directamente.
- La definición de recurso personalizado (CRD)
La creación de objetos
RootSyncyRepoSyncagrega los siguientes componentes:- Para cada objeto
RootSync, un objeto Deployment de reconciliador llamadoroot-reconciler-ROOTSYNC_NAMEPara el objetoRootSyncllamadoroot-sync, el objeto Deployment del reconciliador se llamaroot-reconciler. - Para cada objeto
RepoSync, un objeto Deployment de reconciliador llamadons-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTHPara el objetoRepoSyncllamadorepo-sync, el objeto Deployment del reconciliador se llamans-reconciler.
- Para cada objeto
Implementaciones, pods y contenedores del Sincronizador de configuración
En la siguiente tabla, se proporciona más información sobre la implementación, los pods y los contenedores del Sincronizador de configuración:
| Nombre de la implementación | Espacio de nombres de la implementación | Descripción de la implementación | Recuento de réplicas | Expresión regular del nombre del pod | Cantidad de contenedores | Nombres de los contenedores |
|---|---|---|---|---|---|---|
reconciler-manager |
config-management-system |
El Administrador de reconciliadores se ejecuta en todos los clústeres con el Sincronizador de configuración habilitado en el objeto ConfigManagement. Supervisa los objetos RootSync y RepoSync, y administra una implementación de conciliador para cada uno. |
1 | reconciler-manager-.* |
2 | reconciler-managerotel-agent |
root-reconciler |
config-management-system |
Se crea una implementación de reconciliador raíz para cada objeto RootSync. |
1 | root-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
ns-reconciler |
config-management-system |
Se crea una implementación de un conciliador de espacios de nombres para cada objeto RepoSync. |
1 | ns-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
otel-collector |
config-management-monitoring |
El recopilador de OpenTelemetry se ejecuta en todos los clústeres con el Sincronizador de configuración habilitado en el objeto ConfigManagement.
Recopila métricas de los componentes del Sincronizador de configuración que se ejecutan en los espacios de nombres config-management-system y resource-group-system, y las exporta a Prometheus y Cloud Monitoring. |
1 | otel-collector-.* |
1 | otel-collector |
resource-group-controller-manager |
resource-group-system |
El controlador de grupos de recursos se ejecuta en todos los clústeres con el Sincronizador de configuración habilitado en el objeto ConfigManagement. Supervisa los objetos ResourceGroup y los actualiza con el estado de conciliación actual de cada objeto en su inventario. Se crea un objeto ResourceGroup para cada objeto RootSync y RepoSync para inventariar la lista de objetos que aplica el agente de conciliación desde la fuente de la verdad. |
1 | resource-group-controller-manager-.* |
2 | managerotel-agent |
admission-webhook |
config-management-system |
El webhook de admisión del Sincronizador de configuración se ejecuta en cada clúster con la prevención de desvíos habilitada en el objeto ConfigManagement. Supervisa
las solicitudes a la API de Kubernetes y evita la modificación o eliminación de
recursos administrados por el Sincronizador de configuración. El webhook de admisión del Sincronizador de configuración está inhabilitado de forma predeterminada. |
2 | admission-webhook-.* |
1 | admission-webhook |
1 Para obtener detalles sobre cuándo se crean estos contenedores, consulta Contenedores de Reconciler.
Solicitudes de recursos de Deployment
En la siguiente tabla, se enumeran los requisitos de los recursos de Kubernetes para los componentes del Sincronizador de configuración. Para obtener más información, consulta Administración de recursos para Pods y contenedores en la documentación de Kubernetes.
Las solicitudes de recursos son las mismas para todas las versiones compatibles del Sincronizador de configuración.
| Nombre de la implementación | Solicitud de CPU (m) por réplica | Solicitud de memoria (Mi) por réplica |
|---|---|---|
config-management-operator |
100 | 200 |
resource-group-controller-manager |
110 | 300 |
admission-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (uno por RootSync y RepoSync) |
Consulta reconciler resource requests para obtener más detalles. | |
1 El webhook de admisión tiene dos réplicas. Si usas el webhook de admisión y necesitas calcular el total de solicitudes de recursos, duplica el valor. El webhook de admisión está inhabilitado de forma predeterminada.
Componentes clave
En las siguientes secciones, se exploran los componentes importantes del Sincronizador de configuración con mayor detalle.
Servicio de flota y el objeto ConfigSync
En la versión 1.20.0 y posteriores del Sincronizador de configuración, el servicio de flota de Hub administra los componentes del Sincronizador de configuración en tu clúster directamente:
El servicio de Fleet también administra el objeto ConfigSync en tu clúster. El servicio de flota actualiza tanto la especificación del objeto ConfigSync según tus entradas a la API de Google Cloud como su estado para reflejar el estado de los componentes del Sincronizador de configuración.
Para realizar cambios en la configuración de instalación del Sincronizador de configuración, debes usar la API de Google Cloud . Sin embargo, puedes usar la API de Google Cloudo la API de Kubernetes para supervisar la configuración y el estado de tu instalación del Sincronizador de configuración.
Administrador de reconciliadores y reconciliadores
El Administrador de reconciliadores es responsable de crear y administrar los reconciliadores individuales que garantizan que la configuración de tu clúster permanezca sincronizada.
El administrador de conciliadores crea un conciliador raíz para cada objeto RootSync y un conciliador de espacio de nombres para cada objeto RepoSync. El Sincronizador de configuración usa este diseño en lugar de compartir un solo reconciliador monolítico porque mejora la confiabilidad, ya que reduce los puntos únicos de fallo y permite que los reconciliadores individuales se escalen de forma independiente.
Los reconciliadores de raíz y espacio de nombres recuperan automáticamente la configuración de tu fuente de verdad y la aplican para aplicar el estado que deseas dentro de tu clúster.
En los siguientes diagramas, se muestra cómo el administrador de conciliadores controla el ciclo de vida de cada conciliador raíz y conciliador de espacio de nombres:
Contenedores de Reconciler
Los contenedores específicos que se implementan en los Pods del reconciliador dependen de las opciones de configuración que elijas. En la siguiente tabla, se explica con más detalle lo que hace cada uno de estos contenedores de reconciliador y la condición que hace que el Sincronizador de configuración los cree:
| Nombre del contenedor | Descripción | Afección |
|---|---|---|
reconciler |
Controla la sincronización y la corrección de la deriva. | Siempre están habilitados. |
otel-agent |
Recibe métricas de los otros contenedores de reconciliador y las envía al recopilador de OpenTelemetry. | Siempre están habilitados. |
git-sync |
Extrae los archivos de configuración de tu repositorio de Git a un directorio local que el contenedor del conciliador puede leer. | Se habilita cuando spec.sourceType es git. |
helm-sync |
Extrae y renderiza gráficos de Helm de tu repositorio de gráficos a un directorio local que el contenedor del conciliador puede leer. | Se habilita cuando spec.sourceType es helm. |
oci-sync |
Extrae imágenes de OCI que contienen tus parámetros de configuración de tu registro de contenedores a un directorio local que el contenedor del conciliador puede leer. | Se habilita cuando spec.sourceType es oci. |
gcenode-askpass-sidecar |
Almacena en caché las credenciales de Git del servicio de metadatos de GKE para que las use el contenedor git-sync. |
Se habilita cuando spec.sourceType es git y spec.git.auth es gcenode o gcpserviceaccount. |
hydration-controller |
Controla la compilación de configuraciones de Kustomize en un directorio local que el contenedor del conciliador puede leer. | Se habilita cuando la fuente incluye un archivo kustomize.yaml. |
Como se muestra en la tabla anterior, por lo general, puedes esperar un recuento de contenedores de
tres a cinco en cada Pod de reconciliador. Los contenedores reconciler y otel-agent siempre están presentes. Especificar un tipo para tu fuente de información determina qué contenedor de sincronización se agrega. Además, se crean los contenedores hydration-controller y gcenode-askpass-sidecar si realizaste los cambios de configuración que se mencionan en la tabla.
Solicitudes de recursos del reconciliador
Para cada objeto RootSync y RepoSync, el Sincronizador de configuración crea una implementación de conciliador independiente para controlar la sincronización. La implementación del reconciliador consta de varios contenedores. Para obtener más información sobre estos contenedores, consulta Contenedores de Reconciler.
Las solicitudes de recursos son las mismas para todas las versiones compatibles del Sincronizador de configuración.
En la siguiente tabla, se enumeran las solicitudes de recursos para los clústeres estándar:
| Nombre del contenedor | Solicitud de CPU (m) | Solicitud de memoria (Mi) |
|---|---|---|
reconciler |
50 | 200 |
otel-agent |
10 | 100 |
hydration-controller (Opcional) |
10 | 100 |
git-sync |
10 | 16 |
gcenode-askpass-sidecar (Opcional) |
10 | 20 |
helm-sync |
75 | 128 |
oci-sync |
25 | 32 |
En la siguiente tabla, se enumeran las solicitudes de recursos para los clústeres de Autopilot:
| Nombre del contenedor | Solicitud y límite de CPU (m) | Solicitud y límite de memoria (Mi) |
|---|---|---|
reconciler |
700 | 512 |
otel-agent |
10 | 64 |
hydration-controller (Opcional) |
200 | 256 |
git-sync |
20 | 32 |
gcenode-askpass-sidecar (Opcional) |
50 | 64 |
helm-sync |
250 | 384 |
oci-sync |
50 | 64 |
Para obtener más información sobre cómo anular las solicitudes y los límites de recursos predeterminados, consulta Cómo anular las solicitudes y los límites de recursos.
Versiones de Helm y Kustomize en paquetes
El Sincronizador de configuración aprovecha los ejecutables de Helm y Kustomize para renderizar las configuraciones. En la siguiente tabla, se proporciona una lista de las versiones del Sincronizador de configuración que admiten la función de procesamiento, junto con las versiones de Helm y Kustomize empaquetadas.
| Versiones del Sincronizador de configuración | Versión de Helm | Versión de Kustomize |
|---|---|---|
| 1.22.0 | v3.15.3 | v5.3.0 |
| 1.21.0 | v3.15.3 | v5.3.0 |
| 1.20.0 | v3.15.3 | v5.3.0 |
Para obtener información sobre cómo renderizar Helm a través de Kustomize, consulta Configura Kubernetes con Kustomize. Para obtener información sobre el uso de la API de Helm, consulta Sincroniza gráficos de Helm desde Artifact Registry.
Controlador de ResourceGroup y objetos ResourceGroup
Los reconciliadores de raíz y espacio de nombres crean un objeto de inventario ResourceGroup para cada objeto RootSync y RepoSync que configures. Cada objeto ResourceGroup contiene una lista de objetos sincronizados con el clúster desde la fuente de información por el agente de conciliación de ese objeto RootSync o RepoSync. Luego, el controlador de ResourceGroup supervisa todos los objetos del objeto ResourceGroup y actualiza el estado del objeto ResourceGroup con el estado de conciliación actual de los objetos sincronizados. Esto te permite comprobar el estado del objeto ResourceGroup para obtener una descripción general del estado de sincronización, en lugar de tener que consultar el estado de cada objeto individual por tu cuenta.
Los objetos ResourceGroup tienen el mismo nombre y espacio de nombres que su objeto RootSync o RepoSync correspondiente. Por ejemplo, para el objeto RootSync con el nombre root-sync en el espacio de nombres config-management-system, el objeto ResourceGroup correspondiente también se llama root-sync en el espacio de nombres config-management-system.
No crees ni modifiques objetos ResourceGroup, ya que esto puede interferir con el funcionamiento del Sincronizador de configuración.
Webhook de admisión
El webhook de admisión del Sincronizador de configuración se crea cuando habilitas la prevención de desvíos. La prevención de desvíos intercepta de forma proactiva las solicitudes de modificación para garantizar que se alineen con la fuente de información antes de permitir los cambios.
Si no habilitas la prevención de desvíos, el Sincronizador de configuración seguirá usando un mecanismo de autorecuperación para revertir el desvío de configuración. Con la autorreparación, el Sincronizador de configuración supervisa de forma continua los objetos administrados y revierte automáticamente cualquier cambio que se desvíe del estado previsto.
Objetos RootSync y RepoSync
Los objetos RootSync configuran el Sincronizador de configuración para crear un conciliador raíz que supervise la fuente de información especificada y aplique objetos de esa fuente al clúster. De forma predeterminada, el conciliador raíz de cada objeto RootSync tiene permiso cluster-admin. Con
este permiso predeterminado, los conciliadores raíz pueden sincronizar recursos con permiso de clúster y
con permiso de espacio de nombres. Si es necesario, puedes cambiar estos permisos configurando los campos spec.override.roleRefs. Los objetos RootSync están diseñados para que los usen los administradores de clústeres.
Los objetos RepoSync configuran el Sincronizador de configuración para crear un conciliador de espacio de nombres que supervise la fuente especificada y aplique objetos de esa fuente a un espacio de nombres específico en el clúster. Los reconciliadores de espacios de nombres pueden sincronizar cualquier recurso con alcance de espacio de nombres en ese espacio de nombres con permisos personalizados especificados por el usuario. Los objetos RepoSync están diseñados para que los usen los usuarios del espacio de nombres.
Cómo el servicio de flota administra los objetos RootSync
Cuando instalas el Sincronizador de configuración con la Google Cloud consola, Google Cloud CLI, Config Connector o Terraform, el servicio de flota lo administra, según tus entradas a la Google Cloud API.
Cuando el servicio de Fleet administra tu instalación de Sincronizador de configuración, puedes hacer que también administre tu objeto RootSync inicial, llamado root-sync. Esto te permite iniciar GitOps en tu clúster sin necesidad de aplicar nada directamente al clúster de forma manual. Si decides no permitir que el servicio de Fleet administre tu objeto RootSync inicial, puedes aplicar los objetos RootSync y RepoSync que desees directamente al clúster.
El objeto RootSync llamado root-sync se crea en función de las entradas que proporcionas a laGoogle Cloud API, específicamente, la sección spec.configSync de la API de config-management apply. Debido a que esta API solo expone un subconjunto de los campos RootSync, esos campos se consideran administrados en root-sync, mientras que los otros campos se consideran no administrados. Los campos administrados solo se pueden editar con la API deGoogle Cloud . Los campos no administrados se pueden editar con kubectl o cualquier otro cliente de Kubernetes.
Objetos RootSync y RepoSync adicionales
Para crear objetos RootSync o RepoSync adicionales, puedes usar la herramienta de línea de comandos kubectl o cualquier otro cliente de Kubernetes. También puedes usar el objeto root-sync inicial para administrar objetos RootSync o RepoSync adicionales con GitOps. Para ello, agrega sus manifiestos YAML a la fuente de información desde la que se configuró root-sync para sincronizarse. No se puede usar este método para administrar la configuración del root-sync inicial, ya que el servicio de flota administra algunos de sus campos. Para administrar el objeto root-sync con GitOps, usa Config Connector o Terraform. Para obtener más información sobre cómo crear objetos RootSync y RepoSync adicionales, consulta Configura la sincronización desde más de una fuente de información.
¿Qué sigue?
- Te recomendamos que supervises los componentes del Sincronizador de configuración o que revises sus registros. Para obtener una introducción, consulta Cómo usar la supervisión y los registros.
- Obtén información sobre las solicitudes de recursos para los componentes del Sincronizador de configuración.