Déploiements d’applications avec GitOps (Flux v2) pour AKS et Kubernetes avec Azure Arc

  • Article

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. Les principaux avantages fournis par l’adoption de GitOps pour le déploiement d’applications sur des clusters Kubernetes sont les suivants :

  • Visibilité continue de l’état des applications s’exécutant sur des clusters.
  • Séparation des préoccupations entre les équipes de développement d’applications et les équipes d’infrastructure. Les équipes d’application n’ont pas besoin d’avoir de l’expérience avec les déploiements Kubernetes. Les équipes d’ingénierie de plateforme créent généralement un modèle libre-service pour les équipes d’applications, ce qui leur permet d’exécuter des déploiements en toute confiance.
  • Possibilité de recréer des clusters avec le même état souhaité en cas de blocage ou de scale-out.

Avec GitOps, vous déclarez l’état souhaité de vos clusters Kubernetes dans des fichiers dans des référentiels Git. Les référentiels Git peuvent contenir les fichiers suivants :

Étant donné que ces fichiers sont stockés dans un référentiel Git, ils sont suivis d’une version et les modifications entre les versions sont facilement suivies. Les contrôleurs Kubernetes s’exécutent dans les clusters et réconcilient continuellement l’état du cluster avec l’état souhaité déclaré dans le référentiel Git. Ces opérateurs extraient les fichiers des référentiels Git et appliquent l’état souhaité aux clusters. Les opérateurs garantissent également continuellement que le cluster reste à l’état souhaité.

GitOps sur Azure Kubernetes ou Azure Kubernetes Service utilise Flux, un ensemble d’outils open source populaires. Flux assure la prise en charge des sources de fichiers (dépôts Git et Helm, compartiments, Stockage Blob Azure) et des types de modèles (YAML, Helm et Kustomize) courants. Flux prend également en charge la gestion des dépendances mutualisées et de déploiement, entre autres fonctionnalités.

Flux est déployé directement sur le cluster, et le plan de contrôle de chaque cluster est séparé logiquement. Ceci le rend capable d’être facilement mis à l’échelle à des centaines et des milliers de clusters. Flux permet des déploiements d’applications GitOps basés sur extraction pure. Aucun accès aux clusters n’est nécessaire par le référentiel source ou par tout autre cluster.

Extension de cluster Flux

GitOps est activé dans un cluster Kubernetes avec Arc ou AKS en tant que ressource d’Microsoft.KubernetesConfiguration/extensions/microsoft.fluxextension de cluster. L’extension microsoft.flux doit être installée dans le cluster avant qu’une ou plusieurs fluxConfigurations puisse être créées. L’extension est installée automatiquement lorsque vous créez la première Microsoft.KubernetesConfiguration/fluxConfigurations dans un cluster, ou vous pouvez l’installer manuellement à l’aide du portail, de l’interface de ligne de commande Azure (az k8s-extension create --extensionType=microsoft.flux), du modèle ARM ou de l’API REST.

Contrôleurs

Par défaut, l’extension microsoft.flux installe les contrôleurs Flux (Source, Kustomize, Helm et Notification) et la définition de ressources personnalisée (Custom Resource Definition/CRD) FluxConfig, fluxconfig-agent et fluxconfig-controller. Si vous le souhaitez, vous pouvez également installer les contrôleurs Flux image-automation et image-reflector, qui fournissent des fonctionnalités de mise à jour et de récupération d’images Docker.

  • Contrôleur de source flux: surveille les ressources personnalisées source.toolkit.fluxcd.io. Gère la synchronisation entre les dépôts Git, les dépôts Helm, les compartiments et le stockage Blob Azure. Gère l’autorisation avec la source pour les dépôts privés Git, Helm et les comptes de stockage Blob Azure. Couvre les dernières modifications apportées à la source par le biais d’un fichier d’archive tar.

  • Contrôleur Kustomize de Flux : surveille les ressources personnalisées kustomization.toolkit.fluxcd.io. Applique des fichiers Kustomize ou YAML bruts de la source sur le cluster.

  • Contrôleur Helm de Flux : surveille les ressources personnalisées helm.toolkit.fluxcd.io. Récupère le graphique associé à partir de la source de référentiel Helm exposée par le contrôleur source. Crée la ressource personnalisée HelmChart et applique à HelmRelease la version, le nom et les valeurs définies par le client pour le cluster.

  • Contrôleur de notification de Flux : surveille les ressources personnalisées notification.toolkit.fluxcd.io. Reçoit des notifications de tous les contrôleurs Flux. Transmet les notifications aux points de terminaison de webhook définis par l’utilisateur.

  • Définitions de ressource personnalisées 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

  • FluxConfig CRD : Définition de ressource personnalisée pour fluxconfigs.clusterconfig.azure.com ressources personnalisées qui définissent FluxConfig objets Kubernetes.

  • fluxconfig-agent : responsable de la surveillance d’Azure pour les ressources fluxConfigurations nouvelles ou mises à jour, et pour le démarrage de la configuration Flux associée dans le cluster. Également responsable de l’envoi (push) des modifications d’état de flux dans le cluster vers Azure pour chaque ressource fluxConfigurations .

  • fluxconfig-controller : surveille les ressources personnalisées fluxconfigs.clusterconfig.azure.com et répond aux modifications avec une configuration nouvelle ou mise à jour des machines GitOps dans le cluster.

Remarque

L’extension microsoft.flux est installée dans l’espace de noms flux-system et a étendue à l’échelle du cluster. Vous ne pouvez pas installer cette extension sur une étendue d’espace de noms.

Configurations Flux

Diagramme montrant l’installation d’une configuration Flux dans un cluster Kubernetes avec Azure Arc ou AKS.

Vous créez des ressources de configuration Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) pour activer la gestion GitOps du cluster depuis vos dépôts Git, vos sources de compartiment ou votre Stockage Blob Azure. Lorsque vous créez une ressource fluxConfigurations, les valeurs que vous fournissez pour les paramètres, comme le référentiel Git cible, sont utilisées pour créer et configurer les objets Kubernetes qui activent le processus GitOps dans ce cluster. Pour garantir la sécurité des données, les données de ressources fluxConfigurations sont stockées au repos dans une base de données Azure Cosmos DB par le service de configuration de cluster.

Les agents fluxconfig-agent et fluxconfig-controller, installés avec l’extension microsoft.flux, gèrent le processus de configuration GitOps.

fluxconfig-agent est responsable des tâches suivantes :

  • Interroge le service de plan de données de configuration Kubernetes pour les ressources fluxConfigurations nouvelles ou mises à jour.
  • Crée ou met à jour des ressources personnalisées FluxConfig dans le cluster avec les informations de configuration.
  • Surveille les ressources personnalisées FluxConfig et transmet les modifications d’état aux ressources Azure fluxConfiguration associées.

fluxconfig-controller est responsable des tâches suivantes :

  • Surveille les mises à jour d’état des ressources personnalisées Flux créées par la fluxConfigurations managée.
  • Crée une paire de clés privée/publique qui existe pendant la durée de vie de fluxConfigurations. Cette clé est utilisée pour l’authentification si l’URL est basée sur SSH et si l’utilisateur ne fournit pas sa propre clé privée lors de la création de la configuration.
  • Crée une clé secrète d’authentification personnalisée basée sur des données private-key/http basic-auth/known-hosts/no-auth fournies par l’utilisateur.
  • Configure le contrôle d’accès en fonction du rôle (compte de service approvisionné, liaison de rôle créée/attribué, rôle créé/attribué).
  • Crée une ressource personnalisée GitRepository ou Bucket et des ressources personnalisées Kustomization à partir des informations contenues dans la ressource personnalisée FluxConfig.

Chaque ressource fluxConfigurations dans Azure est associée à une ressource flux GitRepository ou Bucket ressource personnalisée et une ou plusieurs ressources personnalisées Kustomization dans un cluster Kubernetes. Lorsque vous créez une ressource fluxConfigurations , vous spécifiez l’URL vers la source (référentiel Git, Compartiment ou Stockage Blob Azure) et la cible de synchronisation dans la source pour chaque Kustomization. Vous pouvez configurer des dépendances entre des ressources personnalisées Kustomization pour contrôler le séquencement du déploiement. Vous pouvez également créer plusieurs ressources fluxConfigurations étendues à l’espace de noms sur le même cluster pour différentes applications et équipes d’applications.

Remarque

Les moniteurs fluxconfig-agent pour les ressources fluxConfiguration nouvelles ou mises à jour dans Azure. L’agent nécessite une connectivité à Azure pour que l’état souhaité de fluxConfiguration soit appliqué au cluster. Si l’agent ne peut pas se connecter à Azure, les modifications du cluster attendent jusqu’à ce que l’agent puisse se connecter. Si le cluster est déconnecté d’Azure pendant plus de 48 heures, alors la requête adressée au cluster expirera et les modifications devront être réappliquées dans Azure.

Les entrées de clients sensibles telles que la clé privée et le jeton/mot de passe ne sont pas stockées au-delà de 48 heures dans le service de configuration de Kubernetes. Si vous mettez à jour ces valeurs dans Azure, assurez-vous que vos clusters se connectent à Azure dans un délai de 48 heures.

Vous pouvez surveiller l’état et la conformité de la configuration flux dans le portail Azure, ou utiliser des tableaux de bord pour surveiller l’état, la conformité, la consommation des ressources et l’activité de rapprochement. Pour plus d’informations, consultez Surveiller l’état et l’activité GitOps (Flux v2).

Prise en charge de la version

La version la plus récente de l’extension Flux v2 (microsoft.flux) et les deux versions précédentes (N-2) sont prises en charge. Nous vous recommandons généralement d’utiliser la version la plus récente de l’extension. À compter de microsoft.flux version 1.7.0, les clusters ARM64 sont pris en charge.

Remarque

Si vous utilisez Flux v1, nous vous recommandons de migrer vers Flux v2 dès que possible.

La prise en charge des ressources de configuration du cluster basées sur Flux v1, créées avant le 1er janvier 2024, s’achève le 24 mai 2025. À compter du 1er janvier 2024, vous ne pouvez plus créer de ressources de configuration de cluster basées sur Flux v1.

Si vous avez ajouté la prise en charge de la liaison privée à un cluster Kubernetes avec Azure Arc, l’extension microsoft.flux fonctionne telle quelle pour la communication vers Azure. Pour les connexions à votre référentiel Git, référentiel Helm ou tout autre point de terminaison nécessaire pour déployer vos manifestes Kubernetes, vous devez provisionner ces points de terminaison derrière votre pare-feu, ou les répertorier sur votre pare-feu afin que le contrôleur de source de flux puisse les atteindre correctement.

Résidence des données

Le service Azure GitOps (Azure Kubernetes Configuration Management) stocke/traite les données client. Par défaut, les données client sont répliquées dans la région jumelée. Pour les régions Singapour, Asie Est et Brésil Sud, toutes les données des clients sont stockées et traitées dans la région.

Appliquer des configurations à grande échelle Flux

Dans la mesure où Azure Resource Manager gère vos configurations, vous pouvez automatiser la création d’une configuration identique sur toutes les ressources Kubernetes avec Azure Kubernetes Service et Azure Arc via Azure Policy, dans l’étendue d’un abonnement ou d’un groupe de ressources. Cette application à grande échelle garantit que des configurations spécifiques sont appliquées de manière cohérente entre les groupes entiers de clusters.

Pour plus d’informations, consultez Déployez des applications de manière cohérente à l’échelle à l’aide de configurations Flux v2 et Azure Policy.

Paramètres

Pour consulter tous les paramètres pris en charge par Flux v2 dans Azure, consultez la Documentation az k8s-configuration. L’implémentation Azure ne prend actuellement pas en charge chaque paramètre pris en charge par Flux.

Pour plus d’informations sur les paramètres disponibles et leur utilisation, consultez paramètres pris en charge par GitOps (Flux v2).

Multilocation

Flux v2 prend en charge la multilocation à partir de la version 0.26. Cette capacité est intégrée à Flux v2 dans Azure.

Remarque

En ce qui concerne la fonctionnalité multilocataire, vous devez savoir si vous disposez d’une sourceRef multi-espace de noms pour HelmRelease, Kustomization, ImagePolicy ou d’autres objets, ou si vous utilisez une version Kubernetes antérieure à 1.20.6. Pour préparer :

  • Effectuez une mise à niveau vers Kubernetes version 1.20.6 ou ultérieure.
  • Dans vos manifestes Kubernetes, vérifiez que toutes les sourceRef portent sur des objets se trouvant dans le même espace de noms que la configuration GitOps.
    • Si vous avez besoin de temps pour mettre à jour vos manifestes, vous pouvez désactiver la multilocation. Toutefois, vous devez quand même mettre à niveau votre version Kubernetes.

Mettre à jour les manifestes pour la multilocation

Supposons que vous déployez une fluxConfiguration vers l’un de nos clusters Kubernetes dans l’espace de noms cluster-config avec l’étendue du cluster. Vous configurez la source pour synchroniser le dépôt https://github.com/fluxcd/flux2-kustomize-helm-example. Il s’agit du même exemple de référentiel Git utilisé dans le Déployer des applications à l’aide de GitOps avec le didacticiel Flux v2.

Une fois que Flux synchronisé le dépôt, il déploie les ressources décrites dans les manifestes (fichiers YAML). Deux des manifestes décrivent les objets HelmRelease et 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

Par défaut, l’extension Flux déploie fluxConfigurations en empruntant l’identité du compte de service flux-applier déployé uniquement dans l’espace de noms cluster-config. En utilisant les manifestes ci-dessus, lorsque la multilocation est activée, le HelmRelease sera bloqué. Cela est dû au fait que le HelmRelease se trouve dans l’espace de noms nginx, mais il fait référence à un HelmRepository dans l’espace de noms flux-system. En outre, le helm-controller Flux ne peut pas appliquer le HelmRelease car il n’existe aucun compte de service flux-applier dans l’espace de noms nginx.

Pour travailler avec la multilocation, l’approche correcte consiste à déployer tous les objets Flux dans le même espace de noms que le fluxConfigurations. Cette approche évite le problème lié aux références entre espaces de noms, et permet aux contrôleurs Flux d’obtenir les autorisations nécessaires pour appliquer les objets. Par conséquent, pour une configuration GitOps créée dans l’espace de noms cluster-config, ces exemples de manifestes changeraient comme suit :

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

Refuser la multilocation

Lorsque l’extension microsoft.flux est installée, la multilocation est activée par défaut. Si vous devez désactiver la multilocation, vous pouvez la refuser en créant ou en mettant à jour l’extension microsoft.flux dans vos clusters avec --configuration-settings multiTenancy.enforce=false, comme indiqué dans ces exemples de commandes :

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>

Migrer à partir de Flux v1

Si vous utilisez toujours Flux v1, nous vous recommandons de migrer vers Flux v2 dès que possible.

Pour migrer vers l’utilisation de Flux v2 dans les mêmes clusters que ceux que vous utilisez Flux v1, vous devez d’abord supprimer tout flux v1 sourceControlConfigurations des clusters. Étant donné que Flux v2 a une architecture fondamentalement différente, l’extension de cluster microsoft.flux n’est pas installée s’il existe des ressources flux v1 sourceControlConfigurations dans un cluster. Le processus de suppression des configurations Flux v1 et le déploiement de configurations Flux v2 ne doivent pas prendre plus de 30 minutes.

La suppression de flux v1 sourceControlConfigurations n’arrête aucune application qui s’exécute sur les clusters. Toutefois, pendant la période où la configuration de Flux v1 est supprimée et que l’extension Flux v2 n’est pas encore entièrement déployée :

  • S’il existe de nouvelles modifications dans les manifestes d’application stockés dans un référentiel Git, ces modifications ne sont pas extraites pendant la migration et la version de l’application déployée sur le cluster sera obsolète.
  • S’il existe des modifications involontaires dans l’état du cluster et qu’il s’écarte de l’état souhaité spécifié dans le référentiel Git source, le cluster ne pourra pas guérir automatiquement.

Nous vous recommandons de tester votre scénario de migration dans un environnement de développement avant de migrer votre environnement de production.

Afficher et supprimer des configurations Flux v1

Utilisez ces commandes Azure CLI pour rechercher puis supprimer des éléments sourceControlConfigurations existants dans 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>

Vous pouvez également afficher et supprimer des configurations GitOps existantes pour un cluster dans le Portail Azure. Pour ce faire, accédez au cluster où la configuration a été créée et sélectionnez GitOps dans le volet gauche. Sélectionnez la configuration puis sélectionnez Supprimer.

Déployer des configurations Flux v2

Utilisez le portail Azure ou Azure CLI pour appliquer des configurations Flux v2 à vos clusters.

Informations de mise hors service flux v1

Le projet open source de Flux v1 a été archivé et développement de fonctionnalités s’est arrêté indéfiniment.

Flux v2 a été lancé en tant que projet open source mis à niveau de Flux. Il a une nouvelle architecture et prend en charge davantage de cas d’usage GitOps. Microsoft a lancé une version d’une extension à l’aide de Flux v2 en mai 2022. Depuis lors, les clients ont été invités à passer à Flux v2 dans un délai de trois ans, car la prise en charge de l’utilisation de Flux v1 est prévue pour se terminer en mai 2025.

Nouvelles fonctionnalités clés introduites dans l’extension GitOps pour Flux v2 :

  • Flux v1 est un opérateur monolithique do-it-all. Flux v2 sépare les fonctionnalités en contrôleurs spécialisés (contrôleur source, contrôleur Kustomize, contrôleur Helm et contrôleur de notification).
  • Prend en charge la synchronisation avec plusieurs référentiels sources.
  • Prend en charge multilocataire, comme l’application de chaque référentiel source avec son propre ensemble d’autorisations.
  • Fournit des insights opérationnels par le biais de contrôles d’intégrité, d’événements et d’alertes.
  • Prend en charge les branches Git, l’épinglage sur les validations et les balises, ainsi que les plages d’étiquettes SemVer suivantes.
  • Configuration des informations d’identification par ressource GitRepository : clé privée SSH, nom d’utilisateur/mot de passe/jeton HTTP/S et clés publiques OpenPGP.

Étapes suivantes