Arquitectura de Config Sync

En esta página se presenta la arquitectura de Config Sync, 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 entender mejor Config Sync y a depurar y solucionar los problemas que encuentres.

En la siguiente sección se muestra la arquitectura de Config Sync, incluidos sus componentes y dependencias, tanto en Google Cloud como en tu clúster de GKE:

Diagrama que muestra la relación entre los objetos y los recursos de Config Sync

El servicio Fleet gestiona directamente los componentes de Config Sync en tu clúster, sin el operador ConfigManagement ni el objeto ConfigManagement antiguos. Debes actualizar Config Sync manualmente según sea necesario.

La instalación de Config Sync consta de varios pasos, y cada uno de ellos implementa componentes adicionales en el clúster:

  1. Si habilitas Config Sync en tu clúster, se añadirán los siguientes componentes:

    • La ConfigSync definición de recurso personalizado (CRD)
    • Un objeto ConfigSync llamado config-sync.
    • El gestor de reconciliación de un despliegue llamado reconciler-manager.
    • El controlador ResourceGroup de 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 Config Sync en una implementación llamada admission-webhook. El webhook de admisión de Config Sync solo se instala si habilitas la prevención de desviaciones.

    Estos recursos y objetos se crean automáticamente al instalar Config Sync y no deben modificarse directamente.

  2. Al crear objetos RootSync y RepoSync, se añaden los siguientes componentes:

    • Por cada objeto RootSync, una implementación de reconciliador llamada root-reconciler-ROOTSYNC_NAME. En el caso del RootSync objeto llamado root-sync, la implementación del reconciliador se llama root-reconciler.
    • Por cada objeto RepoSync, una implementación de reconciliador llamada ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. En el objeto RepoSync llamado repo-sync, el reconciliador Deployment se llama ns-reconciler.

Despliegues, pods y contenedores de Config Sync

En la siguiente tabla se ofrece más información sobre Config Sync Deployment, los pods y los contenedores:

Nombre del despliegue Espacio de nombres de la implementación Descripción de la implementación Número de réplicas Expresión regular del nombre del pod Número de contenedores Nombres de los contenedores
reconciler-manager config-management-system El gestor de reconciliación se ejecuta en todos los clústeres en los que Config Sync esté habilitado en el objeto ConfigManagement. Monitoriza los objetos RootSync y RepoSync y gestiona una implementación de reconciliador para cada uno. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system Se crea un Deployment de reconciliador raíz para cada objeto RootSync. 1 root-reconciler-.* 3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    ns-reconciler config-management-system Se crea un Deployment de reconciliador de espacio de nombres para cada objeto RepoSync. 1 ns-reconciler-.* 3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    otel-collector config-management-monitoring El OpenTelemetry Collector se ejecuta en todos los clústeres con Config Sync habilitado en el objeto ConfigManagement. Recoge métricas de los componentes de Config Sync que se ejecutan en los espacios de nombres config-management-system y resource-group-system, y exporta estas métricas a Prometheus y Cloud Monitoring. 1 otel-collector-.* 1
  • otel-collector
    		•
    resource-group-controller-manager resource-group-system El controlador ResourceGroup se ejecuta en todos los clústeres con Config Sync habilitado en el objeto ConfigManagement. Monitoriza los objetos ResourceGroup y los actualiza con el estado de conciliación actual de cada objeto de su inventario. Se crea un objeto ResourceGroup para cada objeto RootSync y RepoSync con el fin de inventariar la lista de objetos aplicados por el reconciliador desde la fuente de información veraz. 1 resource-group-controller-manager-.* 2
  • manager
  • otel-agent
    		•
    admission-webhook config-management-system El webhook de admisión de Config Sync se ejecuta en cada clúster con la opción prevención de desviaciones habilitada en el objeto ConfigManagement. Monitoriza las solicitudes de la API de Kubernetes e impide que se modifiquen o eliminen los recursos gestionados por Config Sync. El webhook de admisión de Config Sync está inhabilitado de forma predeterminada. 2 admission-webhook-.* 1
  • admission-webhook
    		•

    1 Para obtener información sobre cuándo se crean estos contenedores, consulta Contenedores de reconciliación.

    Componentes clave

    En las siguientes secciones se analizan con más detalle los componentes importantes de Config Sync.

    Servicio de flota y objeto ConfigSync

    En Config Sync 1.20.0 y versiones posteriores, el servicio Hub Fleet gestiona los componentes de Config Sync de tu clúster directamente:

    Gestión de Config Sync

    El servicio Fleet también gestiona el objeto ConfigSync en tu clúster. El servicio Fleet actualiza tanto la especificación del objeto ConfigSync en función de las entradas que proporciones a la API Google Cloud como su estado para reflejar el estado de los componentes de Config Sync.

    Para cambiar la configuración de la instalación de Config Sync, debes usar la API Google Cloud . Sin embargo, puedes usar la Google CloudAPI o la API de Kubernetes para monitorizar la configuración y el estado de tu instalación de Config Sync.

    Gestor de conciliaciones y conciliadores

    Reconciler Manager se encarga de crear y gestionar los reconciliadores individuales que aseguran que la configuración de tu clúster se mantenga sincronizada.

    Reconciler Manager crea un reconciliador raíz para cada objeto RootSync y un reconciliador de espacio de nombres para cada objeto RepoSync. Config Sync usa este diseño en lugar de compartir un único reconciliador monolítico porque mejora la fiabilidad al reducir los puntos únicos de fallo y permite que los reconciliadores individuales se escalen de forma independiente.

    Los reconciliadores de raíz y de espacio de nombres obtienen automáticamente las configuraciones de tu fuente de información veraz y las aplican para imponer el estado que quieras en tu clúster.

    En los siguientes diagramas se muestra cómo gestiona Reconciler Manager el control del ciclo de vida de cada reconciliador raíz y reconciliador de espacio de nombres:

    Diagrama que muestra cómo controla el gestor de reconciliadores el reconciliador raíz Diagrama que muestra cómo el gestor de reconciliación controla el reconciliador de espacios de nombres

    Contenedores de reconciliación

    Los contenedores específicos implementados en los pods de reconciliación dependen de las opciones de configuración que elijas. En la siguiente tabla se explica qué hace cada uno de estos contenedores de reconciliación y la condición que provoca que Config Sync los cree:

    Nombre del contenedor Descripción Condición
    reconciler Gestiona la sincronización y la corrección de la deriva. Siempre habilitado.
    otel-agent Recibe métricas de los otros contenedores de reconciliación y las envía al OpenTelemetry Collector. Siempre habilitado.
    git-sync Extrae las configuraciones de tu repositorio de Git a un directorio local que el contenedor de reconciliación pueda leer. Se habilita cuando spec.sourceType es git.
    helm-sync Extrae y renderiza los gráficos de Helm de tu repositorio de gráficos en un directorio local que pueda leer el contenedor de reconciliación. Se habilita cuando spec.sourceType es helm.
    oci-sync Extrae las imágenes OCI que contienen tus configuraciones de tu registro de contenedores a un directorio local que el contenedor de reconciliación 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 Gestiona la creación de configuraciones de Kustomize en un directorio local que puede leer el contenedor de reconciliación. Se habilita cuando la fuente incluye un archivo kustomize.yaml.

    Como se muestra en la tabla anterior, normalmente puedes esperar que haya entre tres y cinco contenedores en cada pod de reconciliación. Los contenedores reconciler y otel-agent siempre están presentes. Al especificar un tipo para tu fuente de información veraz, se determina qué contenedor de sincronización se añade. Además, se crearán los contenedores hydration-controller y gcenode-askpass-sidecar si ha realizado los cambios de configuración que se mencionan en la tabla.

    Controlador ResourceGroup y objetos ResourceGroup

    Los reconciliadores de raíz y de 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 veraz por el reconciliador de ese objeto RootSync u RepoSync. A continuación, el controlador ResourceGroup monitoriza todos los objetos del objeto ResourceGroup y actualiza el estado del objeto ResourceGroup con el estado de conciliación actual de los objetos sincronizados. De esta forma, puedes consultar el estado del ResourceGroup objeto para ver un resumen del estado de la sincronización, en lugar de tener que consultar el estado de cada objeto individualmente.

    Los objetos ResourceGroup tienen el mismo nombre y espacio de nombres que sus objetos RootSync o RepoSync correspondientes. 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 en el funcionamiento de Config Sync.

    Webhook de admisión

    El webhook de admisión de Config Sync se crea cuando habilitas la prevención de desviaciones. La prevención de la deriva intercepta de forma proactiva las solicitudes de modificación, lo que asegura que se ajusten a la fuente de información veraz antes de permitir los cambios.

    Si no habilitas la prevención de la deriva, Config Sync seguirá usando un mecanismo de recuperación automática para revertir la deriva de la configuración. Con la autorreparación, Config Sync monitoriza continuamente los objetos gestionados y revierte automáticamente los cambios que se desvíen del estado previsto.

    Objetos RootSync y RepoSync

    Los objetos RootSync configuran Config Sync para crear un reconciliador raíz que monitoriza la fuente de información veraz especificada y aplica los objetos de esa fuente al clúster. De forma predeterminada, el reconciliador raíz de cada objeto RootSync tiene permiso cluster-admin. Con este permiso predeterminado, los reconciliadores raíz pueden sincronizar recursos con permiso de clúster y 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 Config Sync para crear un reconciliador de espacios de nombres que monitoriza la fuente especificada y aplica objetos de esa fuente a un espacio de nombres concreto del clúster. Los reconciliadores de espacios de nombres pueden sincronizar cualquier recurso con permisos de espacio de nombres en ese espacio de nombres con permisos personalizados especificados por el usuario. Los objetos RepoSync se han diseñado para que los usen los arrendatarios de espacios de nombres.

    Cómo gestiona el servicio Fleet los objetos RootSync

    Cuando instalas Config Sync con la Google Cloud consola, la CLI de Google Cloud, Config Connector o Terraform, el servicio Fleet gestiona Config Sync en función de las entradas que proporciones a la API Google Cloud .

    Si el servicio de flotas gestiona tu instalación de Config Sync, también puedes hacer que gestione tu objeto RootSync inicial, llamado root-sync. De esta forma, puedes iniciar GitOps en tu clúster sin tener que aplicar nada manualmente al clúster directamente. Si decides que el servicio Fleet no gestione tu objeto RootSync inicial, puedes aplicar los objetos RootSync y RepoSync que quieras directamente al clúster.

    El objeto RootSync llamado root-sync se crea a partir de los datos que introduces en la APIGoogle Cloud , concretamente en la sección spec.configSync de la API config-management apply. Como esta API solo expone un subconjunto de los RootSynccampos, estos campos se consideran gestionados en root-sync, mientras que los demás campos se consideran no gestionados. Los campos gestionados solo se pueden editar mediante laGoogle Cloud API. Los campos no gestionados se pueden editar con kubectl o con cualquier otro cliente de Kubernetes.

    Objetos RootSync y RepoSync adicionales

    Para crear más objetos RootSync o RepoSync, puedes usar la herramienta de línea de comandos kubectl u otro cliente de Kubernetes. También puedes usar el objeto inicial root-sync para gestionar objetos RootSync o RepoSync adicionales con GitOps. Para ello, añade sus manifiestos YAML a la fuente de información veraz desde la que se ha configurado el objeto root-sync para sincronizar. Este método no se puede usar para gestionar la configuración del root-sync inicial, ya que algunos de sus campos los gestiona el servicio Fleet. Para gestionar 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 el artículo Configurar la sincronización desde más de una fuente de información veraz.

    Siguientes pasos