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

  • Article

Azure fournit une fonctionnalité de déploiements d’applications automatisés à l’aide de GitOps qui fonctionne avec des clusters Azure Kubernetes Service (AKS) et Kubernetes avec Azure Arc. GitOps avec Flux v2 vous permet d’utiliser votre dépôt Git comme source de vérité pour la configuration de clusters 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 très répandu qui prend en charge de nombreux paramètres pour divers 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-configurationdocumentation. 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 commande az k8s-configuration flux create. Vous pouvez également voir la liste complète des paramètres de az k8s-configuration flux à l’aide du paramètre -h dans Azure CLI (par exemple, az k8s-configuration flux -h ou az k8s-configuration flux create -h).

Conseil

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) dans votre dépôt Git. Déployez ces ressources avec la commande az k8s-configuration flux create. Vous serez alors toujours en mesure d'accéder à vos ressources Flux via l'interface utilisateur Azure Arc.

Arguments généraux de configuration

Paramètre Format Notes
--cluster-name -c Chaîne Nom de la ressource de cluster dans Azure.
--cluster-type -t Valeurs autorisées : connectedClusters, managedClusters Utilisez connectedClusters pour les clusters Kubernetes activés par 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 Le nom de la configuration du Flux dans Azure.
--namespace --ns Chaîne Nom de l’espace de noms pour le déploiement de la configuration. Par défaut : default.
--scope -s Chaîne Étendue d’autorisation pour les opérateurs. Les valeurs possibles sont cluster (accès total) ou namespace (accès restreint). Par défaut : cluster.
--suspend flag Interrompt toutes les réconciliations de source et de kustomize définies dans cette configuration de Flux. Les réconciliations actives au moment de la suspension se poursuivront.

Arguments généraux de la source

Paramètre Format Notes
--kind Chaîne Type de source à rapprocher. Valeurs autorisées : bucket, git, azblob. Par défaut : git.
--timeout Format de la durée golang Délai maximal de tentative de réconciliation de la source avant le dépassement du délai d’attente. Valeur par défaut : 10m.
--sync-interval --interval Format de la durée golang Délai entre les réconciliations 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 Notes
--branch Chaîne Branche au sein de la source Git à synchroniser avec le cluster. Par défaut : master. Les référentiels plus récents ont 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 Étiquette 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 de référentiel Git.

Utiliser un référentiel Git public

Paramètre Format Notes
--url -u http[s]://server/repo[.git] URL de la source du référentiel Git à rapprocher 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.

Référentiel Git privé avec des clés créées par SSH et Flux

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

Paramètre Format Notes
--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.

Référentiel Git privé avec SSH et des clés fournies par l’utilisateur

Fournissez votre propre clé privée directement ou dans un fichier. La clé doit être au format PEM et se terminer par un saut de ligne (\n).

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

Paramètre Format Notes
--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é base 64 au format PEM Fournissez la clé directement.
--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é au format PEM

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

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

Tout comme les clés privées, vous pouvez fournir le contenu known_hosts directement ou dans un fichier. Quand vous fournissez votre propre contenu, utilisez les spécifications de format de contenu known_hosts ainsi que l’un des scénarios relatifs aux clés SSH ci-dessus.

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

Référentiel Git privé avec un utilisateur et une clé HTTPS

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

Référentiel Git privé avec un utilisateur et un certificat HTTPS

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

Arguments de la source Bucket

Si vous utilisez la source bucket, voici les arguments de commande propres aux compartiments.

Paramètre Format Notes
--url -u Chaîne d’URL URL de la source bucket. Formats pris en charge : http://, https://.
--bucket-name Chaîne Nom de la source bucket à synchroniser.
--bucket-access-key Chaîne ID de clé d’accès utilisé pour l’authentification auprès de la source bucket.
--bucket-secret-key Chaîne Clé secrète utilisée pour l’authentification auprès de la source bucket.
--bucket-insecure Boolean Communiquer avec une source bucket sans TLS. S’il n’est pas fourni, la valeur par défaut est false. S’il est fourni, la valeur par défaut est true.

Arguments sources des comptes Stockage Blob Azure

Si vous utilisez la source azblob, voici les arguments de commande propres aux objets blob.

Paramètre Format Notes
--url -u Chaîne d’URL URL de la source azblob.
--container-name Chaîne Nom du conteneur Stockage Blob Azure à synchroniser
--sp_client_id Chaîne ID client pour l’authentification d’un principal de service avec Azure Blob, requis pour cette méthode d’authentification
--sp_tenant_id Chaîne ID locataire pour l’authentification d’un principal de service avec Azure Blob, requis 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 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 être au moins affectée au 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 auprès de la source

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

Paramètre Format Notes
--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 auprès de la source.

Pour l’authentification HTTPS, vous créez un secret avec username et 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>

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 de 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

Apprenez-en davantage 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.

Implémentation Git

Pour prendre en charge différents fournisseurs de référentiel 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 référentiels de cloud publics :

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

Pour les référentiels 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 dépôt source qui est rapproché dans le cluster. Vous n’avez pas besoin de créer de 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.

À l’aide de az k8s-configuration flux kustomization create, vous pouvez créer un ou plusieurs kustomizations au cours de la configuration.

Paramètre Format Notes
--kustomization Aucune valeur Début d’une chaîne de paramètres qui configurent un kustomization. Vous pouvez l’utiliser plusieurs fois pour créer plusieurs kustomizations.
name Chaîne Nom unique pour ce kustomization.
path Chaîne URL de la source du dépôt Git à rapprocher avec le cluster. La valeur par défaut est le niveau supérieur de la branche.
prune Boolean La valeur par défaut est false. Le paramètre prune=true garantit que les objets que Flux a déployés sur le cluster sont nettoyés s’ils sont supprimés du dépôt ou si la configuration Flux ou les kustomizations sont supprimés. L’utilisation de 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’un ou plusieurs kustomizations (dans cette configuration) qui doivent être conciliés avant que ce kustomization puisse être concilié. Par exemple : depends_on=["kustomization1","kustomization2"]. Si vous supprimez un kustomization qui a des kustomizations dépendants, le kustomization dépendant prend l’état DependencyNotReady et le rapprochement 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 d'informations.
force Boolean Par défaut : false. Définir force=true pour indiquer au contrôleur kustomize de recréer les ressources lorsque la mise à jour corrective échoue en raison d’une modification de champ immuable.

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

Étapes suivantes