Partager via

Paramètres pris en charge par GitOps (Flux v2)

Azure fournit une fonctionnalité de déploiements d’applications automatisés à l’aide de GitOps qui fonctionne avec Azure Kubernetes Service (AKS) et des clusters Kubernetes avec Azure Arc. GitOps avec Flux v2 vous permet d’utiliser votre référentiel Git comme source de vérité pour la configuration du cluster et le déploiement d’applications. Pour plus d’informations, consultez Déploiements d’applications avec GitOps (Flux v2) et Tutoriel : Déployer des applications à l’aide de GitOps avec Flux v2.

GitOps sur Kubernetes avec Azure Arc ou Azure Kubernetes Service utilise Flux, un ensemble d’outils open source populaire qui prend en charge de nombreux paramètres pour activer différents scénarios. Pour obtenir une description de tous les paramètres pris en charge par flux, consultez la documentation Flux officielle.

Pour afficher tous les paramètres pris en charge par Flux dans Azure, consultez la az k8s-configuration documentation. Cette implémentation ne prend actuellement pas en charge chaque paramètre pris en charge par Flux. Faites-nous savoir si un paramètre dont vous avez besoin est manquant dans l’implémentation d’Azure.

Cet article décrit certains des paramètres et arguments disponibles pour la az k8s-configuration flux create commande. Vous pouvez également voir la liste complète des paramètres pour le az k8s-configuration flux en utilisant le paramètre -h avec Azure CLI (par exemple, az k8s-configuration flux -h ou az k8s-configuration flux create -h).

Conseil / Astuce

Une solution de contournement pour déployer des ressources Flux avec des paramètres non pris en charge consiste à définir les ressources personnalisées Flux requises (telles que GitRepository ou Kustomization) à l’intérieur de votre dépôt Git. Déployez ces ressources avec la az k8s-configuration flux create commande. Vous pourrez alors toujours accéder à vos ressources Flux via l’interface utilisateur Azure Arc.

Arguments généraux de configuration

Paramètre Format Remarques
--cluster-name-c Chaîne Nom de la ressource de cluster dans Azure.
--cluster-type-t Valeurs autorisées : connectedClusters, managedClusters Utiliser connectedClusters pour les clusters Kubernetes avec Azure Arc ou managedClusters pour les clusters AKS.
--resource-group-g Chaîne Nom du groupe de ressources Azure qui contient la ressource de cluster.
--name-n Chaîne Nom de la configuration flux dans Azure.
--namespace--ns Chaîne Nom de l’espace de noms pour déployer la configuration. Par défaut : default.
--scope-s Chaîne Étendue d’autorisation pour les opérateurs. Les valeurs possibles sont cluster (accès complet) ou namespace (accès restreint). Par défaut : cluster.
--suspend drapeau Suspend toutes les réconciliations source et Kustomize définies dans cette configuration Flux. Les rapprochements actifs au moment de la suspension continueront.

Arguments généraux de source

Paramètre Format Remarques
--kind Chaîne Type de source à rapprocher. Valeurs autorisées : bucket, git, azblob. Par défaut : git.
--timeout Format de la durée golang Durée maximale de tentative de rapprochement de la source avant expiration du délai d’attente. Valeur par défaut : 10m.
--sync-interval--interval Format de la durée golang Temps entre les rapprochements de la source sur le cluster. Par défaut : 10m.

Arguments de référence de la source du référentiel Git

Paramètre Format Remarques
--branch Chaîne Branche au sein de la source Git à synchroniser avec le cluster. Par défaut : master. Les dépôts plus récents peuvent avoir une branche racine nommée main, auquel cas vous devez définir --branch=main.
--tag Chaîne Étiquette au sein de la source Git à synchroniser avec le cluster. Exemple : --tag=3.2.0.
--semver Chaîne Plage d’étiquettes Git semver au sein de la source Git à synchroniser avec le cluster. Exemple : --semver=">=3.1.0-rc.1 <3.2.0".
--commit Chaîne Git commit SHA dans la source Git à synchroniser avec le cluster. Exemple : --commit=363a6a8fe6a7f13e05d34c163b0ef02a777da20a.

Pour plus d’informations, consultez la documentation Flux sur les stratégies d’extraction des référentiels Git.

Dépôt Git public

Paramètre Format Remarques
--url-u http[s]://server/repo[.git] URL de la source du dépôt Git à reconcilier avec le cluster.

Dépôt Git privé avec SSH

Important

Azure DevOps annoncé la dépréciation du SSH-RSA comme méthode de chiffrement prise en charge pour la connexion aux référentiels Azure à l’aide de SSH. Si vous utilisez des clés SSH pour vous connecter aux référentiels Azure dans les configurations flux, nous vous recommandons de passer à des clés RSA-SHA2-256 ou RSA-SHA2-512 plus sécurisées. Pour plus d’informations, consultez dépréciation d’Azure DevOps SSH-RSA.

Dépôt Git privé avec des clés SSH créées par Flux

Ajoutez la clé publique générée par Flux au compte d’utilisateur dans votre fournisseur de services Git.

Paramètre Format Remarques
--url-u ssh://user@server/repo[.git] git@ doit remplacer user@ si la clé publique est associée au référentiel au lieu du compte d’utilisateur.

Dépôt Git privé avec des clés SSH et fournies par l’utilisateur

Utilisez votre propre clé privée directement ou à partir d’un fichier. La clé doit être au format PEM et se terminer par une nouvelle ligne (\n).

Ajoutez la clé publique associée au compte d’utilisateur dans votre fournisseur de services Git.

Paramètre Format Remarques
--url-u ssh://user@server/repo[.git] git@ doit remplacer user@ si la clé publique est associée au référentiel au lieu du compte d’utilisateur.
--ssh-private-key Clé Base64 au format PEM Fournissez directement la clé.
--ssh-private-key-file Chemin d’accès complet au fichier local Indiquez le chemin d’accès complet au fichier local qui contient la clé de format PEM.

Hôte Git privé avec des hôtes connus SSH et fournis par l’utilisateur

L’opérateur Flux gère une liste d’hôtes Git courants dans son known_hosts fichier. Flux utilise ces informations pour authentifier le référentiel Git avant d’établir la connexion SSH. Si vous utilisez un dépôt Git rare ou votre propre hôte Git, vous pouvez fournir la clé d’hôte afin que Flux puisse identifier votre dépôt.

Tout comme les clés privées, vous pouvez fournir le contenu known_hosts directement ou dans un fichier. Lorsque vous fournissez votre propre contenu, utilisez les spécifications de format de contenu known_hosts, ainsi que l’un des scénarios clés SSH précédents.

Paramètre Format Remarques
--url-u ssh://user@server/repo[.git] git@ peut remplacer user@.
--known-hosts Chaîne Base64 Fournissez le contenu known_hosts directement.
--known-hosts-file Chemin d’accès complet au fichier local Fournir du contenu known_hosts dans un fichier local.

Dépôt Git privé avec un utilisateur et une clé HTTPS

Paramètre Format Remarques
--url-u https://server/repo[.git] HTTPS avec authentification de base.
--https-user Chaîne brute Nom d’utilisateur HTTPS.
--https-key Chaîne brute Jeton d’accès personnel HTTPS ou mot de passe.

Dépôt Git privé avec un certificat CA HTTPS

Paramètre Format Remarques
--url-u https://server/repo[.git] HTTPS avec authentification de base.
--https-ca-cert Chaîne Base64 Certificat d’autorité de certification pour la communication TLS.
--https-ca-cert-file Chemin d’accès complet au fichier local Fournissez le contenu du certificat d’autorité de certification dans un fichier local.

Arguments de la source de compartiment

Si vous utilisez la source bucket, voici les arguments de commande spécifiques au compartiment.

Paramètre Format Remarques
--url-u Chaîne d’URL URL du bucket. Formats pris en charge : http://, https://.
--bucket-name Chaîne Nom du bucket à synchroniser.
--bucket-access-key Chaîne ID de clé d’accès utilisé pour s’authentifier auprès du bucket.
--bucket-secret-key Chaîne Clé secrète utilisée pour s’authentifier auprès du bucket.
--bucket-insecure Booléen Communiquez avec un bucket sans TLS. S’il n’est pas fourni, supposé false ; s’il est fourni, supposé vrai.

Arguments sources de compte Stockage Blob Azure

Si vous utilisez la source azblob, voici les arguments de commande spécifiques à l’objet blob.

Paramètre Format Remarques
--url-u Chaîne d’URL URL du azblob.
--container-name Chaîne Nom du conteneur Stockage Blob Azure à synchroniser
--sp_client_id Chaîne Pour cette méthode d'authentification, l'ID client pour l'authentification d’un principal de service avec Azure Blob est requis.
--sp_tenant_id Chaîne ID de tenant pour l’authentification d’un principal du service avec Azure Blob, nécessaire pour cette méthode d’authentification
--sp_client_secret Chaîne Clé secrète client pour l’authentification d’un principal de service avec Azure Blob
--sp_client_cert Chaîne Certificat client encodé en Base64 pour l’authentification d’un principal de service avec Azure Blob
--sp_client_cert_password Chaîne Le mot de passe du certificat client utilisé pour authentifier un principal de service avec Azure Blob
--sp_client_cert_send_chain Chaîne Spécifie s’il faut inclure l’en-tête x5c dans les revendications clientes lors de l’acquisition d’un jeton pour activer l’authentification basée sur le nom de l’objet/l’émetteur pour le certificat client
--account_key Chaîne Clé partagée Azure Blob pour l’authentification
--sas_token Chaîne Jeton SAP Azure Blob pour l’authentification
--managed-identity-client-id Chaîne ID client de l’identité managée pour l’authentification avec Azure Blob

Important

Lorsque vous utilisez l’authentification d’identité managée pour les clusters AKS et la source azblob, l’identité managée doit disposer au moins du rôle Lecteur des données Blob du stockage. L’authentification à l’aide d’une identité managée n’est pas encore disponible pour les clusters Kubernetes avec Azure Arc.

Secret local pour l’authentification avec la source

Vous pouvez utiliser un secret Kubernetes local pour l'authentification avec une source git, bucket ou azBlob. Le secret local doit contenir tous les paramètres d’authentification nécessaires à la source et doit être créé dans le même espace de noms que la configuration flux.

Paramètre Format Remarques
--local-auth-ref--local-ref Chaîne Référence locale à un secret Kubernetes dans l’espace de noms de configuration Flux à utiliser pour l’authentification avec la source.

Pour l’authentification HTTPS, vous créez un secret avec :usernamepassword

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>

Pour l'authentification SSH, vous créez un secret avec les champs identity et 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

Important

Azure DevOps annoncé la dépréciation du SSH-RSA comme méthode de chiffrement prise en charge pour la connexion aux référentiels Azure à l’aide de SSH. Si vous utilisez des clés SSH pour vous connecter aux référentiels Azure dans les configurations flux, nous vous recommandons de passer à des clés RSA-SHA2-256 ou RSA-SHA2-512 plus sécurisées. Pour plus d’informations, consultez dépréciation d’Azure DevOps SSH-RSA.

Dans les deux cas, lorsque vous créez la configuration flux, utilisez --local-auth-ref my-custom-secret à la place des autres paramètres d’authentification :

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

En savoir plus sur l’utilisation d’un secret Kubernetes local avec ces méthodes d’authentification :

Remarque

Si vous avez besoin de Flux pour accéder à la source via votre proxy, vous devez mettre à jour les agents Azure Arc avec les paramètres du proxy. Pour plus d’informations, consultez Se connecter à l’aide d’un serveur proxy sortant.

L'implémentation Git

Pour prendre en charge différents fournisseurs de référentiels qui implémentent Git, Flux peut être configuré pour utiliser l’une des deux bibliothèques Git : go-git ou libgit2. Pour plus d’informations, consultez la documentation Flux.

L’implémentation GitOps de Flux v2 détermine automatiquement la bibliothèque à utiliser pour les dépôts de cloud public :

  • Pour les dépôts GitHub, GitLab et BitBucket, Flux utilise go-git.
  • Pour Azure DevOps et tous les autres référentiels, Flux utilise libgit2.

Pour les dépôts locaux, Flux utilise libgit2.

Kustomization

Kustomization est un paramètre créé pour les configurations Flux qui vous permet de choisir un chemin spécifique dans le référentiel source, qui est réconcilié dans le cluster. Vous n’avez pas besoin de créer un fichier « kustomization.yaml sur ce chemin spécifié. Par défaut, tous les manifestes de ce chemin sont rapprochés. Toutefois, si vous souhaitez avoir une superposition Kustomize pour les applications disponibles sur ce chemin de dépôt, vous devez créer des fichiers Kustomize dans Git pour que la configuration Flux les utilise.

En utilisant az k8s-configuration flux kustomization create, vous pouvez créer une ou plusieurs personnalisations pendant la configuration.

Paramètre Format Remarques
--kustomization Aucune valeur Début d’une chaîne de paramètres qui configurent une kustomization. Vous pouvez l’utiliser plusieurs fois pour créer plusieurs kustomizations.
name Chaîne Nom unique pour cette kustomisation.
path Chaîne Chemin dans le dépôt Git à rapprocher avec le cluster. La valeur par défaut est le niveau supérieur de la branche.
prune Booléen La valeur par défaut est false. Définissez prune=true pour vous assurer que les objets déployés par Flux sur le cluster sont nettoyés s’ils sont supprimés du référentiel ou si la configuration de Flux ou les kustomizations sont supprimés. L’utilisation prune=true est importante pour les environnements où les utilisateurs n’ont pas accès aux clusters et peuvent apporter des modifications uniquement via le référentiel Git.
depends_on Chaîne Nom d’une ou plusieurs kustomisations (dans cette configuration) qui doivent se rapprocher avant que cette kustomisation puisse se rapprocher. Par exemple : depends_on=["kustomization1","kustomization2"]. Si vous supprimez une kustomisation qui a des kustomisations dépendantes, l’état des kustomisations dépendantes devient DependencyNotReadyet la réconciliation s’arrête.
timeout Format de la durée golang Par défaut : 10m.
sync_interval Format de la durée golang Par défaut : 10m.
retry_interval Format de la durée golang Par défaut : 10m.
validation Chaîne Valeurs : none, client, server. Par défaut : none. Consultez la documentation Flux pour plus de détails.
force Booléen Par défaut : false. Définissez force=true pour indiquer au contrôleur kustomize de recréer des ressources en cas d’échec de la mise à jour corrective en raison d’une modification de champ immuable.

Vous pouvez également utiliser az k8s-configuration flux kustomization pour mettre à jour, répertorier, afficher et supprimer des kustomizations dans une configuration flux.

Étapes suivantes