Condividi tramite

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 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 in caso di 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:

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 diffuso set di strumenti open source. Flux offre supporto per origini file comuni (repository Git e Helm, bucket, Archiviazione BLOB di Azure) e tipi di modello (YAML, Helm e Kustomize). Tra le altre funzionalità Flux supporta anche multi-tenancy e la gestione delle dipendenze della distribuzione.

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 o servizio Azure Kubernetes abilitato per Azure Arc come una risorsa di Microsoft.KubernetesConfiguration/extensions/microsoft.fluxestensione del 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 (origine, Kustomize, Helm, notifica) e la definizione di risorsa personalizzata (CRD) di FluxConfig, fluxconfig-agent e 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 risorse personalizzatesource.toolkit.fluxcd.io. 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 Kustomize di Flux : controlla le risorse personalizzate kustomization.toolkit.fluxcd.io. Applica i file YAML non elaborati o kustomize dall'origine al cluster.

  • Controller Helm di Flux: controlla le risorse personalizzate helm.toolkit.fluxcd.io. 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 di Flux: controlla le risorse personalizzate notification.toolkit.fluxcd.io. 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 del push delle modifiche dello stato di Flux del cluster ad ogni risorsa fluxConfigurations di Azure.

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

Nota

L'estensione microsoft.flux viene installata nello spazio dei nomi flux-system 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 risorsa fluxConfigurations, 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 vengono archiviati come dati crittografati e inattivi in un database di Azure Cosmos DB da parte del servizio Configurazione 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 di 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 forniti dall'utente private-key/http basic-auth/known-hosts/no-auth.
  • 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.

Nota

fluxconfig-agent monitora le risorse fluxConfiguration nuove o aggiornate in Azure. L'agente richiede la connettività ad Azure per lo stato desiderato di 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 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 di GitOps (Flux v2) e l'attività.

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.

Nota

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

Il supporto per le risorse di configurazione 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 è preconfigurata per comunicare 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 altre informazioni, vedere Distribuire le applicazioni in modo coerente su larga scala usando configurazioni di Flux v2 e Criteri di Azure.

Parametri

Per visualizzare tutti i parametri supportati da Flux v2 in Azure, vedere la documentazione az k8s-configuration. 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 che si sappia se i manifesti contengono un sourceRef tra gli spazi dei nomi per HelmRelease, Kustomization, ImagePolicy o altri oggetti oppure se si usa una versione di Kubernetes inferiore alla 1.20.6. Come prepararsi:

  • 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 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 per 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 rappresentando 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 servizioflux-applier nello spazio dei nomi nginx.

L'approccio corretto per usare la multi-tenancy consiste nel distribuire tutti gli oggetti Flux nello stesso spazio dei nomi di fluxConfigurations. Questo approccio evita il problema di referenza degli spazi dei nomi e consente ai controller Flux di ottenere le autorizzazioni 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 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 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 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>

Inoltre nel portale di Azure è possibile individuare ed eliminare le configurazioni GitOps esistenti di un cluster. A tal proposito 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 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