Tutoriel : Déployer des applications à l’aide de GitOps avec Flux v2

Ce didacticiel explique comment utiliser GitOps dans un cluster Kubernetes. GitOps avec Flux v2 est activé en tant qu’extension de cluster dans les clusters Kubernetes avec Azure Arc ou les clusters Azure Kubernetes Service (AKS). Une fois l'microsoft.fluxextension de cluster installée, vous pouvez créer une ou plusieurs ressources fluxConfigurations qui synchronisent vos sources de référentiel git sur le cluster et rapprochent le cluster de l’état souhaité. Avec GitOps, vous pouvez utiliser votre référentiel git comme source de vérité pour la configuration du cluster et le déploiement d’applications.

Dans ce tutoriel, nous utilisons un exemple de configuration GitOps avec deux kustomizations, afin de voir comment une kustomization peut avoir une dépendance sur une autre. Vous pouvez ajouter d’autres kustomisations et dépendances en fonction des besoins, en fonction de votre scénario.

Avant de vous plonger dans, prenez un moment pour découvrir comment fonctionne GitOps avec Flux.

Conseil

Bien que la source de ce tutoriel soit un dépôt Git, Flux prend également en charge d’autres sources de fichiers courantes, comme des dépôts Helm, des fragments et Stockage Blob Azure.

Vous pouvez également créer des configurations Flux à l’aide de Bicep, de modèles ARM ou d’un fournisseur Terraform AzAPI. Pour plus d’informations, consultez Microsoft.KubernetesConfiguration fluxConfigurations.

Important

L’extension microsoft.flux a publié la version principale 1.0.0. Elle inclut la fonctionnalité de prise en charge multilocataire. Si vous avez des configurations GitOps Flux v2 existantes qui utilisent une version précédente de l’extension microsoft.flux, vous pouvez mettre à niveau vers la version la plus récente manuellement en utilisant Azure CLI : az k8s-extension create -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux --extension-type microsoft.flux -t <CLUSTER_TYPE> (utilisez -t connectedClusters pour les clusters Arc et -t managedClusters pour les clusters AKS).

Prérequis

Pour déployer des applications à l’aide de GitOps avec Flux v2, il vous faut :

Azure CLI

Pour les clusters Kubernetes avec Azure Arc

• Un cluster Kubernetes connecté à Azure Arc qui est en cours d’exécution. Les clusters ARM64 sont pris en charge à compter de microsoft.flux version 1.7.0.

  Découvrez comment connecter un cluster Kubernetes à Azure Arc. Si vous devez vous connecter via un proxy sortant, veillez à installer les agents Arc avec les paramètres de proxy.

• Autorisations de lecture et d’écriture sur le groupe de ressources Microsoft.Kubernetes/connectedClusters.

Pour les clusters Azure Kubernetes Service (AKS)

• Un cluster AKS basé sur une identité de service managée (MSI) qui est en cours d’exécution.

  Important

  Assurez-vous que le cluster AKS est créé avec MSI (et non SPN), car l'extensionmicrosoft.flux ne fonctionne pas avec les clusters AKS basés sur SPN. Pour les nouveaux clusters AKS créés avec az aks create, le cluster est basé sur MSI par défaut. Pour les clusters SPN déjà créés qui doivent être convertis en MSI, exécutez az aks update -g $RESOURCE_GROUP -n $CLUSTER_NAME --enable-managed-identity. Pour plus d’informations, consultez Utiliser une identité managée dans AKS.

• Autorisations de lecture et d’écriture sur le groupe de ressources Microsoft.ContainerService/managedClusters.

Commun aux deux types de cluster

• Autorisations de lecture et d’écriture sur ces types de ressources :

  • Microsoft.KubernetesConfiguration/extensions
  • Microsoft.KubernetesConfiguration/fluxConfigurations

• Azure CLI, version 2.15 ou ultérieure. Installez Azure CLI ou utilisez les commandes suivantes pour effectuer une mise à jour vers la dernière version :

  az version
  az upgrade
  

• Le client de ligne de commande Kubernetes, kubectl. Si vous utilisez Azure Cloud Shell, kubectl est déjà installé.

  Installez kubectl en local avec la commande az aks install-cli :

  az aks install-cli
  

• Inscription des fournisseurs de ressources Azure suivants :

  az provider register --namespace Microsoft.Kubernetes
  az provider register --namespace Microsoft.ContainerService
  az provider register --namespace Microsoft.KubernetesConfiguration
  

  L’inscription est un processus asynchrone qui doit se terminer dans un délai de 10 minutes. Pour superviser le processus d’inscription, utilisez la commande suivante :

  az provider show -n Microsoft.KubernetesConfiguration -o table
  
  Namespace                          RegistrationPolicy    RegistrationState
  ---------------------------------  --------------------  -------------------
  Microsoft.KubernetesConfiguration  RegistrationRequired  Registered
  

Prise en charge des versions et des régions

GitOps est actuellement pris en charge dans toutes les régions prises en charge par Kubernetes avec Azure Arc. GitOps est actuellement pris en charge dans un sous-ensemble des régions prises en charge par AKS. Le service GitOps ajoute de nouvelles régions prises en charge sur une cadence régulière.

La version la plus récente de l’extension Flux v2 et les deux versions précédentes (N-2) sont prises en charge. Nous recommandons généralement d’utiliser la version la plus récente de l’extension.

Configuration requise pour le réseau

Les agents GitOps nécessitent le protocole TCP sortant (sortie) vers la source du référentiel sur le port 22 (SSH) ou le port 443 (HTTPS) pour fonctionner. Les agents requièrent également accès aux URL sortantes suivantes :

Point de terminaison (DNS)	Description
https://management.azure.com	Requis pour que l’agent communique avec le service de configuration Kubernetes.
https://<region>.dp.kubernetesconfiguration.azure.com	Point de terminaison du plan de données permettant à l’agent d’envoyer (push) le statut et de récupérer (fetch) les informations de configuration. Dépend de <region> (les régions prises en charge mentionnées précédemment).
https://login.microsoftonline.com	Requis pour extraire et mettre à jour des jetons Azure Resource Manager.
https://mcr.microsoft.com	Requis pour extraire des images conteneurs pour les contrôleurs de Flux.

Activer les extensions CLI

Installez les derniers packages d’extension CLI k8s-configuration et k8s-extension :

az extension add -n k8s-configuration
az extension add -n k8s-extension

Pour mettre à jour ces packages vers les dernières versions :

az extension update -n k8s-configuration
az extension update -n k8s-extension

Pour afficher une liste des extensions Azure CLI installées et leurs versions, utilisez la commande suivante :

az extension list -o table

Experimental   ExtensionType   Name                   Path                                                       Preview   Version
-------------  --------------  -----------------      -----------------------------------------------------      --------  --------
False          whl             connectedk8s           C:\Users\somename\.azure\cliextensions\connectedk8s         False     1.2.7
False          whl             k8s-configuration      C:\Users\somename\.azure\cliextensions\k8s-configuration    False     1.5.0
False          whl             k8s-extension          C:\Users\somename\.azure\cliextensions\k8s-extension        False     1.1.0

Conseil

Pour obtenir de l’aide sur la résolution des erreurs, consultez la section GitOps (Flux v2) de Résoudre les problèmes d’extension pour les clusters Kubernetes avec Azure Arc.

Azure portal

Pour les clusters Kubernetes avec Azure Arc

• Un cluster Kubernetes connecté à Azure Arc qui est en cours d’exécution. Les clusters ARM64 sont pris en charge à compter de microsoft.flux version 1.7.0.

  Découvrez comment connecter un cluster Kubernetes à Azure Arc. Si vous devez vous connecter via un proxy sortant, veillez à installer les agents Arc avec les paramètres de proxy.

• Autorisations de lecture et d’écriture sur le groupe de ressources Microsoft.Kubernetes/connectedClusters.

Pour les clusters Azure Kubernetes Service (AKS)

• Un cluster AKS basé sur une identité de service managée (MSI) qui est en cours d’exécution.

  Important

  Assurez-vous que le cluster AKS est créé avec MSI (et non SPN), car l'extensionmicrosoft.flux ne fonctionne pas avec les clusters AKS basés sur SPN. Pour les nouveaux clusters AKS créés avec az aks create, le cluster est basé sur MSI par défaut. Pour les clusters SPN déjà créés qui doivent être convertis en MSI, exécutez az aks update -g $RESOURCE_GROUP -n $CLUSTER_NAME --enable-managed-identity. Pour plus d’informations, consultez Utiliser une identité managée dans AKS.

• Autorisations de lecture et d’écriture sur le groupe de ressources Microsoft.ContainerService/managedClusters.

Commun aux deux types de cluster

• Autorisations de lecture et d’écriture sur ces types de ressources :

  • Microsoft.KubernetesConfiguration/extensions
  • Microsoft.KubernetesConfiguration/fluxConfigurations

• Inscription des fournisseurs de ressources Azure suivants :

  • Microsoft.ContainerService
  • Microsoft.Kubernetes
  • Microsoft.KubernetesConfiguration

Prise en charge des versions et des régions

GitOps est actuellement pris en charge dans toutes les régions prises en charge par Kubernetes avec Azure Arc. GitOps est actuellement pris en charge dans un sous-ensemble des régions prises en charge par AKS. Le service GitOps ajoute de nouvelles régions prises en charge sur une cadence régulière.

La version la plus récente de l’extension Flux v2 et les deux versions précédentes (N-2) sont prises en charge. Nous recommandons généralement d’utiliser la version la plus récente de l’extension.

Configuration requise pour le réseau

Les agents GitOps nécessitent le protocole TCP sortant (sortie) vers la source du référentiel sur le port 22 (SSH) ou le port 443 (HTTPS) pour fonctionner. Les agents requièrent également accès aux URL sortantes suivantes :

Point de terminaison (DNS)	Description
https://management.azure.com	Requis pour que l’agent communique avec le service de configuration Kubernetes.
https://<region>.dp.kubernetesconfiguration.azure.com	Point de terminaison du plan de données permettant à l’agent d’envoyer (push) le statut et de récupérer (fetch) les informations de configuration. Dépend de <region> (les régions prises en charge mentionnées précédemment).
https://login.microsoftonline.com	Requis pour extraire et mettre à jour des jetons Azure Resource Manager.
https://mcr.microsoft.com	Requis pour extraire des images conteneurs pour les contrôleurs de Flux.

Appliquez une configuration Flux

Utilisez l'extension k8s-configuration d’Azure CLI (ou le portail Azure) pour activer GitOps dans un cluster KUBERNETES AKS ou Arc. Pour une démonstration, utilisez le référentiel gitops-flux2-kustomize-helm-mt public.

Important

Le référentiel de démonstration est conçu pour simplifier votre utilisation de ce didacticiel et illustrer certains principes clés. Pour rester à jour, le référentiel peut obtenir des changements cassants occasionnellement à partir des mises à niveau de version. Ces modifications n’affectent pas votre nouvelle application de ce didacticiel, mais uniquement les applications de didacticiel précédentes qui n’ont pas été supprimées. Pour savoir comment gérer ces changements, consultez l’exclusion de responsabilité des changements cassants.

Azure CLI

L’exemple suivant utilise la commande az k8s-configuration create pour appliquer une configuration Flux à un cluster, à l’aide des valeurs et paramètres suivants :

• Le groupe de ressources qui contient le cluster est flux-demo-rg :
• Le nom du cluster Azure Arc est flux-demo-arc.
• Le type de cluster est Azure Arc (-t connectedClusters), mais cet exemple fonctionne également avec AKS (-t managedClusters).
• Le nom de la configuration du Flux estcluster-config.
• L’espace de noms pour l’installation de la configuration est cluster-config.
• L’URL du référentiel Git public esthttps://github.com/Azure/gitops-flux2-kustomize-helm-mt.
• La branche du référentiel Git est main.
• La portée de la configuration est cluster. Cette étendue donne aux opérateurs les autorisations nécessaires pour apporter des modifications à l’ensemble du cluster. Pour utiliser l’étendue namespace avec ce didacticiel, consultez les modifications nécessaires.
• Deux kustomizations sont spécifiées avec des nomsinfra et apps. Chacune est associée à un chemin d’accès dans le référentiel.
• La kustomization apps dépend de la kustomization infra. (La kustomization infra doit se terminer avant l'exécution de la kustomization apps.)
• Définir prune=true sur les deux kustomizations. Ce paramètre garantit que les objets que Flux a déployés sur le cluster seront nettoyés s’ils sont supprimés du référentiel ou si la configuration Flux ou les kustomizations sont supprimées.

az k8s-configuration flux create -g flux-demo-rg \
-c flux-demo-arc \
-n cluster-config \
--namespace cluster-config \
-t connectedClusters \
--scope cluster \
-u https://github.com/Azure/gitops-flux2-kustomize-helm-mt \
--branch main  \
--kustomization name=infra path=./infrastructure prune=true \
--kustomization name=apps path=./apps/staging prune=true dependsOn=\["infra"\]

L’extension microsoft.flux est installée sur le cluster (si elle n’était pas déjà installée dans un déploiement GitOps précédent).

Conseil

La commande az k8s-configuration create déploie l’extension microsoft.flux sur le cluster et crée la configuration. Dans certains scénarios, vous pouvez créer l’extension de flux instance séparément avant de créer vos ressources de configuration. Pour ce faire, utilisez la az k8s-extension create commande pour créer un instance de l’extension sur votre cluster.

Lorsque la configuration du flux est installée d’abord, l’état de conformité initial peut être Pending ou Non-compliant, car le rapprochement est toujours en cours. Au bout d’une minute environ, vous pouvez interroger à nouveau la configuration pour voir l’état de conformité final.

az k8s-configuration flux show -g flux-demo-rg -c flux-demo-arc -n cluster-config -t connectedClusters

Pour vérifier que le déploiement a réussi, exécutez la commande suivante :

az k8s-configuration flux show -g flux-demo-rg -c flux-demo-arc -n cluster-config -t connectedClusters

Un déploiement réussi crée les espaces de noms suivants :

• flux-system : Contient les contrôleurs d’extension de Flux.
• cluster-config : Contient les objets de configuration de Flux.
• nginx, podinfo, redis : Espaces de noms pour les charges de travail décrites dans manifestes dans le référentiel Git.

Pour confirmer les espaces de noms, exécutez la commande suivante :

kubectl get namespaces

L'espace de noms flux-system contient les objets d’extension de Flux :

• Contrôleurs Azure Flux : fluxconfig-agent, fluxconfig-controller
• Contrôleurs OSS Flux : source-controller, kustomize-controller, helm-controller, notification-controller

L'agent Flux et les pods du contrôleur doivent être en état de fonctionnement. Confirmez cela à l’aide de la commande suivante :

kubectl get pods -n flux-system

NAME                                      READY   STATUS    RESTARTS   AGE
fluxconfig-agent-9554ffb65-jqm8g          2/2     Running   0          21m
fluxconfig-controller-9d99c54c8-nztg8     2/2     Running   0          21m
helm-controller-59cc74dbc5-77772          1/1     Running   0          21m
kustomize-controller-5fb7d7b9d5-cjdhx     1/1     Running   0          21m
notification-controller-7d45678bc-fvlvr   1/1     Running   0          21m
source-controller-df7dc97cd-4drh2         1/1     Running   0          21m

L’espace de nomscluster-config contient les objets de configuration de Flux.

kubectl get crds

NAME                                                   CREATED AT
alerts.notification.toolkit.fluxcd.io                  2022-04-06T17:15:48Z
arccertificates.clusterconfig.azure.com                2022-03-28T21:45:19Z
azureclusteridentityrequests.clusterconfig.azure.com   2022-03-28T21:45:19Z
azureextensionidentities.clusterconfig.azure.com       2022-03-28T21:45:19Z
buckets.source.toolkit.fluxcd.io                       2022-04-06T17:15:48Z
connectedclusters.arc.azure.com                        2022-03-28T21:45:19Z
customlocationsettings.clusterconfig.azure.com         2022-03-28T21:45:19Z
extensionconfigs.clusterconfig.azure.com               2022-03-28T21:45:19Z
fluxconfigs.clusterconfig.azure.com                    2022-04-06T17:15:48Z
gitconfigs.clusterconfig.azure.com                     2022-03-28T21:45:19Z
gitrepositories.source.toolkit.fluxcd.io               2022-04-06T17:15:48Z
helmcharts.source.toolkit.fluxcd.io                    2022-04-06T17:15:48Z
helmreleases.helm.toolkit.fluxcd.io                    2022-04-06T17:15:48Z
helmrepositories.source.toolkit.fluxcd.io              2022-04-06T17:15:48Z
imagepolicies.image.toolkit.fluxcd.io                  2022-04-06T17:15:48Z
imagerepositories.image.toolkit.fluxcd.io              2022-04-06T17:15:48Z
imageupdateautomations.image.toolkit.fluxcd.io         2022-04-06T17:15:48Z
kustomizations.kustomize.toolkit.fluxcd.io             2022-04-06T17:15:48Z
providers.notification.toolkit.fluxcd.io               2022-04-06T17:15:48Z
receivers.notification.toolkit.fluxcd.io               2022-04-06T17:15:48Z
volumesnapshotclasses.snapshot.storage.k8s.io          2022-03-28T21:06:12Z
volumesnapshotcontents.snapshot.storage.k8s.io         2022-03-28T21:06:12Z
volumesnapshots.snapshot.storage.k8s.io                2022-03-28T21:06:12Z
websites.extensions.example.com                        2022-03-30T23:42:32Z

Confirmez d’autres détails de la configuration à l’aide des commandes suivantes.

kubectl get fluxconfigs -A

NAMESPACE        NAME             SCOPE     URL                                                       PROVISION   AGE
cluster-config   cluster-config   cluster   https://github.com/Azure/gitops-flux2-kustomize-helm-mt   Succeeded   44m

kubectl get gitrepositories -A

NAMESPACE        NAME             URL                                                       READY   STATUS                                                            AGE
cluster-config   cluster-config   https://github.com/Azure/gitops-flux2-kustomize-helm-mt   True    Fetched revision: main/4f1bdad4d0a54b939a5e3d52c51464f67e474fcf   45m

kubectl get helmreleases -A

NAMESPACE        NAME      READY   STATUS                             AGE
cluster-config   nginx     True    Release reconciliation succeeded   66m
cluster-config   podinfo   True    Release reconciliation succeeded   66m
cluster-config   redis     True    Release reconciliation succeeded   66m

kubectl get kustomizations -A


NAMESPACE        NAME                   READY   STATUS                                                            AGE
cluster-config   cluster-config-apps    True    Applied revision: main/4f1bdad4d0a54b939a5e3d52c51464f67e474fcf   65m
cluster-config   cluster-config-infra   True    Applied revision: main/4f1bdad4d0a54b939a5e3d52c51464f67e474fcf   65m

Les charges de travail sont déployées à partir de manifestes dans le référentiel Git.

kubectl get deploy -n nginx

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
nginx-ingress-controller                   1/1     1            1           67m
nginx-ingress-controller-default-backend   1/1     1            1           67m

kubectl get deploy -n podinfo

NAME      READY   UP-TO-DATE   AVAILABLE   AGE
podinfo   1/1     1            1           68m

kubectl get all -n redis

NAME                 READY   STATUS    RESTARTS   AGE
pod/redis-master-0   1/1     Running   0          68m

NAME                     TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service/redis-headless   ClusterIP   None          <none>        6379/TCP   68m
service/redis-master     ClusterIP   10.0.13.182   <none>        6379/TCP   68m

NAME                            READY   AGE
statefulset.apps/redis-master   1/1     68m

Contrôler les contrôleurs déployés avec l’extension de cluster Flux

Pour certains scénarios, vous souhaiterez peut-être modifier les contrôleurs Flux qui sont installés avec l’extension de cluster Flux.

Les contrôleurs de Flux source, helm, kustomize et notificationsont installés par défaut. Les contrôleurs image-automation etimage-reflector, utilisés pour mettre à jour un référentiel Git lorsque de nouvelles images conteneur sont disponibles, doivent être activés explicitement.

Vous pouvez utiliser la commande k8s-extension pour modifier les options par défaut :

• --config source-controller.enabled=<true/false> (par défauttrue)
• --config helm-controller.enabled=<true/false> (par défauttrue)
• --config kustomize-controller.enabled=<true/false> (par défauttrue)
• --config notification-controller.enabled=<true/false> (par défauttrue)
• --config image-automation-controller.enabled=<true/false> (par défautfalse)
• --config image-reflector-controller.enabled=<true/false> (par défautfalse)

Par exemple, pour désactiver les notifications, vous pouvez définir notification-controller.enabled sur false.

Cet exemple de commande installe les contrôleurs image-reflector et image-automation. Si l’extension de Flux a été créée automatiquement lors de la création de la configuration de Flux, le nom de l’extension sera flux .

az k8s-extension create -g <cluster_resource_group> -c <cluster_name> -t <connectedClusters or managedClusters or provisionedClusters> --name flux --extension-type microsoft.flux --config image-automation-controller.enabled=true image-reflector-controller.enabled=true

Utilisation d’une identité Kubelet comme méthode d’authentification pour les clusters AKS

Pour des clusters AKS, l’une des options d’authentification à utiliser est l’identité kubelet. Par défaut, AKS crée sa propre identité kubelet dans le groupe de ressources managé. Si vous préférez, vous pouvez utiliser une identité managée kubelet précréée. Pour ce faire, ajoutez le paramètre --config useKubeletIdentity=true au moment de l’installation de l’extension Flux.

az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config useKubeletIdentity=true

Conseils d’intégration Red Hat OpenShift

Les contrôleurs de flux nécessitent une contrainte de contexte de sécuriténon racine pour approvisionner correctement les pods sur le cluster. Ces contraintes doivent être ajoutées au cluster avant l’intégration de l’extension microsoft.flux.

NS="flux-system"
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:kustomize-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:helm-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:source-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:notification-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:image-automation-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:image-reflector-controller

Pour plus d’informations sur les conseils d’OpenShift pour l’intégration de Flux, consultez la documentation Flux.

Azure portal

Le Portail Azure est utile pour gérer les configurations de GitOps et l’extension de Flux dans les clusters Kubernetes ou AKS compatibles avec Azure Arc. Dans le Portail Azure, vous pouvez voir toutes les configurations flux associées à chaque cluster et obtenir des informations détaillées, notamment l’état de conformité globale de chaque cluster.

Notes

Certaines options ne sont actuellement pas prises en charge dans le Portail Azure. Consultez les étapes d’Azure CLI pour obtenir des options supplémentaires, notamment la suspension du rapprochement continu, le contrôle des contrôleurs déployés avec l’extension de cluster Flux et l’utilisation de l’identité Kubelet comme méthode d’authentification pour les clusters AKS.

Suivez ces étapes pour appliquer un exemple de configuration Flux à un cluster. Dans le cadre de ce processus, Azure installe l’extension microsoft.flux sur le cluster, si elle n’a pas déjà été installée en raison d’un déploiement précédent.

1. Accédez à votre cluster sur le Portail Azure.

2. Sous Paramètres dans le volet gauche, sélectionnez GitOps.

3. Cliquez sur Créer.

   

4. Dans la section Bases :

   1. Entrez un nom pour la configuration.
   2. Entrez l’espace de noms dans lequel les ressources personnalisées Flux seront installées. Il peut s’agir d’un espace de noms existant ou d’un nouvel espace de noms qui sera créé lors du déploiement de la configuration.
   3. Sous Étendue, sélectionnez Cluster afin que l’opérateur Flux ait accès pour appliquer la configuration à tous les espaces de noms du cluster. Pour utiliser l’étendue namespace avec ce didacticiel, consultez les modifications nécessaires.
   4. Sélectionnez Suivant pour passer à la section Source.

   

5. Dans la section Source :

   1. Dans Type de source, sélectionnez Référentiel Git.
   2. Entrez l’URL du référentiel où se trouvent les manifestes Kubernetes : https://github.com/Azure/gitops-flux2-kustomize-helm-mt.
   3. Pour le type de référence, sélectionnez Branche. Laissez Branche définie sur principale.
   4. Pour le Type de référentiel, sélectionnez Public.
   5. Laissez les autres options définies par défaut, puis sélectionnez Suivant.

   

6. Dans la section Kustomizations, vous créez deux kustomizations : infrastructure et staging. Ces kustomizations sont des ressources Flux, chacune associée à un chemin dans le référentiel représentant l’ensemble des manifestes que Flux doit rapprocher du cluster.

   1. Sélectionnez Create (Créer).

   2. Dans l’écran Créer une Kustomization :

      1. Pour le Nom de l’instance, entrez infrastructure.

      2. Pour Chemin d’accès, entrez ./infrastructure.

      3. Cochez la case Élaguer. Ce paramètre garantit que les objets que le flux déployé sur le cluster seront nettoyés s’ils sont supprimés du référentiel ou si la configuration Flux ou les kustomizations sont supprimés.

      4. Laissez les autres options telles qu’elles sont, puis sélectionnez Enregistrer pour créer la kustomisation infrastructure.

         

   3. Vous verrez la kustomisation infrastructure dans la section Kustomizations. Pour créer la kustomisation suivante, sélectionnez Créer.

   4. Dans l’écran Créer une Kustomization :

      1. Pour le Nom de l’instance, entrez mise en lots.

      2. Pour le Chemin d'accès, entrez ./apps/staging.

      3. Cochez la case Élaguer.

      4. Dans la zone Dépend de, sélectionnez Infrastructure.

      5. Laissez les autres options telles qu’elles sont, puis sélectionnez Enregistrer pour créer la kustomisation staging.

         

   5. Vous devez maintenant voir les deux kustomizations affichées dans la section Kustomizations. Sélectionnez Suivant pour continuer.

7. Passez en revue les options que vous avez sélectionnées dans les étapes précédentes. Sélectionnez ensuite Créer pour terminer la création de votre configuration GitOps.

Affichez les configurations et les objets

Pour afficher toutes les configurations d’un cluster, accédez au cluster et sélectionnez GitOps dans le volet gauche.

Sélectionnez le nom d’une configuration pour afficher plus de détails tels que l’état, les propriétés et la source de la configuration. Vous pouvez ensuite sélectionner Objets de configuration pour afficher tous les objets qui ont été créés pour activer la configuration GitOps. Cela vous permet de voir rapidement l’état de conformité et d’autres détails sur chaque objet.

Pour voir les autres ressources Kubernetes déployées sur le cluster, revenez à la page de vue d’ensemble du cluster et sélectionnez Ressources Kubernetes dans le volet gauche.

Pour afficher les conditions détaillées d’un objet de configuration, sélectionnez son nom.

Pour plus d’informations, consultez Surveiller l’état et l’activité GitOps (Flux v2).

Utiliser des paramètres

Flux 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. Flux dans Azure ne prend pas encore en charge tous les paramètres. Faites-nous savoir si un paramètre dont vous avez besoin est manquant dans l’implémentation d’Azure.

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

Gérer la configuration du cluster à l’aide du contrôleur Flux Kustomize

Le contrôleur Flux Kustomize est installé dans le cadre de l'extension de cluster microsoft.flux. Il permet la gestion déclarative de la configuration du cluster et le déploiement d’applications à l’aide de manifestes Kubernetes synchronisés à partir d’un référentiel Git. Ces manifestes Kubernetes peuvent éventuellement inclure un fichier kustomize.yaml .

Pour plus d’informations d’utilisation, consultez les ressources suivantes :

• Contrôleur flux Kustomize
• Documents de référence Kustomize
• Fichier kustomization
• Projet Kustomize
• Guides Kustomize

Gérer les versions du graphique Helm à l'aide du contrôleur Flux Helm

Le contrôleur Flux Helm est installé dans le cadre de l'extension microsoft.flux de cluster. Il vous permet de gérer de façon déclarative les versions du graphique Helm avec les manifestes Kubernetes que vous gérez dans votre référentiel Git.

Pour plus d’informations d’utilisation, consultez les ressources suivantes :

• Flux pour les utilisateurs Helm
• Gérer les versions Helm
• Migrer vers Flux v2 Helm à partir de Flux v1 Helm
• Contrôleur Flux Helm

Conseil

En raison de la façon dont Helm gère les fichiers d’index, le traitement des graphiques Helm est une opération coûteuse et peut avoir une empreinte mémoire très élevée. Par conséquent, le rapprochement d’un grand nombre de graphiques Helm à la fois peut entraîner des pics de mémoire et des erreursOOMKilled. Par défaut, le contrôleur définit sa limite de mémoire à 1 Gi et ses demandes de mémoire à 64 Mi. Pour augmenter cette limite et les demandes en raison d’un nombre élevé de rapprochements de graphiques Helm volumineux, exécutez la commande suivante après avoir installé l’extension microsoft.flux :

az k8s-extension update -g <resource-group> -c <cluster-name> -n flux -t connectedClusters --config source-controller.resources.limits.memory=2Gi source-controller.resources.requests.memory=300Mi

Utiliser la source GitRepository pour des graphiques Helm

Si vos graphiques Helm sont stockés dans la source GitRepository que vous configurez dans le cadre de la ressource fluxConfigurations, vous pouvez indiquer que la source configurée doit être utilisée comme source des graphiques Helm en ajoutant clusterconfig.azure.com/use-managed-source: "true" à votre fichier HelmRelease.yaml, comme le montre l’exemple suivant :

---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: somename
  namespace: somenamespace
  annotations:
    clusterconfig.azure.com/use-managed-source: "true"
spec:
  ...

Lorsque vous utilisez cette annotation, le HelmRelease déployé est corrigé avec la référence à la source configurée. Actuellement, seule la source GitRepository est prise en charge.

Détection de la dérive Helm

La détection de dérive pour les versions Helm n’est pas activée par défaut. À partir de microsoft.flux v1.7.5, vous pouvez activer la détection de dérive Helm en exécutant la commande suivante :

az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --name flux --cluster-type <cluster-type> --config helm-controller.detectDrift=true 

Espion OOM Helm

À partir de microsoft.flux v1.7.5, vous pouvez activer l’espion OOM Helm. Pour plus d’informations, consultez Activer Helm près de la détection OOM.

Veillez à passer en revue les stratégies de correction potentielles et à les appliquer si nécessaire lors de l’activation de cette fonctionnalité.

Pour activer l’espion OOM, exécutez la commande suivante :

az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --name flux --cluster-type <cluster-type> --config helm-controller.outOfMemoryWatch.enabled=true helm-controller.outOfMemoryWatch.memoryThreshold=70 helm-controller.outOfMemoryWatch.interval=700ms

Si vous ne spécifiez pas de valeurs pour memoryThreshold et outOfMemoryWatch, le seuil de mémoire par défaut est défini sur 95 %, l’intervalle dont il faut vérifier l’utilisation de la mémoire est défini sur 500 ms.

Identité de charge de travail dans les clusters AKS

À compter de microsoft.fluxv1.8.0, vous pouvez créer des configurations Flux dans clusters AKS avec l’identité de charge de travail activée. Pour ce faire, modifiez l’extension de flux comme indiqué dans les étapes suivantes.

1. Récupérez l’URL de l’émetteur OIDC pour votre cluster.

2. Créez une identité managée et notez son ID client.

3. Créez l’extension de flux sur le cluster à l’aide de la commande suivante :

   az k8s-extension create --resource-group <resource_group_name> --cluster-name <aks_cluster_name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config workloadIdentity.enable=true workloadIdentity.azureClientId=<user_assigned_client_id>
   

4. Établissez une informations d’identification d’identité fédérée. Par exemple :

   # For source-controller
   az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"flux-system":"source-controller" --audience api://AzureADTokenExchange
   
   # For image-reflector controller if you plan to enable it during extension creation, it is not deployed by default
   az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"flux-system":"image-reflector-controller" --audience api://AzureADTokenExchange
   

5. Vérifiez que la ressource personnalisée qui doit utiliser l’identité de charge de travail a défini .spec.provider valeur sur azure dans le manifeste. Par exemple :

   apiVersion: source.toolkit.fluxcd.io/v1beta2
   kind: HelmRepository
   metadata:
     name: acrrepo
   spec:
     interval: 10m0s
     type: <helm_repository_type>
     url: <helm_repository_link>
     provider: azure
   

6. Veillez à fournir les autorisations appropriées pour l’identité de charge de travail pour la ressource que vous souhaitez que le contrôleur source-contrôleur ou le contrôleur de réflexion d’image extrait. Par exemple, si vous utilisez Azure Container Registry, AcrPull les autorisations sont requises.

Supprimer la configuration et l’extension flux

Utilisez les commandes suivantes pour supprimer votre configuration Flux et, si vous le souhaitez, l’extension Flux elle-même.

Azure CLI

Supprimer la configuration Flux

La commande suivante supprime à la fois la ressource fluxConfigurations dans Azure et les objets de configuration Flux dans le cluster. Étant donné que la configuration de Flux a été créée à l’origine avec le paramètre prune=true pour kustomization, tous les objets créés dans le cluster en fonction des manifestes dans le référentiel git seront supprimés lors de la suppression de la configuration de Flux. Toutefois, cette commande ne supprime pas l’extension Flux elle-même.

az k8s-configuration flux delete -g flux-demo-rg -c flux-demo-arc -n cluster-config -t connectedClusters --yes

Supprimer l’extension de cluster de Flux

Lorsque vous supprimez l’extension Flux, la ressource d’extension microsoft.flux dans Azure et les objets d’extension Flux dans le cluster sont supprimés.

Important

Veillez à supprimer toutes les configurations flux dans le cluster avant de supprimer l’extension Flux. La suppression de l’extension sans supprimer d’abord les configurations flux peut laisser votre cluster dans une condition instable.

Si l’extension de Flux a été créée automatiquement lors de la création de la configuration de Flux, le nom de l’extension sera flux .

az k8s-extension delete -g flux-demo-rg -c flux-demo-arc -n flux -t connectedClusters --yes

Conseil

Ces commandes utilisent -t connectedClusters, qui est approprié pour un cluster Kubernetes avec Azure Arc. Pour un cluster AKS, utilisez -t managedClusters à la place.

Azure portal

Supprimer la configuration Flux

Pour supprimer une configuration Flux, accédez au cluster où la configuration a été créée et sélectionnez GitOps dans le volet gauche. Sélectionnez la configuration que vous souhaitez supprimer. En haut de la page, sélectionnez Supprimer, puis sélectionnez à nouveau Supprimer lorsque vous êtes invité(e) à confirmer.

Lorsque vous supprimez une configuration Flux, tous les objets de configuration Flux du cluster seront également supprimés. Néanmoins, cette action ne supprime pas l'extension microsoft.flux elle-même.

Supprimer l’extension de cluster de Flux

Lorsque vous supprimez l’extension Flux, la ressource d’extension microsoft.flux dans Azure et les objets d’extension Flux dans le cluster sont supprimés.

Important

Veillez à supprimer toutes les configurations flux dans le cluster avant de supprimer l’extension Flux. La suppression de l’extension sans supprimer d’abord les configurations flux peut laisser votre cluster dans une condition instable.

Pour un cluster Kubernetes avec Azure Arc, accédez au cluster et sélectionnez Extensions. Sélectionnez l’extension flux, sélectionnez Désinstaller, puis confirmez la suppression.

Pour les clusters AKS, vous ne pouvez pas utiliser le Portail Azure pour supprimer l’extension. Utilisez plutôt la commande Azure CLI suivante :

az k8s-extension delete -g <resource-group> -c <cluster-name> -n flux -t managedClusters --yes

Étapes suivantes

• En savoir plus sur les configurations et GitOps.
• Découvrez comment utiliser Azure Policy pour appliquer GitOps à grande échelle.
• En savoir plus sur Surveiller l’état et l’activité GitOps (Flux v2).