Best practice per GitOps per Kubernetes con Config Sync

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

GitOps è una best practice universale che gestiscono la configurazione Kubernetes su larga scala. Ma quando si tratta di a progettare quella soluzione, ci sono molte scelte. Comprendere le opzioni a tua disposizione e i vantaggi e i compromessi di queste decisioni possono aiutarti a evitare di riscrivere le parole la tua architettura in futuro.

Non è necessario seguire tutte le best practice elencate in questa pagina. Quale migliore le pratiche che scegli di adottare dipendono dalla tua specifica situazione. L'obiettivo Questa pagina ti aiuterà a prendere decisioni consapevoli durante la configurazione dell'architettura.

Utilizza un repository di pacchetti privato e centralizzato

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

Il team della piattaforma può implementare criteri in cui i team dedicati alle applicazioni possono solo dal repository centrale. In alternativa, potrebbe utilizzare repository centrale sotto forma di insieme di pacchetti verificati.

Puoi limitare le autorizzazioni di scrittura al repository solo a un numero limitato di ingegneristici. Il resto dell'organizzazione può avere accesso in lettura. I nostri suggerimenti implementare un processo per promuovere i pacchetti nel repository centrale e trasmettendolo.

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

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 per il cluster o lo spazio dei nomi. Le modifiche al repository bagnato o completamente idratato essere facili da rivedere usando un diff. È buona norma apportare modifiche solo il repository bagnato tramite un processo di revisione (ad esempio, in GitHub, 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

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, come kubeval.

La tabella seguente elenca i vantaggi e gli svantaggi del controllo di eventuali problemi prima del giorno applicazione di 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 vedere le varianti. Ad esempio, con i rami, non riesci a capire se il delta tra un ramo di produzione e di fase è una modifica imminente o una differenza permanente tra la fase e la produzione Mi piace.

Nella tabella seguente sono elencati i vantaggi e gli svantaggi dell'utilizzo delle cartelle anziché 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 ti consente di applicare determinate parti di una configurazione a un sottoinsieme di cluster. Invece di configurare RootSync o RepoSync, puoi modificare la risorsa applicata o aggiungere etichette ai cluster. Tuttavia, nel tempo, man mano che aumenta il numero di ClusterSelectors, può diventare complicato comprendere lo stato finale del cluster.

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

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, 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 elimina l'oggetto solo se 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 un job durata (TTL), il job viene eliminato automaticamente e Config Sync automaticamente lo ricrea, riavviando il job, finché non lo elimini dall'origine la verità. Spesso questo non è ciò che intendevi, perché Config Sync esegue nuovamente il job.

• Problemi di riconciliazione: Config Sync di solito attende che gli oggetti vengano riconciliazione dopo l'applicazione. Tuttavia, i job vengono considerati riconciliati quando il deployment dei modelli. Ciò significa che Config Sync non attende il job da completare prima di continuare ad applicare altri oggetti. Tuttavia, se in seguito il job non va a buon fine e questo è considerato un errore di riconciliazione. In alcuni casi, questo può bloccare la sincronizzazione di altre risorse e causare errori finché non lo correggi. In altri casi, la sincronizzazione può riuscire e la riconciliazione non riesce.

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é i job stessi.

La tabella seguente elenca i vantaggi e gli svantaggi del non utilizzare 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 strutturati e gerarchici. Non strutturati è l'approccio consigliato perché ti consente di organizzare un repository nel modo che preferisci. I repository gerarchici, invece, applicano una struttura specifica. Per Ad esempio, i CRD devono trovarsi in una directory specifica. Ciò può causare problemi quando devi condividere le configurazioni. Ad esempio, se un team pubblica un pacchetto contiene un CRD, un altro team che deve utilizzare quel pacchetto dovrà il CRD in una directory cluster, aggiungendo più overhead al processo.

La tabella seguente elenca i vantaggi e gli svantaggi legati all'utilizzo di strumenti repository:

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 Converti 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. Autorizzazioni e preoccupazioni per le persone che lavorano al codice sono generalmente diverse. Mantenendo il codice e la configurazione separati, ogni repository può avere autorizzazioni proprie alla struttura del centro di costo.

Nella tabella seguente sono elencati i vantaggi e gli svantaggi della separazione di codice e di configurazione dei repository:

Vantaggi	Svantaggi
Evita il "loop" commit. 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 della 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 mono-repository, sono necessarie autorizzazioni diverse cartelle diverse. Per questo motivo, separare i repository consente confini tra sicurezza, piattaforma e configurazione dell'applicazione. È anche un è buona norma separare i repository di produzione da quelli non di produzione.

La tabella seguente elenca i vantaggi e gli svantaggi dell'isolamento delle modifiche a 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" 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 viene accidentalmente spostato in avanti senza un'esplicita implementazione.

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 su GKE che consente 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. Questo potrebbe anche essere un grafico Helm archiviato in Artifact Registry.
2. Un repository della piattaforma in cui il team della piattaforma archivia la configurazione a livello di parco risorse per i cluster e gli 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 di configurazione delle applicazioni. I team di sviluppo eseguono il push del codice per e configurazioni delle applicazioni in un repository. Il codice per entrambi di app e configurazioni sono archiviate nella stessa posizione e i team delle applicazioni 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