Condividi tramite

Parametri supportati da GitOps (Flux v2)

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. GitOps con Flux v2 consente di usare il repository Git come origine della verità per la configurazione del cluster e la distribuzione di applicazioni. Per altre informazioni, vedere Distribuzioni di applicazioni con GitOps (Flux v2) e Esercitazione: Distribuire applicazioni con GitOps con Flux v2.

GitOps in Kubernetes o nel servizio Azure Kubernetes abilitato per Azure Arc usa Flux, un set di strumenti open source diffuso che supporta molti parametri per abilitare vari scenari. Per una descrizione di tutti i parametri supportati da Flux, vedere la documentazione ufficiale di Flux.

Per visualizzare tutti i parametri supportati da Flux in Azure, vedere la az k8s-configuration documentazione. Questa implementazione non supporta attualmente tutti i parametri supportati da Flux. Segnalare se un parametro necessario non è presente nell'implementazione di Azure.

Questo articolo descrive alcuni parametri e argomenti disponibili per il az k8s-configuration flux create comando. È anche possibile visualizzare l'elenco completo dei parametri per az k8s-configuration flux usando il parametro nell'interfaccia -h della riga di comando di Azure , ad esempio az k8s-configuration flux -h o az k8s-configuration flux create -h.

Suggerimento

Una soluzione alternativa per distribuire risorse Flux con parametri non supportati consiste nel definire le risorse personalizzate Flux necessarie (ad esempio GitRepository o Kustomization) all'interno del repository Git. Distribuire queste risorse con il az k8s-configuration flux create comando . Sarà quindi possibile accedere alle risorse Flux tramite l'interfaccia utente di Azure Arc.

Argomenti generali di configurazione

Parametro Formato Note
--cluster-name -c Stringa Nome della risorsa cluster in Azure.
--cluster-type -t Valori consentiti: connectedClusters, managedClusters Usare connectedClusters per i cluster di Azure Arc-enabled Kubernetes o managedClusters per i cluster AKS.
--resource-group -g Stringa Nome del gruppo di risorse di Azure che contiene la risorsa cluster.
--name -n Stringa Nome della configurazione Flux in Azure.
--namespace --ns Stringa Nome dello spazio dei nomi in cui distribuire la configurazione. Impostazione predefinita: default.
--scope -s Stringa Ambito di autorizzazione per gli operatori. I valori possibili sono cluster (accesso completo) o namespace (accesso limitato). Impostazione predefinita: cluster.
--suspend bandiera Sospende tutte le riconciliazioni di origine e kustomize definite nella configurazione di Flux. Le riconciliazione attive al momento della sospensione continueranno.

Argomenti generali di origine

Parametro Formato Note
--kind Stringa Tipo di origine da riconciliare. Valori consentiti: bucket, git, azblob. Impostazione predefinita: git.
--timeout formato di durata "golang" Tempo massimo per tentare di riconciliare l'origine prima del timeout. Impostazione predefinita: 10m.
--sync-interval --interval formato di durata golang Tempo tra le riconciliazione dell'origine nel cluster. Impostazione predefinita: 10m.

Argomenti di riferimento all'origine del repository Git

Parametro Formato Note
--branch Stringa Ramo all'interno dell'origine Git da sincronizzare con il cluster. Impostazione predefinita: master. I repository più recenti potrebbero avere un ramo radice denominato main, nel qual caso è necessario impostare --branch=main.
--tag Stringa Tag dell'origine Git da sincronizzare con il cluster. Esempio: --tag=3.2.0.
--semver Stringa Intervallo di tag semver Git all'interno dell'origine Git da sincronizzare con il cluster. Esempio: --semver=">=3.1.0-rc.1 <3.2.0".
--commit Stringa Git commit SHA all'interno dell'origine Git per la sincronizzazione con il cluster. Esempio: --commit=363a6a8fe6a7f13e05d34c163b0ef02a777da20a.

Per altre informazioni, vedere la documentazione di Flux sulle strategie di checkout del repository Git.

Git pubblico repository

Parametro Formato Note
--url -u http[s]://server/repo[.git] URL dell'origine del repository Git da sincronizzare con il cluster.

Repository Git privato con SSH

Importante

Azure DevOps ha annunciato la deprecazione di SSH-RSA come metodo di crittografia supportato per la connessione ai repository di Azure tramite SSH. Se si usano chiavi SSH per connettersi ai repository di Azure nelle configurazioni di Flux, è consigliabile passare alle chiavi RSA-SHA2-256 o RSA-SHA2-512 più sicure. Per altre informazioni, vedere Azure DevOps SSH-RSA deprecazione.

Repository Git privato con chiavi CREATE da SSH e Flux

Aggiungere la chiave pubblica generata da Flux all'account utente nel provider di servizi Git.

Parametro Formato Note
--url -u ssh://user@server/repo[.git] git@ deve sostituire user@ se la chiave pubblica è associata al repository anziché all'account utente.

Repository Git privato con chiavi SSH e fornite dall'utente

Usare la propria chiave privata direttamente o da un file. La chiave deve essere in formato PEM e terminare con una nuova riga (\n).

Aggiungere la chiave pubblica associata all'account utente nel provider di servizi Git.

Parametro Formato Note
--url -u ssh://user@server/repo[.git] git@ deve sostituire user@ se la chiave pubblica è associata al repository anziché all'account utente.
--ssh-private-key Chiave Base64 in formato PEM Specificare direttamente la chiave.
--ssh-private-key-file Percorso completo del file locale Specificare il percorso completo del file locale che contiene la chiave in formato PEM.

Host Git privato con SSH e host noti forniti dall'utente

L'operatore Flux mantiene un elenco di host Git comuni nel relativo known_hosts file. Flux usa queste informazioni per autenticare il repository Git prima di stabilire la connessione SSH. Se si usa un repository Git non comune o il proprio host Git, è possibile specificare la chiave host in modo che Flux possa identificare il repository.

Analogamente alle chiavi private, è possibile fornire il contenuto di known_hosts direttamente o in un file. Quando si fornisce contenuto personalizzato, usare le specifiche del formato di contenuto known_hosts, insieme a uno degli scenari di chiave SSH precedenti.

Parametro Formato Note
--url -u ssh://user@server/repo[.git] git@ può sostituire user@.
--known-hosts Stringa Base64 Specificare known_hosts direttamente il contenuto.
--known-hosts-file Percorso completo del file locale Fornire known_hosts contenuto in un file locale.

Repository Git privato con un utente e una chiave HTTPS

Parametro Formato Note
--url -u https://server/repo[.git] HTTPS con autenticazione di base.
--https-user Stringa grezza Nome utente HTTPS.
--https-key Stringa grezza Token di accesso personale HTTPS o password.

Repository Git privato con un certificato della CA HTTPS

Parametro Formato Note
--url -u https://server/repo[.git] HTTPS con autenticazione di base.
--https-ca-cert Stringa Base64 Certificato CA per la comunicazione TLS.
--https-ca-cert-file Percorso completo del file locale Specificare il contenuto del certificato DELLA CA in un file locale.

Argomenti di origine del bucket

Se utilizzi bucket come origine, ecco gli argomenti di comando specifici per il bucket.

Parametro Formato Note
--url -u Stringa URL URL dell'oggetto bucket. Formati supportati: http://, https://.
--bucket-name Stringa Nome dell'oggetto bucket da sincronizzare.
--bucket-access-key Stringa ID della chiave di accesso utilizzato per l'autenticazione con bucket.
--bucket-secret-key Stringa Chiave privata usata per l'autenticazione con .bucket
--bucket-insecure Booleano Comunicare con bucket senza TLS. Se non specificato, si presuppone false; se specificato, si presuppone true.

Argomenti di origine dell'account di archiviazione BLOB di Azure

Se si utilizza la sorgente azblob, ecco gli argomenti di comando specifici del blob.

Parametro Formato Note
--url -u Stringa URL URL del azblob.
--container-name Stringa Nome del contenitore di Archiviazione BLOB di Azure da sincronizzare
--sp_client_id Stringa ID client per l'autenticazione di un'entità di servizio con Azure Blob Storage, necessario per questo metodo di autenticazione
--sp_tenant_id Stringa ID tenant per l'autenticazione di un principale del servizio con Azure Blob, necessario per questo metodo di autenticazione
--sp_client_secret Stringa Il segreto del client per l'autenticazione di un principale del servizio con Azure Blob
--sp_client_cert Stringa Certificato client codificato in Base64 per autenticare un principale del servizio con Azure Blob
--sp_client_cert_password Stringa Password per il certificato client usato per autenticare un principale di servizio su Azure Blob
--sp_client_cert_send_chain Stringa Specifica se includere un'intestazione x5c nelle dichiarazioni del client durante l'acquisizione di un token per abilitare l'autenticazione basata su nome del soggetto/emittente per il certificato del client
--account_key Stringa Chiave condivisa BLOB di Azure per l'autenticazione
--sas_token Stringa Token SAS BLOB di Azure per l'autenticazione
--managed-identity-client-id Stringa ID client dell'identità gestita per l'autenticazione con BLOB di Azure

Importante

Quando si utilizza l'autenticazione dell'identità gestita per i cluster AKS e azblob l'origine, all'identità gestita deve essere assegnato almeno il ruolo di Lettore dei dati dei BLOB di archiviazione. L'autenticazione con un'identità gestita non è ancora disponibile per i cluster Kubernetes abilitati per Azure Arc.

Segreto locale per l'autenticazione con l'origine

È possibile usare un segreto Kubernetes locale per l'autenticazione con un'origine gito bucketazBlob . Il segreto locale deve contenere tutti i parametri di autenticazione necessari per l'origine e deve essere creato nello stesso spazio dei nomi della configurazione Flux.

Parametro Formato Note
--local-auth-ref --local-ref Stringa Riferimento locale a un segreto di Kubernetes nello spazio dei nomi della configurazione Flux da utilizzare per l'autenticazione con la sorgente.

Per l'autenticazione HTTPS, creare un segreto con username e password:

kubectl create ns flux-config
kubectl create secret generic -n flux-config my-custom-secret --from-literal=username=<my-username> --from-literal=password=<my-password-or-key>

Per l'autenticazione SSH, creare un segreto con i campi identity e known_hosts.

kubectl create ns flux-config
kubectl create secret generic -n flux-config my-custom-secret --from-file=identity=./id_rsa --from-file=known_hosts=./known_hosts

Importante

Azure DevOps ha annunciato la deprecazione di SSH-RSA come metodo di crittografia supportato per la connessione ai repository di Azure tramite SSH. Se si usano chiavi SSH per connettersi ai repository di Azure nelle configurazioni di Flux, è consigliabile passare alle chiavi RSA-SHA2-256 o RSA-SHA2-512 più sicure. Per ulteriori informazioni, consultare Azure DevOps SSH-RSA obsolescenza.

Per entrambi i casi, quando si crea la configurazione Flux, usare --local-auth-ref my-custom-secret al posto degli altri parametri di autenticazione:

az k8s-configuration flux create -g <cluster_resource_group> -c <cluster_name> -n <config_name> -t connectedClusters --scope cluster --namespace flux-config -u <git-repo-url> --kustomization name=kustomization1 --local-auth-ref my-custom-secret

Altre informazioni sull'uso di un segreto Kubernetes locale con questi metodi di autenticazione:

Annotazioni

Se è necessario Flux per accedere all'origine tramite il proxy, è necessario aggiornare gli agenti di Azure Arc con le impostazioni proxy. Per maggiori informazioni, vedere Connettersi usando un server proxy in uscita.

Implementazione Git

Per supportare vari provider di repository che implementano Git, Flux può essere configurato per l'uso di una delle due librerie Git: go-git o libgit2. Per informazioni dettagliate, vedere la documentazione di Flux.

L'implementazione di GitOps di Flux v2 determina automaticamente quale libreria usare per i repository cloud pubblici:

  • Per i repository GitHub, GitLab e BitBucket, Flux usa go-git.
  • Per Azure DevOps e tutti gli altri repository, Flux usa libgit2.

Per i repository locali, Flux usa libgit2.

Personalizzazione

Kustomization è un'impostazione creata per le configurazioni di Flux che consente di scegliere un percorso specifico nel repository di origine riconciliato nel cluster. Non è necessario creare un file 'kustomization.yaml in questo percorso specificato. Per impostazione predefinita, tutti i manifesti in questo percorso vengono riconciliati. Tuttavia, se si desidera creare un overlay Kustomize per le applicazioni disponibili in questo percorso di repository, è necessario realizzare file Kustomize in Git per la configurazione di Flux da utilizzare.

Usando az k8s-configuration flux kustomization create, è possibile creare una o più kustomization durante la configurazione.

Parametro Formato Note
--kustomization Nessun valore Inizio di una stringa di parametri che configurano una kustomization. È possibile usarlo più volte per creare più kustomization.
name Stringa Nome univoco per questa personalizzazione.
path Stringa Percorso all'interno del repository Git per riconciliarsi con il cluster. Il valore predefinito è il livello principale del ramo.
prune Booleano Il valore predefinito è false. Impostare prune=true per assicurarsi che gli oggetti Flux distribuiti nel cluster vengano puliti se vengono rimossi dal repository o se la configurazione di Flux o le kustomization vengono eliminate. L'uso prune=true è importante per gli ambienti in cui gli utenti non hanno accesso ai cluster e possono apportare modifiche solo tramite il repository Git.
depends_on Stringa Nome di una o più kustomization (all'interno di questa configurazione) che deve riconciliarsi prima che questa kustomization possa riconciliarsi. Ad esempio: depends_on=["kustomization1","kustomization2"]. Se si rimuove una kustomization che ha kustomization dipendenti, lo stato delle kustomization dipendenti diventa DependencyNotReady, e la riconciliazione si interrompe.
timeout formato della durata di Golang Impostazione predefinita: 10m.
sync_interval formato della durata in golang Impostazione predefinita: 10m.
retry_interval formato di durata golang Impostazione predefinita: 10m.
validation Stringa Valori: none, client, server. Impostazione predefinita: none. Per informazioni dettagliate, vedere la documentazione di Flux .
force Booleano Impostazione predefinita: false. Impostare force=true per indicare al controller kustomize di ricreare le risorse quando l'applicazione di patch fallisce a causa di una modifica del campo immutabile.

È anche possibile usare az k8s-configuration flux kustomization per aggiornare, elencare, visualizzare ed eliminare le kustomization in una configurazione di Flux.

Passaggi successivi

  • Last updated on