Questa pagina fornisce un punto di partenza per aiutarti a pianificare e progettare pipeline CI/CD GitOps per Kubernetes. GitOps, insieme a strumenti come Config Sync, offre vantaggi come una maggiore stabilità del codice, una migliore leggibilità e l'automazione.
GitOps è un approccio in rapida crescita per la gestione della configurazione di Kubernetes su larga scala. A seconda dei requisiti della pipeline CI/CD, esistono molte opzioni per l'architettura e l'organizzazione del codice di configurazione e dell'applicazione. Se impari alcune best practice di GitOps, puoi creare un'architettura stabile, ben organizzata e sicura.
Questa pagina è rivolta ad amministratori, architetti e operatori che vogliono implementare GitOps nel proprio ambiente. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti GKE. Google Cloud
Organizzare i repository
Quando configuri l'architettura GitOps, separa i repository in base ai tipi di file di configurazione archiviati in ciascun repository. A livello generale, puoi prendere in considerazione almeno quattro tipi di repository:
- Un repository di pacchetti per gruppi di configurazioni correlate.
- Un repository della piattaforma per la configurazione a livello di parco risorse per cluster e spazi dei nomi.
- Un repository di configurazione dell'applicazione.
- Un repository di codice dell'applicazione.
Il seguente diagramma mostra il layout di questi repository:
Nella Figura 2:
- I team di sviluppo eseguono il push del codice per le applicazioni e le configurazioni delle applicazioni in un repository.
- Il codice per le app e le configurazioni è archiviato nello stesso posto e i team di sviluppo delle applicazioni hanno il controllo di questi repository.
- I team dell'applicazione eseguono il push del codice in una build.
Utilizzare un repository di pacchetti privato centralizzato
Utilizza un repository centrale per i pacchetti pubblici o interni, ad esempio i grafici Helm,per
aiutare i team a trovare i pacchetti. Ad esempio, se il repository è
strutturato in modo logico o contiene un readme, l'utilizzo di repository di pacchetti privati centralizzati
può aiutare i team a trovare rapidamente le informazioni. Puoi utilizzare servizi come
Artifact Registry o repository Git per organizzare il repository centrale.
Ad esempio, il team della piattaforma della tua organizzazione può implementare policy in cui i team delle applicazioni possono utilizzare i pacchetti solo dal repository centrale.
Puoi limitare le autorizzazioni di scrittura al repository solo a un numero ridotto di ingegneri. Il resto dell'organizzazione può avere accesso in lettura. Ti consigliamo di implementare una procedura per promuovere i pacchetti nel repository centrale e trasmettere gli aggiornamenti.
Sebbene la gestione di un repository centrale possa aggiungere un overhead aggiuntivo, poiché qualcuno deve gestirlo e aggiunge un processo aggiuntivo per i team di sviluppo di applicazioni, questo approccio presenta molti vantaggi:
- Un team centrale può scegliere di aggiungere pacchetti pubblici a una cadenza definita, il che aiuta a evitare interruzioni dovute a problemi di connettività o churn upstream.
- Una combinazione di revisori automatici e umani può controllare i pacchetti per rilevare eventuali problemi prima di renderli ampiamente disponibili.
- Il repository centrale consente ai team di scoprire cosa viene utilizzato e supportato. Ad esempio, i team possono trovare l'implementazione standard di Redis memorizzata nel repository centrale.
- Puoi automatizzare le modifiche ai pacchetti upstream per assicurarti che soddisfino gli standard interni, ad esempio valori predefiniti, aggiunta di etichette e repository di immagini container.
Creare repository WET
WET è l'acronimo di "Write Everything Twice" (Scrivi tutto due volte). È in contrasto con DRY, che sta per "Don't Repeat Yourself" (non ripeterti). Questi approcci rappresentano due tipi diversi di file di configurazione:
- Configurazioni DRY, in cui un singolo file di configurazione viene sottoposto a un'azione di trasformazione per compilare i campi con valori diversi per ambienti diversi. Ad esempio, potresti avere una configurazione del cluster condivisa che viene compilata con una regione diversa o impostazioni di sicurezza diverse per ambienti diversi.
- Configurazioni WET (o a volte "completamente idratate"), in cui ogni file di configurazione rappresenta lo stato finale.
Sebbene i repository WET possano portare ad alcuni file di configurazione ripetuti, presentano i seguenti vantaggi per un workflow GitOps:
- È più facile per i membri del team rivedere le modifiche.
- Non è necessaria alcuna elaborazione per visualizzare lo stato previsto di un file di configurazione.
Esegui i test in anticipo durante la convalida delle configurazioni
Attendere l'inizio della sincronizzazione di Config Sync per verificare la presenza di problemi può creare commit Git non necessari e un lungo ciclo di feedback. Molti problemi possono essere rilevati
prima che una configurazione venga applicata a un cluster utilizzando le funzioni di convalida kpt.
Sebbene tu debba aggiungere strumenti e logica aggiuntivi al processo di commit, il test prima di applicare le configurazioni presenta i seguenti vantaggi:
- Mettere in evidenza le modifiche alla configurazione in una richiesta di modifica può contribuire a evitare che gli errori vengano inseriti in un repository.
- Riduce l'impatto dei problemi nelle configurazioni condivise.
Utilizzare le cartelle anziché i rami
Utilizza le cartelle per le varianti dei file di configurazione anziché i rami. Con
le cartelle, puoi utilizzare il comando tree per visualizzare le varianti. Con i rami, non puoi sapere se la differenza tra un ramo di produzione e uno di sviluppo è una modifica alla configurazione imminente o una differenza permanente tra l'aspetto degli ambienti prod e dev.
Il principale svantaggio di questo approccio è che l'utilizzo delle cartelle non consente di promuovere le modifiche alla configurazione utilizzando una richiesta di modifica agli stessi file. Tuttavia, l'utilizzo delle cartelle anziché dei rami presenta i seguenti vantaggi:
- L'individuazione delle cartelle è più semplice rispetto a quella dei rami.
- Eseguire un diff sulle cartelle è possibile con molti strumenti CLI e GUI, mentre il diff dei rami è meno comune al di fuori dei provider Git.
- Distinguere tra differenze permanenti e non promosse è più semplice con le cartelle.
- Puoi implementare le modifiche in più cluster e spazi dei nomi in un'unica richiesta di modifica, mentre i rami richiedono diverse richieste di modifica a rami diversi.
Riduci al minimo l'utilizzo di ClusterSelectors
ClusterSelectors ti consentono di applicare determinate parti di una configurazione a un sottoinsieme di cluster. Invece di configurare un oggetto RootSync o RepoSync,
puoi modificare la risorsa che viene applicata o aggiungere etichette
ai cluster. Sebbene questo sia un modo semplice per aggiungere caratteristiche a un cluster,
man mano che il numero di ClusterSelectors aumenta nel tempo, può diventare complicato
comprendere lo stato finale del cluster.
Poiché Config Sync ti consente di sincronizzare più oggetti RootSync e RepoSync contemporaneamente, puoi aggiungere la configurazione pertinente a un repository separato e poi sincronizzarla con i cluster che preferisci. In questo modo è più facile comprendere lo stato finale del cluster e puoi assemblare le configurazioni per il cluster in una cartella anziché applicare direttamente le decisioni di configurazione sul cluster.
Evita di gestire i job con Config Sync
Nella maggior parte dei casi, i lavori 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.
Sebbene Config Sync possa applicare i job per te, i job non sono adatti per le implementazioni GitOps per i seguenti motivi:
Campi immutabili: molti campi di lavoro 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 involontaria di Job: se sincronizzi un Job con Config Sync e poi questo Job viene eliminato dal cluster, Config Sync considera questa deviazione dallo stato scelto e ricrea il Job. Se specifichi un TTL durata (TTL) job, Config Sync elimina automaticamente il job e lo ricrea e riavvia automaticamente, finché non lo elimini dalla fonte attendibile.
Problemi di riconciliazione: Config Sync in genere attende la riconciliazione degli oggetti dopo l'applicazione. Tuttavia, i job vengono considerati riconciliati quando hanno iniziato l'esecuzione. Ciò significa che Config Sync non attende il completamento del job prima di continuare ad applicare altri oggetti. Tuttavia, se il job non riesce in un secondo momento, viene considerato un mancato riconciliazione. In alcuni casi, ciò può impedire la sincronizzazione di altre risorse e causare errori fino a quando non risolvi il problema. In altri casi, la sincronizzazione potrebbe riuscire e solo la riconciliazione non va a buon fine.
Per questi motivi, non è consigliabile sincronizzare i job con Config Sync.
Utilizzare repository non strutturati
Config Sync supporta due strutture per organizzare un repository: non strutturata e gerarchica.
L'approccio non strutturato è consigliato perché
ti consente di organizzare un repository nel modo più conveniente per te.
I repository gerarchici, al contrario, applicano una struttura specifica come le definizioni di risorse personalizzate (CRD) in una directory cluster.
Ciò 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 deve spostare il CRD in una directory cluster, aggiungendo ulteriori
overhead al processo.
L'utilizzo di un repository non strutturato semplifica notevolmente la condivisione e il riutilizzo dei pacchetti di configurazione. Tuttavia, senza un processo o linee guida definiti per l'organizzazione dei repository, le strutture dei repository possono variare da un team all'altro, il che può rendere più difficile l'implementazione di strumenti a livello di flotta.
Per scoprire come convertire un repository gerarchico, consulta Convertire un repository gerarchico in un repository non strutturato.
Repository di codice e configurazione separati
Quando viene eseguito lo scale up di un monorepo, è necessaria una build specifica per ogni cartella. Le autorizzazioni e i problemi per le persone che lavorano sul codice e sulla configurazione del cluster sono generalmente diversi.
La separazione dei repository di codice e configurazione presenta i seguenti vantaggi:
- 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 a sua volta richiede un commit del codice.
- Il numero di commit richiesti può diventare un peso per i membri del team che contribuiscono.
- Puoi utilizzare autorizzazioni diverse per le persone che lavorano al codice dell'applicazione e alla configurazione del cluster.
La separazione dei repository di codice e configurazione presenta i seguenti svantaggi:
- Riduce l'individuazione della configurazione dell'applicazione perché non si trova nello stesso repository del codice dell'applicazione.
- La gestione di molti repository può richiedere molto tempo.
Utilizza repository separati per isolare le modifiche
Quando aumenti le dimensioni di un monorepo, sono necessarie autorizzazioni diverse per cartelle diverse. Per questo motivo, la separazione dei repository consente di creare limiti di sicurezza tra la configurazione di sicurezza, della piattaforma e delle applicazioni. È anche consigliabile separare i repository di produzione e non di produzione.
Sebbene la gestione di molti repository possa essere un'attività impegnativa, l'isolamento di diversi tipi di configurazione in repository diversi presenta i seguenti vantaggi:
- In un'organizzazione con team di piattaforma, sicurezza e applicazioni, la cadenza delle modifiche e delle autorizzazioni è diversa.
- Le autorizzazioni rimangono a livello di repository. I file
CODEOWNERSconsentono alle organizzazioni di limitare l'autorizzazione di scrittura, consentendo comunque l'autorizzazione di lettura. - Config Sync supporta più sincronizzazioni per spazio dei nomi, il che può ottenere un effetto simile all'approvvigionamento di file da più repository.
Bloccare le versioni dei pacchetti
Indipendentemente dall'utilizzo di Helm o Git, devi bloccare la versione del pacchetto di configurazione su un valore che non venga spostato inavvertitamente in avanti senza un rollout esplicito.
Sebbene ciò aggiunga controlli aggiuntivi ai tuoi rollout quando viene aggiornata una configurazione condivisa, riduce il rischio che gli aggiornamenti condivisi abbiano un impatto maggiore del previsto.
Utilizzare la federazione delle identità per i carichi di lavoro per GKE
Puoi abilitare Workload Identity Federation for GKE sui cluster GKE, il che consente ai carichi di lavoro Kubernetes di accedere ai servizi Google in modo sicuro e gestibile.
Sebbene alcuni servizi nonGoogle Cloud , come GitHub e GitLab, non supportino Workload Identity Federation for GKE, ti consigliamo di utilizzare Workload Identity Federation for GKE ogni volta che è possibile, a causa della maggiore sicurezza e della riduzione della complessità della gestione di secret e password.