GitOps per il servizio Azure Kubernetes

GitOps è un set di principi per il funzionamento e la gestione di un sistema software. Questo articolo descrive le tecniche per l'uso dei principi GitOps per gestire e gestire un cluster del servizio Azure Kubernetes.This article describes techniques for using GitOps principles to operate and manage an servizio Azure Kubernetes s clusters (AKS).

I logo Flux, Argo CD, OPA Gatekeeper, Kubernetes e Git sono marchi delle rispettive società. Nessuna verifica dell'autenticità è implicita nell'uso di questi marchi.

Architettura

Due operatori GitOps che è possibile usare con il servizio Azure Kubernetes sono Flux e Argo CD. Sono entrambi laureati progetti CLOUD Native Computing Foundation (CNF) e sono ampiamente utilizzati. Gli scenari seguenti illustrano i modi per usarli.

Scenario 1: GitOps con Flux e servizio Azure Kubernetes

Scaricare un file di Visio di questa architettura.

Flusso di dati per lo scenario 1

Flux è un'estensione del cluster nativa per il servizio Azure Kubernetes . Le estensioni del cluster offrono una piattaforma per l'installazione e la gestione di soluzioni in un cluster del servizio Azure Kubernetes. È possibile usare gli script portale di Azure, dell'interfaccia della riga di comando di Azure o dell'infrastruttura come codice (IaC), ad esempio gli script Terraform o Bicep, per abilitare Flux come estensione al servizio Azure Kubernetes. È anche possibile usare Criteri di Azure per applicare configurazioni di Flux v2 su larga scala nei cluster del servizio Azure Kubernetes. Per altre informazioni, vedere Distribuire le applicazioni in modo coerente su larga scala usando configurazioni di Flux v2 e Criteri di Azure.

Flux può distribuire manifesti Kubernetes, grafici Helm e file di Kustomization nel servizio Azure Kubernetes. Flux è un processo basato su polling, in modo da poter rilevare, eseguire il pull e riconciliare le modifiche di configurazione senza esporre gli endpoint del cluster agli agenti di compilazione.

In questo scenario, gli amministratori di Kubernetes possono modificare gli oggetti di configurazione di Kubernetes, ad esempio segreti e ConfigMaps, ed eseguire il commit delle modifiche direttamente in un repository GitHub.

Il flusso di dati per questo scenario è:

1. Lo sviluppatore esegue il commit delle modifiche alla configurazione nel repository GitHub.
2. Flux rileva la deriva della configurazione nel repository Git ed esegue il pull delle modifiche alla configurazione.
3. Flux riconcilia lo stato nel cluster Kubernetes.

Alternative per lo scenario 1

• È possibile usare Flux con altri repository Git, ad esempio Azure DevOps, GitLab e BitBucket.
• Anziché i repository Git, l'API Bucket Flux definisce un'origine per produrre un artefatto per gli oggetti da soluzioni di archiviazione come Amazon S3 e i bucket di Google Cloud Storage. È anche possibile usare una soluzione con un'API compatibile con S3. Due esempi sono Minio e Alibaba Sistema operativo cloud S, ma ci sono altri.
• È anche possibile configurare Flux su un contenitore Archiviazione BLOB di Azure come origine per produrre artefatti. Per altre informazioni, vedere Configurazioni di GitOps Flux v2 con il servizio Azure Kubernetes e Kubernetes abilitato per Azure Arc.

Scenario 2: Usare GitOps con Flux, GitHub e servizio Azure Kubernetes per implementare CI/CD

Scaricare un file di Visio di questa architettura.

Flusso di dati per lo scenario 2

Questo scenario è una pipeline DevOps basata sul pull per una tipica applicazione Web. La pipeline usa GitHub Actions per la compilazione. Per la distribuzione, usa Flux come operatore GitOps per eseguire il pull e la sincronizzazione dell'app. Il flusso dei dati nello scenario avviene come segue:

1. Il codice dell'app viene sviluppato usando un IDE, ad esempio Visual Studio Code.
2. Il codice dell'app viene eseguito il commit in un repository GitHub.
3. GitHub Actions compila un'immagine del contenitore dal codice dell'app ed esegue il push dell'immagine del contenitore in Registro Azure Container.
4. GitHub Actions aggiorna un file di distribuzione del manifesto Kubernetes con la versione dell'immagine corrente basata sul numero di versione dell'immagine del contenitore in Registro Azure Container.
5. L'operatore Flux rileva la deriva della configurazione nel repository Git ed esegue il pull delle modifiche di configurazione.
6. Flux usa i file manifesto per distribuire l'app nel cluster del servizio Azure Kubernetes.

Scenario 3: GitOps con Argo CD, repository GitHub e servizio Azure Kubernetes

Scaricare un file di Visio di questa architettura.

Flusso di dati per lo scenario 3

In questo scenario, l'amministratore di Kubernetes può modificare gli oggetti di configurazione di Kubernetes, ad esempio segreti e ConfigMaps, ed eseguire il commit delle modifiche direttamente nel repository GitHub.

Il flusso di dati per questo scenario è:

1. L'amministratore di Kubernetes apporta modifiche alla configurazione nei file YAML ed esegue il commit delle modifiche nel repository GitHub.
2. Argo CD esegue il pull delle modifiche dal repository Git.
3. Argo CD riconcilia le modifiche di configurazione al cluster del servizio Azure Kubernetes.

Argo CD non deve sincronizzare automaticamente lo stato di destinazione desiderato nel cluster del servizio Azure Kubernetes. Viene implementato come controller Kubernetes che monitora continuamente le applicazioni in esecuzione. Confronta lo stato attivo corrente del cluster del servizio Azure Kubernetes con lo stato di destinazione desiderato specificato nel repository Git. Argo CD segnala e visualizza le differenze, fornendo strutture per sincronizzare automaticamente o manualmente lo stato attivo allo stato di destinazione desiderato.

Argo CD fornisce un'interfaccia utente basata su browser. È possibile usarlo per aggiungere configurazioni dell'applicazione, osservare lo stato di sincronizzazione rispetto al cluster e avviare la sincronizzazione sul cluster. È anche possibile usare la riga di comando di Argo CD per eseguire queste operazioni. Sia l'interfaccia utente che l'interfaccia della riga di comando forniscono funzionalità per visualizzare la cronologia delle modifiche di configurazione e per eseguire il rollback a una versione precedente.

Per impostazione predefinita, l'interfaccia utente di Argo CD e il server API non sono esposti. Per accedervi, è consigliabile creare un controller di ingresso con un indirizzo IP interno. In alternativa, è possibile usare un servizio di bilanciamento del carico interno per esporli.

Alternative per lo scenario 3

Qualsiasi repository compatibile con Git, incluso Azure DevOps, può fungere da repository di origine della configurazione.

Scenario 4: Usare GitOps con Argo CD, GitHub Actions e servizio Azure Kubernetes per implementare CI/CD

Scaricare un file di Visio di questa architettura.

Flusso di dati per lo scenario 4

Questo scenario è una pipeline DevOps basata sul pull per una tipica applicazione Web. La pipeline usa GitHub Actions per la compilazione. Per la distribuzione, usa Argo CD come operatore GitOps per eseguire il pull e la sincronizzazione dell'app. Il flusso dei dati nello scenario avviene come segue:

1. Il codice dell'app viene sviluppato usando un IDE, ad esempio Visual Studio Code.
2. Il codice dell'app viene eseguito il commit in un repository GitHub.
3. GitHub Actions compila un'immagine del contenitore dal codice dell'app ed esegue il push dell'immagine del contenitore in Registro Azure Container.
4. GitHub Actions aggiorna un file di distribuzione del manifesto Kubernetes con la versione dell'immagine corrente basata sul numero di versione dell'immagine del contenitore in Registro Azure Container.
5. Argo CD esegue il pull dal repository Git.
6. Argo CD distribuisce l'app nel cluster del servizio Azure Kubernetes.

Alternative per lo scenario 4

Qualsiasi repository compatibile con Git, incluso Azure DevOps, può fungere da repository di origine della configurazione.

Dettagli dello scenario

GitOps è un set di principi per il funzionamento e la gestione di un sistema software.

• Usa il controllo del codice sorgente come singola fonte di verità per il sistema.
• Applica procedure di sviluppo come controllo della versione, collaborazione, conformità e integrazione continua/distribuzione continua (CI/CD) all'automazione dell'infrastruttura.
• È possibile applicarlo a qualsiasi sistema software.

GitOps viene spesso usato per la gestione e il recapito di applicazioni del cluster Kubernetes. Questo articolo descrive alcune opzioni comuni per l'uso di GitOps insieme a un cluster del servizio Azure Kubernetes.

In base ai principi di GitOps, lo stato desiderato di un sistema gestito da GitOps deve essere:

1. Dichiarativo: un sistema gestito da GitOps deve avere lo stato desiderato espresso in modo dichiarativo. La dichiarazione viene in genere archiviata in un repository Git.
2. Controllo delle versioni e non modificabile: lo stato desiderato viene archiviato in modo da applicare l'immutabilità e il controllo delle versioni e mantiene una cronologia delle versioni completa.
3. Pull automatico: gli agenti software estraggono automaticamente le dichiarazioni di stato desiderate dall'origine.
4. Riconciliato continuamente: gli agenti software osservano continuamente lo stato effettivo del sistema e tentano di applicare lo stato desiderato.

In GitOps l'infrastruttura come codice (IaC) usa il codice per dichiarare lo stato desiderato dei componenti dell'infrastruttura, ad esempio macchine virtuali, reti e firewall. Questo codice è sottoposto al controllo dalla versione ed è controllabile.

Kubernetes descrive tutti gli elementi, dallo stato del cluster alle distribuzioni di applicazioni in modo dichiarativo con manifesti. GitOps per Kubernetes sottopone lo stato desiderato dell'infrastruttura del cluster al controllo della versione. Un componente nel cluster, in genere denominato operatore, sincronizza continuamente lo stato dichiarativo. Questo approccio consente di esaminare e controllare le modifiche al codice che interessano il cluster. Migliora la sicurezza supportando il principio dei privilegi minimi.

Gli agenti GitOps riconciliano continuamente lo stato del sistema con lo stato desiderato archiviato nel repository di codice. Alcuni agenti GitOps possono ripristinare le operazioni eseguite all'esterno del cluster, ad esempio la creazione manuale di oggetti Kubernetes. I controller di ammissione, ad esempio, applicano criteri agli oggetti durante le operazioni di creazione, aggiornamento ed eliminazione. È possibile usarli per assicurarsi che le distribuzioni cambino solo se il codice di distribuzione nel repository di origine cambia.

È possibile combinare gli strumenti di gestione e imposizione dei criteri con GitOps per applicare i criteri e fornire commenti e suggerimenti per le modifiche dei criteri proposte. È possibile configurare le notifiche per vari team per fornire loro lo stato GitOps aggiornato. Ad esempio, è possibile inviare notifiche relative ai successi della distribuzione e agli errori di riconciliazione.

GitOps come singola fonte di verità

GitOps offre coerenza e standardizzazione dello stato del cluster e consente di migliorare la sicurezza. È anche possibile usare GitOps per garantire uno stato coerente tra più cluster. Ad esempio, GitOps può applicare la stessa configurazione tra cluster primari e di ripristino di emergenza o in una farm di cluster.

Se si vuole imporre che solo GitOps possa modificare lo stato del cluster, è possibile limitare l'accesso diretto al cluster. Esistono diversi modi per eseguire questa operazione, tra cui il controllo degli accessi in base al ruolo di Azure, i controller di ammissione e altri strumenti.

Usare GitOps per avviare la configurazione iniziale

È possibile che sia necessario distribuire i cluster del servizio Azure Kubernetes come parte della configurazione di base. Un esempio è che è necessario distribuire un set di servizi condivisi o una configurazione prima di distribuire i carichi di lavoro. Questi servizi condivisi possono configurare componenti aggiuntivi del servizio Azure Kubernetes, ad esempio:

• ID dei carichi di lavoro di Microsoft Entra.
• Provider di Azure Key Vault per il driver CSI dell'archivio segreti.
• Strumenti per i partner, ad esempio:
  • Prisma Cloud Defender.
• Strumenti open source come:
  • KEDA.
  • ExternalDNS.
  • Cert-manager.

È possibile abilitare Flux come estensione applicata quando si crea un cluster del servizio Azure Kubernetes. Flux può quindi eseguire il bootstrap della configurazione di base nel cluster. L'architettura di base per un cluster del servizio Azure Kubernetes suggerisce l'uso di GitOps per il bootstrap. Se si usa l'estensione Flux, è possibile avviare i cluster molto presto dopo la distribuzione.

Altri strumenti e componenti aggiuntivi GitOps

È possibile estendere gli scenari descritti ad altri strumenti GitOps. Jenkins X è un altro strumento GitOps che fornisce istruzioni per l'integrazione in Azure. È possibile usare strumenti di recapito progressivo come Flagger per lo spostamento graduale dei carichi di lavoro di produzione distribuiti tramite GitOps.

Potenziali casi d'uso

Questa soluzione è vantaggiosa per qualsiasi organizzazione che vuole usufruire dei vantaggi offerti dalla distribuzione di applicazioni e infrastruttura come codice, con un audit trail di ogni modifica.

GitOps protegge lo sviluppatore dalle complessità della gestione di un ambiente contenitore. Gli sviluppatori possono continuare a lavorare con strumenti familiari, ad esempio Git, per gestire gli aggiornamenti e le nuove funzionalità. In questo modo, GitOps migliora la produttività degli sviluppatori.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Uno dei pilastri chiave dell'affidabilità è la resilienza. L'obiettivo della resilienza consiste nel ripristinare uno stato completamente funzionale dell'applicazione dopo un errore. Se un cluster non è più disponibile, GitOps può crearne uno nuovo rapidamente. Usa il repository Git come singola origine di verità per la configurazione e la logica dell'applicazione kubernetes. Può creare e applicare la configurazione del cluster e la distribuzione dell'applicazione come unità di scala e può stabilire il modello di stamp di distribuzione.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Con l'approccio GitOps, i singoli sviluppatori o amministratori non accedono direttamente ai cluster Kubernetes per applicare modifiche o aggiornamenti. Gli utenti eseggono invece le modifiche in un repository Git e l'operatore GitOps (Flux o Argo CD) legge le modifiche e le applica al cluster. Questo approccio segue la procedura consigliata per la sicurezza basata su privilegi minimi, senza fornire ai team DevOps autorizzazioni di scrittura per l'API Kubernetes. Negli scenari di diagnostica o risoluzione dei problemi è possibile concedere le autorizzazioni del cluster per un periodo di tempo limitato, caso per caso.

Oltre all'attività di configurazione delle autorizzazioni dei repository, è consigliabile implementare le misure di sicurezza seguenti nei repository Git che vengono sincronizzati con i cluster del servizio Azure Kubernetes:

• Protezione dei rami: proteggere i rami che rappresentano lo stato dei cluster Kubernetes dal push diretto delle modifiche. Usare le richieste pull per apportare modifiche e avere almeno un'altra persona che esamina ogni richiesta pull. Usare anche le richieste pull per eseguire controlli automatici.
• Revisione delle richieste pull: è necessario che le richieste pull siano sottoposte ad almeno un revisore per applicare il principio del doppio controllo. È anche possibile usare la funzionalità GitHub dei proprietari di codice per definire singoli utenti o team responsabili della revisione di file specifici in un repository.
• Cronologia non modificabile: consente solo nuovi commit in aggiunta alle modifiche esistenti. La cronologia non modificabile è particolarmente importante ai fini del controllo.
• Altre misure di sicurezza: richiedere agli utenti di GitHub di attivare l'autenticazione a due fattori. Inoltre, consentire solo i commit firmati, per impedire le modifiche.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

• Nel livello gratuito, il servizio Azure Kubernetes offre la gestione gratuita dei cluster. I costi sono limitati alle risorse di calcolo, archiviazione e rete usate dal servizio Azure Kubernetes per ospitare i nodi.
• GitHub offre un servizio gratuito, ma per usare le funzionalità avanzate correlate alla sicurezza come proprietari del codice o revisori obbligatori, è necessario sottoscrivere il piano Team. Per altre informazioni, vedere la pagina dei prezzi di GitHub.
• Azure DevOps offre un livello gratuito che è possibile usare per alcuni scenari.
• Usare il calcolatore dei prezzi di Azure per stimare i costi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

GitOps può aumentare la produttività DevOps. Una delle funzionalità più utili consiste nella possibilità di eseguire rapidamente il rollback delle modifiche che si comportano in modo imprevisto, semplicemente eseguendo operazioni Git. Il grafo dei commit contiene ancora tutti i commit, quindi può essere utile per l'analisi post-mortem.

I team GitOps gestiscono spesso più ambienti per la stessa applicazione. In genere è necessario disporre di diverse fasi di un'applicazione distribuita in cluster o spazi dei nomi Kubernetes diversi. Il repository Git, che è l'unica fonte di verità, mostra le versioni delle applicazioni distribuite al momento in un cluster.

Distribuire uno scenario

Nell'elenco seguente vengono forniti riferimenti per informazioni sulla distribuzione dei cinque scenari:

• Scenario 1: per indicazioni sull'uso di GitOps con Flux v2 per distribuire applicazioni nel servizio Azure Kubernetes, vedere Esercitazione: Distribuire applicazioni con GitOps con Flux v2. Per un esempio di come usare l'estensione Flux per avviare la distribuzione del cluster del servizio Azure Kubernetes, vedere l'implementazione di riferimento per la baseline del servizio Azure Kubernetes.
• Scenario 2: Per indicazioni sull'uso di GitOps con Flux v2 nel servizio Azure Kubernetes per distribuire applicazioni e implementare CI/CD, vedere: Esercitazione: Implementare CI/CD con GitOps (Flux v2).
• Scenari 3 e 4: per indicazioni dettagliate sulla distribuzione di un carico di lavoro di esempio con Argo CD e servizio Azure Kubernetes, vedere lo scenario CI/CD basato sul pull in Automazione baseline del servizio Azure Kubernetes.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Francesco Simy Nazareth | Principal Cloud Solutions Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Documentazione di Argo CD
• Documentazione di Flux CD
• GitOps con Jenkins X
• Che cos'è il controllo degli accessi in base al ruolo di Azure?

Risorse correlate

• Architettura di base per un cluster del servizio Azure Kubernetes (AKS)
• Baseline di AKS per cluster multiarea
• DevSecOps in servizio Azure Kubernetes (servizio Azure Kubernetes)
• DevSecOps per l'infrastruttura come codice (IaC)
• Infrastruttura aziendale come codice con Bicep e Registro Azure Container
• Automatizzare la riconfigurazione dell'infrastruttura usando Azure