Informazioni sulle fonti attendibili

Config Sync ti consente di automatizzare i deployment delle risorse Kubernetes nei tuoi cluster da una fonte di verità centrale, sostituendo i comandi kubectl manuali. Nei workflow GitOps, una fonte di verità è il repository centrale in cui archivi i file di configurazione YAML o JSON che definiscono le risorse del cluster. Config Sync monitora continuamente questo repository e applica automaticamente le modifiche ai tuoi cluster.

Puoi sincronizzare i file di configurazione da tre tipi di origini: repository Git, immagini Open Container Initiative (OCI) e grafici Helm. Comprendere il modo in cui Config Sync interagisce con ogni tipo di origine ti aiuta a scegliere l'opzione 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 sfruttare i vantaggi del controllo della versione e della ramificazione, se necessario. Poiché Git è maturo e ampiamente supportato, hai a disposizione una varietà di opzioni per provider e strumenti.

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

Esempio di configurazione di RootSync

L'esempio seguente mostra un manifest RootSync che si sincronizza 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 controlla la directory cluster-configs nel branch 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

Immagina di essere 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 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 la pacchettizzazione delle applicazioni e delle 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ù rapide su larga scala. Con OCI, puoi utilizzare l'infrastruttura e gli strumenti delle immagini container come Artifact Registry per gestire le tue immagini e Workload Identity Federation for GKE per semplificare l'autenticazione.

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

Quando configuri Config Sync con un'immagine OCI come fonte di verità, Config Sync utilizza un container oci-sync all'interno del pod del reconciler per eseguire il pull dell'immagine OCI contenente le configurazioni dal registry.

Esempio di configurazione di RootSync

L'esempio seguente mostra un manifest RootSync che si sincronizza 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 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 in modo che esegua test di convalida (come il comando nomos vet), crei i file YAML in un'immagine OCI e ne esegua il push ad Artifact Registry. Config Sync rileverà e applicherà automaticamente la nuova versione dell'immagine ai tuoi cluster, garantendo un'implementazione convalidata e con controllo della versione di tutte le modifiche alla configurazione.

Grafici Helm

Helm è un popolare gestore di pacchetti 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 già familiarità con Helm, il processo di creazione di modelli e release può aggiungere ulteriore complessità alla pipeline di gestione delle configurazioni.

Quando configuri Config Sync con un grafico Helm come fonte di verità, Config Sync utilizza un container helm-sync all'interno del pod del reconciler 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 i manifest Kubernetes. In alternativa, puoi utilizzare Config Sync con Kustomize per eseguire il rendering dei grafici Helm. Per ulteriori informazioni su questo approccio, consulta Utilizza Config Sync con Kustomize e Helm.

Esempio di configurazione di RootSync

L'esempio seguente mostra un manifest RootSync che si sincronizza 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 della release my-chart-release.

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

Immagina 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, definisci l'origine del grafico, la versione e qualsiasi values personalizzato 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 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 delle configurazioni per uso generico; flessibilità; leggibilità da parte di un essere umano Configurazioni immutabili e con controllo delle versioni; sfruttamento dell'infrastruttura di container Pacchettizzazione e distribuzione di applicazioni complesse
Mutabilità Modificabile Immutabile Mutabile (le versioni dei grafici sono immutabili, ma i valori possono cambiare)
Rollback Ripristina i commit o cambia i branch Esegui il deployment del tag immagine precedente Esegui il rollback a una versione precedente del grafico
Strumenti Client Git standard, pipeline CI/CD Docker o Podman, container registry Interfaccia a riga di comando Helm, repository Helm
Prestazioni Può essere più lento per repository di grandi dimensioni Più veloce, soprattutto su larga scala Rapido durante il recupero da un repository di grafici
Autenticazione Flessibile (SSH, token), può essere più complessa 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 tipi di origine diversi per scopi diversi sullo stesso cluster. Ad esempio, un cluster potrebbe avere:

  • Un RootSync che si sincronizza 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 che si sincronizza 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