Architecture de Config Sync

Cette page vous présente l'architecture de Config Sync, y compris les composants hébergés qui s'exécutent dans Google Cloud et les composants Open Source qui s'exécutent sur votre cluster Google Kubernetes Engine. En découvrant l'architecture, vous pouvez mieux comprendre Config Sync et résoudre les problèmes que vous rencontrez.

La section suivante présente l'architecture de Config Sync, y compris ses composants et dépendances, à la fois dans Google Cloud et sur votre cluster GKE :

Le service de parc gère directement les composants Config Sync sur votre cluster, sans l'ancien opérateur ConfigManagement ni l'objet ConfigManagement. Vous devez mettre à niveau Config Sync manuellement si nécessaire.

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 :

   • Définition de ressource personnalisée (CRD) ConfigSync
   • Un objet ConfigSync nommé config-sync.
   • 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. Le webhook d'admission Config Sync n'est installé que si vous activez la protection contre les dérives.

   Ces ressources et objets sont créés automatiquement lorsque vous installez Config Sync. Vous ne devez pas les modifier directement.

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

   • Pour chaque objet RootSync, un déploiement de rapprochement nommé root-reconciler-ROOTSYNC_NAME. Pour l'objet RootSync nommé root-sync, le déploiement du réconciliateur est nommé root-reconciler.
   • Pour chaque objet RepoSync, un déploiement de rapprochement nommé ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Pour l'objet RepoSync nommé repo-sync, le déploiement du rapprochement est nommé ns-reconciler.

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 du nom du pod	Nombre de conteneurs	Noms des conteneurs
reconciler-manager	config-management-system	Le gestionnaire de rapprochement s'exécute sur chaque cluster pour lequel Config Sync est 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 - 5^1	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 - 5^1	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 s'exécutant 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 sur lequel Config Sync est 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 Conteneurs de réconciliateur.

Demandes de ressources de déploiement

Le tableau suivant répertorie les exigences concernant les ressources Kubernetes pour les composants de Config Sync. Pour en savoir plus, consultez Gestion des ressources pour les pods et les conteneurs dans la documentation Kubernetes.

Les demandes de ressources sont les mêmes pour toutes les versions compatibles de Config Sync.

Nom du déploiement	Demande de processeur (m) par instance dupliquée	Demande de mémoire (Mi) par instance dupliquée
config-management-operator	100	200
resource-group-controller-manager	110	300
admission-webhook^1	10	100
otel-collector	200	400
reconciler-manager	20	150
reconciler (un par RootSync et RepoSync)	Pour en savoir plus, consultez Demandes de ressources du réconciliateur.

¹ Le webhook d'admission comporte deux instances répliquées. Si vous utilisez le webhook d'admission et que vous devez calculer le nombre total de requêtes de ressources, doublez la valeur. Le webhook d'admission est désactivé par défaut.

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 Hub 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 spécification 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 . Toutefois, vous pouvez utiliser l'API Google Cloudou l'API Kubernetes pour surveiller la configuration et l'état de votre installation Config Sync.

Gestionnaire de rapprochement et rapprocheurs

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 rapprocheur monolithique, car elle améliore la fiabilité en réduisant les points de défaillance uniques et permet de mettre à l'échelle les rapprocheurs individuels de manière indépendante.

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 :

Conteneurs de rapprochement

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 de la dérive.	Toujours activés
otel-agent	Reçoit les métriques des autres conteneurs de réconciliateur 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	Met en cache les identifiants Git du service de métadonnées GKE pour qu'ils puissent être utilisés 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 le montre 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é. De plus, les conteneurs hydration-controller et gcenode-askpass-sidecar sont créés si vous avez apporté les modifications de configuration mentionnées dans le tableau.

Demandes de ressources du reconciler

Pour chaque objet RootSync et RepoSync, Config Sync crée un déploiement de rapprochement indépendant pour gérer la synchronisation. Le déploiement du réconciliateur se compose de plusieurs conteneurs. Pour en savoir plus sur ces conteneurs, consultez Conteneurs de réconciliateur.

Les demandes de ressources sont les mêmes pour toutes les versions compatibles de Config Sync.

Le tableau suivant répertorie les demandes de ressources pour les clusters standards :

Nom du conteneur	Demande de processeur (m)	Demande de mémoire (Mi)
reconciler	50	200
otel-agent	10	100
hydration-controller (Facultatif)	10	100
git-sync	10	16
gcenode-askpass-sidecar (Facultatif)	10	20
helm-sync	75	128
oci-sync	25	32

Le tableau suivant répertorie les demandes de ressources pour les clusters Autopilot :

Nom du conteneur	Demande et limite de processeur (m)	Demande et limite de mémoire (Mi)
reconciler	700	512
otel-agent	10	64
hydration-controller (Facultatif)	200	256
git-sync	20	32
gcenode-askpass-sidecar (Facultatif)	50	64
helm-sync	250	384
oci-sync	50	64

Pour savoir comment remplacer les demandes et limites de ressources par défaut, consultez Remplacer les demandes et limites de ressources.

Versions groupées de Helm et Kustomize

Config Sync exploite les exécutables Helm et Kustomize pour effectuer le rendu des configurations. Le tableau suivant fournit une liste des versions de Config Sync compatibles avec la fonctionnalité de rendu, ainsi que les versions groupées de Helm et Kustomize.

Versions de Config Sync	Version de Helm	Version 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

Pour savoir comment afficher Helm via Kustomize, consultez Configurer Kubernetes avec Kustomize. Pour en savoir plus sur l'utilisation de l'API Helm, consultez Synchroniser des graphiques Helm à partir d'Artifact Registry.

Contrôleur ResourceGroup et objets ResourceGroup

Les reconcilers 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 la synchronisation, au lieu d'avoir à interroger vous-même l'état de chaque objet individuel.

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 d'objets ResourceGroup, car cela peut perturber 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. Avec l'autoréparation, Config Sync surveille en permanence les objets gérés et annule automatiquement toute modification qui s'écarte de l'état prévu.

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 racines peuvent synchroniser les ressources à l'échelle du cluster et 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 réconciliateurs d'espace 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 manuellement quoi que ce soit 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 d'autres objets RootSync ou RepoSync avec GitOps, en ajoutant leurs fichiers manifestes YAML à la source de vérité à 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'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

• Vous pouvez surveiller les composants Config Sync ou consulter leurs journaux. Pour une présentation, consultez Utiliser la surveillance et les journaux.
• Découvrez les demandes de ressources pour les composants Config Sync.