Config Sync utilise des composants hébergés dans Google Cloud et des composants Open Source sur votre cluster Google Kubernetes Engine pour rapprocher en continu l'état du cluster d'une source de vérité centrale. Comprendre comment ces composants interagissent vous aide à concevoir des workflows GitOps évolutifs et à résoudre les problèmes de synchronisation ou de rapprochement.
Présentation de l'architecture
Le schéma suivant illustre l'architecture de Config Sync, y compris ses composants et ses dépendances, à la fois dans Google Cloud et sur votre cluster GKE :
Le service Fleet gère directement les composants Config Sync sur votre cluster, sans l'ancien ConfigManagement Operator 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 :
L'activation de Config Sync sur votre cluster ajoute les composants suivants :
- La définition de ressource personnalisée (CRD)
ConfigSync - Un objet
ConfigSyncnommé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 et ne doivent pas être modifiés directement.
- La définition de ressource personnalisée (CRD)
La création des objets
RootSyncetRepoSyncajoute les composants suivants :- Pour chaque objet
RootSync, un déploiement de rapprochement nomméroot-reconciler-ROOTSYNC_NAME. Pour l'objetRootSyncnomméroot-sync, le déploiement de l'outil de rapprochement 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'objetRepoSyncnommérepo-sync, le déploiement du rapprochement est nomméns-reconciler-REPOSYNC_NAMESPACE.
- Pour chaque objet
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-managerotel-agent |
root-reconciler |
config-management-system |
Un déploiement de rapprochement racine est créé pour chaque objet RootSync. |
1 | root-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-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 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
otel-collector |
config-management-monitoring |
Le collecteur OpenTelemetry s'exécute sur chaque cluster pour lequel Config Sync est 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, puis 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 | managerotel-agent |
admission-webhook |
config-management-system |
Le webhook d'admission Config Sync s'exécute sur chaque cluster pour lequel la protection contre les dérives est activée dans l'objet ConfigManagement. Il surveille les requêtes 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 Conteneurs de rapprochement.
Requêtes 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 la section Gestion des ressources pour les pods et les conteneurs dans la documentation Kubernetes.
Les requêtes 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-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (un par RootSync et RepoSync) |
Pour en savoir plus, consultez Requêtes de ressources de l'outil de rapprochement. | |
1 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 décrivent plus en détail les composants importants de Config Sync.
Le service de parc et l'objet ConfigSync
Le service Hub Fleet gère les composants Config Sync sur votre cluster :
Le service de parc 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.
Reconciler Manager et les 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 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 rapprochement monolithique, car elle améliore la fiabilité en réduisant les points de défaillance uniques et permet de faire évoluer les rapprochements 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 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 correction 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 dans 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 helm. |
oci-sync |
Extrait les images OCI contenant vos configurations de votre Container Registry 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 soient 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 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é. 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.
Requêtes de ressources de l'outil de rapprochement
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 de l'outil de rapprochement se compose de plusieurs conteneurs. Pour en savoir plus sur ces conteneurs, consultez Conteneurs de rapprochement.
Les requêtes de ressources sont identiques pour toutes les versions compatibles de Config Sync.
Le tableau suivant liste les requêtes de ressources pour les clusters standards :
| Nom du conteneur | Demande de CPU (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 liste les requêtes de ressources pour les clusters Autopilot :
| Nom du conteneur | Demande et limite de CPU (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 en savoir plus sur le remplacement des 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. Pour trouver les versions groupées de Helm et Kustomize pour votre version de Config Sync, consultez les champs HELM_VERSION et KUSTOMIZE_VERSION dans le fichier Makefile du dépôt Open Source Config Sync.
Vous pouvez basculer entre les branches dans GitHub pour afficher les versions des différentes versions de Config Sync.
Pour en savoir plus sur l'affichage de Helm via Kustomize, consultez Configurer Kubernetes avec Kustomize. Pour en savoir plus sur l'utilisation de l'API Helm, consultez la page Synchroniser des charts Helm à partir d'Artifact Registry.
Objets ResourceGroupController et 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 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 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 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 à l'autoréparation, Config Sync surveille en permanence les objets gérés et annule automatiquement toutes les modifications qui s'écartent 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 rapprocheurs racine 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 rapprochements d'espaces de noms peuvent synchroniser toutes les ressources d'un 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 de parc 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 des objets RootSync ou RepoSync supplémentaires avec GitOps, en ajoutant leurs fichiers manifestes YAML à la source de vérité à partir de laquelle l'objet root-sync est configuré pour se synchroniser. Cette méthode ne peut pas être utilisée pour gérer la configuration du 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 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 Utiliser la surveillance et les journaux.
- Découvrez les requêtes de ressources pour les composants Config Sync.