Questa pagina ti introduce all'architettura di Config Sync. Informazioni su i componenti creati da Config Sync possono aiutarti a comprendere meglio Config Sync e può aiutarti a eseguire il debug e a risolvere i problemi riscontrati.
Il seguente diagramma mostra l'architettura di Config Sync e i relativi risorse su un cluster Google Kubernetes Engine (GKE) Enterprise:
In questo diagramma, l'utente crea una fonte attendibile e installa Config Sync utilizzando Gestore delle funzionalità.
Per installare Config Sync sono previsti più passaggi e ognuno di questi passaggi esegue il deployment di componenti aggiuntivi sul tuo cluster:
L'abilitazione di Config Sync sul cluster aggiunge i seguenti componenti:
- L'operatore ConfigManagement in un deployment denominato
config-management-operator
. - La definizione di risorsa personalizzata (CRD)
ConfigManagement
e l'oggetto denominatoconfig-management
. - Il gestore riconciliatore in un deployment denominato
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 Config Sync in un deployment denominato
admission-webhook
.
La maggior parte di queste risorse e oggetti viene creata automaticamente installano Config Sync e non devi modificarli.
- L'operatore ConfigManagement in un deployment denominato
La creazione di oggetti
RootSync
eRepoSync
comporta l'aggiunta di quanto segue componenti:- Per ogni
RootSync
, un deployment del riconciliatore denominatoroot-reconciler-ROOTSYNC_NAME
. - Per ogni
RepoSync
, un deployment del riconciliatore denominatons-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH
.
- Per ogni
Deployment, pod e container in Config Sync
La tabella seguente fornisce ulteriori informazioni su Config Sync Deployment, pod e container:
Nome deployment | Spazio dei nomi deployment | Descrizione deployment | Numero repliche | Espressione regolare del nome del pod | Numero di container | Nomi container |
---|---|---|---|---|---|---|
config-management-operator |
config-management-system |
L'operatore ConfigManagement viene eseguito su ogni cluster con Config Sync
installato. Controlla l'oggetto ConfigManagement e gestisce
Componenti di Config Sync, come Reconciler Manager e OpenTelemetry
Raccoglitore. |
1 | config-management-operator-.* |
1 | manager |
reconciler-manager |
config-management-system |
Reconciler Manager viene eseguito su ogni cluster con Config Sync
abilitato nell'oggetto ConfigManagement . Guarda
RootSync
e RepoSync oggetti e gestisce un deployment di riconciliazione
per ognuno. |
1 | reconciler-manager-.* |
2 | reconciler-manager otel-agent |
root-reconciler |
config-management-system |
Viene creato un deployment del riconciliatore radice per ogni oggetto RootSync . |
1 | root-reconciler-.* |
3 - 51 |
reconciler otel-agent git-sync helm-sync oci-sync gcenode-askpass-sidecar hydration-controller |
ns-reconciler |
config-management-system |
Per ogni oggetto RepoSync viene creato un deployment del riconciliatore dello spazio dei nomi. |
1 | ns-reconciler-.* |
3 - 51 |
reconciler otel-agent git-sync helm-sync oci-sync gcenode-askpass-sidecar hydration-controller |
otel-collector |
config-management-monitoring |
Il raccoglitore OpenTelemetry viene eseguito su ogni cluster con Config Sync
abilitato nell'oggetto ConfigManagement . Raccoglie metriche
dai componenti di Config Sync in esecuzione
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 . Guarda
ResourceGroup oggetti e li aggiorna con lo stato attuale
di ogni oggetto nell'inventario. R
Viene creato ResourceGroup oggetto ogni
RootSync e RepoSync contestano l'inventario
elenco di oggetti applicati dal riconciliatore dall'origine dei dati. |
1 | resource-group-controller-manager-.* |
2 | reconciler-manager otel-agent |
admission-webhook |
config-management-system |
Il webhook di ammissione di Config Sync viene eseguito su ogni cluster con
prevenzione della deviazione
abilitato nell'oggetto ConfigManagement . Monitora
richiede l'API Kubernetes e impedisce la modifica o l'eliminazione
e risorse gestite da Config Sync. Ingresso Config Sync
webhook è disattivato per impostazione predefinita. |
2 | admission-webhook-.* |
1 | admission-webhook |
1 Per maggiori dettagli su quando vengono creati questi container, consulta Container di riconciliazione.
Componenti chiave
Le seguenti sezioni esplorano i componenti importanti di Config Sync in dettaglio.
Operatore e oggetto ConfigManagement
L'operatore ConfigManagement monitora l'oggetto ConfigManagement
e
crea e gestisce gli altri componenti necessari per il funzionamento di Config Sync:
Poiché l'operatore ConfigManagement installa alcuni componenti che richiedono
cluster-admin
di autorizzazioni, l'operatore ConfigManagement richiede
cluster-admin
autorizzazioni.
Responsabile riconciliatore e riconciliatori
Il responsabile della riconciliazione è responsabile della creazione e della gestione riconciliatori che garantiscano la sincronizzazione della configurazione del cluster.
Il Gestore riconciliatore crea un riconciliatore radice per ogni oggetto RootSync
e
un riconciliatore dello spazio dei nomi per ogni oggetto RepoSync
. Config Sync utilizza questo
del progetto anziché condividere un unico riconciliatore monolitico perché
l'affidabilità riducendo i single point of failure e consente alle singole
da scalare in modo indipendente.
I riconciliatori radice e dello spazio dei nomi recuperano automaticamente le configurazioni dall'origine di e applicarle per applicare lo stato che vuoi all'interno del cluster.
I seguenti diagrammi mostrano come il Gestore riconciliatore gestisce il controllo ciclo di vita di ciascun riconciliatore radice e dello spazio dei nomi:
Container riconciliatori
I container specifici di cui è stato eseguito il deployment nei pod del riconciliatore dipendono le scelte di configurazione che fai. La tabella seguente fornisce ulteriori informazioni su cosa ognuno di questi container di riconciliazione e la condizione che Config Sync per crearle:
Nome container | Descrizione | Condizione |
---|---|---|
reconciler |
Gestisce la sincronizzazione e la correzione delle deviazioni. | Sempre attiva. |
otel-agent |
Riceve le metriche dagli altri contenitori del riconciliatore e le invia alla OpenTelemetry Collector. | Sempre attiva. |
git-sync |
Esegue il pull delle configurazioni dal tuo repository Git a una directory locale in cui il container del riconciliatore può leggere. | Attivato quando il criterio spec.sourceType è git . |
helm-sync |
Esegue il pull e il rendering dei grafici Helm dal tuo repository di grafici a una directory letta dal container del riconciliatore. | Attivato quando il criterio spec.sourceType è helm . |
oci-sync |
Esegue il pull delle immagini OCI contenenti le tue configurazioni dal Container Registry a un la directory locale che può leggere il container del riconciliatore. | Attivato quando il criterio spec.sourceType è oci . |
gcenode-askpass-sidecar |
Memorizza nella cache le credenziali Git del servizio di metadati GKE per
utilizzata dal container git-sync . |
Attivato quando il valore di 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. | Attivato quando l'origine include un file kustomize.yaml . |
Come mostrato nella tabella precedente, in genere è previsto un conteggio dei container
da tre a cinque all'interno di ciascun pod del riconciliatore. reconciler
e otel-agent
i container sono sempre presenti. Specificare un tipo per la fonte di riferimento
indica quale contenitore di sincronizzazione viene aggiunto. Inoltre, hydration-controller
e gcenode-askpass-sidecar
container vengono creati se hai creato
modifiche alla configurazione
menzionate nella tabella.
Oggetti ResourceGroup Controller e ResourceGroup
I riconciliatori radice 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
riconciliatore per l'oggetto RootSync
o RepoSync
. Il gruppo di risorse
Il controller controlla poi tutti gli oggetti nell'oggetto ResourceGroup
e
aggiorna lo stato dell'oggetto ResourceGroup
con la riconciliazione attuale
degli oggetti sincronizzati. In questo modo puoi controllare lo stato di ResourceGroup
oggetto
per una panoramica dello stato della sincronizzazione, invece di dover chiedere lo stato
personalmente ogni singolo oggetto.
ResourceGroup
oggetti hanno lo stesso nome e spazio dei nomi dei corrispondenti
Oggetto RootSync
o RepoSync
. Ad esempio, per l'oggetto RootSync
con
root-sync
nello spazio dei nomi config-management-system
, il valore corrispondente
L'oggetto ResourceGroup
è denominato anche root-sync
nel
config-management-system
.
Non creare o modificare ResourceGroup
oggetti, poiché potrebbero interferire con
il funzionamento di Config Sync.
Webhook di ammissione
Il webhook di ammissione per Config Sync viene creato quando attivi prevenzione della deviazione. Prevenzione della deviazione intercetta in modo proattivo le richieste di modifica, assicurandosi che siano in linea con una fonte attendibile prima di consentire cambiamenti.
Se non attivi la prevenzione delle deviazioni, Config Sync utilizza comunque una funzionalità di riparazione automatica per ripristinare la deviazione della configurazione. Con la riparazione automatica, Config Sync monitora continuamente gli oggetti gestiti e inverte automaticamente qualsiasi modifica che si discostano dallo stato previsto.
Oggetti RootSync e RepoSync
RootSync
oggetti configurano Config Sync per creare un riconciliatore principale che
controlla la fonte di dati specificata e applica gli oggetti provenienti da tale origine al
in un cluster Kubernetes. Per impostazione predefinita, il riconciliatore radice per ogni oggetto RootSync
dispone dell'autorizzazione cluster-admin
. Con
questa autorizzazione predefinita, i riconciliatori radice possono sincronizzare sia con ambito cluster
con ambito a livello di spazio dei nomi. Se necessario, puoi modificare queste autorizzazioni
la configurazione
spec.override.roleRefs
campi. Gli oggetti RootSync
sono progettati per essere utilizzati dagli amministratori del cluster.
RepoSync
oggetti configurano Config Sync per creare un riconciliatore dello spazio dei nomi
che osserva l'origine specificata e applica gli oggetti provenienti da tale origine a un
uno spazio dei nomi specifico
nel cluster. I riconciliatori dello spazio dei nomi possono sincronizzare
con ambito a livello di spazio dei nomi con risorse
autorizzazioni aggiuntive. Gli oggetti RepoSync
sono progettati per essere utilizzati dai tenant dello spazio dei nomi.
Modalità di gestione degli oggetti RootSync da parte del servizio Fleet
Quando installi Config Sync con la console Google Cloud, Google Cloud CLI Config Connector, o Terraform, Config Sync è gestito dal servizio Fleet, in base ai tuoi input all'API Google Cloud.
Quando l'installazione di Config Sync è gestita dal servizio Parco risorse, puoi
facoltativamente gestire anche l'oggetto RootSync
iniziale, denominato
root-sync
. Questo ti consente di eseguire il bootstrap di GitOps nel tuo cluster senza dover
di applicare manualmente qualsiasi cosa direttamente al cluster. Se decidi di non avere
Il servizio del parco risorse gestisce l'oggetto RootSync
iniziale, ma puoi ancora applicare
qualsiasi oggetto RootSync
e RepoSync
da assegnare direttamente al cluster.
L'oggetto RootSync
denominato root-sync
viene creato in base ai tuoi input nell'oggetto
l'API Google Cloud, in particolare la sezione spec.configSync
del
applica la configurazione della configurazione
API. Poiché questa API
espone solo un sottoinsieme dei RootSync
campi,
questi campi vengono 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. L'account non gestito
campi
può essere modificato utilizzando kubectl
o qualsiasi altro client Kubernetes. Ad esempio,
che ti mostra come esportare il file YAML root-sync
, modificarlo localmente e applicare nuovamente
vedi Creare e modificare una configurazione RootSync
.
Per le installazioni manuali:
gestire Config Sync con lo strumento a riga di comando kubectl
o con qualsiasi altro
un client Kubernetes.
Oggetti RootSync e RepoSync aggiuntivi
Per creare altri oggetti RootSync
o RepoSync
, puoi utilizzare kubectl
a strumento a riga di comando o un altro client Kubernetes. Puoi anche utilizzare il modello
root-sync
oggetto per gestire oggetti RootSync
o RepoSync
aggiuntivi con
GitOps, aggiungendo i propri manifest YAML alla fonte attendibile che
root-sync
è configurato per la sincronizzazione. Questo metodo non può essere utilizzato per gestire
del valore iniziale di root-sync
, poiché alcuni dei suoi campi sono gestiti
Servizio di flotta. Per gestire l'oggetto root-sync
con GitOps, utilizza Config Connector o
con Terraform. Per scoprire di più sulla creazione di RootSync
e RepoSync
aggiuntivi
di oggetti, vedi
Configura la sincronizzazione da più fonti di riferimento.
Passaggi successivi
- Potresti voler monitorare i componenti di Config Sync o controllare i relativi log. Per per un'introduzione, vedi Utilizza il monitoraggio e i log.
- Scopri di più sulle richieste di risorse per i componenti di Config Sync.