Distribuzioni di applicazioni con GitOps (Flux v2) per AKS e Kubernetes abilitato per Azure Arc

Azure offre una funzionalità di distribuzione automatica delle applicazioni usando GitOps che funziona con il servizio Azure Kubernetes e i cluster Kubernetes abilitati per Azure Arc. I vantaggi principali dell'adozione di GitOps per la distribuzione di applicazioni nei cluster Kubernetes includono:

• Visibilità continua sullo stato delle applicazioni in esecuzione nei cluster.
• Separazione dei compiti tra i team di sviluppo di applicazioni e i team dell'infrastruttura. I team delle applicazioni possono non avere esperienza con le distribuzioni Kubernetes. I team di progettazione della piattaforma creano in genere un modello self-service per i team delle applicazioni, consentendo loro di eseguire distribuzioni con maggiore attendibilità.
• Possibilità di ricreare i cluster con lo stesso stato desiderato in caso di arresto anomalo o di aumento delle prestazioni.
• Possibilità di distribuire applicazioni su larga scala tramite Criteri di Azure.

Con GitOps si dichiara lo stato desiderato dei cluster Kubernetes nei file nei repository Git. I repository Git possono contenere i file seguenti:

• Manifesti in formato YAML che descrivono le risorse kubernetes (ad esempio spazi dei nomi, segreti, distribuzioni e altri)
• Helm charts per distribuire applicazioni
• File Kustomize per descrivere le modifiche specifiche all'ambiente

Poiché questi file vengono archiviati in un repository Git, le versioni vengono eseguite e le modifiche tra le versioni vengono facilmente rilevate. I controller Kubernetes vengono eseguiti nei cluster e riconciliano continuamente lo stato del cluster con lo stato desiderato dichiarato nel repository Git. Questi operatori estraggono i file dai repository Git e applicano lo stato desiderato ai cluster. Inoltre cli operatori assicurano continuamente che il cluster rimanga nello stato desiderato.

GitOps in Kubernetes o nel servizio Azure Kubernetes abilitato per Azure Arc usa Flux, un set di strumenti open source diffuso. Flux offre supporto per origini file comuni (repository Git e Helm, bucket, Archiviazione BLOB di Azure) e tipi di modello (YAML, Helm e Kustomize). Flux supporta anche la multi-tenancy e la gestione delle dipendenze di distribuzione, tra le altre funzionalità.

Flux viene distribuito direttamente nel cluster e il piano di controllo di ogni cluster è separato logicamente. Ciò rende la scalabilità ottimale a centinaia e migliaia di cluster. Flux consente distribuzioni di applicazioni GitOps pure e basate sul pull. Non è necessario alcun accesso ai cluster dal repository di origine o da qualsiasi altro cluster.

Estensione del cluster Flux

GitOps è abilitato in un cluster Kubernetes abilitato per Azure Arc o in un cluster AKS come risorsa Microsoft.KubernetesConfiguration/extensions/microsoft.flux cluster. L'estensione microsoft.flux deve essere installata nel cluster prima che possano essere creati uno o più fluxConfigurations. L'estensione viene installata automaticamente quando si crea il primo Microsoft.KubernetesConfiguration/fluxConfigurations in un cluster oppure è possibile installarla manualmente usando il portale, l'interfaccia della riga di comando di Azure (az k8s-extension create --extensionType=microsoft.flux), il modello di Resource Manager o l'API REST.

Controller

Per impostazione predefinita, l'estensione microsoft.flux installa i controller Flux (Source, Kustomize, Helm, Notification) e FluxConfig Custom Resource Definition (CRD), fluxconfig-agente fluxconfig-controller. Facoltativamente è anche possibile installare Flux image-automation e i controller image-reflector che forniscono funzionalità per l'aggiornamento e il recupero di immagini Docker.

• Controller di origine Flux: controlla le source.toolkit.fluxcd.io risorse personalizzate. Gestisce la sincronizzazione tra repository Git, repository Helm, bucket e Archiviazione BLOB di Azure. Gestisce l'autorizzazione con l'origine per Git privati, repository Helm e account di Archiviazione BLOB di Azure. Visualizza le ultime modifiche apportate all'origine tramite un file di archivio tar.

• Controller Flux Kustomize: controlla le kustomization.toolkit.fluxcd.io risorse personalizzate. Applica i file Kustomize o YAML non elaborati dall'origine al cluster.

• Controller Helm Flux: controlla le helm.toolkit.fluxcd.io risorse personalizzate. Recupera il grafico associato dall'origine del repository Helm rilevata dal controller di origine. Crea la risorsa personalizzata HelmChart e applica HelmRelease con la versione, il nome e i valori definiti dal cliente specificati al cluster.

• Controller di notifica Flux: controlla le notification.toolkit.fluxcd.io risorse personalizzate. Riceve notifiche da tutti i controller Flux. Esegue il push delle notifiche agli endpoint webhook definiti dall'utente.

• Definizioni di risorse personalizzate Flux:

  • kustomizations.kustomize.toolkit.fluxcd.io
  • imagepolicies.image.toolkit.fluxcd.io
  • imagerepositories.image.toolkit.fluxcd.io
  • imageupdateautomations.image.toolkit.fluxcd.io
  • alerts.notification.toolkit.fluxcd.io
  • providers.notification.toolkit.fluxcd.io
  • receivers.notification.toolkit.fluxcd.io
  • buckets.source.toolkit.fluxcd.io
  • gitrepositories.source.toolkit.fluxcd.io
  • helmcharts.source.toolkit.fluxcd.io
  • helmrepositories.source.toolkit.fluxcd.io
  • helmreleases.helm.toolkit.fluxcd.io
  • fluxconfigs.clusterconfig.azure.com

• CRD FluxConfig: definizione di risorsa personalizzata per le risorse personalizzate fluxconfigs.clusterconfig.azure.com che definiscono oggetti Kubernetes FluxConfig.

• fluxconfig-agent: responsabile del controllo in Azure delle risorse fluxConfigurations nuove o aggiornate e responsabile dell'avvio della configurazione di Flux associata nel cluster. Inoltre è responsabile di inviare le modifiche dello stato di Flux nel cluster di ritorno ad Azure per ciascuna risorsa fluxConfigurations.

• fluxconfig-controller: controlla le risorse personalizzate fluxconfigs.clusterconfig.azure.com e risponde alle modifiche con una configurazione nuova o aggiornata dei macchinari GitOps nel cluster.

Configurazioni di Flux

Per scaricare diagrammi di architettura in alta risoluzione, visitare Jumpstart Gem.

Crei risorse di configurazione di Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) per abilitare la gestione GitOps del cluster dai tuoi repository Git, dalle fonti bucket o dall'archiviazione Blob di Azure. Quando si crea una fluxConfigurations risorsa, i valori forniti per i parametri, ad esempio il repository Git di destinazione, vengono usati per creare e configurare gli oggetti Kubernetes che abilitano il processo GitOps in tale cluster. Per garantire la sicurezza dei dati, i dati delle risorse fluxConfigurations sono archiviati crittografati a riposo in un database di Azure Cosmos DB dal servizio di configurazione del cluster.

Gli agenti fluxconfig-agent e fluxconfig-controller, installati con l'estensione microsoft.flux, gestiscono il processo di configurazione di GitOps.

fluxconfig-agent è responsabile delle seguenti attività:

• Esegue il polling del servizio piano dati di configurazione di Kubernetes per le risorse fluxConfigurations nuove o aggiornate.
• Crea o aggiorna risorse personalizzate FluxConfig nel cluster con le informazioni di configurazione.
• Controlla le risorse personalizzate FluxConfig ed esegue il push delle modifiche dello stato alle risorse di Azure fluxConfiguration associate.

fluxconfig-controller è responsabile delle seguenti attività:

• Controlla gli aggiornamenti dello stato delle risorse personalizzate Flux create da fluxConfigurations gestito.
• Crea una coppia di chiavi privata/pubblica esistente per la durata di fluxConfigurations. Questa chiave viene usata per l'autenticazione se l'URL è basato su SSH e se l'utente non fornisce la propria chiave privata durante la creazione della configurazione.
• Crea un segreto di autenticazione personalizzato basato sui dati private-key/http basic-auth/known-hosts/no-auth forniti dall'utente.
• Configura il controllo degli accessi in base al ruolo (con provisioning dell'account del servizio, associazione di ruoli creata/assegnata, ruolo creato/assegnato).
• Crea risorse personalizzate GitRepository o Bucket e risorse personalizzate Kustomization dalle informazioni nella risorsa personalizzata FluxConfig.

Ogni risorsa fluxConfigurations in Azure è associata a una risorsa Flux GitRepository o a una risorsa personalizzata Bucket e a una o più risorse personalizzate Kustomization in un cluster Kubernetes. Quando si crea una risorsa fluxConfigurations, si specifica l'URL dell'origine (repository Git, bucket o archiviazione BLOB di Azure) e la destinazione di sincronizzazione nell'origine per ogni Kustomization. È possibile configurare le dipendenze tra le risorse personalizzate Kustomization per controllare la sequenza della distribuzione. È anche possibile creare più risorse fluxConfigurations con ambito spazio dei nomi nello stesso cluster per applicazioni e team di app diversi.

È possibile monitorare lo stato e la conformità di Flux nel portale di Azure oppure usare le dashboard per monitorare lo stato, la conformità, l'utilizzo delle risorse e l'attività di riconciliazione. Per altre informazioni, vedere Monitorare lo stato e l'attività di GitOps (Flux v2).

Supporto versione

Sono supportate la versione più recente dell'estensione (microsoft.flux) Flux v2 e le due versioni precedenti (N-2). In genere è consigliabile usare la versione più recente dell'estensione. A partire da microsoft.flux versione 1.7.0 i cluster basati su ARM64 sono supportati.

GitOps con collegamento privato

Se è stato aggiunto il supporto per il collegamento privato a un cluster Kubernetes abilitato per Azure Arc, l'estensione microsoft.flux funziona automaticamente con la comunicazione con Azure. Per le connessioni al repository Git, al repository Helm o a qualsiasi altro endpoint necessario per distribuire i manifesti di Kubernetes, è necessario effettuare il provisioning di questi endpoint dietro il firewall o elencarli nel firewall in modo che il controller di origine Flux possa raggiungerli correttamente.

Residenza dei dati

Il servizio Azure GitOps (Gestione della configurazione di Azure Kubernetes) archivia/elabora i dati dei clienti. Per impostazione predefinita i dati dei clienti vengono replicati nell'area abbinata. Per le aree Singapore, Asia orientale e Brasile meridionale tutti i dati dei clienti vengono archiviati ed elaborati nell'area.

Applicare le configurazioni Flux su larga scala

Poiché Azure Resource Manager gestisce le configurazioni, è possibile automatizzare la creazione della stessa configurazione in tutte le risorse del servizio Azure Kubernetes e di Kubernetes abilitate per Azure Arc usando Criteri di Azure all'interno dell'ambito di una sottoscrizione o di un gruppo di risorse. Questa tutela su larga scala garantisce che specifiche configurazioni vengano applicate in modo coerente tra interi gruppi di cluster.

Per ulteriori informazioni, consulta Distribuisci le applicazioni in modo coerente su larga scala utilizzando le configurazioni di Flux v2 e i Criteri di Azure.

Parametri

Per visualizzare tutti i parametri supportati da Flux v2 in Azure, vedere la az k8s-configuration documentazione. L'implementazione di Azure attualmente non supporta tutti i parametri supportati da Flux.

Per informazioni sui parametri disponibili e su come usarli, vedere Parametri supportati di GitOps (Flux v2).

Multiutenza

Flux v2 supporta la multi-tenancy a partire dalla versione 0.26. Questa funzionalità è integrata in Flux v2 in Azure.

Aggiornare i manifesti per la multi-tenancy

Si supponga di distribuire un fluxConfiguration in uno dei cluster Kubernetes nello spazio dei nomi cluster-config con ambito cluster. Configurare l'origine per sincronizzare il repository https://github.com/fluxcd/flux2-kustomize-helm-example. Questo è lo stesso repository Git di esempio usato nell'esercitazione Distribuire applicazioni con GitOps con Flux v2.

Flux, dopo che sincronizza il repository, distribuisce le risorse descritte nei manifesti (file YAML). Due dei manifesti descrivono gli oggetti HelmRelease e HelmRepository.

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: nginx
spec:
  releaseName: nginx-ingress-controller
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

Per impostazione predefinita, l'estensione Flux distribuisce fluxConfigurations impersonando l'account del servizio flux-applier, distribuito solo nello spazio dei nomi cluster-config. Usando i manifesti precedenti, quando è abilitata la multi-tenancy, l'oggetto HelmRelease viene bloccato. Ciò è dovuto al fatto che HelmRelease si trova nello spazio dei nomi nginx, ma fa riferimento a HelmRepository nello spazio dei nomi flux-system. Inoltre, helm-controller di Flux non può applicare HelmRelease perché non esiste alcun account del servizio flux-applier nel namespace nginx.

L'approccio corretto per lavorare con la multi-tenancy consiste nel distribuire tutti gli oggetti Flux nello stesso namespace di fluxConfigurations. Questo approccio evita il problema di riferimento incrociato di namespace e consente ai gestori Flux di ottenere l'autorizzazione necessaria per applicare gli oggetti. Pertanto per una configurazione GitOps creata nello spazio dei nomi cluster-config questi manifesti di esempio cambiano nel modo seguente:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: cluster-config 
spec:
  releaseName: nginx-ingress-controller
  targetNamespace: nginx
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: cluster-config
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: cluster-config
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

Rifiutare esplicitamente la multi-tenancy

Quando l'estensione microsoft.flux è installata, la multi-tenancy è abilitata per impostazione predefinita. Se è necessario disabilitare la multi-tenancy, è possibile disattivarla aggiornando l'estensione microsoft.flux nei cluster con --configuration-settings multiTenancy.enforce=false, come illustrato in questi comandi di esempio:

az k8s-extension create --extension-type microsoft.flux --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

az k8s-extension update --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

Eseguire la migrazione da Flux v1

Se si usa ancora Flux v1, è consigliabile eseguire la migrazione a Flux v2 il prima possibile.

Per eseguire la migrazione all'uso di Flux v2 negli stessi cluster in cui si usa Flux v1, prima è necessario eliminare tutti sourceControlConfigurations di Flux v1 dai cluster. Poiché Flux v2 ha un'architettura fondamentalmente diversa, l'estensione del cluster microsoft.flux non verrà installata se sono presenti risorse sourceControlConfigurations Flux v1 in un cluster. Il processo di rimozione delle configurazioni di Flux v1 e della distribuzione delle configurazioni di Flux v2 non dovrebbe richiedere più di 30 minuti.

La rimozione di sourceControlConfigurations Flux v1 non arresta le applicazioni in esecuzione nei cluster. Tuttavia quando la configurazione di Flux v1 viene rimossa e l'estensione Flux v2 non è ancora completamente distribuita:

• Se sono presenti nuove modifiche nei manifesti dell'applicazione archiviati in un repository Git, queste modifiche non vengono estratte durante la migrazione e la versione dell'applicazione distribuita nel cluster non sarà aggiornata.
• Se sono presenti modifiche impreviste nello stato del cluster che si discosta dallo stato desiderato specificato nel repository Git di origine, il cluster non sarà in grado di eseguire la riparazione automatica.

È consigliabile testare lo scenario di migrazione in un ambiente di sviluppo prima di eseguire la migrazione dell'ambiente di produzione.

Visualizzare ed eliminare le configurazioni di Flux v1

Usare questi comandi dell'interfaccia della riga di comando di Azure per trovare ed eliminare sourceControlConfigurations esistente in un cluster:

az k8s-configuration flux list --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>
az k8s-configuration flux delete --name <configuration name> --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>

Inoltre nel portale di Azure è possibile individuare ed eliminare le configurazioni GitOps esistenti di un cluster. A tale scopo, passare al cluster in cui è stata creata la configurazione e selezionare GitOps nel riquadro sinistro. Selezionare la configurazione, quindi selezionare Elimina.

Distribuire configurazioni di Flux v2

Usare il portale di Azure o l'interfaccia della riga di comando di Azure per applicare le configurazioni di Flux v2 ai cluster.

Informazioni sul ritiro di Flux v1

Il progetto open source di Flux v1 è stato archiviato e lo sviluppo di funzionalità è stato interrotto a tempo indeterminato.

Flux v2 è stato lanciato come progetto open source e aggiornamento di Flux. Include una nuova architettura e supporta altri casi d'uso di GitOps. Nel maggio 2022 Microsoft ha lanciato una versione di un'estensione usando Flux v2. Da allora i clienti sono stati invitati a passare a Flux v2 entro tre anni, poiché il supporto per l'uso di Flux v1 terminerà nel maggio 2025.

Nuove funzionalità principali introdotte nell'estensione GitOps per Flux v2:

• Flux v1 è un operatore monolitico che esegue tutte le operazioni. Flux v2 separa le funzionalità in controller specializzati (controller di origine, controller Kustomize, controller Helm e controller di notifica).
• Supporta la sincronizzazione con più repository di origine.
• Supporta la multi-tenancy, ad esempio l'applicazione di ogni repository di origine con un proprio set di autorizzazioni.
• Fornisce informazioni operative dettagliate tramite controlli di integrità, eventi e avvisi.
• Supporta rami Git, l'aggiunta a commit e tag e gli intervalli di tag SemVer seguenti.
• Configurazione delle credenziali per risorsa GitRepository: chiave privata SSH, nome utente/password/token HTTP/S e chiavi pubbliche OpenPGP.

Passaggi successivi

• Usa il nostro tutorial per imparare a abilitare GitOps sui tuoi cluster AKS o sui cluster Kubernetes abilitati per Azure Arc.
• Informazioni sul flusso di lavoro CI/CD con GitOps.