Architettura di Config Sync

Questa pagina illustra l'architettura di Config Sync, inclusi i componenti ospitati in Google Cloud e i componenti open source che vengono eseguiti sul cluster Google Kubernetes Engine (GKE) Enterprise. Conoscere l'architettura può aiutarti a comprendere meglio Config Sync e a eseguire il debug e risolvere i problemi che riscontri.

L'architettura di Config Sync è cambiata nel tempo:

• Nella versione 1.5.1 di Config Sync è stata aggiunta una nuova modalità multi-repository. Questa modalità utilizza un'architettura multi-tenant più scalabile con un riconciliatore per ogni oggetto RootSync e RepoSync, che consente la gestione indipendente delle autorizzazioni, il ridimensionamento indipendente e più domini di errori indipendenti.
• Nella versione 1.18.0 di Config Sync è stata aggiunta la funzionalità di upgrade automatico. Con gli upgrade automatici abilitati, l'operatore ConfigManagement e l'oggetto ConfigManagement vengono rimossi dal cluster. Il servizio Fleet (GKE Hub) gestisce invece direttamente i componenti open source nel cluster. Con gli upgrade automatici disattivati, l'operatore ConfigManagement viene comunque utilizzato.
• Nella versione 1.19.0 di Config Sync, la modalità monorepo facoltativa è stata rimossa. Questa modalità utilizzava un'architettura più semplice con meno componenti, ma era difficile da scalare e non supportava il multitenancy. Per questi motivi, è stata sostituita dalla modalità multi-repo più recente. Per ulteriori informazioni, consulta la sezione sulla migrazione alla modalità multirepo.
• Nella versione 1.20.0 di Config Sync, l'operatore ConfigManagement e l'oggetto ConfigManagement sono stati rimossi completamente, anche con gli upgrade automatici disattivati. Il servizio Fleet (GKE Hub) gestisce invece direttamente i componenti open source sul cluster.

La sezione seguente mostra l'architettura di Config Sync, inclusi i relativi componenti e le dipendenze, sia in Google Cloud che nel tuo cluster Google Kubernetes Engine (GKE) Enterprise Edition, per varie versioni di Config Sync:

1.20.0 e versioni successive

In Config Sync 1.20.0 e versioni successive, il servizio Fleet gestisce direttamente i componenti di Config Sync nel cluster, senza l'operatore ConfigManagement o l'oggetto ConfigManagement precedente. Puoi configurare il servizio Fleet per eseguire l'upgrade automatico di Config Sync oppure eseguire manualmente l'upgrade di Config Sync in base alle tue esigenze.

Questa architettura viene utilizzata anche per Config Sync versione 1.18.0 e successive, quando sono abilitati gli upgrade automatici.

Esistono diversi passaggi per installare Config Sync e ognuno di questi passaggi esegue il deployment di componenti aggiuntivi sul cluster:

1. L'attivazione di Config Sync sul cluster aggiunge i seguenti componenti:

   • La ConfigSync definizione di risorsa personalizzata (CRD)
   • Un oggetto ConfigSync denominato config-sync.
   • Il gestore del riconciliatore in un deployment denominato reconciler-manager.
   • Il controller ResourceGroup in un deployment denominato resource-group-controller-manager.
   • Il raccoglitore OpenTelemetry in un deployment denominato otel-collector.
   • (Facoltativo) L'webhook di ammissione Config Sync in un deployment denominato admission-webhook. L'webhook di ammissione della sincronizzazione della configurazione viene installato solo se attivi la prevenzione dello slittamento.

   Queste risorse e questi oggetti vengono creati automaticamente quando installi Config Sync e non devono essere modificati direttamente.

2. La creazione di oggetti RootSync e RepoSync aggiunge i seguenti componenti:

   • Per ogni oggetto RootSync, un deployment del riconciliatore denominato root-reconciler-ROOTSYNC_NAME. Per l'oggetto RootSync denominato root-sync, il deployment del riconciliatore è denominato root-reconciler.
   • Per ogni oggetto RepoSync, un deployment del riconciliatore denominato ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Per l'oggetto RepoSync denominato repo-sync, il deployment del riconciliatore è denominato ns-reconciler.

1.19.x e precedenti

In Config Sync versione 1.19.x e precedenti, quando utilizzi gli upgrade manuali, il servizio Fleet gestisce ConfigManagement Operator, che a sua volta gestisce i componenti di Config Sync nel cluster.

In Config Sync versione 1.18.x e successive, quando utilizzi gli upgrade automatici, viene utilizzata l'architettura 1.20.0 e successive.

Esistono diversi passaggi per installare Config Sync e ognuno di questi passaggi esegue il deployment di componenti aggiuntivi sul cluster:

1. L'attivazione di Config Sync sul cluster aggiunge i seguenti componenti:

   • L'operatore ConfigManagement in un deployment denominato config-management-operator.
   • La definizione di risorsa personalizzata (ConfigManagement).
   • Un oggetto ConfigManagement denominato config-management.
   • Il gestore del riconciliatore in un deployment denominato reconciler-manager.
   • Il controller ResourceGroup in un deployment denominato resource-group-controller-manager.
   • Il raccoglitore OpenTelemetry in un deployment denominato otel-collector.
   • (Facoltativo) L'webhook di ammissione Config Sync in un deployment denominato admission-webhook. L'webhook di ammissione della sincronizzazione della configurazione viene installato solo se attivi la prevenzione dello slittamento.

   La maggior parte di queste risorse e oggetti viene creata automaticamente quando installi Config Sync e non deve essere modificata direttamente. Tuttavia, l'oggetto ConfigManagement ha alcuni campi che possono essere modificati direttamente. Per ulteriori informazioni, consulta Campi ConfigManagement.

2. La creazione di oggetti RootSync e RepoSync aggiunge i seguenti componenti:

   • Per ogni oggetto RootSync, un deployment del riconciliatore denominato root-reconciler-ROOTSYNC_NAME. Per l'oggetto RootSync denominato root-sync, il deployment del riconciliatore è denominato root-reconciler.
   • Per ogni oggetto RepoSync, un deployment del riconciliatore denominato ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Per l'oggetto RepoSync denominato repo-sync, il deployment del riconciliatore è denominato ns-reconciler.

Deployment, pod e container di Config Sync

La tabella seguente fornisce ulteriori informazioni su deployment, pod e container di Config Sync:

Nome deployment	Spazio dei nomi del deployment	Descrizione deployment	Numero repliche	Espressione regolare del nome del pod	Conteggio dei container	Nomi dei container
config-management-operator	config-management-system	L'operatore ConfigManagement viene eseguito sui cluster con la versione 1.19.x e versioni precedenti di Config Sync installata, quando si utilizzano gli upgrade manuali. Monitora l'oggetto ConfigManagement e gestisce gli altri componenti di Config Sync, come Reconciler Manager e OpenTelemetry Collector. In Config Sync versione 1.20.0 e successive, l'operatore ConfigManagement è stato sostituito da un'estensione del servizio Fleet (GKE Hub).	1	config-management-operator-.*	1	manager
reconciler-manager	config-management-system	Reconciler Manager viene eseguito su ogni cluster con Config Sync attivo nell'oggetto ConfigManagement. Monitora gli oggetti RootSync e RepoSync e gestisce un deployment del riconciliatore per ciascuno.	1	reconciler-manager-.*	2	reconciler-manager otel-agent
root-reconciler	config-management-system	Viene creato un deployment del riconciliatore principale per ogni oggetto 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	Viene creato un deployment del riconciliatore dello spazio dei nomi per ogni oggetto 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	OpenTelemetry Collector viene eseguito su ogni cluster con Config Sync attivo nell'oggetto ConfigManagement. Raccoglie le metriche dai componenti di Config Sync in esecuzione negli spazi dei nomi config-management-system e resource-group-system ed esporta queste metriche in Prometheus e Cloud Monitoring.	1	otel-collector-.*	1	otel-collector
resource-group-controller-manager	resource-group-system	ResourceGroup Controller viene eseguito su ogni cluster con Config Sync attivo nell'oggetto ConfigManagement. Monitora gli oggetti ResourceGroup e li aggiorna con lo stato corrente della riconciliazione di ciascun oggetto nell'inventario. Per ogni oggetto RootSync e RepoSync viene creato un oggetto ResourceGroup per inventariare l'elenco di oggetti applicati dal riconciliatore dalla fonte di verità.	1	resource-group-controller-manager-.*	2	manager otel-agent
admission-webhook	config-management-system	Il webhook di ammissione di Config Sync viene eseguito su ogni cluster con la prevenzione dello scostamento abilitata nell'oggetto ConfigManagement. Monitora le richieste all'API Kubernetes e impedisce la modifica o l'eliminazione delle risorse gestite da Config Sync. Il webhook di ammissione di Config Sync è disattivato per impostazione predefinita.	2	admission-webhook-.*	1	admission-webhook

¹ Per informazioni dettagliate su quando vengono creati questi contenitori, consulta Contenitori di riconciliazione.

Componenti chiave

Le sezioni seguenti illustrano in maggiore dettaglio i componenti importanti di Config Sync.

Servizio di parco risorse e oggetto ConfigSync

In Config Sync versione 1.20.0 e successive, nonché nella versione 1.18.0 e successive con gli upgrade automatici abilitati, il servizio GKE Fleet gestisce direttamente i componenti di Config Sync nel tuo cluster:

Il servizio Fleet gestisce anche l'oggetto ConfigSync nel tuo cluster. Il servizio Fleet aggiorna sia la specifica dell'oggetto ConfigSync in base ai tuoi input all'API Google Cloud sia il relativo stato in modo da riflettere lo stato dei componenti di Config Sync.

Per apportare modifiche alla configurazione di installazione di Config Sync, devi utilizzare l' Google Cloud API. Tuttavia, puoi utilizzare l'API Google Cloud o l'API Kubernetes per monitorare la configurazione e lo stato dell'installazione di Config Sync.

Operatore ConfigManagement e oggetto ConfigManagement

In Config Sync versione 1.19.x e precedenti, quando utilizzi gli upgrade manuali, il servizio GKE Fleet gestisce l'operatore ConfigManagement, che a sua volta gestisce i componenti di Config Sync nel cluster:

Per apportare modifiche alla configurazione di installazione di Config Sync, utilizza principalmente l' Google Cloud API. Tuttavia, puoi anche utilizzare l'API Kubernetes per apportare alcune modifiche all'oggetto ConfigManagement. Per maggiori informazioni, consulta Campi ConfigManagement.

L'operatore ConfigManagement controlla l'oggetto ConfigManagement per verificare la presenza di modifiche alle specifiche, gestisce i componenti di Config Sync sul cluster in modo che riflettano le specifiche e aggiorna lo stato dell'oggetto ConfigManagement in base allo stato dei componenti di Config Sync.

Poiché ConfigManagement Operator installa alcuni componenti che richiedono autorizzazioni cluster-admin, anche ConfigManagement Operator richiede autorizzazioni cluster-admin.

Reconciler Manager e riconciliatori

Reconciler Manager è responsabile della creazione e della gestione dei singoli agenti di riconciliazione che assicurano la sincronizzazione della configurazione del cluster.

Reconciler Manager crea un riconciliatore principale per ogni oggetto RootSync e un riconciliatore del nome dello spazio per ogni oggetto RootSync.RepoSync Config Sync utilizza questo design anziché condividere un singolo riconciliatore monolitico perché migliora l'affidabilità riducendo i single point of failure e consente di scalare i singoli riconciliatori in modo indipendente.

I riconciliatori di spazi dei nomi e principali recuperano automaticamente le configurazioni dalla tua fonte di verità e le applicano per applicare lo stato che preferisci all'interno del cluster.

I seguenti diagrammi mostrano come Reconciler Manager gestisce il controllo del ciclo di vita di ogni riconciliatore principale e riconciliatore dello spazio dei nomi:

Container di riconciliazione

I contenitori specifici di cui è stato eseguito il deployment nei pod di riconciliazione dipendono dalle scelte di configurazione che effettui. La tabella seguente spiega di più su cosa fanno ciascuno di questi contenitori di riconciliazione e sulla condizione che ne causa la creazione da parte di Config Sync:

Nome del contenitore	Descrizione	Condizione
reconciler	Gestisce la sincronizzazione e la correzione della deriva.	Sempre abilitata.
otel-agent	Riceve le metriche dagli altri contenitori di riconciliazione e le invia a OpenTelemetry Collector.	Sempre abilitata.
git-sync	Estrae le configurazioni dal tuo repository Git in una directory locale che il contenitore del riconciliatore può leggere.	Abilitato quando spec.sourceType è git.
helm-sync	Estrae e esegue il rendering dei grafici Helm dal tuo repository di grafici in una directory locale che il contenitore del riconciliatore può leggere.	Abilitato quando spec.sourceType è helm.
oci-sync	Estrae le immagini OCI contenenti le configurazioni dal tuo registry di container in una directory locale che il container di riconciliazione può leggere.	Abilitato quando spec.sourceType è oci.
gcenode-askpass-sidecar	Memorizza nella cache le credenziali Git del servizio di metadati GKE per essere utilizzate dal contenitore git-sync.	Abilitato quando spec.sourceType è git e spec.git.auth è gcenode o gcpserviceaccount.
hydration-controller	Gestisce la creazione di configurazioni Kustomize in una directory locale che il contenitore del riconciliatore può leggere.	Attivata quando l'origine include un file kustomize.yaml.

Come mostrato nella tabella precedente, in genere puoi aspettarti un conteggio di container da tre a cinque in ogni pod di riconciliazione. I contenitori reconciler e otel-agent sono sempre presenti. La specifica di un tipo per l'origine della verità determina il contenitore di sincronizzazione da aggiungere. Inoltre, i contenitori hydration-controller e gcenode-askpass-sidecar vengono creati se hai apportato le modifiche alla configurazione indicate nella tabella.

Oggetti ResourceGroup Controller e ResourceGroup

I riconciliatori dello spazio dei nomi e della radice creano un oggetto di inventario ResourceGroup per ogni oggetto RootSync e RepoSync configurato. Ogni oggetto ResourceGroup contiene un elenco di oggetti sincronizzati con il cluster dalla fonte di verità dal riconciliatore per quell'oggetto RootSync o RepoSync. ResourceGroupController monitora quindi tutti gli oggetti nell'oggetto ResourceGroup e aggiorna lo stato dell'oggetto ResourceGroup con lo stato corrente della riconciliazione degli oggetti sincronizzati. In questo modo puoi controllare lo stato dell'oggetto ResourceGroup per avere una panoramica dello stato della sincronizzazione, anziché dover eseguire query sullo stato di ogni singolo oggetto.

Gli oggetti ResourceGroup hanno lo stesso nome e spazio dei nomi dell'oggetto RootSync o RepoSync corrispondente. Ad esempio, per l'oggetto RootSync con il nome root-sync nello spazio dei nomi config-management-system, l'oggetto ResourceGroup corrispondente è denominato anche root-sync nello spazio dei nomi config-management-system.

Non creare o modificare oggetti ResourceGroup, in quanto ciò potrebbe interferire con il funzionamento di Config Sync.

Webhook di ammissione

L'webhook di ammissione della sincronizzazione della configurazione viene creato quando attivi la prevenzione dello slittamento. La prevenzione della deriva intercetta in modo proattivo le richieste di modifica, assicurandosi che siano in linea con la fonte attendibile prima di consentire le modifiche.

Se non attivi la prevenzione della deriva, Config Sync utilizza comunque un meccanismo di riparazione automatica per annullare la deriva della configurazione. Con la funzionalità di riparazione automatica, Config Sync monitora continuamente gli oggetti gestiti e annulla automaticamente eventuali modifiche che si discostano dallo stato previsto.

Oggetti RootSync e RepoSync

Gli oggetti RootSync configurano Config Sync per creare un riconciliatore principale che monitora la fonte attendibile specificata e applica gli oggetti da questa fonte al cluster. Per impostazione predefinita, il riconciliatore principale per ogni oggetto RootSync ha l'autorizzazione cluster-admin. Con questa autorizzazione predefinita, i riconciliatori principali possono sincronizzare sia le risorse con ambito cluster sia quelle con ambito dello spazio dei nomi. Se necessario, puoi modificare queste autorizzazioni configurando i campi spec.override.roleRefs. Gli oggetti RootSync sono progettati per essere utilizzati dagli amministratori del cluster.

Gli oggetti RepoSync configurano Config Sync per creare un riconciliatore dello spazio dei nomi che monitora l'origine specificata e applica gli oggetti da quell'origine a un spazio dei nomi specifico nel cluster. I riconciliatori dello spazio dei nomi possono sincronizzare qualsiasi risorsa con ambito a livello di spazio dei nomi in quello spazio con autorizzazioni personalizzate specificate dall'utente. Gli oggetti RepoSync sono progettati per essere utilizzati dai tenant dello spazio dei nomi.

In che modo il servizio Fleet gestisce gli oggetti RootSync

Quando installi Config Sync con la console Google Cloud, Google Cloud CLI, Config Connector o Terraform, Config Sync viene gestito dal servizio Fleet in base ai tuoi input all' Google Cloud API.

Quando l'installazione di Config Sync è gestita dal servizio Fleet, puoi anche chiedere di gestire l'oggetto RootSync iniziale, denominato root-sync. In questo modo puoi avviare GitOps nel tuo cluster senza dover applicare manualmente nulla direttamente al cluster. Se decidi di non consentire al servizio Fleet di gestire l'oggetto RootSync iniziale, puoi comunque applicare gli oggetti RootSync e RepoSync che preferisci direttamente al cluster.

L'oggetto RootSync denominato root-sync viene creato in base ai tuoi input all'Google Cloud API, in particolare alla sezione spec.configSync dell'Google Cloud API config-management apply. Poiché questa API espone solo un sottoinsieme dei campi RootSync, questi campi sono considerati gestiti in root-sync, mentre gli altri sono considerati non gestiti. I campi gestiti possono essere modificati solo utilizzando l'Google Cloud API. I campi non gestiti possono essere modificati utilizzando kubectl o qualsiasi altro client Kubernetes.

Ulteriori oggetti RootSync e RepoSync

Per creare altri oggetti RootSync o RepoSync, puoi utilizzare lo strumento a riga di comando kubectl o un altro client Kubernetes. Puoi anche utilizzare l'oggetto root-sync iniziale per gestire altri oggetti RootSync o RepoSync con GitOps, aggiungendo i relativi manifest YAML alla verità oggettiva da cui root-sync è configurato per eseguire la sincronizzazione. Questo metodo non può essere utilizzato per gestire la configurazione dell'root-sync iniziale, perché alcuni dei suoi campi sono gestiti dal servizio Fleet. Per gestire l'oggetto root-sync con GitOps, utilizza Config Connector o Terraform. Per scoprire di più sulla creazione di altri oggetti RootSync e RepoSync, consulta Configurare la sincronizzazione da più di una fonte attendibile.

Passaggi successivi

• Ti consigliamo di monitorare i componenti di Config Sync o di controllare i relativi log. Per un'introduzione, consulta Utilizzare il monitoraggio e i log.
• Scopri di più sulle richieste di risorse per i componenti di Config Sync.