Architettura di Config Sync

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

La sezione seguente mostra l'architettura di Config Sync, inclusi i relativi componenti e dipendenze, sia in Google Cloud sia nel tuo cluster GKE:

Il servizio di parco risorse gestisce direttamente i componenti Config Sync sul cluster, senza l'operatore ConfigManagement legacy o l'oggetto ConfigManagement. Devi eseguire manualmente l'upgrade di Config Sync in base alle esigenze.

L'installazione di Config Sync prevede più passaggi 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.
   • Reconciler Manager in una deployment denominata reconciler-manager.
   • Il controller ResourceGroup in un deployment denominato resource-group-controller-manager.
   • OpenTelemetry Collector in un deployment denominato otel-collector.
   • (Facoltativo) Il webhook di ammissione di Config Sync in un deployment denominato admission-webhook. Il webhook di ammissione di Config Sync viene installato solo se attivi la prevenzione della deriva.

   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 di riconciliazione 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 di riconciliazione denominato ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Per l'oggetto RepoSync denominato repo-sync, il deployment del reconciler è 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
reconciler-manager	config-management-system	Reconciler Manager viene eseguito su ogni cluster con Config Sync abilitato nell'oggetto ConfigManagement. Monitora gli oggetti RootSync e RepoSync e gestisce un deployment di riconciliazione per ciascuno.	1	reconciler-manager-.*	2	reconciler-manager otel-agent
root-reconciler	config-management-system	Viene creato un deployment di riconciliazione 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 di riconciliazione 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 abilitato nell'oggetto ConfigManagement. Raccoglie le metriche dai componenti 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 abilitato nell'oggetto ConfigManagement. Monitora gli oggetti ResourceGroup e li aggiorna con lo stato di riconciliazione corrente di ciascun oggetto nel suo inventario. Viene creato un oggetto ResourceGroup per ogni oggetto RootSync e RepoSync per inventariare l'elenco di oggetti applicati dal riconciliatore dalla fonte attendibile.	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 prevenzione della deriva abilitata nell'oggetto ConfigManagement. Monitora le richieste dell'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 container, vedi Container di riconciliazione.

Componenti chiave

Le sezioni seguenti esplorano in modo più dettagliato i componenti importanti di Config Sync.

Servizio di gestione della flotta e oggetto ConfigSync

In Config Sync versione 1.20.0 e successive, il servizio Hub Fleet gestisce direttamente i componenti di Config Sync sul cluster:

Il servizio Fleet gestisce anche l'oggetto ConfigSync sul cluster. Il servizio Fleet aggiorna sia la specifica dell'oggetto ConfigSync in base ai tuoi input all'API Google Cloud sia il suo stato per 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.

Gestore della riconciliazione e riconciliatori

Reconciler Manager è responsabile della creazione e della gestione dei singoli riconciliatori che garantiscono la sincronizzazione della configurazione del cluster.

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

I riconciliatori root e dello spazio dei nomi recuperano automaticamente le configurazioni dalla tua origine di verità e le applicano per imporre lo stato che vuoi all'interno del cluster.

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

Container di riconciliazione

I container specifici di cui è stato eseguito il deployment nei pod di riconciliazione dipendono dalle scelte di configurazione che fai. La tabella seguente spiega in dettaglio la funzione di ciascuno di questi contenitori di riconciliazione e la condizione che determina la creazione di Config Sync:

Nome del contenitore	Descrizione	Condizione
reconciler	Gestisce la sincronizzazione e la correzione della deriva.	Sempre abilitato.
otel-agent	Riceve le metriche dagli altri container di riconciliazione e le invia a OpenTelemetry Collector.	Sempre abilitato.
git-sync	Estrae le configurazioni dal repository Git in una directory locale che il container di riconciliazione può leggere.	Attivata quando spec.sourceType è git.
helm-sync	Estrae e visualizza i grafici Helm dal repository dei grafici in una directory locale che il container reconciler può leggere.	Attivata quando spec.sourceType è helm.
oci-sync	Estrae le immagini OCI contenenti le configurazioni dal registro di container in una directory locale che il container di riconciliazione può leggere.	Attivata quando spec.sourceType è oci.
gcenode-askpass-sidecar	Memorizza nella cache le credenziali Git dal servizio di metadati GKE per l'utilizzo da parte del container git-sync.	Attivato 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.	Attivato quando la sorgente include un file kustomize.yaml.

Come mostrato nella tabella precedente, in genere puoi prevedere un conteggio dei container da tre a cinque all'interno di ogni pod di riconciliazione. I contenitori reconciler e otel-agent sono sempre presenti. La specifica di un tipo per l'origine attendibile determina quale contenitore di sincronizzazione viene aggiunto. Inoltre, i contenitori hydration-controller e gcenode-askpass-sidecar vengono creati se hai apportato le modifiche alla configurazione menzionate nella tabella.

Oggetti ResourceGroup Controller e ResourceGroup

I riconciliatori di root e spazio dei nomi creano un oggetto inventario ResourceGroup per ogni oggetto RootSync e RepoSync che configuri. Ogni oggetto ResourceGroup contiene un elenco di oggetti sincronizzati con il cluster dalla fonte attendibile dal riconciliatore per l'oggetto RootSync o RepoSync. Il controller ResourceGroup osserva quindi tutti gli oggetti nell'oggetto ResourceGroup e aggiorna lo stato dell'oggetto ResourceGroup con lo stato di riconciliazione attuale degli oggetti sincronizzati. In questo modo puoi controllare lo stato dell'oggetto ResourceGroup per una panoramica dello stato della sincronizzazione, anziché dover interrogare lo 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ò può interferire con il funzionamento di Config Sync.

Webhook di controllo dell'ammissione

L'webhook di ammissione di Config Sync viene creato quando attivi la prevenzione della deriva. La prevenzione della deriva intercetta in modo proattivo le richieste di modifica, assicurandosi che siano in linea con la fonte di verità prima di consentire le modifiche.

Se non attivi la prevenzione della deriva, Config Sync utilizza comunque un meccanismo di autoriparazione per ripristinare la deriva della configurazione. Con l'autoriparazione, Config Sync monitora continuamente gli oggetti gestiti e annulla automaticamente qualsiasi modifica che si discosta dallo stato previsto.

Oggetti RootSync e RepoSync

Gli oggetti RootSync configurano Config Sync per creare un riconciliatore radice che monitora l'origine attendibile specificata e applica gli oggetti di questa origine al cluster. Per impostazione predefinita, il riconciliatore principale per ogni oggetto RootSync dispone dell'autorizzazione cluster-admin. Con questa autorizzazione predefinita, i riconciliatori root possono sincronizzare le risorse con ambito cluster e con ambito 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 di questa origine a uno 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 dei nomi con autorizzazioni personalizzate specificate dall'utente. Gli oggetti RepoSync sono progettati per essere utilizzati dai tenant dello spazio dei nomi.

Come 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'API Google Cloud .

Quando l'installazione di Config Sync è gestita dal servizio Fleet, puoi anche fare in modo che gestisca l'oggetto RootSync iniziale, denominato root-sync. In questo modo puoi eseguire il bootstrap di GitOps sul cluster senza dover applicare manualmente nulla direttamente al cluster. Se decidi di non far gestire l'oggetto RootSync iniziale dal servizio Fleet, puoi comunque applicare gli oggetti RootSync e RepoSync che vuoi 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'API config-management apply. Poiché questa API espone solo un sottoinsieme dei RootSync campi, questi campi sono considerati gestiti in root-sync, mentre gli altri campi sono considerati non gestiti. I campi gestiti possono essere modificati solo utilizzando l'API Google Cloud . I campi non gestiti possono essere modificati utilizzando kubectl o qualsiasi altro client Kubernetes.

Oggetti RootSync e RepoSync aggiuntivi

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 ulteriori oggetti RootSync o RepoSync con GitOps, aggiungendo i relativi manifest YAML all'origine attendibile da cui root-sync è configurato per la sincronizzazione. Questo metodo non può essere utilizzato per gestire la configurazione di 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 oggetti RootSync e RepoSync aggiuntivi, consulta Configurare la sincronizzazione da più di una fonte attendibile.

Passaggi successivi

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