Cette page 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. Comprendre l'architecture peut vous aider à mieux comprendre Config Sync et à déboguer et résoudre les problèmes que vous rencontrez.
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 GKE :
Le
service Fleet
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 :
L'activation de Config Sync sur votre cluster ajoute les composants suivants :
- La définition de ressource personnalisée
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-webhookLe webhook d'admission Config Sync n'est installé que si vous activez la prévention des 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
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 rapprochement est nomméroot-reconciler. Pour chaque objet
RepoSync, un déploiement de rapprochement nomméns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTHPour l'objetRepoSyncnommérepo-sync, le déploiement de 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 s'exécutant sous les
config-management-system et resource-group-system
espaces de noms, 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 pour 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 avec
prévention des 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 le moment où ces conteneurs sont créés, consultez la section 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 de Kubernetes.
Les demandes de ressources sont identiques 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 la section Requêtes de ressources 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 explorent plus en détail les composants importants de Config Sync.
Service Fleet et objet ConfigSync
Le service Hub Fleet gère 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 la spécification de l'objet ConfigSync en fonction de vos entrées
dans l' Google Cloud API 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' Google Cloud API. Toutefois, vous pouvez utiliser l' Google Cloud API ou 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 responsable de la création et de la gestion des rapprochements 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 rapprochement monolithique, car elle améliore la fiabilité en réduisant les points de défaillance uniques et permet de mettre à l'échelle 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 dérives. | 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 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 registre de conteneurs vers un répertoire local que le conteneur de rapprochement peut lire. | Activé lorsque spec.sourceType est oci. |
gcenode-askpass-sidecar |
Met en cache les identifiants Git du service de métadonnées GKE pour
une utilisation par le git-sync conteneur. |
Activé lorsque spec.sourceType est git et
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 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.
Requêtes de ressources 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 rapprochement se compose de plusieurs conteneurs. Pour en savoir plus sur ces conteneurs,
consultez la section Conteneurs de rapprochement.
Les demandes de ressources sont identiques pour toutes les versions compatibles de Config Sync.
Le tableau suivant répertorie les demandes de ressources pour les clusters Standard :
| 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 en savoir plus sur la façon de remplacer les demandes et limites de ressources par défaut, consultez la section 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
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 le rendu de Helm via Kustomize, consultez la section Configurer Kubernetes avec Kustomize. Pour en savoir plus sur l'utilisation de l'API Helm, consultez la section Synchroniser les charts Helm à partir d'Artifact Registry.
Les objets ResourceGroup Controller 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'ResourceGroup
objet
pour obtenir une vue d'ensemble 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 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 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. Avec 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.
Les 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 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
spec.override.roleRefs
champs. 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'espace de noms peuvent synchroniser toutes les ressources à l'échelle 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'espace de noms.
Comment le service Fleet gère les objets RootSync
Lorsque vous installez Config Sync avec la Google Cloud console, Google Cloud CLI, Config Connector ou Terraform, Config Sync est géré par le service Fleet, en fonction de vos entrées dans l' Google Cloud API.
Lorsque votre installation Config Sync est gérée par le service Fleet, vous pouvez également choisir de le faire gérer votre objet RootSync initial, nommé root-sync. Cela vous permet de démarrer GitOps sur votre cluster sans avoir à appliquer manuellement quoi que ce soit directement au cluster. Si vous décidez de ne pas faire gérer votre objet RootSync initial par le service Fleet, vous pouvez toujours appliquer les objets RootSync et RepoSync de votre choix directement au cluster.
L'RootSync objet nommé root-sync est créé en fonction de vos entrées dans l'
Google Cloud API, en particulier la section spec.configSync de l'
API
config-management apply. Étant donné que cette API
n'expose qu'un sous-ensemble des RootSync
champs,
ces champs sont considérés comme gérés dans le 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'
Google Cloud API. Les champs non gérés peuvent être modifiés à l'aide de ou de tout autre client Kubernetes.kubectl
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 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 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 la section
Configurer la synchronisation à partir de plusieurs sources de vérité.
Étape suivante
- Vous pouvez surveiller les composants Config Sync ou vérifier leurs journaux. Pour une présentation, consultez la section Utiliser la surveillance et les journaux.
- Découvrez les demandes de ressources pour les composants Config Sync.