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 workflow 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 attendibile specificata e applica automaticamente eventuali modifiche ai cluster.

Config Sync può sincronizzare i file di configurazione da tre diversi tipi di fonti: 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 essi. La lettura di questo documento può aiutarti a scegliere l'opzione di origine migliore per il tuo workflow 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, se necessario, usufruire dei vantaggi del controllo della versione e del branching. Poiché Git è una tecnologia matura e ampiamente adottata, hai a disposizione una varietà 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 del riconciliatore per eseguire il pull delle configurazioni dal repository Git. Puoi configurare l'URL, il ramo e la revisione (commit o tag) del repository per un maggiore controllo sulla posizione in cui eseguire il pull delle configurazioni all'interno del repository Git.

Esempio di configurazione RootSync

L'esempio seguente mostra un manifest RootSync che esegue la sincronizzazione 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 per sincronizzare 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, verificando la presenza di aggiornamenti ogni 60 secondi senza autenticazione.

Esempio di caso d'uso: gestione centralizzata

Supponiamo che tu sia un amministratore della piattaforma che vuole utilizzare un repository Git per applicare policy di base a tutti i cluster di un parco risorse. 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 eseguire la sincronizzazione dal repository standard-configs, contribuendo a garantire che tutti i cluster soddisfino gli standard organizzativi fin dall'inizio.

Immagini OCI

Le immagini OCI sono un formato standard per la creazione di pacchetti di applicazioni e relative dipendenze. Questo approccio tratta le configurazioni come artefatti, in modo simile a come tratteresti le immagini container. Questo approccio offre vantaggi come l'immutabilità e prestazioni più veloci su larga scala. Con OCI, puoi utilizzare l'infrastruttura e gli strumenti delle 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 una procedura separata 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 leggibile direttamente dall'utente 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 eseguire il pull dell'immagine OCI contenente le configurazioni dal registro.

Esempio di configurazione 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 per eseguire la sincronizzazione da un'immagine OCI. Config Sync esegue il pull dell'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

Supponiamo che tu voglia 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 in modo che esegua test di convalida (come il comando nomos vet), crei i file YAML in un'immagine OCI ed esegua il push dell'immagine in Artifact Registry. Config Sync rileverà e applicherà automaticamente la nuova versione dell'immagine ai cluster, garantendo un rollout convalidato e con controllo della versione di tutte le modifiche alla configurazione.

Grafici Helm

Helm è un gestore di pacchetti popolare 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 creare pacchetti 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 release 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 del riconciliatore per eseguire il pull dei 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, consulta Utilizzare Config Sync con Kustomize e Helm.

Esempio di configurazione RootSync

L'esempio seguente mostra un manifest RootSync che esegue la sincronizzazione 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.s3ns.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 ed esegue l'autenticazione con l'account di servizio my-service-account@my-project.s3ns.iam.gserviceaccount.com. Esegue il deployment delle risorse del grafico nello spazio dei nomi my-app-namespace con il nome della release my-chart-release.

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

Supponiamo che tu faccia parte di un team 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, definisci l'origine, la versione e qualsiasi values personalizzato del grafico all'interno dell'oggetto RootSync o RepoSync di Config Sync. Config Sync mantiene quindi il deployment sincronizzato con la versione e le configurazioni del grafico specificate.

Scelta di un tipo di origine

Il tipo di origine migliore dipende dagli strumenti, dai workflow 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 scopi generici; flessibilità; leggibilità Configurazioni immutabili e con controllo della versione; utilizzo dell'infrastruttura container Creazione di pacchetti e distribuzione di applicazioni complesse
Mutabilità Modificabile Immutabile Modificabile (le versioni del grafico sono immutabili, ma i valori possono cambiare)
Rollback Ripristina i commit o cambia i rami Esegui il deployment del tag dell'immagine precedente Esegui il rollback a una versione precedente del grafico
Strumenti Client Git standard, pipeline CI/CD Docker o Podman, registri container CLI Helm, repository Helm
Prestazioni Può essere più lento per repository di grandi dimensioni Più veloce, soprattutto su larga scala Veloce quando si recupera da un repository di grafici
Autenticazione Flessibile (SSH, token), può essere più complesso da configurare Semplificata con Workload Identity Federation for GKE (ad esempio, con Artifact Registry) Semplificata con Workload Identity Federation for GKE (ad esempio, con Artifact Registry)

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

  • Un oggetto RootSync che esegue la sincronizzazione da un repository Git contenente risorse e policy di base a livello di cluster gestite dal team della piattaforma.
  • Un oggetto RepoSync in uno spazio dei nomi specifico che esegue la sincronizzazione da un grafico Helm per eseguire il deployment di un'istanza Redis gestita da un team di applicazioni.
  • Un altro oggetto 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