Best practice per gli GitOps in Kubernetes con Config Sync

Questa pagina fornisce un punto di partenza per aiutarti a pianificare e creare architetture delle pipeline GitOps CI/CD per Kubernetes, che possono aiutarti a sfruttare al meglio Config Sync.

La stessa GitOps è una best practice universale per le organizzazioni che gestiscono la configurazione di Kubernetes su larga scala. Tuttavia, per quanto riguarda l'architettura di questa soluzione, hai molte opzioni. Comprendere le opzioni disponibili e i vantaggi e i compromessi di queste decisioni può aiutarti a evitare di riscrivere la tua 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 unica. L'obiettivo di questa pagina è aiutarti a prendere decisioni informate durante la configurazione dell'architettura GitOps.

Usa un repository di pacchetti privato 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 utilizzare servizi come i repository Artifact Registry o Git.

Il team dedicato alla piattaforma può implementare criteri in cui i team applicativi possano utilizzare i pacchetti solo dal repository centrale. In alternativa, potrebbero utilizzare il repository centrale come set di pacchetti controllati.

Puoi limitare le autorizzazioni di scrittura al repository solo a un numero limitato di ingegneri. Il resto dell'organizzazione può disporre dell'accesso in lettura. Ti consigliamo di implementare una procedura per la promozione dei pacchetti nel repository centrale e per la trasmissione degli aggiornamenti.

Nella tabella seguente sono elencati i vantaggi e gli svantaggi dell'utilizzo di un repository di pacchetti privato e centralizzato:

Vantaggi

Svantaggi

Importa pacchetti pubblici con una frequenza definita, per evitare di rompersi a causa della connettività o del tasso di abbandono. Rivedi e analizza i pacchetti condivisi. Consente di scoprire facilmente cosa è in uso e supportato. 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 standard interni come valori predefiniti, aggiunta di etichette e repository di immagini container.

Qualcuno deve mantenere il repository centrale. Aggiunge più processi per i team interessati.

Crea repository bagnati

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

Nella tabella seguente sono elencati i vantaggi e gli svantaggi della creazione di repository bagnati:

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

Sposta a sinistra per convalidare le configurazioni

Attendere che Config Sync inizi a eseguire la sincronizzazione per verificare eventuali problemi può creare commit Git non necessari e un lungo ciclo di feedback. Puoi riscontrare molti problemi prima che una configurazione venga applicata a un cluster utilizzando le funzioni di convalida kpt come kubeval.

Nella tabella seguente sono elencati i vantaggi e gli svantaggi del controllo dei problemi prima dell'applicazione di una configurazione:

Vantaggi	Svantaggi
L'inclusione di modifiche alla configurazione in una richiesta di modifica può aiutare a evitare che l'errore venga trasformato 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 invece dei rami

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

Nella tabella seguente sono elencati i vantaggi e gli svantaggi dell'utilizzo delle cartelle anziché dei rami:

Vantaggi

Svantaggi

Il rilevamento delle cartelle è più semplice dei rami. È possibile eseguire una differenza sulle cartelle con molti strumenti dell'interfaccia a riga di comando e della GUI, mentre la differenza del ramo è meno comune al di fuori dei provider Git. Distinguere tra differenze permanenti e differenze non promosse più facilmente con le cartelle. 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 della configurazione utilizzando 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. Invece di configurare RootSync o RepoSync, puoi modificare la risorsa applicata o aggiungere etichette ai cluster. Nel tempo, tuttavia, con l'aumento del numero di ClusterSelectors può essere complicato comprendere lo stato finale del cluster.

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

Nella tabella seguente sono elencati i vantaggi e gli svantaggi dell'utilizzo di ClusterSelectors:

Vantaggi	Svantaggi
È più facile assemblare la configurazione che sarà sul cluster in una cartella invece di prendere la decisione sul cluster. Riduce il carico mentale di comprensione di cosa verrà effettivamente applicato al cluster.	Le etichette sono un modo semplice per aggiungere una caratteristica a un cluster ed è più complesso creare un nuovo "RepoSync".

Utilizza repository non strutturati

Config Sync supporta due strutture per organizzare un repository: non strutturato e gerarchico. L'approccio non strutturato è l'approccio consigliato perché ti consente di organizzare un repository nel modo più pratico per te. I repository gerarchici, per confronto, applicano una struttura specifica. Ad esempio, i file 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 questo pacchetto dovrà spostare il CRD in una directory cluster, aggiungendo più overhead al processo.

La seguente tabella 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 delle linee guida, le strutture dei repository possono variare da un team all'altro, il che può rendere più difficile l'implementazione degli 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 viene fatto lo scale up di un monorepository, è necessaria una build specifica per ogni cartella. Le autorizzazioni e i problemi per le persone che lavorano al codice e lavorano alla configurazione del cluster sono generalmente diverse. Mantenendo separati i repository di codice e configurazione, ogni repository può avere le proprie autorizzazioni e la propria struttura.

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

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

Utilizzare repository separati per isolare le modifiche

Quando si esegue lo scale up di un repository singolo, sono necessarie autorizzazioni diverse per cartelle diverse. Per questo motivo, la separazione dei repository consente di limitare la sicurezza tra configurazione di piattaforma, sicurezza e applicazione. Inoltre, è una buona idea separare i repository di produzione da quelli non di produzione.

Nella tabella seguente sono elencati i vantaggi e gli svantaggi dell'isolamento delle modifiche nei repository separati:

Vantaggi

Svantaggi

In un'organizzazione con team di piattaforma, sicurezza e applicazioni, la frequenza delle modifiche e delle autorizzazioni è diversa. 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.

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

Fissa versioni dei pacchetti

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

Nella tabella seguente sono elencati i vantaggi e gli svantaggi delle versioni con pacchetto bloccato:

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

Utilizzo di Workload Identity

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

Nella tabella seguente sono elencati i vantaggi e gli svantaggi dell'utilizzo di Workload Identity:

Vantaggi	Svantaggi
Riduce la complessità e i potenziali problemi di 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 ti servono almeno quattro tipi di repository:

1. Un repository di pacchetti in cui è archiviata la configurazione condivisa. Potrebbe anche essere un grafico Helm memorizzato in Artifact Registry.
2. Un repository di piattaforme in cui il team della piattaforma archivia la configurazione a livello di 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 applicazioni e configurazioni delle applicazioni in un repository. Il codice per le app e le configurazioni è archiviato nella stessa posizione e i team applicativi hanno il controllo di questi repository. I team dell'app possono quindi eseguire il push del codice in una build.

Passaggi successivi

• Inizia a utilizzare Config Sync