Best practice per Kubernetes GitOps con Config Sync

Questa pagina fornisce un punto di partenza per aiutarti a pianificare e progettare 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 di Kubernetes. Ma quando si tratta di progettare questa soluzione, hai molte scelte. Comprendere le opzioni a tua disposizione e i vantaggi e i compromessi di queste decisioni può aiutarti a evitare di riscrivere la tua architettura in futuro.

Non è necessario utilizzare 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 informate 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 più facilmente i pacchetti. Puoi usare servizi come i repository Artifact Registry o Git.

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

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

La seguente tabella 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, per evitare interruzioni dovute alla connettività o al tasso di abbandono upstream. Rivedi ed esegui la scansione dei pacchetti condivisi. Consente di scoprire facilmente cosa viene usato 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 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 di candidatura.

Crea repository in modalità umida

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

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

Vantaggi	Svantaggi
È più facile esaminare le differenze. Non è necessaria alcuna elaborazione per verificare lo stato previsto della configurazione.	Una configurazione completamente idratante può causare la ripetizione di YAML.

Shift a sinistra per convalidare le configurazioni

Attendere che Config Sync avvii la sincronizzazione per verificare la presenza di problemi può creare commit Git non necessari e un lungo ciclo di feedback. Puoi rilevare molti problemi prima di applicare una configurazione a un cluster utilizzando le funzioni di convalida di kpt come kubeval.

Nella tabella seguente sono elencati i vantaggi e gli svantaggi del controllo della presenza di problemi prima di applicare una configurazione:

Vantaggi	Svantaggi
Mostrare le modifiche alla configurazione in una richiesta di modifica può aiutare a evitare che gli errori diventino disponibili in un repository. Riduce l'impatto dei problemi nelle configurazioni condivise.	Devi aggiungere strumenti e logica al processo di commit per contribuire a rilevare i problemi.

Utilizza cartelle anziché 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 capire se il delta tra un ramo di produzione e uno di fase sia una modifica imminente nella configurazione o una differenza permanente tra la fase e la fase 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 rispetto ai rami. Fare una differenza sulle cartelle è possibile con molti strumenti dell'interfaccia a riga di comando e GUI, mentre le differenze dei rami 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 un'unica 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. Nel corso del tempo, tuttavia, con l'aumento del numero di ClusterSelectors, può essere complicato comprendere lo stato finale del cluster.

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

Nella tabella seguente sono elencati i vantaggi e gli svantaggi del non utilizzo di ClusterSelectors:

Vantaggi	Svantaggi
Semplifica l'assemblaggio della configurazione che sarà presente nel cluster in una cartella, anziché dover prendere questa decisione sul cluster. Riduce il carico mentale di comprendere cosa verrà effettivamente applicato al cluster.	Le etichette sono un modo leggero per aggiungere un trait a un cluster ed è più complesso creare un nuovo "RepoSync".

Evita di gestire i job con Config Sync

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

• Campi immutabili: molti campi Job sono immutabili. Per modificare un campo immutabile, devi eliminare e ricreare l'oggetto. 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 quest'ultimo viene eliminato dal cluster, Config Sync considera la deviazione dallo stato selezionato e ricrea il job. Se specifichi una durata (TTL) del job, il job viene eliminato automaticamente e Config Sync lo ricrea automaticamente, riavviando il job, finché non lo elimini dalla fonte attendibile. Spesso questo non è quello previsto, perché Config Sync esegue di nuovo il job.

• Problemi di riconciliazione: Config Sync attende in genere la riconciliazione degli oggetti dopo l'applicazione. Tuttavia, i job sono considerati riconciliati quando sono iniziati in esecuzione. Ciò significa che Config Sync non attende il completamento del job prima di continuare ad applicare altri oggetti. Tuttavia, se in un secondo momento il job non riesce, la riconciliazione viene considerata non riuscita. In alcuni casi, questo può bloccare la sincronizzazione di altre risorse e causare errori fino a quando non lo correggi. In altri casi, la sincronizzazione potrebbe avere esito positivo 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à situali dovrebbero 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 seguente tabella elenca i vantaggi e gli svantaggi del non utilizzare Config Sync per gestire i job:

Vantaggi

Svantaggi

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

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

Usa repository non strutturati

Config Sync supporta due strutture per l'organizzazione di un repository: non strutturato e gerarchico. L'approccio non strutturato è quello consigliato perché ti consente di organizzare un repository nel modo che preferisci. I repository gerarchici, al confronto, 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 dovrà spostare il CRD in una directory cluster, aggiungendo ulteriore 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 al loro interno contengono CRD o altre definizioni a livello di cluster.	Senza un processo o linee guida, le strutture dei repository possono variare da un team all'altro, il che può rendere più difficile l'implementazione di strumenti a livello di parco risorse.

Per informazioni su come convertire un repository gerarchico, consulta Convertire un repository gerarchico in un repository non strutturato.

Separa i repository di codice e configurazione

Quando fai lo scale up di un repository mono, richiede 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. Mantenendo separati i repository di codice e di configurazione, ogni repository può avere le proprie autorizzazioni e la propria struttura.

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

Vantaggi	Svantaggi
Evita i commit "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 di codice e così via. Puoi utilizzare autorizzazioni diverse per chi lavora sul codice dell'applicazione e sulla 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 fai lo scale up di un repository mono, sono necessarie autorizzazioni diverse per cartelle diverse. Per questo motivo, la separazione dei repository consente di definire limiti di sicurezza tra sicurezza, piattaforma e configurazione delle applicazioni. È 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 in repository separati:

Vantaggi

Svantaggi

In un'organizzazione con team dedicati alla piattaforma, alla sicurezza e alle applicazioni, la cadenza 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, consentendo comunque 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/rimozione del cluster ora deve includere la gestione dei repository.

Blocca le versioni del pacchetto

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

Nella tabella seguente sono elencati i vantaggi e gli svantaggi legati alla possibilità di bloccare le 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.

Nella tabella seguente sono elencati i vantaggi e gli svantaggi legati all'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 ti servono almeno quattro tipi di repository:

1. Un repository di pacchetti in cui è archiviata la configurazione condivisa. Potrebbe anche essere un grafico Helm archiviato in Artifact Registry.
2. Un repository della piattaforma in cui il team dedicato alla piattaforma archivia le configurazioni a livello di parco risorse per cluster e spazi dei nomi.
3. Un repository di configurazione dell'applicazione.
4. Un repository di codice dell'applicazione.

Il seguente diagramma mostra il layout di questi repository:

Il seguente diagramma mostra il flusso di 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 in un repository. Il codice sia per le app sia per le configurazioni è archiviato nella stessa posizione e i team delle applicazioni hanno il controllo di questi repository. I team delle app possono quindi eseguire il push del codice in una build.

Passaggi successivi

• Inizia a utilizzare Config Sync