Questa pagina fornisce un punto di partenza per aiutarti a pianificare e progettare le pipeline CI/CD GitOps per Kubernetes. GitOps, insieme a strumenti come Config Sync, offre vantaggi come stabilità del codice migliorata, migliore leggibilità e all'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, sono disponibili molte opzioni per progettare e organizzare il codice dell'applicazione e di configurazione. Se conosci alcune best practice di GitOps, puoi creare un'architettura stabile, ben organizzata e sicura.
Questa pagina è rivolta agli amministratori, agli architetti e agli operatori che vogliono a implementare GitOps nel proprio ambiente. Per scoprire di più sui ruoli comuni e su alcuni esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.
Organizzare i repository
Quando configuri l'architettura GitOps, separa i tuoi basati sui tipi di file di configurazione archiviati in ciascun repository. A livello generale, potresti prendere in considerazione almeno quattro tipi di repository:
- Un repository di pacchetti per gruppi di configurazioni correlate.
- Un repository di piattaforme per la configurazione a livello di parco risorse per cluster e spazi dei nomi.
- Un repository di configurazione delle applicazioni.
- 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 di app e configurazioni viene archiviato nello stesso luogo e i team di applicazioni hanno il controllo su questi repository.
- I team delle applicazioni eseguono il push del codice in una build.
Utilizza un repository di pacchetti privato e centralizzato
Usa un repository centrale per i pacchetti pubblici o interni, ad esempio i grafici Helm,
e aiutano i team a trovare i pacchi. Ad esempio, se il repository è strutturato in modo logico o contiene un readme, l'utilizzo di repository di pacchetti privati e centralizzati può aiutare i team a trovare rapidamente le informazioni. Puoi usare servizi come
Repository Artifact Registry o Git per organizzare il repository centrale.
Ad esempio, il team della piattaforma della tua organizzazione può implementare criteri in base ai quali i team di applicazioni possono utilizzare i pacchetti solo dal repository centrale.
Puoi limitare le autorizzazioni di scrittura al repository solo a un numero limitato di ingegneristici. Il resto dell'organizzazione può avere accesso in lettura. Ti consigliamo di implementare una procedura per promuovere i pacchetti nel repository centrale e di trasmettere gli aggiornamenti.
Sebbene la gestione di un repository centrale possa comportare un sovraccarico aggiuntivo, poiché qualcuno deve occuparsi della sua manutenzione, e aggiunge un'ulteriore procedura per i team di applicazioni, questo approccio presenta molti vantaggi:
- Un team centrale può scegliere di aggiungere pacchetti pubblici con una cadenza definita, il che consente di evitare interruzioni a causa di problemi di connettività o di abbandono a monte.
- Una combinazione di revisori automatici e umani può verificare la presenza di problemi nei pacchetti prima di renderli disponibili a livello generale.
- Il repository centrale consente ai team di scoprire cosa è in uso e supportato. Ad esempio, i team possono trovare il deployment Redis standard memorizzato nel repository centrale.
- Puoi automatizzare le modifiche ai pacchetti a monte per assicurarti che soddisfino gli standard interni, come i valori predefiniti, l'aggiunta di etichette e i repository di immagini dei contenitori.
Creare repository WET
WET è l'acronimo di "Write Everything Twice". È in contrasto con DRY, che per "Non ripetere". Questi approcci rappresentano due diversi tipi di di configurazione dei deployment:
- 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 diversi ambienti.
- WET (o a volte "completamente idratato"), in cui ogni file di configurazione è rappresentativo dello stato finale.
Sebbene i repository WET possano portare a alcuni file di configurazione ripetuti, hanno i seguenti vantaggi per un flusso di lavoro GitOps:
- Per i membri del team è più facile rivedere le modifiche.
- Non è richiesta alcuna elaborazione per visualizzare lo stato previsto di un file di configurazione.
Esegui test precedenti al momento della convalida delle configurazioni
In attesa dell'avvio della sincronizzazione di Config Sync per verificare la presenza di problemi, è possibile 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.
Anche se devi aggiungere strumenti e logica aggiuntivi alla procedura di commit, i test prima di applicare le configurazioni hanno i seguenti vantaggi:
- Mostrare 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.
Utilizza le cartelle anziché i rami
Utilizza le cartelle per le varianti dei file di configurazione anziché i rami. Con
cartelle, puoi usare il comando tree per visualizzare le varianti. Con i branch,
non puoi capire se il delta tra un branch di produzione e uno di sviluppo è una
modifica imminente nella configurazione o una differenza permanente tra ciò che dovrebbero essere gli ambienti
prod e dev.
Lo svantaggio principale di questo approccio è che l'utilizzo delle cartelle non consente di promuovere modifiche alla configurazione utilizzando una richiesta di modifica per gli stessi file. Tuttavia, l'utilizzo di cartelle invece di branch presenta i seguenti vantaggi:
- La scoperta delle cartelle è più facile rispetto ai rami.
- Eseguire un confronto tra cartelle è possibile con molti strumenti a riga di comando e GUI, mentre la differenza tra i branch è meno comune al di fuori dei fornitori di Git.
- La distinzione tra differenze permanenti e differenze non promosse più semplice con le cartelle.
- Puoi eseguire il deployment di modifiche a più cluster e spazi dei nomi con una sola modifica mentre le filiali richiedono varie richieste di modifica rami.
Riduci al minimo l'utilizzo di ClusterSelectors
ClusterSelectors ti consente di applicare determinate parti di una configurazione a un sottoinsieme di cluster. Invece di configurare un oggetto RootSync o RepoSync,
puoi modificare la risorsa applicata o aggiungere etichette ai cluster. Sebbene si tratti di un modo semplice per aggiungere tratti a un cluster, poiché il numero di ClusterSelectors aumenta nel tempo, può diventare complicato comprendere lo stato finale del cluster.
Poiché Config Sync consente di sincronizzare più oggetti RootSync e RepoSync
puoi aggiungere la configurazione pertinente a un repository separato
e poi sincronizzarlo con i cluster che vuoi. In questo modo è più facile comprendere lo stato finale del cluster e puoi assemblare le configurazioni per il cluster in una cartella anziché applicare queste decisioni di configurazione direttamente sul cluster.
Evitare di gestire 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.
Sebbene Config Sync possa applicare i job al posto tuo, i job non sono adatti a Deployment di GitOps per i seguenti motivi:
Campi immutabili: molti campi Job sono immutabili. Per modificare un modello 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 il job viene eliminato dal cluster, Config Sync considera deve derivare dallo stato scelto e ricrea il job. Se specifichi Durata (TTL) job, Config Sync elimina automaticamente il job e lo ricrea automaticamente e riavvia il job, finché non lo elimini dalla fonte attendibile.
Problemi di riconciliazione: in genere, Config Sync attende che gli oggetti vengano riconciliati dopo l'applicazione. Tuttavia, i job vengono considerati riconciliati quando hanno iniziato a essere eseguiti. Ciò significa che Config Sync non attende il job da completare prima di continuare ad applicare altri oggetti. Tuttavia, se il job non va a buon fine in un secondo momento, viene considerata una mancata riconciliazione. In alcuni casi, questo 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 potrebbe non andare a buon fine.
Per questi motivi, sconsigliamo di sincronizzare i job con Config Sync.
Utilizza repository non strutturati
Config Sync supporta due strutture per organizzare un repository: non strutturati e gerarchici.
L'approccio non strutturato è consigliato perché consente di organizzare un repository nel modo più pratico per te.
I repository gerarchici, invece, applicano una struttura specifica come le definizioni di risorse personalizzate (CRD) in una directory cluster.
Questo può causare problemi quando devi condividere le configurazioni. Ad esempio, se un team
pubblica un pacchetto contenente un CRD, un altro team che deve utilizzarlo
deve spostare il CRD in una directory cluster, aggiungendo
il carico di lavoro per il processo.
Utilizzando un repository non strutturato, diventa molto condividere e riutilizzare i pacchetti di configurazione. Tuttavia, senza una procedura definita o linee guida per l'organizzazione dei repository, le strutture dei repository possono variare da un team all'altro e questo può rendere più implementare strumenti a livello di parco risorse.
Per scoprire come convertire un repository gerarchico, consulta Convertire un repository gerarchico in un repository non strutturato.
Repository di codice e configurazione separati
Quando esegui l'upgrade di un monorepo, è necessaria una build specifica per ogni cartella. Le autorizzazioni e le preoccupazioni per le persone che lavorano al codice e alla configurazione del cluster sono in genere diverse.
La separazione dei repository di codice e configurazione presenta i seguenti vantaggi:
- Evita il "loop" commit. Ad esempio, l'esecuzione di commit in un repository di codice potrebbe attivare una richiesta di CI, che potrebbe produrre un'immagine, che a sua volta richiede un commit del codice.
- Il numero di commit richiesti può diventare un onere per i membri del team che contribuiscono.
- Puoi usare autorizzazioni diverse per chi lavora al codice dell'applicazione la configurazione del cluster.
La separazione dei repository di codice e di configurazione presenta i seguenti svantaggi:
- Riduce il rilevamento 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 si fa lo scale up di un mono-repository, sono necessarie autorizzazioni diverse cartelle diverse. Per questo motivo, separare i repository consente confini tra sicurezza, piattaforma e configurazione dell'applicazione. È inoltre consigliabile separare i repository di produzione e non di produzione.
Sebbene la gestione di molti repository possa essere un'attività impegnativa, isolare diversi tipi di configurazione in repository diversi presenta i seguenti vantaggi:
- In un'organizzazione con team dedicati a piattaforme, sicurezza e applicazioni, la cadenza delle modifiche e le autorizzazioni sono diverse.
- Le autorizzazioni rimangono a livello di repository. I file
CODEOWNERSconsentono alle organizzazioni di limitare l'autorizzazione di scrittura, consentendo al contempo l'autorizzazione di lettura. - Config Sync supporta più sincronizzazioni per spazio dei nomi, il che può raggiungere un effetto simile a quello dei 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 accidentalmente in avanti senza un rollout esplicito.
Anche se in questo modo vengono aggiunti ulteriori controlli alle implementazioni quando viene aggiornata, riduce il rischio che gli aggiornamenti condivisi un impatto maggiore del previsto.
Utilizzare la federazione delle identità per i carichi di lavoro per GKE
Puoi abilitare la Federazione delle identità per i carichi di lavoro per GKE su GKE che consente ai carichi di lavoro Kubernetes di accedere ai servizi Google in modo sicuro e gestibile.
Sebbene alcuni servizi non Google Cloud, come GitHub e GitLab, non supportino la federazione delle identità per i carichi di lavoro per GKE, ti consigliamo di utilizzare questa funzionalità se possibile per una maggiore sicurezza e una minore complessità nella gestione di segreti e password.