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

  • Articolo

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

  • Visibilità continua sullo stato delle applicazioni in esecuzione nei cluster.
  • Separazione delle problematiche tra i team di sviluppo di applicazioni e i team dell'infrastruttura. I team delle applicazioni non devono 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 aumento del numero di istanze.

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)
  • Grafici Helm per la distribuzione di applicazioni
  • Kustomize files to describe environment-specific changes

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. Gli operatori assicurano inoltre continuamente che il cluster rimanga nello stato desiderato.

GitOps in Kubernetes abilitato per Azure Arc o servizio Azure Kubernetes 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 gestione delle dipendenze multi-tenancy e 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 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 o servizio Azure Kubernetes abilitato per Azure Arc come risorsa di estensione del Microsoft.KubernetesConfiguration/extensions/microsoft.fluxcluster. L'estensione microsoft.flux deve essere installata nel cluster prima di poter creare una o più fluxConfigurations estensioni. L'estensione viene installata automaticamente quando si crea la prima 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 arm 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 i controller e image-reflector Fluximage-automation, 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 YAML non elaborati o kustomize 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 HelmChart risorsa personalizzata e applica l'oggetto con la versione, il HelmRelease 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 fluxconfigs.clusterconfig.azure.com risorse personalizzate che definiscono FluxConfig oggetti Kubernetes.

  • fluxconfig-agent: responsabile del controllo di Azure per le risorse nuove o aggiornate fluxConfigurations e per l'avvio della configurazione di Flux associata nel cluster. Inoltre, è responsabile del push delle modifiche dello stato del flusso nel cluster in Azure per ogni fluxConfigurations risorsa.

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

Nota

L'estensione microsoft.flux viene installata nello spazio dei flux-system nomi e ha un ambito a livello di cluster. Non è possibile installare questa estensione nell'ambito dello spazio dei nomi.

Configurazioni di Flux

Diagramma che mostra l'installazione di una configurazione Flux in un cluster Kubernetes o servizio Azure Kubernetes abilitato per Azure Arc.

È possibile creare risorse di configurazione di Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) per abilitare la gestione di GitOps del cluster dai repository Git, dalle origini bucket o dall'archivio 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 fluxConfigurations risorse vengono archiviati crittografati inattivi in un database di Azure Cosmos DB dal servizio Configurazione cluster.

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

fluxconfig-agent è responsabile delle attività seguenti:

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

fluxconfig-controller è responsabile delle attività seguenti:

  • Controlla gli aggiornamenti dello stato delle risorse personalizzate Flux create dall'oggetto gestito fluxConfigurations.
  • Crea una coppia di chiavi privata/pubblica esistente per la durata dell'oggetto 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 GitRepository o Bucket risorse personalizzate e Kustomization risorse personalizzate dalle informazioni nella FluxConfig risorsa personalizzata.

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

Nota

Monitora le fluxconfig-agent risorse nuove o aggiornate fluxConfiguration in Azure. L'agente richiede la connettività ad Azure per lo stato desiderato dell'oggetto fluxConfiguration da applicare al cluster. Se l'agente non riesce a connettersi ad Azure, le modifiche nel cluster attendono fino a quando l'agente non riesce a connettersi. Se il cluster è disconnesso da Azure per più di 48 ore, si verifica il timeout della richiesta al cluster e le modifiche dovranno essere riapplicate in Azure.

Gli input dei clienti sensibili, ad esempio la chiave privata e il token/password, vengono archiviati per meno di 48 ore nel servizio di configurazione di Kubernetes. Se si aggiorna uno di questi valori in Azure, assicurarsi che i cluster si connettano ad Azure entro 48 ore.

È possibile monitorare lo stato e la conformità di Flux nella portale di Azure oppure usare i 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 Flux v2 (microsoft.flux) e le due versioni precedenti (N-2). In genere è consigliabile usare la versione più recente dell'estensione. microsoft.flux A partire dalla versione 1.7.0, sono supportati cluster basati su ARM64.

Nota

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

Il supporto per le risorse di configurazione del cluster basate su Flux v1 create prima del 1° gennaio 2024 terminerà il 24 maggio 2025. A partire dal 1° gennaio 2024, non sarà possibile creare nuove risorse di configurazione del cluster basate su Flux v1.

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 configurazioni Flux su larga scala

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

Per altre informazioni, vedere Distribuire le applicazioni su larga scala usando configurazioni Flux v2 e 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).

Multi-tenancy

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

Nota

Per la funzionalità multi-tenancy, è necessario sapere se i manifesti contengono un sourceRef tra spazi dei nomi per HelmRelease, Kustomization, ImagePolicy o altri oggetti oppure se si usa una versione di Kubernetes inferiore alla 1.20.6. Per preparare:

  • Eseguire l'aggiornamento a Kubernetes versione 1.20.6 o successiva.
  • Nei manifesti kubernetes assicurarsi che tutti sourceRef siano a oggetti all'interno dello stesso spazio dei nomi della configurazione di GitOps.

Aggiornare i manifesti per la multi-tenancy

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

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

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 rappresentando l'account del flux-applier servizio distribuito solo nello spazio dei cluster-config nomi . 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 nginx nomi , ma fa riferimento a helmRepository nello spazio dei flux-system nomi . Inoltre, Flux helm-controller non può applicare , HelmReleaseperché non esiste alcun flux-applier account di servizio nello spazio dei nginx nomi .

Per usare il multi-tenancy, l'approccio corretto consiste nel distribuire tutti gli oggetti Flux nello stesso spazio dei nomi di fluxConfigurations. Questo approccio evita il problema di riferimento tra spazi dei nomi e consente ai controller Flux di ottenere le autorizzazioni per applicare gli oggetti. Pertanto, per una configurazione GitOps creata nello cluster-config spazio dei nomi, 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 rifiutare esplicitamente la creazione o l'aggiornamento dell'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 Flux v1 sourceControlConfigurations dai cluster. Poiché Flux v2 ha un'architettura fondamentalmente diversa, l'estensione microsoft.flux del cluster non verrà installata se sono presenti risorse Flux v1 sourceControlConfigurations 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 Flux v1 sourceControlConfigurations non arresta le applicazioni in esecuzione nei cluster. Tuttavia, durante il periodo in cui 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 e 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 configurazioni di Flux v1

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

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

È anche possibile trovare ed eliminare configurazioni GitOps esistenti per un cluster nel portale di Azure. 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 la 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 aggiornato di Flux. Include una nuova architettura e supporta altri casi d'uso di GitOps. Microsoft ha lanciato una versione di un'estensione usando Flux v2 a maggio 2022. Da allora, i clienti sono stati invitati a passare a Flux v2 entro tre anni, poiché il supporto per l'uso di Flux v1 è previsto per terminare nel maggio 2025.

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

  • Flux v1 è un operatore do-it-all monolitico. 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 i rami Git, l'aggiunta a commit e tag e i seguenti intervalli di tag SemVer.
  • Configurazione delle credenziali per risorsa GitRepository: chiave privata SSH, nome utente/password/token HTTP/S e chiavi pubbliche OpenPGP.

Passaggi successivi