Discipline CI/CD e GitOps con Kubernetes abilitato per Azure Arc

  • Articolo

Come costrutto nativo del cloud, Kubernetes richiede un approccio nativo del cloud per la distribuzione e le operazioni. Con GitOps si dichiara lo stato desiderato delle distribuzioni basate sull'applicazione nei file archiviati nei repository Git. Le applicazioni dispongono di oggetti Kubernetes che devono essere eseguiti, che possono includere distribuzioni, scaler horizontal-pod-autoscaler, servizi e configurazione Mappe. Gli operatori Kubernetes vengono eseguiti nei cluster e riconciliano continuamente lo stato di ogni cluster con lo stato desiderato dichiarato nel repository Git. Questi operatori estraggono i file dai repository Git e applicano lo stato desiderato ai cluster. Gli operatori assicurano inoltre continuamente che il cluster rimanga nello stato desiderato.

L'implementazione di GitOps consente di:

  • Migliorare la visibilità complessiva dello stato e della configurazione del cluster Kubernetes.
  • Avere una semplice cronologia di controllo e versione delle modifiche apportate al cluster tramite la cronologia delle modifiche Git che mostra chi ha apportato modifiche, quando sono state apportate tali modifiche e perché.
  • Correggere automaticamente la deriva che può verificarsi nel cluster.
  • Eseguire il rollback della configurazione di Kubernetes a una versione precedente tramite i comandi di ripristino git o rollback git. La ri-creazione della distribuzione del cluster per scenari di ripristino di emergenza diventa anche un processo rapido e semplice perché la configurazione del cluster desiderata di Kubernetes è archiviata in Git.
  • Migliorare la sicurezza riducendo il numero di account di servizio necessari per avere le autorizzazioni di distribuzione per il cluster.
  • Implementare una pipeline CI/CD per la distribuzione di applicazioni nel cluster.

GitOps in Kubernetes abilitato per Azure Arc usa un'estensione che implementa Flux, un set di strumenti open source diffuso. Flux è un operatore che automatizza le distribuzioni di configurazione di GitOps nel cluster. Flux supporta origini di file (repository Git, repository Helm, bucket) e tipi di modello (YAML, Helm, e Kustomize) comuni. Flux supporta anche la gestione delle dipendenze multi-tenancy e distribuzione tra le altre funzionalità.

Architettura

I diagrammi seguenti illustrano un'architettura di riferimento concettuale che evidenzia il provisioning dell'installazione dell'estensione del cluster Flux in un cluster, il processo di configurazione GitOps per un cluster Kubernetes abilitato per Azure Arc e GitOps Flow.

Processo di provisioning dell'estensione cluster Flux v2:

Diagram that shows Flux extension installation.

Processo di configurazione di GitOps:

Diagram that shows how to configure GitOps.

GitOps Flow che mostra un aggiornamento dell'applicazione:

Diagram that shows a typical GitOps workflow.

Considerazioni relative alla progettazione

Esaminare le considerazioni di progettazione seguenti quando si prevede di implementare GitOps per Kubernetes abilitato per Azure Arc.

Impostazione

Prendere in considerazione i diversi livelli di configurazione nel cluster Kubernetes e le responsabilità coinvolte nel relativo provisioning.

Livelli di configurazione

  • Configurazione dell'applicazione necessaria per distribuire un'applicazione e i relativi oggetti Kubernetes nel cluster, ad esempio le risorse Deployment, Service, HPA e ConfigMap. Le configurazioni dell'applicazione vengono in genere applicate a una configurazione GitOps a livello di spazio dei nomi, richiedendo la configurazione dei componenti dell'applicazione solo all'interno di un singolo spazio dei nomi.
  • Configurazione a livello di cluster per la creazione di oggetti Kubernetes, ad esempio Namespaces, ServiceAccounts, Roles e RoleBindings e altri criteri a livello di cluster.
  • Componenti a livello di cluster, ad esempio controller di ingresso, stack di monitoraggio e sicurezza e vari agenti che operano nel cluster.

Responsabilità

  • Gli sviluppatori di applicazioni sono responsabili del push del codice sorgente, dell'attivazione delle compilazioni e della creazione di immagini del contenitore.
  • Gli operatori dell'applicazione sono responsabili della gestione dei repository dell'applicazione, delle configurazioni, delle variabili di ambiente, dei grafici helm specifici dell'app, delle kustomizzazioni e così via.
  • Gli operatori del cluster sono responsabili della configurazione della baseline del cluster. In genere si occupano della configurazione di componenti e criteri a livello di cluster. Gestiscono una o più directory di repository Git contenenti strumenti comuni dell'infrastruttura, ad esempio Namespaces, ServiceAccounts, RoleBindings, CRD, criteri a livello di cluster, componenti in ingresso e così via.

Struttura del repository

Prendere in considerazione i compromessi quando si sceglie una struttura del repository Git. La struttura scelta definirà lo stato del cluster Kubernetes, che include applicazioni e componenti a livello di cluster. A seconda delle responsabilità e degli utenti tipo identificati, è importante considerare qualsiasi collaborazione necessaria o l'indipendenza del team desiderata necessaria per diverse opzioni della struttura del repository.

È possibile usare qualsiasi strategia di diramazione desiderata per i repository di codice, perché viene usata solo dal processo di integrazione continua .

Per i repository di configurazione GitOps, prendere in considerazione le strategie seguenti in base alle esigenze aziendali, alle dimensioni e agli strumenti dell'organizzazione:

  • Repository singolo (ramo per ambiente):
    • Consente la massima flessibilità per controllare i criteri e le autorizzazioni Git per ogni ramo che rappresenta un ambiente.
    • Lo svantaggio è che non esiste alcuna condivisione della configurazione comune tra gli ambienti, perché gli strumenti come Kustomize non funzionano con i rami Git.
  • Repository singolo (directory per ambiente):
    • È possibile implementare questo approccio usando strumenti come Kustomize, che consente di definire una configurazione di base per gli oggetti Kubernetes e un set di artefatti (ad esempio patch) per l'ambiente che esegue l'override delle configurazioni nella base.
    • Questo approccio può ridurre i file YAML duplicati per ogni ambiente, ma riduce anche la separazione della configurazione tra ambienti. L'applicazione di una singola modifica al repository ha il potenziale per influire su tutti gli ambienti contemporaneamente, quindi è importante comprendere in modo completo l'effetto delle modifiche alle directory di base e occuparsene con attenzione.
  • Più repository (ognuno dei quali serve a uno scopo specifico):
    • Può essere usato per separare i repository di configurazione per ogni applicazione, team, livello o tenant.
    • Ciò consente ai team di avere un controllo più indipendente, ma si allontana dal principio di definire lo stato del sistema in un unico repository per migliorare la configurazione centrale, la visibilità e il controllo delle distribuzioni in un cluster.
    • La configurazione di più repository deve essere considerata per esigenze multi-tenancy. È disponibile il controllo degli accessi in base al ruolo e la sicurezza predefinita per definire la configurazione che un team o un tenant assegnato a un repository specifico può applicare, ad esempio consentendo solo la distribuzione a determinati spazi dei nomi.

Altri modi per strutturare il repository sono disponibili nella guida a Flux.

Configurazione dell'applicazione e della piattaforma

Gli operatori della piattaforma e gli operatori dell'applicazione hanno diverse opzioni per la gestione della configurazione di Kubernetes:

  • I file YAML di Kubernetes non elaborati che rappresentano le specifiche YAML per ogni oggetto API Kubernetes che si sta distribuendo possono funzionare bene per singoli ambienti. Lo svantaggio dell'uso di file YAML non elaborati è che la personalizzazione diventa difficile quando si inizia a incorporare più ambienti, poiché è necessario duplicare i file YAML e non esiste un buon metodo di riutilizzo.
  • Helm è uno strumento di gestione dei pacchetti per gli oggetti Kubernetes. Si tratta di un'opzione valida che gli operatori cluster possono usare per l'installazione di applicazioni di terze parti non disponibili. Assicurarsi di non usare il modello troppo pesantemente come strumento di gestione della configurazione per le applicazioni interne, perché può diventare complesso da gestire man mano che i modelli aumentano.
    • Se si usa Helm, Flux include un controller Helm che consente di gestire in modo dichiarativo le versioni del grafico Helm con manifesti Kubernetes. È possibile creare un oggetto HelmRelease per gestire il processo.
  • Kustomize è uno strumento di gestione della configurazione nativa kubernetes che introduce un modo senza modello per personalizzare la configurazione dell'applicazione.
    • Se si usa Kustomize, Flux include un controller Kustomize specializzato nell'esecuzione di pipeline di recapito continuo per l'infrastruttura e i carichi di lavoro definiti con manifesti Kubernetes e assemblati con Kustomize. È possibile creare un oggetto Kustomization per gestire il processo.
  • Con Kubernetes abilitato per Azure Arc, invece di dover gestire manualmente il ciclo di vita e il supporto dei componenti, è possibile usare un elenco di estensioni disponibili gestite e supportate da Microsoft. Queste estensioni vengono gestite tramite Azure Resource Manager. Alcune di queste estensioni, ad esempio il provider di segreti di Azure Key Vault, hanno alternative open source. La gestione dei componenti all'esterno del processo di estensione offre maggiore controllo sui componenti, ma richiede anche un sovraccarico maggiore per il supporto e la gestione del ciclo di vita.

Flusso di integrazione continua e recapito continuo (CI/CD)

Le sezioni seguenti forniscono considerazioni per la pipeline dell'applicazione e il processo di aggiornamento dei componenti.

Pipeline dell'applicazione

  • Prendere in considerazione la compilazione, il test e le convalide dell'applicazione che è necessario includere nel processo di integrazione continua. Questi possono includere linting e test correlati a sicurezza, integrazione e prestazioni, necessari per creare un candidato alla versione (RC) per le distribuzioni dell'ambiente.
  • È possibile usare un metodo di distribuzione push tradizionale per colmare il divario tra un'immagine del contenitore di compilazione nella pipeline ci e la relativa distribuzione in un cluster chiamando l'API Kubernetes direttamente dalla pipeline di distribuzione.

Per evitare modifiche di configurazione manuali al repository GitOps, è possibile eseguire la pipeline cd come account del servizio, che dispone dell'autorizzazione per aprire le richieste pull o eseguire il commit di una nuova modifica dell'immagine del contenitore direttamente in un repository di configurazione. Queste modifiche possono anche effettuare il provisioning di tutti gli oggetti YAML necessari per l'applicazione.

Il diagramma di processo seguente illustra il processo di integrazione continua dell'applicazione tradizionale incorporato con le modifiche che supportano GitOps.

Diagram that shows the standard GitOps process.

Processo di aggiornamento dei componenti a livello di cluster

  • Gli operatori del cluster devono gestire i componenti a livello di cluster, quindi è probabile che non provenga dalla pipeline cd usata per distribuire applicazioni e servizi. Valutare la possibilità di definire un processo di promozione specifico per gli operatori cluster per garantire che le modifiche siano in grado di passare senza problemi da un ambiente a un altro.
  • Se è necessario applicare la configurazione GitOps identica su larga scala ai cluster Kubernetes abilitati per Azure Arc, è consigliabile applicare un Criteri di Azure in grado di installare automaticamente l'estensione Flux e applicare la configurazione GitOps ai cluster Kubernetes abilitati per Azure Arc esistenti o ai nuovi cluster durante l'onboarding in Azure Arc.

Quando si aggiorna la configurazione, è probabile che si voglia verificare che le modifiche siano state applicate correttamente all'ambiente desiderato. È possibile definire le notifiche in Flux per l'integrazione con gli strumenti CI/CD, la posta elettronica o gli strumenti di ChatOps e inviare automaticamente avvisi relativi a modifiche riuscite e errori di distribuzione. È anche possibile trovare informazioni sullo stato della distribuzione nella portale di Azure e tramite l'interfaccia della riga di comando di configurazione k8s e l'API ARM.

Considerazioni sulla sicurezza

Esaminare le considerazioni sulla sicurezza seguenti quando si prevede di implementare GitOps per Kubernetes abilitato per Azure Arc.

Autenticazione del repository

  • È possibile usare un repository Git pubblico o privato con GitOps, ma a causa della natura sensibile delle configurazioni di Kubernetes, è consigliabile usare un repository privato che richiede l'autenticazione tramite chiave SSH o chiave API. GitOps funziona anche con i repository Git accessibili solo all'interno di una rete privata, purché il cluster Kubernetes possa accedervi, ma questa configurazione limita la possibilità di usare provider Git basati sul cloud come Azure Repos o GitHub.
  • I protocolli HTTPS e SSH offrono una connessione affidabile e sicura che è possibile usare per connettersi allo strumento di controllo del codice sorgente. Tuttavia, HTTPS è spesso più facile da configurare e usa una porta che raramente richiede l'apertura di più porte nei firewall.

Sicurezza del repository e del ramo

  • Impostare le autorizzazioni e i criteri del ramo nel repository di configurazione. Man mano che il repository Git diventa il componente centrale delle distribuzioni kubernetes, è fondamentale configurare le autorizzazioni per controllare chi può leggere e aggiornare il codice in un ramo e implementare i criteri per applicare la qualità del codice e la gestione delle modifiche del team. In caso contrario, il flusso di lavoro di GitOps può spedire codice non fino agli standard dell'organizzazione.
  • Le pipeline di richieste pull possono usare i criteri dei rami per convalidare la configurazione YAML e/o distribuire gli ambienti di test in base alle esigenze. I controlli consentono di eliminare gli errori di configurazione e aumentare la sicurezza e la sicurezza della distribuzione.
  • Quando si assegnano le autorizzazioni di accesso, considerare quali utenti dell'organizzazione devono avere l'accesso in lettura al repository, l'accesso alla creazione della richiesta pull e l'accesso per l'approvazione della richiesta pull.

Gestione dei segreti

  • Evitare di archiviare segreti con codifica Base64 o testo normale nel repository Git. Prendere invece in considerazione l'uso di un provider di segreti esterni, ad esempio Azure Key Vault. Il provider di Azure Key Vault per il driver CSI dell'archivio segreti consente di integrare un insieme di credenziali delle chiavi di Azure come archivio segreti con un cluster del servizio Azure Kubernetes (AKS) servizio Azure Kubernetes usando un volume CSI. Questo servizio è disponibile tramite l'estensione Kubernetes abilitata per Azure Arc. HashiCorp Vault è un'alternativa al provider di segreti gestiti di terze parti.
  • Un altro modo alternativo per gestire i segreti consiste nell'usare i segreti sealed di Bitnami, che operavano dal concetto di chiavi pubbliche e private. In questo modo gli operatori possono archiviare un segreto crittografato unidirezionale usando una chiave pubblica in Git, che può essere decrittografata solo tramite la chiave privata, usata da un controller SealedSecrets in esecuzione nel cluster.

Suggerimenti per la progettazione

Esaminare le raccomandazioni di progettazione seguenti quando si prevede di implementare GitOps per Kubernetes abilitato per Azure Arc.

Il diagramma seguente contiene un'architettura di riferimento che illustra le responsabilità, i repository e le pipeline necessarie per implementare un processo GitOps usando l'estensione Kubernetes Flux abilitata per Azure Arc.

Diagram that shows a GitOps Reference flow.

Repository

Nella progettazione sono inclusi tre repository Git:

  • Repository del codice dell'applicazione
    • Questo repository archivia il codice dell'applicazione e qualsiasi definizione di pipeline e script di configurazione.
    • Usare una strategia di diramazione dello sviluppo facile da comprendere e limitare il numero di rami a esecuzione prolungata indesiderati.
  • Repository di configurazione dell'applicazione
    • Questo repository archivia le configurazioni dell'applicazione, inclusi oggetti Kubernetes, ad esempio Config Mappe, Distribuzioni, Servizi e oggetti HPA. Strutturare questo repository con directory diverse per ogni applicazione. Flux sincronizza le modifiche dal repository e dal ramo di destinazione al cluster.
    • Incorporare strumenti che semplificano la compilazione di configurazioni iniziali per ogni ambiente da parte di sviluppatori di applicazioni e operatori. Gli operatori dell'applicazione devono definire una configurazione dell'applicazione specifica di Kubernetes che usa strumenti di gestione pacchetti come Helm o strumenti di configurazione come Kustomize per semplificare la configurazione.
    • Creare un ramo per rappresentare ogni tipo di ambiente. In questo modo è possibile controllare con granularità fine le modifiche in ogni ambiente specifico, ad esempio ambienti non di produzione e produzione.
    • Quando un'applicazione viene distribuita in uno spazio dei nomi specifico, usare la funzionalità di ambito dello spazio dei nomi all'interno della configurazione di GitOps per applicare la configurazione solo per un determinato spazio dei nomi.
  • Repository di configurazione a livello di cluster
    • Definire componenti a livello di cluster come Controller in ingresso, Spazi dei nomi, Controllo degli accessi in base al ruolo, monitoraggio e stack di sicurezza per la gestione degli operatori cluster. Flux sincronizza le modifiche dal repository e dal ramo di destinazione al cluster.
    • Strutturare questo repository con directory diverse che rappresentano componenti diversi.
    • Creare un ramo per rappresentare ogni tipo di ambiente. In questo modo è possibile controllare con granularità fine le modifiche in ogni ambiente specifico, ad esempio ambienti non di produzione e produzione.
    • Gli operatori cluster devono usare gestioni pacchetti come Helm o strumenti di configurazione come le sovrimpressioni Kustomize per semplificare la configurazione.

Processo di aggiornamento ci/cd e configurazione

Aggiornamenti delle immagini ci/CD e contenitori

  • CI Pipeline
    • I team di sviluppo devono definire una pipeline di integrazione continua tramite processo che include compilazione, linting, test e push di un'applicazione nel registro contenitori.
  • CD Pipeline
    • Creare una pipeline cd che esegue uno script destinato alle modifiche nel repository di configurazione dell'applicazione. Questo script crea un ramo temporaneo originato dall'ambiente di destinazione, apporta una modifica alla versione del tag immagine, esegue il commit della modifica e apre una richiesta pull nel ramo dell'ambiente di destinazione. Questa pipeline cd può avere fasi di ambiente con variabili di ambiente appropriate per specificare come destinazione il repository e il ramo di Configurazione gitOps corretti.
    • Definire i passaggi di approvazione manuale per le fasi dell'ambiente per limitare le richieste pull indesiderate a tutti gli ambienti.
  • Abilitare i criteri di ramo nel repository di configurazione dell'applicazione per applicare la revisione peer o le approvazioni per gli ambienti. Ciò può comportare un numero minimo di revisioni necessarie o un'approvazione automatica per ambienti inferiori. Prendere in considerazione anche integrazioni e approvazioni di terze parti in base alle esigenze per soddisfare gli standard dell'organizzazione.

Aggiornamenti della configurazione a livello di cluster e dell'applicazione

  • Gli operatori cluster e gli operatori dell'applicazione definiscono ogni configurazione nei rispettivi repository di configurazione. Questi utenti non richiedono strumenti della pipeline per eseguire il push delle configurazioni. Usano invece processi di commit e richiesta pull Git nativi per definire una configurazione ed eseguire il push delle modifiche in un ramo che rappresenta un ambiente.
  • Per le nuove definizioni di configurazione, iniziare definendo la configurazione in ambienti inferiori, ad esempio Sviluppo, quindi alzare di livello a ambienti più elevati tramite merge e richieste pull. Cherry-pick aggiornamenti della configurazione specifici per determinati ambienti in base alle esigenze.

Commenti e suggerimenti

  • Configurare notifiche Flux per avvisare quando le configurazioni di GitOps non sono in grado di sincronizzare o generano errori. Gli operatori dell'applicazione devono configurare gli avvisi per determinare quando la distribuzione di un'applicazione ha avuto esito positivo ed è integra. Gli operatori cluster devono configurare gli avvisi per determinare quando la riconciliazione dei componenti a livello di cluster non è riuscita e quando si verificano problemi di sincronizzazione con il repository Git.
  • Implementare GitOps Connessione or per integrare il feedback dell'agente Flux agli strumenti CI/CD.

Suggerimenti per la sicurezza

  • Esaminare le raccomandazioni relative alla governance e alla sicurezza per i cluster Kubernetes abilitati per Azure Arc.
  • Evitare l'accesso indesiderato a qualsiasi configurazione del cluster usando un repository Git privato con autenticazione e autorizzazione che è possibile usare per definire qualsiasi repository di configurazione.
  • Accedere al repository Git tramite il protocollo SSH e una chiave SSH se il provider Git lo supporta. Se SSH non è utilizzabile a causa di restrizioni di connettività in uscita o se il provider Git non supporta le librerie SSH necessarie, usare un account del servizio dedicato e associare una chiave API a tale account per l'uso di Flux. Se è necessaria un'alternativa a SSH quando si usa GitHub, è possibile creare un token di accesso personale per l'autenticazione.
  • Configurare i criteri e le autorizzazioni dei rami che corrispondono alle responsabilità del cluster. Impostare un numero minimo di revisori per approvare le modifiche.
  • Configurare una pipeline di richiesta pull per convalidare configurazioni e sintassi YAML e distribuire facoltativamente un cluster Kubernetes di test. Configurare un criterio di ramo che richiede che questa pipeline venga eseguita correttamente prima che sia possibile accettare qualsiasi merge.
  • Implementare segreti usando il provider di Azure Key Vault per il driver CSI dell'archivio segreti, che consentirà l'integrazione di un insieme di credenziali delle chiavi di Azure come archivio segreti con un cluster Kubernetes abilitato per Azure Arc tramite un volume CSI.
  • L'estensione Flux supporta configurazioni con ambito spazio dei nomi e cluster. Scegliere l'ambito dello spazio dei nomi quando la configurazione non deve avere accesso oltre un singolo spazio dei nomi.

Passaggi successivi

Per altre informazioni sul percorso cloud ibrido e multicloud, vedere gli articoli seguenti.