Architettura di Config Sync

Questa pagina illustra l'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:

Diagramma che mostra la relazione tra gli oggetti e le risorse di Config Sync

In questo diagramma, l'utente crea una fonte attendibile e installa Config Sync utilizzando Gestore funzionalità.

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

  1. 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 config-management.
    • Il gestore 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) 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.

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

    • Per ogni RootSync, un deployment del riconciliatore denominato root-reconciler-ROOTSYNC_NAME.
    • Per ogni RepoSync, un deployment del riconciliatore denominato ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH.

Deployment, pod e container di Config Sync

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

Nome deployment Spazio dei nomi del 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 su cui è installato Config Sync. Monitora l'oggetto ConfigManagement e gestisce i componenti di Config Sync, come Reconciler Manager e OpenTelemetry Collector. 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 principale 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 Viene creato un deployment del riconciliatore dello spazio dei nomi per ogni oggetto RepoSync. 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 ResourceGroup Controller viene eseguito su ogni cluster con Config Sync attivo 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:

    Azionamento dell'operatore

    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 assicurano la sincronizzazione della configurazione del cluster.

    Reconciler Manager crea un riconciliatore principale per ogni oggetto RootSync e un riconciliatore del nome di spazio per ogni oggetto RootSync. 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 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:

    Diagramma che mostra come il Gestore riconciliatore controlla il riconciliatore radice Diagramma che mostra come Reconciler Manager controlla il riconciliatore dello spazio dei nomi

    Container riconciliatori

    I contenitori specifici di cui viene 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 delle deviazioni. Sempre abilitata.
    otel-agent Riceve le metriche dagli altri container di riconciliazione e le invia a 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. Abilitata quando spec.sourceType è git.
    helm-sync Esegue il pull e il rendering dei grafici Helm dal tuo repository di grafici a una la directory che può essere letta dal container del riconciliatore. Attivato quando il valore di 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. Abilitata 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. 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 contenitore del riconciliatore può leggere. Attivato 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 in ogni pod di riconciliazione. 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.

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

    Non creare o modificare gli oggetti ResourceGroup, poiché potrebbero 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. 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 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

    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 principali possono sincronizzare sia le risorse con ambito cluster sia quelle con ambito dello 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 quest'ultima 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.

    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 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 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.

    Ulteriori oggetti RootSync e RepoSync

    Per creare altri oggetti RootSync o RepoSync, puoi utilizzare kubectl a strumento a riga di comando 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 sorgente attendibile con cui 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 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