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

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.
  • Possibilité de déployer des applications à grande échelle via Azure Policy.

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 multilocataire et des dépendances 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.

Important

Il n’existe aucun frais pour les déploiements Flux sur Azure Kubernetes Service (AKS), AKS Edge Essentials ou AKS activé par Azure Arc sur Azure Local. Pour les autres distributions Kubernetes connectées via Kubernetes avec Azure Arc, aucun frais n’est facturé pour les déploiements flux sur les six premiers processeurs virtuels de votre abonnement. Les frais s’appliquent ensuite en fonction du nombre de processeurs virtuels par cluster. Pour plus d’informations, consultez la tarification d’Azure Arc.

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.

Controllers

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. 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: Surveille Azure pour les ressources nouvelles ou mises à jour fluxConfigurations et démarre la configuration de Flux associée dans le cluster. Il transmet également les modifications d’état flux dans le cluster vers Azure pour chaque fluxConfigurations ressource.

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

Pour télécharger des diagrammes d’architecture en haute résolution, visitez Jumpstart Gems.

Créez des ressources de configuration Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) afin de permettre la gestion GitOps du cluster depuis vos dépôts Git, sources de Bucket ou 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, le service Configuration du cluster stocke les fluxConfigurations données de ressources chiffrées au repos dans une base de données Azure Cosmos DB.

Les agents fluxconfig-agent et fluxconfig-controller, installés à l’aide de 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 fluxConfigurations ressource, 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, la demande adressée au cluster expire et les modifications doivent ê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. Utilisez la version la plus récente de l’extension. À compter de microsoft.flux version 1.7.0, les clusters ARM64 sont pris en charge.

Si vous avez ajouté la prise en charge de Private Link à un cluster Kubernetes compatible Azure Arc, l’microsoft.fluxextension microsoft.flux fonctionne prête à l’emploi avec une 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 flux puisse les atteindre.

Résidence des données

Le service Azure GitOps (Azure Kubernetes Configuration Management) stocke et 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

Étant donné qu’Azure Resource Manager gère vos configurations, vous pouvez automatiser la création de la même configuration sur toutes les ressources Kubernetes Service Azure et Kubernetes avec Azure Arc à l’aide d’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).

Mutualisation

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

Remarque

Pour la fonctionnalité de multi-tenant, vérifiez si vos manifestes contiennent des sourceRef inter-espaces de noms pour HelmRelease, Kustomization, ImagePolicy ou d’autres objets, ou si vous utilisez une version de Kubernetes infé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éployiez un fluxConfiguration sur l’un de vos clusters Kubernetes dans l’espace de noms cluster-config avec une portée au niveau 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/v2
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 précédents, lorsque la fonctionnalité de multi-tenant est activée, le HelmRelease est bloqué. Ce bloc se produit parce que le HelmRelease est situé dans l'espace de noms nginx, mais fait référence à un HelmRepository dans l'espace de noms flux-system. En outre, le Flux helm-controller ne peut pas appliquer le HelmRelease, car il n’existe pas de compte de service flux-applier dans l’espace de noms nginx.

Pour travailler avec la fonctionnalité de multi-tenant, déployez 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 le namespace cluster-config, ces exemples de manifestes changent de la manière suivante :

apiVersion: helm.toolkit.fluxcd.io/v2
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 vous installez l’extension microsoft.flux, le multi-tenancy est activé par défaut. Pour désactiver la fonctionnalité de multi-tenant, désinscrivez-vous 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>

Étapes suivantes

  • Last updated on