Architecture de Config Sync

Cette page présente l'architecture de Config Sync. Le fait de connaître les composants créés par Config Sync peut vous permettre de mieux comprendre Config Sync et vous aider à déboguer et à résoudre les problèmes que vous rencontrez.

Le schéma suivant illustre l'architecture de Config Sync et les ressources associées sur un cluster Google Kubernetes Engine (GKE) Enterprise :

Schéma illustrant la relation entre les objets et les ressources Config Sync

Dans ce schéma, l'utilisateur crée une source de vérité et installe Config Sync à l'aide du gestionnaire de fonctionnalités.

Plusieurs étapes permettent d'installer Config Sync. Chacune de ces étapes déploie des composants supplémentaires sur votre cluster :

  1. L'activation de Config Sync sur votre cluster ajoute les composants suivants :

    • L'opérateur ConfigManagement dans un déploiement nommé config-management-operator.
    • La définition de ressource personnalisée (CRD) ConfigManagement et l'objet nommé config-management.
    • Le gestionnaire de rapprochement dans un déploiement nommé reconciler-manager.
    • Le contrôleur ResourceGroup dans un déploiement nommé resource-group-controller-manager.
    • Le collecteur OpenTelemetry dans un déploiement nommé otel-collector.
    • Facultatif : le webhook d'admission Config Sync dans un déploiement nommé admission-webhook.

    La plupart de ces ressources et de ces objets sont automatiquement créés lors de l'installation de Config Sync et vous n'avez pas besoin de les modifier.

  2. La création des objets RootSync et RepoSync ajoute les composants suivants :

    • Pour chaque RootSync, un déploiement de rapprochement nommé root-reconciler-ROOTSYNC_NAME.
    • Pour chaque RepoSync, un déploiement de rapprochement nommé ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH.

Déploiements, pods et conteneurs Config Sync

Le tableau suivant fournit des informations supplémentaires sur le déploiement, les pods et les conteneurs Config Sync :

Nom du déploiement Espace de noms du déploiement Description du déploiement Nombre d'instances répliquées Expression régulière de nom de pod Nombre de conteneurs Noms des conteneurs
config-management-operator config-management-system ConfigManagement Operator s'exécute sur chaque cluster sur lequel Config Sync est installé. Il surveille l'objet ConfigManagement et gère les composants Config Sync, tels que le gestionnaire de rapprochement et le collecteur OpenTelemetry. 1 config-management-operator-.* 1
  • manager
    		•
    reconciler-manager config-management-system Le gestionnaire de rapprochement s'exécute sur chaque cluster avec Config Sync activé dans l'objet ConfigManagement. Il surveille les objets RootSync et RepoSync et gère un déploiement de rapprochement pour chacun d'eux. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system Un déploiement de rapprochement racine est créé pour chaque objet 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 Un déploiement de rapprochement des espaces de noms est créé pour chaque objet 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 OpenTelemetry Collector s'exécute sur chaque cluster avec Config Sync activé dans l'objet ConfigManagement. Il collecte des métriques à partir des composants Config Sync exécutés sous les espaces de noms config-management-system et resource-group-system, puis exporte ces métriques vers Prometheus et Cloud Monitoring. 1 otel-collector-.* 1
  • otel-collector
    		•
    resource-group-controller-manager resource-group-system Le contrôleur ResourceGroup s'exécute sur chaque cluster avec Config Sync activé dans l'objet ConfigManagement. Il surveille les objets ResourceGroup et les met à jour avec l'état de rapprochement actuel de chaque objet de leur inventaire. Un objet ResourceGroup est créé pour chaque objet RootSync et RepoSync afin d'inventorier la liste d'objets appliquée par le rapprochement à partir de la source de référence. 1 resource-group-controller-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    admission-webhook config-management-system Le webhook d'admission Config Sync s'exécute sur chaque cluster avec la protection contre les dérives activée dans l'objet ConfigManagement. Il surveille les requêtes d'API Kubernetes et empêche la modification ou la suppression des ressources gérées par Config Sync. Le webhook d'admission Config Sync est désactivé par défaut. 2 admission-webhook-.* 1
  • admission-webhook
    		•

    1 Pour en savoir plus sur la création de ces conteneurs, consultez la section Conteneurs de rapprochement.

    Composants clés

    Les sections suivantes explorent plus en détail les composants importants de Config Sync.

    Opérateur et objet ConfigManagement

    ConfigManagement Operator surveille l'objet ConfigManagement, puis crée et gère les autres composants nécessaires au fonctionnement de Config Sync :

    Activation de l'opérateur

    Étant donné que ConfigManagement Operator installe certains composants qui nécessitent des autorisations cluster-admin, il nécessite également des autorisations cluster-admin.

    Gestionnaire de rapprochement et rapprochements

    Le gestionnaire de rapprochement est chargé de créer et de gérer les rapprochements individuels qui garantissent que la configuration de votre cluster reste synchronisée.

    Le gestionnaire de rapprochement crée un outil de rapprochement racine pour chaque objet RootSync et un outil de rapprochement d'espace de noms pour chaque objet RepoSync. Config Sync utilise cette conception au lieu de partager un seul rapprochement monolithique, car il améliore la fiabilité en réduisant les points de défaillance uniques et permet le scaling indépendant des rapprochements individuels.

    Les rapprochements racine et d'espace de noms récupèrent automatiquement les configurations de votre source de vérité et les appliquent pour appliquer l'état souhaité dans votre cluster.

    Les schémas suivants montrent comment le gestionnaire de rapprochement gère le contrôle du cycle de vie de chaque rapprochement racine et rapprochement des espaces de noms :

    Schéma montrant comment le gestionnaire de rapprochement contrôle le rapprochement racine Schéma illustrant la façon dont le gestionnaire de rapprochement contrôle le rapprochement d'espace de noms

    Rapprocher des conteneurs

    Les conteneurs spécifiques déployés dans les pods de rapprochement dépendent des choix de configuration que vous effectuez. Le tableau suivant explique ce que fait chacun de ces conteneurs de rapprochement et la condition qui oblige Config Sync à les créer :

    Nom du conteneur Description Condition
    reconciler Gère la synchronisation et la résolution des écarts. Toujours activés
    otel-agent Reçoit les métriques des autres conteneurs de rapprochement et les envoie au collecteur OpenTelemetry. Toujours activés
    git-sync Extrait les configurations de votre dépôt Git vers un répertoire local que le conteneur de rapprochement peut lire. Activé lorsque spec.sourceType est défini sur git.
    helm-sync Extrait et affiche les charts Helm de votre dépôt de chart dans un répertoire local que le conteneur de rapprochement peut lire. Activé lorsque spec.sourceType est défini sur helm.
    oci-sync Extrait des images OCI contenant vos configurations de votre registre de conteneurs vers un répertoire local que le conteneur de rapprochement peut lire. Activé lorsque spec.sourceType est défini sur oci.
    gcenode-askpass-sidecar Met en cache les identifiants Git du service de métadonnées GKE pour les utiliser par le conteneur git-sync. Activé lorsque spec.sourceType est défini sur git et spec.git.auth est gcenode ou gcpserviceaccount.
    hydration-controller Gère la création des configurations Kustomize dans un répertoire local que le conteneur de rapprochement peut lire. Activé lorsque la source inclut un fichier kustomize.yaml.

    Comme indiqué dans le tableau précédent, vous pouvez généralement vous attendre à un nombre de conteneurs de trois à cinq dans chaque pod de rapprochement. Les conteneurs reconciler et otel-agent sont toujours présents. La spécification d'un type de source de vérité détermine le conteneur de synchronisation ajouté. En outre, les conteneurs hydration-controller et gcenode-askpass-sidecar sont créés si vous avez apporté les modifications de configuration mentionnées dans le tableau.

    Contrôleur ResourceGroup et objets ResourceGroup

    Les rapprochements racine et d'espace de noms créent un objet d'inventaire ResourceGroup pour chaque objet RootSync et RepoSync que vous configurez. Chaque objet ResourceGroup contient une liste d'objets synchronisés avec le cluster à partir de la source de vérité par le rapprochement pour cet objet RootSync ou RepoSync. Le contrôleur ResourceGroup surveille ensuite tous les objets de l'objet ResourceGroup et met à jour l'état de l'objet ResourceGroup avec l'état de rapprochement actuel des objets synchronisés. Cela vous permet de vérifier l'état de l'objet ResourceGroup pour obtenir un aperçu de l'état de synchronisation, plutôt que de devoir interroger vous-même l'état de chaque objet.

    Les objets ResourceGroup ont le même nom et le même espace de noms que l'objet RootSync ou RepoSync correspondant. Par exemple, pour l'objet RootSync nommé root-sync dans l'espace de noms config-management-system, l'objet ResourceGroup correspondant est également nommé root-sync dans l'espace de noms config-management-system.

    Ne créez pas et ne modifiez pas les objets ResourceGroup, car cela pourrait interférer avec le fonctionnement de Config Sync.

    Webhook d'admission

    Le webhook d'admission Config Sync est créé lorsque vous activez la prévention des dérives. La prévention des dérives intercepte de manière proactive les requêtes de modification, en s'assurant qu'elles correspondent à la source de vérité avant d'autoriser les modifications.

    Si vous n'activez pas la prévention des dérives, Config Sync utilise toujours un mécanisme d'autoréparation pour annuler les écarts de configuration. Grâce à l'autoréparation, Config Sync surveille en permanence les objets gérés et annule automatiquement toutes les modifications qui diffèrent de l'état souhaité.

    Objets RootSync et RepoSync

    Les objets RootSync configurent Config Sync pour créer un rapprochement racine qui surveille la source de vérité spécifiée et applique les objets de cette source au cluster. Par défaut, le rapprochement racine de chaque objet RootSync dispose de l'autorisation cluster-admin. Avec cette autorisation par défaut, les rapprochements racine peuvent synchroniser les ressources à l'échelle du cluster et à l'échelle de l'espace de noms. Si nécessaire, vous pouvez modifier ces autorisations en configurant les champs spec.override.roleRefs. Les objets RootSync sont conçus pour être utilisés par les administrateurs de cluster.

    Les objets RepoSync configurent Config Sync pour créer un rapprochement des espaces de noms qui surveille la source spécifiée et applique les objets de cette source à un espace de noms spécifique dans le cluster. Les rapprochements d'espaces de noms peuvent synchroniser toutes les ressources à l'échelle d'un espace de noms dans cet espace de noms avec des autorisations personnalisées spécifiées par l'utilisateur. Les objets RepoSync sont conçus pour être utilisés par les locataires d'espaces de noms.

    Comment le service Fleet gère les objets RootSync

    Lorsque vous installez Config Sync avec la console Google Cloud, Google Cloud CLI, Config Connector ou Terraform, Config Sync est géré par le service Fleet, en fonction de vos entrées dans l'API Google Cloud.

    Lorsque votre installation Config Sync est gérée par le service Fleet, vous pouvez également lui demander de gérer votre objet RootSync initial, nommé root-sync. Cela vous permet d'amorcer GitOps sur votre cluster sans avoir à appliquer directement quoi que ce soit au cluster. Si vous décidez de ne pas laisser le service Fleet gérer votre objet RootSync initial, vous pouvez toujours appliquer les objets RootSync et RepoSync de votre choix directement au cluster.

    L'objet RootSync nommé root-sync est créé en fonction de vos entrées dans l'API Google Cloud, en particulier la section spec.configSync de l'API config-management apply. Comme cette API n'expose qu'un sous-ensemble des champs RootSync, ces champs sont considérés comme gérés dans root-sync, tandis que les autres champs sont considérées comme non gérées. Les champs gérés ne peuvent être modifiés qu'à l'aide de l'API Google Cloud. Les champs non gérés peuvent être modifiés à l'aide de kubectl ou de tout autre client Kubernetes. Pour obtenir un exemple illustrant comment exporter les root-sync YAML, modifiez-le localement, puis appliquez-le à nouveau. Reportez-vous à créer et modifier un fichier de configuration RootSync.

    Pour les installations manuelles, vous gérez Config Sync avec l'outil de ligne de commande kubectl ou tout autre client Kubernetes.

    Objets RootSync et RepoSync supplémentaires

    Pour créer des objets RootSync ou RepoSync supplémentaires, vous pouvez utiliser l'outil de ligne de commande kubectl ou un autre client Kubernetes. Vous pouvez également utiliser l'objet root-sync initial pour gérer des objets RootSync ou RepoSync supplémentaires avec GitOps, en ajoutant leurs fichiers manifestes YAML à la source de référence à partir de laquelle root-sync est configuré pour la synchronisation. Cette méthode ne peut pas être utilisée pour gérer la configuration de l'objet root-sync initial, car certains de ses champs sont gérés par le service Fleet. Pour gérer l'objet root-sync avec GitOps, utilisez Config Connector ou Terraform. Pour en savoir plus sur la création d'objets RootSync et RepoSync supplémentaires, consultez la section Configurer la synchronisation à partir de plusieurs sources de vérité.

    Étapes suivantes