Architettura di Config Sync

Questa pagina illustra l'architettura di Config Sync. Conoscere i componenti creati da Config Sync può offrirti una comprensione più approfondita di Config Sync e può aiutarti a eseguire il debug e a risolvere i problemi che hai riscontrato.

Il seguente diagramma mostra l'architettura di Config Sync e le relative risorse su un cluster della versione Google Kubernetes Engine (GKE) Enterprise:

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

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

Per installare Config Sync sono previsti più passaggi e ognuno di questi esegue il deployment di componenti aggiuntivi sul tuo cluster:

  1. L'abilitazione di Config Sync sul tuo 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 denominato config-management.
    • Gestore riconciliazione 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 questi oggetti viene creata automaticamente durante l'installazione di Config Sync e non è necessario modificarli.

  2. La creazione di oggetti RootSync e RepoSync comporta l'aggiunta dei seguenti componenti:

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

Deployment, pod e container di Config Sync

La seguente tabella fornisce ulteriori informazioni sul deployment di Config Sync, sui pod e sui container:

Nome deployment Spazio dei nomi deployment Descrizione deployment Numero repliche Espressione regolare del nome del pod Conteggio container Nomi container
config-management-operator config-management-system L'operatore ConfigManagement viene eseguito su ogni cluster in cui è installato Config Sync. Controlla 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 Il Gestore riconciliazione viene eseguito su ogni cluster con Config Sync abilitato nell'oggetto ConfigManagement. Controlla RootSync e RepoSync oggetti e gestisce un deployment del riconciliatore per ciascuno di essi. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system Viene creato un deployment con riconciliazione 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 per la riconciliazione 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 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 Il controller ResourceGroup viene eseguito su ogni cluster con Config Sync abilitato nell'oggetto ConfigManagement. Controlla ResourceGroup oggetti e li aggiorna con lo stato di riconciliazione attuale di ciascun oggetto nel proprio inventario. Viene creato un oggetto ResourceGroup per ogni oggetto RootSync e RepoSync per inventariare l'elenco di oggetti applicati dal riconciliatore a partire dalla fonte dei dati. 1 resource-group-controller-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    admission-webhook config-management-system Il webhook Config Sync Admission viene eseguito su ogni cluster con la prevenzione delle derivazioni 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 Config Sync è disattivato per impostazione predefinita. 2 admission-webhook-.* 1
  • admission-webhook
    		•

    1 Per maggiori dettagli su quando vengono creati questi container, consulta Contenitori di riconciliazione.

    Componenti chiave

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

    Operatore e oggetto ConfigManagement

    L'operatore ConfigManagement controlla l'oggetto ConfigManagement e crea e gestisce altri componenti necessari al funzionamento di Config Sync:

    Azionamento dell'operatore

    Poiché l'operatore ConfigManagement installa alcuni componenti che richiedono le autorizzazioni cluster-admin, l'operatore ConfigManagement richiede anche le autorizzazioni cluster-admin.

    Responsabile riconciliatore e riconciliatori

    Il Gestore riconciliazione è responsabile della creazione e della gestione dei singoli riconciliatori affinché la configurazione del cluster rimanga sincronizzata.

    Il Gestore riconciliazione crea un riconciliatore principale per ogni oggetto RootSync e uno strumento di riconciliazione dello spazio dei nomi per ogni oggetto RepoSync. Config Sync utilizza questa progettazione 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 radice e dello spazio dei nomi recuperano automaticamente le configurazioni dalla fonte attendibile e le applicano per applicare lo stato che vuoi all'interno del cluster.

    I seguenti diagrammi mostrano il modo in cui Gestore riconciliatore gestisce il controllo del ciclo di vita di ogni riconciliatore principale e riconciliatore dello spazio dei nomi:

    Diagramma che mostra in che modo il Gestore riconciliare controlla il riconciliatore principale Diagramma che mostra in che modo il Gestore riconciliazioni controlla lo strumento di riconciliazione dello spazio dei nomi

    Contenitori di riconciliazione

    I container specifici di cui è stato eseguito il deployment nei pod del riconciliazione dipendono dalle scelte di configurazione effettuate. La tabella seguente fornisce ulteriori informazioni sulle azioni di ciascun container del riconciliazione e sulla condizione che causa la creazione di Config Sync:

    Nome contenitore Description Condizione
    reconciler Gestisce la sincronizzazione e la correzione delle deviazioni. Sempre abilitata.
    otel-agent Riceve le metriche dagli altri container del riconciliazione e le invia a OpenTelemetry Collector. Sempre abilitata.
    git-sync Estrae le configurazioni dal repository Git a una directory locale che può essere letta dal container del riconciliazione. Abilitato quando il valore di spec.sourceType è git.
    helm-sync Esegue il pull e il rendering dei grafici Helm dal tuo repository di grafici a una directory locale che il container del riconciliazioner può leggere. Abilitato quando il valore di spec.sourceType è helm.
    oci-sync Estrae le immagini OCI contenenti le tue configurazioni dal Container Registry a una directory locale che il container del riconciliatore può leggere. Abilitato quando il valore di spec.sourceType è oci.
    gcenode-askpass-sidecar Memorizza nella cache le credenziali Git del servizio di metadati GKE per essere utilizzate dal container git-sync. 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 può essere letta dal container dello strumento di riconciliazione. Abilitato quando l'origine include un file kustomize.yaml.

    Come mostrato nella tabella precedente, in genere puoi aspettarti un conteggio dei container compreso tra 3 e 5 in ogni pod di riconciliazione. I container reconciler e otel-agent sono sempre presenti. Se specifichi un tipo per la tua origine dati, stabilisci quale container di sincronizzazione aggiungere. Inoltre, i container hydration-controller e gcenode-askpass-sidecar vengono creati se hai apportato le modifiche di configurazione menzionate nella tabella.

    Oggetti ResourceGroup Controller e ResourceGroup

    I riconciliatori principali e dello spazio dei nomi creano un oggetto inventario ResourceGroup per ogni oggetto RootSync e RepoSync configurato. Ogni oggetto ResourceGroup contiene un elenco di oggetti sincronizzati con il cluster dalla fonte dei dati dal riconciliazione per l'oggetto RootSync o RepoSync. Il controller ResourceGroup controlla 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 di 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, anche l'oggetto ResourceGroup corrispondente è denominato root-sync nello spazio dei nomi config-management-system.

    Non creare o modificare gli oggetti ResourceGroup, poiché ciò può interferire con il funzionamento di Config Sync.

    Webhook di ammissione

    Il webhook Config Sync Admission viene creato quando abiliti la prevenzione delle derivazioni. La prevenzione delle deviazioni intercetta in modo proattivo le richieste di modifica, garantendo che siano in linea con la fonte attendibile prima di consentire le modifiche.

    Se non abiliti la prevenzione delle deviazioni, Config Sync utilizza comunque un meccanismo di riparazione automatica per ripristinare la deriva della configurazione. Con la riparazione automatica, Config Sync monitora costantemente gli oggetti gestiti e annulla automaticamente qualsiasi modifica che devia dallo stato previsto.

    Oggetti RootSync e RepoSync

    Gli oggetti RootSync configurano Config Sync per creare un riconciliatore radice che controlla la fonte di riferimento 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 risorse con ambito cluster e spazio dei nomi. Se necessario, puoi modificare queste autorizzazioni configurando i campi spec.override.roleRefs. RootSync oggetti sono progettati per l'utilizzo da parte degli amministratori del cluster.

    Gli oggetti RepoSync configurano Config Sync per creare uno strumento di riconciliazione 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 dello spazio dei nomi possono sincronizzare qualsiasi risorsa con ambito a livello di spazio dei nomi all'interno di quello spazio dei nomi con autorizzazioni personalizzate specificate dall'utente. RepoSync oggetti sono progettati per l'uso da parte dei tenant dello spazio dei nomi.

    In che modo il servizio parco risorse 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 nell'API Google Cloud.

    Quando l'installazione di Config Sync è gestita dal servizio Fleet, puoi scegliere di far gestire anche 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 al servizio parco risorse, puoi comunque applicare qualsiasi oggetto RootSync e RepoSync che vuoi direttamente al cluster.

    L'oggetto RootSync denominato root-sync viene creato in base ai tuoi input nell'API Google Cloud, in particolare la sezione spec.configSync dell'API config-management apply. Poiché questa API espone solo un sottoinsieme dei campi RootSync, quei campi sono considerati gestiti in root-sync, mentre gli altri 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. Per un esempio che mostra come esportare il file YAML root-sync, modificarlo localmente e applicarlo nuovamente, consulta Creare e modificare un file di configurazione RootSync.

    Per le installazioni manuali, gestisci Config Sync con lo strumento a riga di comando 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 altri oggetti RootSync o RepoSync con GitOps, aggiungendo i relativi manifest YAML alla fonte attendibile da cui è configurato root-sync per la sincronizzazione. Impossibile utilizzare questo metodo per gestire la configurazione dell'elemento root-sync iniziale, poiché alcuni dei suoi campi sono gestiti dal servizio del parco risorse. 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 un'origine attendibile.

    Passaggi successivi