Best practice per GitOps per Kubernetes con Config Sync

Questa pagina fornisce un punto di partenza per aiutarti a pianificare e progettare l'architettura delle pipeline GitOps CI/CD per Kubernetes, che possono aiutarti a ottenere il massimo da Config Sync.

GitOps è una best practice universale per le organizzazioni che gestiscono la configurazione ma quando si tratta di progettare la soluzione hai molte opzioni. Comprendere le opzioni a tua disposizione, nonché i vantaggi e i compromessi di queste decisioni, può aiutarti a evitare di riscrivere l'architettura in futuro.

Non è necessario seguire tutte le best practice elencate in questa pagina. Le best practice che scegli di adottare dipendono dalla tua situazione specifica. L'obiettivo di questa pagina è aiutarti a prendere decisioni consapevoli durante la configurazione dell'architettura GitOps.

Utilizza un repository di pacchetti privato e centralizzato

L'utilizzo di un repository centrale per i pacchetti pubblici o interni (come Helm o kpt) può aiutare i team a trovare i pacchetti più facilmente. Puoi usare servizi come Artifact Registry o repository Git.

Il team della piattaforma può implementare criteri in cui i team delle applicazioni possono usare i pacchetti solo dal repository centrale. In alternativa, potrebbero usare il repository centrale come insieme di pacchetti verificati.

Puoi limitare le autorizzazioni di scrittura nel repository solo a un numero limitato di ingegneri. Il resto dell'organizzazione può avere accesso in lettura. Consigliamo di implementare una procedura per promuovere i pacchetti nel repository centrale e la trasmissione degli aggiornamenti.

La tabella seguente elenca i vantaggi e gli svantaggi dell'utilizzo di un repository di pacchetti privato e centralizzato:

Vantaggi

Svantaggi

Importa i pacchetti pubblici a una cadenza definita, in modo da evitare interruzioni a causa della connettività o del tasso di abbandono a monte. Esamina e scansiona i pacchetti condivisi. Offre un modo semplice per scoprire quali file sono in uso e supportati. Ad esempio, i team possono trovare più facilmente il deployment Redis standard archiviato nel repository centrale. Apporta modifiche ai pacchetti upstream per assicurarti che soddisfino gli standard interni come i valori predefiniti, l'aggiunta di etichette e i repository di immagini container.

Qualcuno deve gestire il repository centrale. Aggiunge ulteriori procedure per i team che si occupano delle domande di partecipazione.

crea repository bagnati

Crea repository con l'output YAML che corrisponde allo stato desiderato del cluster o dello spazio dei nomi. Le modifiche al repository bagnato o completamente idratato dovrebbero essere facili da rivedere utilizzando un diff. È buona norma apportare modifiche al repository Wet tramite un processo di revisione (ad esempio, in GitHub, si tratta di una richiesta di pull).

La seguente tabella elenca i vantaggi e gli svantaggi della creazione di repository "bag":

Vantaggi	Svantaggi
È più facile esaminare le differenze. Non è necessaria alcuna elaborazione per vedere lo stato previsto della configurazione.	Una configurazione completamente idratata può portare a YAML ripetuti.

Shift a sinistra per convalidare le configurazioni

Attendere l'avvio della sincronizzazione di Config Sync per verificare la presenza di problemi può creare commit Git non necessari e un lungo ciclo di feedback. È possibile rilevare molti problemi prima che una configurazione venga applicata a un cluster utilizzando le funzioni di convalida di kpt come kubeval.

La tabella seguente elenca i vantaggi e gli svantaggi del controllo della presenza di problemi prima di applicare una configurazione:

Vantaggi	Svantaggi
La visualizzazione delle modifiche alla configurazione in una richiesta di modifica può aiutare a evitare che gli errori vengano inseriti in un repository. Riduce l'impatto dei problemi nelle configurazioni condivise.	Devi aggiungere strumenti e logica al processo di commit per contribuire a individuare i problemi.

Utilizzare le cartelle anziché i rami

Utilizza le cartelle per le varianti della configurazione anziché i rami. Con le cartelle, puoi utilizzare il comando tree per visualizzare le varianti. Ad esempio, con i rami, non è possibile capire se il delta tra un ramo di produzione e di fase sia un cambiamento imminente nella configurazione o una differenza permanente tra la fase e il ramo di produzione.

La seguente tabella elenca i vantaggi e gli svantaggi dell'utilizzo delle cartelle anziché dei rami:

Vantaggi

Svantaggi

Il rilevamento delle cartelle è più semplice dei rami. Fare differenze sulle cartelle è possibile con molti strumenti dell'interfaccia a riga di comando e GUI, mentre le differenze di ramo sono meno comuni al di fuori dei provider Git. Con le cartelle è più facile distinguere tra differenze permanenti e differenze non promosse. Puoi implementare le modifiche a più cluster e spazi dei nomi in una singola richiesta di modifica, mentre i rami richiedono diverse richieste di modifica a rami diversi.

Non è possibile promuovere modifiche alla configurazione tramite una richiesta di modifica agli stessi file.

Riduci al minimo l'utilizzo di ClusterSelectors

ClusterSelectors consente di applicare determinate parti di una configurazione a un sottoinsieme di cluster. Anziché configurare RootSync o RepoSync, puoi modificare la risorsa applicata o aggiungere etichette ai cluster. Tuttavia, nel tempo, con l'aumento del numero di ClusterSelectors, può diventare complicato comprendere lo stato finale del cluster.

Config Sync consente di sincronizzare più RootSyncs e RepoSyncs contemporaneamente, il che significa che puoi aggiungere la configurazione pertinente a un repository separato e quindi sincronizzarla con i cluster che preferisci.

La tabella seguente elenca i vantaggi e gli svantaggi del non utilizzare ClusterSelectors:

Vantaggi	Svantaggi
È più facile combinare la configurazione che si troverà sul cluster in una cartella, anziché prendere questa decisione sul cluster. Riduce il carico mentale della comprensione di cosa verrà effettivamente applicato al cluster.	Le etichette sono un modo leggero per aggiungere un tratto a un cluster ed è più complesso creare un nuovo "RepoSync".

Evita di gestire i job con Config Sync

Sebbene Config Sync possa applicare i job al posto tuo, questi non sono adatti al deployment di GitHub per i seguenti motivi:

• Campi immutabili: molti campi Job sono immutabili. Per modificare un campo immutabile, l'oggetto deve essere eliminato e ricreato. Tuttavia, Config Sync non elimina l'oggetto a meno che non lo rimuovi dall'origine.

• Esecuzione non intenzionale di job: se sincronizzi un job con Config Sync e poi il job viene eliminato dal cluster, Config Sync considera la deviazione dallo stato scelto e ricrea il job. Se specifichi un valore TTL (TTL), il job viene eliminato automaticamente e Config Sync lo ricrea automaticamente riavviando il job finché non lo elimini dalla fonte attendibile. Spesso questo non è ciò che intendevi, perché Config Sync esegue di nuovo il job.

• Problemi di riconciliazione: Config Sync di solito attende la riconciliazione degli oggetti dopo l'applicazione. Tuttavia, i job vengono considerati riconciliati all'avvio dell'esecuzione. Ciò significa che Config Sync non attende il completamento del job prima di continuare ad applicare altri oggetti. Tuttavia, se in seguito il job non riesce, la riconciliazione viene considerata un errore. In alcuni casi, questa operazione può bloccare la sincronizzazione di altre risorse e causare errori finché non lo correggi. In altri casi, la sincronizzazione potrebbe riuscire e solo la riconciliazione non va a buon fine.

Per questi motivi, sconsigliamo di sincronizzare i job con Config Sync.

Nella maggior parte dei casi, i job e altre attività situazionali devono essere gestiti da un servizio che ne gestisce la gestione del ciclo di vita. Puoi quindi gestire il servizio con Config Sync, anziché con i job stessi.

La tabella seguente elenca i vantaggi e gli svantaggi del mancato utilizzo di Config Sync per gestire i job:

Vantaggi

Svantaggi

Aumenta la compatibilità con GitOps. I job non funzionano bene con l'approccio dichiarativo con controllo della versione di GitOps a causa dei loro campi immutabili. Riduce le conseguenze indesiderate. Elimina il rischio che Config Sync ricrea automaticamente i job eliminati, causandone potenzialmente l'esecuzione inaspettata. Meno errori di sincronizzazione. Vengono evitati i potenziali conflitti di sincronizzazione e gli errori attivati da job non riusciti.

Gestione manuale dei job. Devi trovare un altro servizio per gestire i job.

Utilizza repository non strutturati

Config Sync supporta due strutture per organizzare un repository: non strutturato e gerarchico. Non strutturati è l'approccio consigliato, perché ti consente di organizzare un repository nel modo che preferisci. I repository gerarchici, invece, applicano una struttura specifica. Ad esempio, i CRD devono trovarsi in una directory specifica. Questo può causare problemi quando devi condividere le configurazioni. Ad esempio, se un team pubblica un pacchetto che contiene un CRD, un altro team che deve utilizzare quel pacchetto dovrebbe spostare la CRD in una directory cluster, aumentando il carico di lavoro al processo.

La tabella seguente elenca i vantaggi e gli svantaggi dell'utilizzo di repository non strutturati:

Vantaggi	Svantaggi
Puoi riutilizzare i pacchetti di configurazione condivisi anche se contengono CRD o altre definizioni a livello di cluster.	Senza un processo o una guida, la struttura dei repository può variare da un team all'altro, il che può rendere più difficile l'implementazione di strumenti a livello di parco risorse.

Per scoprire come convertire un repository gerarchico, vedi Convertire un repository gerarchico in un repository non strutturato.

Separa i repository di codice e di configurazione

Quando si fa lo scale up di un repository mono, richiede una build specifica per ogni cartella. Le autorizzazioni e i problemi per gli utenti che lavorano al codice e alla configurazione del cluster sono generalmente diversi. Mantenendo separati i repository di codice e configurazione, ogni repository può avere autorizzazioni e struttura proprie.

La seguente tabella elenca i vantaggi e gli svantaggi della separazione dei repository di codice e di configurazione:

Vantaggi	Svantaggi
Evita i commit "in loop". Ad esempio, il commit in un repository di codice potrebbe attivare una richiesta CI, che potrebbe produrre un'immagine, che poi richiede un commit del codice e così via. Puoi utilizzare autorizzazioni diverse per le persone che lavorano al codice dell'applicazione e alla configurazione del cluster.	Riduce il rilevamento per la configurazione dell'app perché non si trova nello stesso repository del codice dell'applicazione. La gestione di molti repository può richiedere molto tempo.

Usa repository separati per isolare le modifiche

Quando si fa lo scale up di un repository mono, sono necessarie autorizzazioni diverse su cartelle diverse. Per questo motivo, la separazione dei repository consente di definire i confini di sicurezza tra la configurazione della sicurezza, della piattaforma e dell'applicazione. Inoltre, è una buona idea separare i repository di produzione da quelli non di produzione.

La seguente tabella elenca i vantaggi e gli svantaggi dell'isolamento delle modifiche in repository separati:

Vantaggi

Svantaggi

In un'organizzazione con team dedicati a piattaforma, sicurezza e applicazioni, la cadenza delle modifiche e le autorizzazioni sono diverse. Le autorizzazioni rimangono a livello di repository. I file CODEOWNERS consentono alle organizzazioni di limitare l'autorizzazione di scrittura, pur consentendo l'autorizzazione di lettura. Config Sync supporta più sincronizzazioni per spazio dei nomi che possono ottenere un "effetto mix-in" da più repository.

La gestione di molti repository è un'attività a sé stante. Quindi, nel caso in cui crei un nuovo repository per cluster, il problema di configurazione/smontaggio del cluster ora deve includere la gestione dei repository.

Fissa le versioni del pacchetto

Sia che utilizzi Helm o Git, devi bloccare la versione del pacchetto di configurazione su qualcosa che non venga accidentalmente spostato in avanti senza un'implementazione esplicita.

La tabella seguente elenca i vantaggi e gli svantaggi del blocco delle versioni dei pacchetti:

Vantaggi	Svantaggi
L'aggiornamento della configurazione condivisa può avere un impatto maggiore del previsto se la versione del pacchetto non è bloccata.	Le implementazioni richiedono dei controlli quando i pacchetti condivisi vengono aggiornati.

Utilizzo di Workload Identity

Puoi abilitare Workload Identity sui cluster GKE, per consentire ai carichi di lavoro Kubernetes di accedere ai servizi Google in modo sicuro e gestibile.

La tabella seguente elenca i vantaggi e gli svantaggi derivanti dall'utilizzo di Workload Identity:

Vantaggi	Svantaggi
Riduce la complessità e i potenziali problemi relativi a secret e password.	I servizi esterni a Google Cloud (come GitHub e GitLab) non supportano Workload Identity.

Architettura di alto livello

A livello generale, probabilmente vorrai avere almeno quattro tipi di repository:

1. Un repository di pacchetti in cui è archiviata la configurazione condivisa. Potrebbe anche trattarsi di un grafico Helm archiviato in Artifact Registry.
2. Un repository della piattaforma in cui il team della piattaforma archivia la configurazione dell'intero parco risorse per cluster e spazi dei nomi.
3. Un repository di configurazione delle applicazioni.
4. Un repository di codice dell'applicazione.

Il seguente diagramma mostra il layout di questi repository:

Il seguente diagramma mostra il flusso della configurazione dal codice dell'applicazione a un repository di configurazione dell'applicazione. I team di sviluppo eseguono il push del codice per le applicazioni e le configurazioni delle applicazioni. Il codice sia per le app che per le configurazioni viene archiviato nella stessa posizione e i team delle applicazioni hanno il controllo su questi repository. I team dedicati alle app possono quindi eseguire il push del codice in una build.

Passaggi successivi

• Inizia a utilizzare Config Sync