Architecture de Config Sync

Cette page présente l'architecture de Config Sync, y compris les composants hébergés exécutés dans Google Cloud et les composants Open Source exécutés sur votre cluster Google Kubernetes Engine (GKE) Enterprise Edition. En savoir plus sur l'architecture peut vous aider à mieux comprendre Config Sync et à déboguer et résoudre les problèmes que vous rencontrez.

L'architecture de Config Sync a évolué au fil du temps:

• Dans la version 1.5.1 de Config Sync, un nouveau mode multi-dépôt a été ajouté. Ce mode utilise une architecture multi-tenant plus évolutive avec un outil de rapprochement pour chaque objet RootSync et RepoSync, ce qui permet une gestion des autorisations indépendante, une mise à l'échelle indépendante et plusieurs domaines de défaillance indépendants.
• La fonctionnalité de mise à niveau automatique a été ajoutée dans la version 1.18.0 de Config Sync. Lorsque les mises à niveau automatiques sont activées, l'opérateur ConfigManagement et l'objet ConfigManagement sont supprimés du cluster. À la place, le service Fleet (GKE Hub) gère directement les composants Open Source sur le cluster. Lorsque les mises à niveau automatiques sont désactivées, l'opérateur ConfigManagement est toujours utilisé.
• Dans la version 1.19.0 de Config Sync, le mode monorépertoire facultatif a été supprimé. Ce mode utilisait une architecture plus simple avec moins de composants, mais était difficile à faire évoluer et ne prenait pas en charge la multi-propriété. C'est pourquoi il a été remplacé par le nouveau mode multi-dépôt. Pour en savoir plus, consultez la page Passer au mode multi-dépôt.
• Dans la version 1.20.0 de Config Sync, ConfigManagement Operator et l'objet ConfigManagement ont été supprimés complètement, même lorsque les mises à niveau automatiques étaient désactivées. À la place, le service Fleet (GKE Hub) gère directement les composants Open Source sur le cluster.

La section suivante présente l'architecture de Config Sync, y compris ses composants et ses dépendances, à la fois dans Google Cloud et sur votre cluster Google Kubernetes Engine (GKE) Enterprise, pour différentes versions de Config Sync:

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 de déploiement	Description du déploiement	Nombre d'instances répliquées	Expression régulière du nom du pod	Nombre de conteneurs	Noms des conteneurs
config-management-operator	config-management-system	Config Management Operator s'exécute sur les clusters avec la version 1.19.x ou antérieure de Config Sync installée, lors des mises à niveau manuelles. Il surveille l'objet ConfigManagement et gère les autres composants Config Sync, tels que le Gestionnaire de rapprochement et le collecteur OpenTelemetry. Dans Config Sync 1.20.0 et les versions ultérieures, l'opérateur ConfigManagement a été remplacé par une extension du service Fleet (hub GKE).	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 d'espace 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	Le collecteur OpenTelemetry s'exécute sur chaque cluster avec Config Sync activé dans l'objet ConfigManagement. Il collecte les métriques des composants Config Sync exécutés sous les espaces de noms config-management-system et resource-group-system, et les exporte 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	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 de l'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

¹ Pour en savoir plus sur le moment où ces conteneurs sont créés, consultez la section Réconcilier les conteneurs.

Composants clés

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

Service de parc et objet ConfigSync

Dans Config Sync 1.20.0 et les versions ultérieures, le service GKE Fleet gère directement les composants Config Sync sur votre cluster:

Le service Fleet gère également l'objet ConfigSync sur votre cluster. Le service Fleet met à jour à la fois les spécifications de l'objet ConfigSync en fonction de vos entrées dans l'API Google Cloud et son état pour refléter l'état des composants Config Sync.

Pour modifier la configuration de votre installation Config Sync, vous devez utiliser l'API Google Cloud . Vous pouvez toutefois utiliser l'API Google Cloudou l'API Kubernetes pour surveiller la configuration et l'état de votre installation Config Sync.

ConfigManagement Operator et l'objet ConfigManagement

Dans la version 1.19.x de Config Sync et les versions antérieures, lorsque vous utilisez des mises à niveau manuelles, le service GKE Fleet gère l'opérateur ConfigManagement, qui gère à son tour les composants Config Sync de votre cluster:

Pour modifier la configuration de votre installation Config Sync, vous utilisez principalement l'API Google Cloud . Toutefois, vous pouvez également utiliser l'API Kubernetes pour apporter des modifications à l'objet ConfigManagement. Pour en savoir plus, consultez la section Champs ConfigManagement.

ConfigManagement Operator surveille l'objet ConfigManagement pour détecter les modifications de spécifications, gère les composants Config Sync de votre cluster pour refléter les spécifications et met à jour l'état de l'objet ConfigManagement pour refléter l'état des composants Config Sync.

É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 outils de rapprochement

Le Gestionnaire de réconciliateurs est chargé de créer et de gérer les réconciliateurs individuels qui garantissent la synchronisation de la configuration de votre cluster.

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

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 :

Réconcilier les conteneurs

Les conteneurs spécifiques déployés dans les pods de réconciliateur 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 correction des écarts.	Toujours activés
otel-agent	Il reçoit les métriques des autres conteneurs de réconciliateurs 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 les 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	Mise en cache des identifiants Git à partir du service de métadonnées GKE pour l'utilisation par le conteneur git-sync.	Activé lorsque spec.sourceType est git et que spec.git.auth est gcenode ou gcpserviceaccount.
hydration-controller	Gère la création de 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 compris entre trois et cinq dans chaque pod de réconciliateur. 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 outils de réconciliation de l'espace racine et des espaces 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. Vous pouvez ainsi vérifier l'état de l'objet ResourceGroup pour obtenir un aperçu de l'état de la synchronisation, au lieu d'avoir à 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 leur 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 ni ne modifiez pas d'objets ResourceGroup, car cela peut interférer avec le fonctionnement de Config Sync.

Webhook d'admission

Le webhook d'admission Config Sync est créé lorsque vous activez la protection contre les 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 à la réparation automatique, Config Sync surveille en permanence les objets gérés et annule automatiquement toute modification qui s'écarte 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 réconciliateurs racine peuvent synchroniser à la fois les ressources à l'échelle du cluster et celles à 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 d'espace de noms qui surveille la source spécifiée et applique les objets de cette source à un espace de noms spécifique du cluster. Les outils de réconciliation d'espaces de noms peuvent synchroniser toutes les ressources à l'échelle de l'espace de noms de 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-t-il 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. Vous pouvez ainsi démarrer GitOps sur votre cluster sans avoir à appliquer quoi que ce soit manuellement directement 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'APIGoogle Cloud , en particulier la section spec.configSync de l'API config-management apply. Étant donné que 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és comme non gérés. Les champs gérés ne peuvent être modifiés qu'à l'aide de l'APIGoogle Cloud . Les champs non gérés peuvent être modifiés à l'aide de kubectl ou de 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 vérité à partir de laquelle root-sync est configuré pour se synchroniser. Cette méthode ne peut pas être utilisée pour gérer la configuration de l'root-sync initiale, 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

• Vous pouvez surveiller les composants Config Sync ou consulter leurs journaux. Pour en savoir plus, consultez la section Utiliser la surveillance et les journaux.
• Découvrez les requêtes de ressources pour les composants Config Sync.