El Sincronizador de configuración usa componentes alojados en Google Cloud y componentes de código abierto en tu clúster de Google Kubernetes Engine para conciliar de forma continua el estado del clúster con una fuente de información central. Comprender cómo interactúan estos componentes te ayuda a diseñar flujos de trabajo de GitOps escalables y solucionar problemas de sincronización o conciliación.
Descripción general de la arquitectura
En el siguiente diagrama, 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 flota
administra los componentes del Sincronizador de configuración en tu clúster directamente, sin el
operador ConfigManagement heredado ni el objeto ConfigManagement. Debes actualizar manualmente
el Sincronizador de configuración 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 un Deployment llamado
reconciler-manager - El controlador de ResourceGroup en un Deployment llamado
resource-group-controller-manager - El recopilador de OpenTelemetry en una implementación llamada
otel-collector - Opcional: El webhook de admisión del Sincronizador de configuración en un Deployment llamado
admission-webhook. El 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 conciliador 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 Deployment del conciliador se llamans-reconciler-REPOSYNC_NAMESPACE.
- 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 Deployment de conciliador
para cada uno. |
1 | reconciler-manager-.* |
2 | reconciler-managerotel-agent |
root-reconciler |
config-management-system |
Se crea un Deployment de conciliador 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 las solicitudes de recursos del conciliador 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.
El servicio de flota y el objeto ConfigSync
El servicio de flota de Hub administra los componentes del Sincronizador de configuración en tu clúster:
El servicio de flota también administra el objeto ConfigSync en tu clúster. El
servicio de flota actualiza la especificación del objeto ConfigSync según tus entradas
a la API de Google Cloud y su estado para reflejar el estado de los
componentes del Sincronizador de configuración.
Para realizar cambios en la configuración de la instalación del Sincronizador de configuración, debes usar la API de Google Cloud . Sin embargo, puedes usar la API de Google Cloud o 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 conciliador
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 conciliador
consta de varios contenedores. Para obtener más información sobre estos contenedores,
consulta Contenedores del conciliador.
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 de Standard:
| 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 Anula 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 opciones de configuración. Para encontrar las versiones de Helm y Kustomize empaquetadas para tu versión
del Sincronizador de configuración, consulta los campos HELM_VERSION y KUSTOMIZE_VERSION en el
Makefile del
repositorio de código abierto del Sincronizador de configuración.
Puedes cambiar entre ramas en GitHub para ver las versiones de las diferentes
versiones del Sincronizador de configuración.
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 consola de Google Cloud , Google Cloud CLI, Config Connector o Terraform, el servicio de flota lo administra, según tus entradas a la API de Google Cloud .
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 la
API deGoogle Cloud , 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.