Config Sync utilizza componenti in hosting in Google Cloud e componenti open source nel tuo cluster Google Kubernetes Engine per riconciliare continuamente lo stato del cluster con una fonte di verità centrale. Comprendere il modo in cui questi componenti interagiscono ti aiuta a progettare flussi di lavoro GitOps scalabili e a risolvere i problemi di sincronizzazione o riconciliazione.
Panoramica dell'architettura
Il seguente diagramma mostra l'architettura di Config Sync, inclusi i suoi componenti e le sue dipendenze, sia in Google Cloud sia nel tuo cluster GKE:
Il servizio del parco risorse gestisce i componenti di Config Sync direttamente nel 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 diversi passaggi, ognuno dei quali esegue il deployment di componenti aggiuntivi nel cluster:
L'attivazione di Config Sync sul cluster aggiunge i seguenti componenti:
- La definizione di risorsa personalizzata (CRD)
ConfigSync - Un oggetto
ConfigSyncdenominatoconfig-sync. - Il Reconciler Manager 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) 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 deviazione.
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 reconciler denominatoroot-reconciler-ROOTSYNC_NAME. Per l'oggettoRootSyncdenominatoroot-sync, il deployment del reconciler è denominatoroot-reconciler. Per ogni oggetto
RepoSync, un deployment del reconciler denominatons-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Per l'oggettoRepoSyncdenominatorepo-sync, il deployment del reconciler è denominatons-reconciler-REPOSYNC_NAMESPACE.
- Per ogni oggetto
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 container | Nomi dei container |
|---|---|---|---|---|---|---|
reconciler-manager |
config-management-system |
Il Reconciler Manager viene eseguito su ogni cluster con Config Sync abilitato nell'oggetto ConfigManagement. Controlla gli oggetti RootSync e RepoSync e gestisce un deployment del riconciliatore per ciascuno. |
1 | reconciler-manager-.* |
2 | reconciler-managerotel-agent |
root-reconciler |
config-management-system |
Viene creato un deployment del reconciler principale 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 reconciler 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 |
Il Collector OpenTelemetry viene eseguito su ogni cluster con Config Sync abilitato 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 |
Il controller ResourceGroup 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 ogni oggetto nel loro inventario. Viene creato un oggetto ResourceGroup per ogni oggetto RootSync e RepoSync per inventariare l'elenco di oggetti applicati dal reconciler dalla fonte di verità. |
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 deviazione abilitata nell'oggetto ConfigManagement. Monitora le richieste 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 |
1 Per informazioni dettagliate su quando vengono creati questi container, consulta Container del reconciler.
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 le stesse per tutte le versioni supportate di Config Sync.
| Nome deployment | Richiesta 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 maggiori dettagli, consulta le richieste di risorse del reconciler. | |
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 è disattivato per impostazione predefinita.
Componenti chiave
Le sezioni seguenti descrivono in modo più dettagliato i componenti importanti di Config Sync.
Servizio del parco risorse e oggetto ConfigSync
Il servizio Hub Fleet gestisce i componenti di Config Sync nel cluster:
Il servizio Fleet gestisce anche l'oggetto ConfigSync nel tuo cluster. Il servizio Fleet aggiorna sia la specifica dell'oggetto ConfigSync in base agli input dell'API Google Cloud sia lo stato per riflettere lo stato dei componenti di Config Sync.
Per apportare modifiche alla configurazione dell'installazione di Config Sync, devi utilizzare l'API Google Cloud . Tuttavia, puoi utilizzare l'API Google Cloud o l'API Kubernetes per monitorare la configurazione e lo stato dell'installazione di Config Sync.
Reconciler Manager e reconciler
Il gestore del reconciler è responsabile della creazione e della gestione dei singoli reconciler che assicurano che la configurazione del cluster rimanga sincronizzata.
Il Reconciler Manager crea un reconciler root per ogni oggetto RootSync e un reconciler 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 fonte di verità e le applicano per applicare lo stato che vuoi all'interno del cluster.
I seguenti diagrammi mostrano in che modo Reconciler Manager gestisce il controllo del ciclo di vita di ogni riconciliatore root e riconciliatore dello spazio dei nomi:
Container del reconciler
I container specifici di cui viene eseguito il deployment nei pod del reconciler dipendono dalle scelte di configurazione che effettui. La tabella seguente spiega in modo più dettagliato cosa fa ciascuno di questi container del sincronizzatore e la condizione che ne determina la creazione da parte di Config Sync:
| Nome container | Descrizione | Condizione |
|---|---|---|
reconciler |
Gestisce la sincronizzazione e la correzione della deviazione. | Sempre attiva. |
otel-agent |
Riceve le metriche dagli altri container del reconciler e le invia al collettore OpenTelemetry. | Sempre attiva. |
git-sync |
Esegue il pull delle configurazioni dal repository Git a una directory locale che il container del reconciler può leggere. | Attivato quando spec.sourceType è git. |
helm-sync |
Esegue il pull e il rendering dei grafici Helm dal repository dei grafici a una directory locale che il container del reconciler può leggere. | Attivato quando spec.sourceType è helm. |
oci-sync |
Esegue il pull delle immagini OCI contenenti le configurazioni dal Container Registry a una directory locale che il container del reconciler può leggere. | Attivato quando spec.sourceType è oci. |
gcenode-askpass-sidecar |
Memorizza nella cache le credenziali Git del 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 container del reconciler può leggere. | Attivato quando l'origine include un file kustomize.yaml. |
Come mostrato nella tabella precedente, in genere puoi aspettarti un numero di container compreso tra tre e cinque all'interno di ogni pod del reconciler. I container reconciler e otel-agent sono sempre presenti. La specifica di un tipo per la fonte di riferimento determina quale contenitore di sincronizzazione viene aggiunto. Inoltre, vengono creati i container hydration-controller e gcenode-askpass-sidecar se hai apportato le modifiche alla configurazione menzionate nella tabella.
Richieste di risorse del reconciler
Per ogni oggetto RootSync e RepoSync, Config Sync crea un deployment del reconciler indipendente per gestire la sincronizzazione. Il deployment del reconciler è costituito da più container. Per saperne di più su questi container, consulta Container del reconciler.
Le richieste di risorse sono le stesse per tutte le versioni supportate di Config Sync.
La tabella seguente elenca le richieste di risorse per i cluster Standard:
| Nome container | Richiesta 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 saperne di più su come eseguire l'override delle richieste e dei limiti delle risorse predefiniti, consulta Override delle richieste e dei limiti delle risorse.
Versioni di Helm e Kustomize in bundle
Config Sync sfrutta gli eseguibili Helm e Kustomize per eseguire il rendering delle configurazioni. Per trovare le versioni di Helm e Kustomize incluse nel 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 branch all'altro in GitHub per visualizzare le versioni per le diverse release di Config Sync.
Per informazioni sul rendering di Helm tramite Kustomize, consulta Configura Kubernetes con Kustomize. Per informazioni sull'utilizzo dell'API Helm, consulta Sincronizza i grafici Helm da Artifact Registry.
Oggetti ResourceGroup Controller e ResourceGroup
I reconciler 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 dalla fonte di verità dal reconciler 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 corrente degli oggetti sincronizzati. In questo modo puoi controllare lo stato dell'oggetto ResourceGroup per avere una panoramica dello stato della sincronizzazione, invece di dover eseguire query sullo stato di ogni singolo oggetto.
Gli oggetti ResourceGroup hanno lo stesso nome e lo stesso 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 ammissione
Il webhook di ammissione di Config Sync viene creato quando attivi la prevenzione della deviazione. La prevenzione della deviazione intercetta in modo proattivo le richieste di modifica, assicurandosi che siano in linea con la fonte di attendibilità prima di consentire le modifiche.
Se non attivi la prevenzione della deviazione, Config Sync utilizza comunque un meccanismo di riparazione automatica per ripristinare la deviazione della configurazione. Con l'autoriparazione, Config Sync monitora continuamente gli oggetti gestiti e annulla 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 controlla la fonte di verità specificata e applica gli oggetti di quella fonte al cluster. Per impostazione predefinita, il reconciler 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 dei cluster.
Gli oggetti RepoSync configurano Config Sync per creare un riconciliatore dello spazio dei nomi che controlla l'origine specificata e applica gli oggetti di quell'origine a uno spazio dei nomi specifico nel cluster. I riconciliatori degli spazi dei nomi possono sincronizzare qualsiasi risorsa con ambito dello spazio dei nomi in quello spazio dei nomi con autorizzazioni personalizzate specificate dall'utente. Gli oggetti RepoSync sono progettati per l'utilizzo da parte dei 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 del parco risorse, in base agli input forniti all'API Google Cloud .
Quando l'installazione di Config Sync è gestita dal servizio del parco risorse, puoi anche fare in modo che gestisca l'oggetto RootSync iniziale, denominato root-sync. In questo modo puoi eseguire il bootstrap di GitOps sul tuo cluster senza dover applicare manualmente nulla direttamente al cluster. Se decidi di non far gestire l'oggetto RootSync iniziale dal servizio del parco risorse, 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 per l'APIGoogle Cloud , in particolare la 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'APIGoogle 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 oggetti RootSync o RepoSync aggiuntivi con GitOps, aggiungendo i relativi manifest YAML alla fonte di riferimento da cui è configurato l'oggetto root-sync per la sincronizzazione. Questo metodo non può essere utilizzato per gestire la configurazione del 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 saperne di più sulla creazione di oggetti RootSync e RepoSync aggiuntivi, consulta Configura la sincronizzazione da più di una fonte di attendibilità.
Passaggi successivi
- Potresti voler monitorare i componenti di Config Sync o controllare i relativi log. Per un'introduzione, consulta Utilizza il monitoraggio e i log.
- Scopri di più sulle richieste di risorse per i componenti di Config Sync.