Condividi tramite

GitOps per il servizio Azure Kubernetes

Servizio Azure Kubernetes (AKS)
GitHub

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

Diagramma di GitOps con Flux v2, GitHub e AKS.

Scaricare un file di Visio di questa architettura.

Flusso di dati per lo scenario 1

Flux è un'estensione del cluster che si integra in modo nativo con AKS. Un'estensione del cluster offre una piattaforma per l'installazione e la gestione di soluzioni in un cluster AKS. È 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 su larga scala usando configurazioni 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 seguente corrisponde al diagramma precedente:

  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 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 Cloud Object Storage Service (OSS), ma esistono altre soluzioni.

  • È 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.

  • Flux v2 supporta la multi-tenancy consentendo a team separati di distribuire i carichi di lavoro in un singolo cluster Kubernetes condiviso. È possibile sincronizzare più repository Git che rappresentano un tenant diverso nel cluster. Per garantire l'isolamento del carico di lavoro tra i team, ogni team potrebbe avere uno o più spazi dei nomi all'interno del cluster AKS a cui l'accesso è limitato tramite le policy RBAC di Kubernetes.

  • Flux può usare un cluster per gestire le app nello stesso cluster o in altri cluster. Un cluster hub del servizio Azure Kubernetes con l'operatore Flux gestisce la distribuzione continua tramite GitOps di applicazioni e carichi di lavoro infrastrutturali verso più cluster spoke del servizio Azure Kubernetes.

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

Diagramma che illustra come implementare CI/CD usando GitOps con Flux, GitHub e Azure Kubernetes Service.

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 di dati seguente corrisponde al diagramma precedente:

  1. Il codice dell'app viene sviluppato usando un ambiente di sviluppo integrato (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 manifesto di distribuzione di Kubernetes con la versione attuale dell'immagine, che si basa sul numero di versione dell'immagine del contenitore nel Container Registry.

  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 di GitHub e Azure Kubernetes Service

Diagramma di GitOps con Argo CD, GitHub e AKS.

Scaricare un file di Visio di questa architettura.

Flusso di dati per lo scenario 3

È possibile abilitare Argo CD come estensione del cluster nel servizio Azure Kubernetes. 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 seguente corrisponde al diagramma precedente:

  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 AKS con lo stato desiderato specificato nel repository Git. Argo CD segnala e visualizza le differenze e fornisce strumenti 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 attività. 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, puoi 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

Diagramma che illustra come implementare CI/CD usando GitOps con Argo CD, GitHub e AKS.

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 di dati seguente corrisponde al diagramma precedente:

  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 Contenitori.

  4. GitHub Actions aggiorna un file di distribuzione del manifest Kubernetes con la versione corrente dell'immagine, basata sul numero di versione dell'immagine del contenitore nel Registro dei Contenitori.

  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 il controllo della versione, la collaborazione, la conformità e l'integrazione continua e la 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.

In base ai principi di GitOps, lo stato desiderato di un sistema gestito da GitOps deve soddisfare i criteri seguenti:

  • 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.

  • 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.

  • Pull automatico: Gli agenti software estraggono automaticamente le dichiarazioni di stato desiderate dall'origine.

  • Riconciliato continuamente: Gli agenti software osservano continuamente lo stato effettivo del sistema e tentano di applicare lo stato desiderato.

In GitOps , IaC usa il codice per dichiarare lo stato desiderato dei componenti dell'infrastruttura, ad esempio macchine virtuali (VM), 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 usando 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 (PoLP).

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. Ad esempio, i controller di ammissione 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 i singoli team per mantenerle informate sullo stato corrente di GitOps. 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. GitOps, ad esempio, può applicare la stessa configurazione tra cluster primari e di ripristino di emergenza o in una farm di cluster.

Per applicare GitOps come unico metodo per modificare lo stato del cluster, limitare l'accesso diretto al cluster. Per impostare questa configurazione, usare il controllo degli accessi in base al ruolo di Azure, i controller di ammissione o altri strumenti.

Usare GitOps per avviare la configurazione iniziale

In alcuni casi la distribuzione del cluster di Azure Kubernetes Service (AKS) è necessaria come parte della configurazione di base. Ad esempio, potrebbe essere necessario distribuire servizi condivisi o configurazioni a livello di sistema prima di distribuire carichi di lavoro dell'applicazione. Questi servizi condivisi possono configurare i componenti aggiuntivi e gli strumenti seguenti:

È 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 AKS consiglia di usare GitOps per il bootstrapping. Se si usa l'estensione Flux, è possibile avviare i cluster subito 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 offre vantaggi alle organizzazioni che vogliono distribuire applicazioni e IaC e mantenere un audit trail di ogni modifica.

GitOps semplifica la gestione dei contenitori per gli sviluppatori, migliorando così la produttività. Gli sviluppatori possono continuare a lavorare con strumenti familiari, ad esempio Git, per gestire gli aggiornamenti e le nuove funzionalità.

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 Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Se un cluster non è più disponibile, GitOps deve essere usato come parte della creazione di un nuovo cluster. 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 Stamp di distribuzione .

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Con l'approccio GitOps, i singoli sviluppatori o amministratori non accedono direttamente ai cluster Kubernetes per applicare modifiche o aggiornamenti. Invece, gli utenti eseguono le modifiche in un repository Git e l'operatore GitOps, come 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 a configurare le autorizzazioni del repository, è consigliabile implementare le misure di sicurezza seguenti nei repository Git 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 pull request (PR) per apportare modifiche e fare in modo che almeno un'altra persona esamini ogni PR. Usare anche le richieste pull per eseguire controlli automatici.

  • Revisione PR: Richiedere alle richieste di pull di avere 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. Consentire solo i commit firmati per impedire modifiche non autorizzate.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

  • Il livello gratuito di AKS offre una gestione gratuita dei cluster. I costi sono limitati alle risorse di calcolo, archiviazione e rete usate dal servizio Azure Kubernetes per ospitare i nodi. Il livello gratuito del servizio Azure Kubernetes non include un contratto di servizio e non è consigliato per i carichi di lavoro di produzione.

  • GitHub offre un servizio gratuito, ma per usare funzionalità avanzate correlate alla sicurezza, ad esempio proprietari di codice o revisori necessari, è necessario il piano team. Per altre informazioni, vedere 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 maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

GitOps può aumentare la produttività DevOps. Una delle funzionalità più utili è la possibilità di eseguire rapidamente il rollback delle modifiche che si comportano in modo imprevisto eseguendo operazioni Git. Il grafico di commit contiene ancora tutti i commit, in modo che possa essere utile per l'analisi retrospettiva.

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

Per altre informazioni sulla distribuzione dei cinque scenari, vedere le risorse seguenti:

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

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

Passaggi successivi