Questa pagina presenta l'architettura di Config Sync, inclusi i componenti ospitati che vengono eseguiti in Google Cloud e i componenti open source che vengono eseguiti sul cluster Google Kubernetes Engine. Comprendere l'architettura può aiutarti a capire 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 suoi componenti e dipendenze, sia in Google Cloud che nel tuo cluster GKE:
Il
servizio Fleet
gestisce i componenti di Config Sync sul cluster direttamente, senza l'
operatore ConfigManagement legacy o l'oggetto ConfigManagement. Devi eseguire l'upgrade manuale di Config Sync, se necessario.
L'abilitazione di Config Sync sul cluster aggiunge i seguenti componenti:
- La definizione di risorsa personalizzata (CRD)
ConfigSync. - Un oggetto
ConfigSyncdenominatoconfig-sync. - Reconciler Manager in un deployment denominato
reconciler-manager. - ResourceGroup Controller in un deployment denominato
resource-group-controller-manager. - Il 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 abiliti la prevenzione della deriva.
Queste risorse e questi oggetti vengono creati automaticamente quando installi Config Sync e non devono essere modificati direttamente.
- La definizione di risorsa personalizzata (CRD)
La creazione di oggetti
RootSynceRepoSyncaggiunge i seguenti componenti:- Per ogni oggetto
RootSync, un deployment del riconciliatore denominatoroot-reconciler-ROOTSYNC_NAME. Per l'oggettoRootSyncdenominatoroot-sync, il deployment del riconciliatore è denominatoroot-reconciler. Per ogni oggetto
RepoSync, un deployment del riconciliatore denominatons-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Per l'RepoSyncoggetto denominatorepo-sync, il deployment del riconciliatore è denominatons-reconciler-REPOSYNC_NAMESPACE.
- Per ogni oggetto
Deployment, pod e container di Config Sync
La tabella seguente fornisce ulteriori informazioni sul deployment, sui pod e sui 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 del riconciliatore
per ognuno. |
1 | reconciler-manager-.* |
2 | reconciler-managerotel-agent |
root-reconciler |
config-management-system |
Viene creato un deployment del riconciliatore root per ogni oggetto RootSync. |
1 | root-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
ns-reconciler-.* |
config-management-system |
Viene creato un deployment del riconciliatore dello spazio dei nomi per ogni oggetto RepoSync. |
1 | ns-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-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 di Config Sync in esecuzione negli
config-management-system e resource-group-system
spazi dei nomi 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 attuale di ogni oggetto nel relativo inventario. Viene creato un oggetto
ResourceGroup per ogni
RootSync e RepoSync per inventariare l'
elenco degli oggetti applicati dal riconciliatore dall'origine attendibile. |
1 | resource-group-controller-manager-.* |
2 | managerotel-agent |
admission-webhook |
config-management-system |
Il webhook di ammissione di Config Sync viene eseguito su ogni cluster con
la 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
è disabilitato per impostazione predefinita. |
2 | admission-webhook-.* |
1 | admission-webhook |
1 Per informazioni dettagliate su quando vengono creati questi container, consulta Container del riconciliatore.
Richieste di risorse di deployment
La tabella seguente elenca i requisiti delle risorse Kubernetes per i componenti di Config Sync. Per ulteriori informazioni, consulta Gestione delle risorse per pod e container nella documentazione di Kubernetes.
Le richieste di risorse sono uguali per tutte le versioni supportate di Config Sync.
| Nome deployment | Richiesta di CPU (m) per replica | Richiesta di memoria (Mi) per replica |
|---|---|---|
config-management-operator |
100 | 200 |
resource-group-controller-manager |
110 | 300 |
admission-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (uno per RootSync e RepoSync) |
Per informazioni dettagliate, consulta Richieste di risorse del riconciliatore. | |
1 Il webhook di ammissione ha due repliche. Se utilizzi il webhook di ammissione e devi calcolare le richieste di risorse totali, raddoppia il valore. Il webhook di ammissione è disabilitato per impostazione predefinita.
Componenti chiave
Le sezioni seguenti esplorano in modo più dettagliato i componenti importanti di Config Sync.
Servizio Fleet e oggetto ConfigSync
Il servizio Hub Fleet gestisce 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' Google Cloud API sia il relativo stato per riflettere lo stato dei
componenti di Config Sync.
Per apportare modifiche alla configurazione dell'installazione di Config Sync, devi utilizzare l' Google Cloud API. Tuttavia, puoi utilizzare l' Google Cloud API o l'API Kubernetes per monitorare la configurazione e l'integrità dell'installazione di Config Sync.
Reconciler Manager e riconciliatori
Reconciler Manager è responsabile della creazione e della gestione dei singoli riconciliatori che garantiscono che la configurazione del cluster rimanga sincronizzata.
Reconciler Manager crea un riconciliatore root per ogni oggetto RootSync e un riconciliatore dello spazio dei nomi per ogni oggetto RepoSync. Config Sync utilizza questa progettazione anziché condividere un singolo riconciliatore monolitico perché migliora l'affidabilità riducendo i singoli punti di errore e consente di scalare i singoli riconciliatori in modo indipendente.
I riconciliatori root e dello spazio dei nomi recuperano automaticamente le configurazioni dall'origine attendibile e le applicano per applicare lo stato desiderato all'interno del cluster.
I seguenti diagrammi mostrano come Reconciler Manager gestisce il controllo del ciclo di vita di ogni riconciliatore root e riconciliatore dello spazio dei nomi:
Container del riconciliatore
I container specifici di cui viene eseguito il deployment nei pod del riconciliatore dipendono dalle scelte di configurazione che effettui. La tabella seguente fornisce ulteriori informazioni su cosa fa ciascuno di questi container del riconciliatore e sulla condizione che fa sì che Config Sync li crei:
| Nome container | Descrizione | Condizione |
|---|---|---|
reconciler |
Gestisce la sincronizzazione e la correzione della deriva. | Sempre abilitato. |
otel-agent |
Riceve le metriche dagli altri container del riconciliatore e le invia a OpenTelemetry Collector. | Sempre abilitato. |
git-sync |
Estrae le configurazioni dal repository Git in una directory locale che il container del riconciliatore può leggere. | Abilitato quando spec.sourceType è git. |
helm-sync |
Estrae ed esegue il rendering dei grafici Helm dal repository dei grafici in una directory locale che il container del riconciliatore può leggere. | Abilitato quando spec.sourceType è helm. |
oci-sync |
Estrae le immagini OCI contenenti le configurazioni dal registro di container in una directory locale che il container del riconciliatore può leggere. | Abilitato quando spec.sourceType è oci. |
gcenode-askpass-sidecar |
Memorizza nella cache le credenziali Git dal servizio di metadati GKE per
l'utilizzo da parte del git-sync container. |
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 container del riconciliatore può leggere. | Abilitato quando l'origine 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 del riconciliatore. I container reconciler e otel-agent sono sempre presenti. La specifica di un tipo per l'origine attendibile determina il container di sincronizzazione da aggiungere. Inoltre, i container hydration-controller e gcenode-askpass-sidecar vengono creati se hai apportato le modifiche alla configurazione menzionate nella tabella.
Richieste di risorse del riconciliatore
Per ogni oggetto RootSync e RepoSync, Config Sync crea un deployment del riconciliatore indipendente per gestire la sincronizzazione. Il deployment del riconciliatore è costituito da più container. Per ulteriori informazioni su questi container,
vedi Container del riconciliatore.
Le richieste di risorse sono uguali per tutte le versioni supportate di Config Sync.
La tabella seguente elenca le richieste di risorse per i cluster standard:
| Nome container | Richiesta di CPU (m) | Richiesta di memoria (Mi) |
|---|---|---|
reconciler |
50 | 200 |
otel-agent |
10 | 100 |
hydration-controller (facoltativo) |
10 | 100 |
git-sync |
10 | 16 |
gcenode-askpass-sidecar (facoltativo) |
10 | 20 |
helm-sync |
75 | 128 |
oci-sync |
25 | 32 |
La tabella seguente elenca le richieste di risorse per i cluster Autopilot:
| Nome container | Richiesta e limite di CPU (m) | Richiesta e limite di memoria (Mi) |
|---|---|---|
reconciler |
700 | 512 |
otel-agent |
10 | 64 |
hydration-controller (facoltativo) |
200 | 256 |
git-sync |
20 | 32 |
gcenode-askpass-sidecar (facoltativo) |
50 | 64 |
helm-sync |
250 | 384 |
oci-sync |
50 | 64 |
Per ulteriori informazioni su come sostituire le richieste e i limiti di risorse predefiniti, consulta Sostituzione delle richieste e dei limiti di risorse.
Versioni di Helm e Kustomize in bundle
Config Sync utilizza gli eseguibili Helm e Kustomize per eseguire il rendering delle configurazioni. Per trovare le versioni di Helm e Kustomize in bundle per la tua versione
di Config Sync, consulta i campi HELM_VERSION e KUSTOMIZE_VERSION nel
Makefile del
repository open source di Config Sync.
Puoi passare da un ramo all'altro in GitHub per visualizzare le versioni per le diverse release di Config Sync.
Per informazioni sul rendering di Helm tramite Kustomize, consulta Configurare Kubernetes con Kustomize. Per informazioni sull'utilizzo dell'API Helm, consulta Sincronizzare i grafici Helm da Artifact Registry.
ResourceGroup Controller e oggetti ResourceGroup
I riconciliatori root e dello spazio dei nomi creano un oggetto di inventario ResourceGroup per ogni oggetto RootSync e RepoSync che configuri. Ogni oggetto ResourceGroup contiene un elenco di oggetti sincronizzati con il cluster dall'origine attendibile dal riconciliatore per quell'oggetto RootSync o RepoSync. ResourceGroup Controller monitora 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'ResourceGroup
oggetto
per una panoramica dello stato di 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 gli oggetti ResourceGroup, in quanto ciò può interferire con il funzionamento di Config Sync.
Webhook di ammissione
Il webhook di ammissione di Config Sync viene creato quando abiliti la prevenzione della deriva. La prevenzione della deriva intercetta in modo proattivo le richieste di modifica, assicurandosi che siano allineate all'origine attendibile prima di consentire le modifiche.
Se non abiliti la prevenzione della deriva, Config Sync utilizza comunque un meccanismo di auto-riparazione per ripristinare la deriva della configurazione. Con l'auto-riparazione, Config Sync monitora continuamente gli oggetti gestiti e inverte automaticamente le modifiche che si discostano dallo stato previsto.
Oggetti RootSync e RepoSync
Gli oggetti RootSync configurano Config Sync per creare un riconciliatore root che monitora l'origine attendibile specificata e applica gli oggetti da quell'origine al cluster. Per impostazione predefinita, il riconciliatore root per ogni oggetto RootSync ha l'autorizzazione cluster-admin. Con questa autorizzazione predefinita, i riconciliatori root possono sincronizzare sia le risorse con ambito cluster sia quelle 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 da quell'origine a uno spazio dei nomi specifico nel cluster. I riconciliatori dello spazio dei nomi possono sincronizzare tutte le risorse con ambito 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 Google Cloud console, 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 fare in modo che gestisca l'oggetto RootSync iniziale, denominato root-sync. In questo modo puoi eseguire il bootstrapping di GitOps sul cluster senza dover applicare manualmente nulla direttamente al cluster. Se decidi di non fare in modo che il servizio Fleet gestisca l'oggetto RootSync iniziale, puoi comunque applicare direttamente al cluster gli oggetti RootSync e RepoSync che preferisci.
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 campi RootSync
,
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'
Google Cloud API. I campi
non gestiti
possono essere modificati utilizzando kubectl,
o qualsiasi altro client Kubernetes.
Oggetti RootSync e RepoSync aggiuntivi
Per creare oggetti RootSync o RepoSync aggiuntivi, puoi utilizzare lo strumento a riga di comando kubectl o un altro client Kubernetes. Puoi anche utilizzare l'oggetto root-sync iniziale per gestire oggetti RootSync o RepoSync aggiuntivi 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 ulteriori informazioni sulla creazione di oggetti RootSync e
RepoSync aggiuntivi, consulta
Configurare la sincronizzazione da più di un'origine attendibile.
Passaggi successivi
- Potresti voler monitorare i componenti di Config Sync o 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.