Informazioni sulle fonti attendibili

Questo documento spiega i diversi tipi di fonti attendibili da cui Config Sync può eseguire la sincronizzazione.

Un concetto chiave nei flussi di lavoro GitOps è la fonte attendibile, un repository centrale in cui sono archiviati i file di configurazione. Un file di configurazione è in genere un file YAML o JSON che definisce le risorse Kubernetes. Normalmente, potresti applicare manualmente gli oggetti Kubernetes con lo strumento a riga di comando kubectl, ma Config Sync può applicare automaticamente queste risorse da un'unica fonte attendibile, ad esempio un repository Git. Config Sync monitora quindi la fonte di verità specificata e applica automaticamente le modifiche ai cluster.

Config Sync può sincronizzare i file di configurazione da tre diversi tipi di origini: repository Git, immagini Open Container Initiative (OCI) e grafici Helm. Questo documento spiega ciascuno di questi tipi di origine e il modo in cui Config Sync interagisce con loro. La lettura di questo documento può aiutarti a scegliere l'opzione di origine migliore per il tuo flusso di lavoro e il tuo ambiente.

Repository Git

Git è una tecnologia ampiamente adottata per il controllo della versione e la collaborazione. Con Git, puoi organizzare il repository nel modo più adatto alle tue esigenze e usufruire dei vantaggi del controllo delle versioni e della creazione di rami, se necessario. Poiché Git è una tecnologia matura e ampiamente adottata, hai a disposizione una vasta gamma di opzioni per provider e strumenti.

Quando configuri Config Sync con un repository Git come fonte attendibile, Config Sync utilizza un container git-sync all'interno del pod reconciler per estrarre le configurazioni dal repository Git. Puoi configurare l'URL, il ramo e la revisione (commit o tag) del repository per avere un maggiore controllo su dove estrarre le configurazioni all'interno del repository Git.

Configurazione di esempio di RootSync

L'esempio seguente mostra un manifest RootSync che viene sincronizzato da un repository Git:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

Questa configurazione imposta Config Sync in modo che sincronizzi i manifest da un repository Git. Config Sync monitora la directory cluster-configs nel ramo main del repository https://github.com/example/my-configs.git, controllando gli aggiornamenti ogni 60 secondi senza autenticazione.

Esempio di caso d'uso: gestione centralizzata

Immagina di essere un amministratore della piattaforma che vuole utilizzare un repository Git per applicare criteri di base a tutti i cluster di un parco progetti. In questo scenario, potresti archiviare NetworkPolicies, RoleBindings e ResourceQuotas standard in un repository Git centrale denominato standard-configs. Quando viene eseguito il provisioning di un nuovo cluster, Config Sync viene configurato per la sincronizzazione dal repository standard-configs, contribuendo a garantire che tutti i cluster soddisfino gli standard dell'organizzazione fin dall'inizio.

Immagini OCI

Le immagini OCI sono un formato standard per il packaging di applicazioni e relative dipendenze. Questo approccio considera le configurazioni come artefatti, in modo simile a come tratteresti le immagini container. Questo approccio offre vantaggi come l'immutabilità e prestazioni più rapide su larga scala. Con OCI, puoi utilizzare l'infrastruttura e gli strumenti per le immagini container come Artifact Registry per gestire le immagini e Workload Identity Federation for GKE per semplificare l'autenticazione.

L'utilizzo di OCI come origine di configurazione in genere richiede un processo separato per creare i file di configurazione in un'immagine OCI e poi eseguirne il push in una piattaforma di registro come Artifact Registry. Questo approccio può essere meno direttamente leggibile rispetto alle configurazioni archiviate come file in un repository Git.

Quando configuri Config Sync con un'immagine OCI come fonte attendibile, Config Sync utilizza un container oci-sync all'interno del pod del riconciliatore per estrarre l'immagine OCI contenente le configurazioni dal registro.

Configurazione di esempio di RootSync

L'esempio seguente mostra un manifest RootSync che esegue la sincronizzazione da un'immagine OCI archiviata in Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

Questa configurazione imposta Config Sync in modo che esegua la sincronizzazione da un'immagine OCI. Config Sync estrae l'immagine us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 da Artifact Registry utilizzando un account di servizio Kubernetes per l'autenticazione.

Esempio di caso d'uso: integrazione della pipeline CI/CD

Immagina di voler integrare la creazione di immagini OCI nella pipeline CI/CD della tua organizzazione. Quando le modifiche ai file di configurazione vengono unite, puoi configurare la pipeline per eseguire test di convalida (come il comando nomos vet), creare i file YAML in un'immagine OCI ed eseguire il push dell'immagine in Artifact Registry. Config Sync rileverebbe e applicherebbe automaticamente la nuova versione dell'immagine ai tuoi cluster, garantendo un'implementazione con controllo delle versioni e convalidata di tutte le modifiche alla configurazione.

Grafici Helm

Helm è un gestore di pacchetti molto diffuso per Kubernetes, che utilizza un formato di pacchettizzazione chiamato grafici. Config Sync può recuperare, eseguire il rendering e sincronizzare le risorse definite nei grafici Helm.

Helm offre un modo coerente per pacchettizzare e riutilizzare le applicazioni Kubernetes. Puoi utilizzare modelli o grafici Helm predefiniti per configurazioni coerenti e riutilizzabili.

Se non hai familiarità con Helm, il processo di creazione di modelli e rilascio può aggiungere ulteriore complessità alla pipeline di gestione della configurazione.

Quando configuri Config Sync con un grafico Helm come fonte attendibile, Config Sync utilizza un container helm-sync all'interno del pod riconciliatore per estrarre i grafici da un repository Helm (come Artifact Registry) o da un repository Git, quindi esegue il rendering del grafico per produrre manifest Kubernetes. In alternativa, puoi utilizzare Config Sync con Kustomize per eseguire il rendering dei grafici Helm. Per ulteriori informazioni su questo approccio, vedi Utilizzo di Config Sync con Kustomize e Helm.

Configurazione di esempio di RootSync

L'esempio seguente mostra un manifest RootSync che viene sincronizzato da un grafico Helm archiviato in Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

Questa configurazione imposta Config Sync per sincronizzare un grafico Helm da un repository OCI. Config Sync recupera la versione 1.2.0 del grafico my-chart dal repository oci://us-central1-docker.pkg.dev/my-project/my-helm-repo e si autentica con il account di servizio my-service-account@my-project.iam.gserviceaccount.com. Esegue il deployment delle risorse del grafico nello spazio dei nomi my-app-namespace con il nome di release my-chart-release.

Esempio di caso d'uso: deployment di un'applicazione di terze parti

Supponi di far parte di un team di sviluppo di applicazioni che vuole eseguire il deployment di Prometheus in un cluster. Puoi configurare Config Sync in modo che esegua il pull da un grafico Helm predefinito che esegue il deployment di Prometheus. Anziché eseguire manualmente i comandi Helm, puoi definire l'origine, la versione e qualsiasi values personalizzato del grafico all'interno dell'oggetto RootSync o RepoSync di Config Sync. Config Sync mantiene il deployment sincronizzato con la versione e le configurazioni del grafico specificate.

Scegliere un tipo di fonte

Il tipo di origine migliore dipende dagli strumenti, dai flussi di lavoro e dalle preferenze esistenti del tuo team. Puoi utilizzare questa tabella per comprendere le caratteristiche principali di ogni tipo di origine e prendere una decisione informata:

Funzionalità Repository Git Immagine OCI Grafico Helm
Ideale per Gestione della configurazione per uso generico; flessibilità; leggibilità per gli esseri umani Configurazioni immutabili e con controllo delle versioni; utilizzo dell'infrastruttura di container Pacchettizzazione e distribuzione di applicazioni complesse
Mutabilità Modificabile Immutabile Modificabile (le versioni del grafico sono immutabili, ma i valori possono cambiare)
Rollback Ripristinare i commit o cambiare i rami Esegui il deployment del tag immagine precedente Eseguire il rollback a una versione precedente del grafico
Strumenti Client Git standard, pipeline CI/CD Docker o Podman, registri container Interfaccia a riga di comando Helm, repository Helm
Prestazioni Può essere più lento per i repository di grandi dimensioni Più veloce, soprattutto su larga scala Veloce durante il recupero da un repository di grafici
Autenticazione Flessibile (SSH, token), può essere più complesso da configurare Semplificato con la federazione delle identità per i carichi di lavoro per GKE (ad esempio, con Artifact Registry) Semplificato con la federazione delle identità per i carichi di lavoro per GKE (ad esempio, con Artifact Registry)

È anche possibile utilizzare diversi tipi di origine per scopi diversi nello stesso cluster. Ad esempio, un cluster potrebbe avere le seguenti caratteristiche:

  • Un RootSync sincronizzato da un repository Git contenente risorse e policy di base a livello di cluster gestite dal team della piattaforma.
  • Un RepoSync in uno spazio dei nomi specifico sincronizzato da un grafico Helm per eseguire il deployment di un'istanza Redis gestita da un team di applicazioni.
  • Un altro RepoSync in uno spazio dei nomi diverso che esegue la sincronizzazione da un'immagine OCI contenente un insieme di configurazioni specifiche dell'applicazione create da un processo CI/CD separato.

Passaggi successivi