Configurations GitOps Flux v1 pour Kubernetes avec Azure Arc

  • Article

Important

Les documents de cette section sont destinés à GitOps avec Flux v1. GitOps avec Flux v2 est désormais disponible pour les clusters AKS (Azure Kubernetes Service) et Kubernetes avec Azure Arc. Apprenez-en davantage sur GitOps avec Flux v2. Nous vous recommandons d’effectuer une migration 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.

Par rapport à Kubernetes, GitOps permet de déclarer l’état souhaité des configurations de cluster Kubernetes (déploiements, espaces de noms, etc.) dans un référentiel Git. Cette déclaration est suivie d’un déploiement d’interrogation et d’extraction de ces configurations de cluster à l’aide d’un opérateur. Le référentiel Git peut contenir les éléments suivants :

  • Des manifestes au format YAML décrivant toutes sortes de ressources Kubernetes valides, telles que Namespaces, ConfigMaps, Deployments, DaemonSets, etc.
  • Des graphiques Helm pour le déploiement d’applications.

Flux, outil open source populaire dans l’espace GitOps, peut être déployé sur le cluster Kubernetes pour faciliter le flux des configurations entre un dépôt Git et un cluster Kubernetes. Flux prend en charge le déploiement de son opérateur sur les étendues de cluster et d’espace de noms. Un opérateur de flux déployé avec l’étendue d’espace de noms peut uniquement déployer des objets Kubernetes dans cet espace de noms spécifique. La possibilité de choisir entre l’étendue de cluster ou d’espace de noms vous permet d’obtenir des modèles de déploiement mutualisés sur le même cluster Kubernetes.

Configurations

Configurations architecture

La connexion entre votre cluster et un dépôt Git est créée en tant que ressource de configuration (Microsoft.KubernetesConfiguration/sourceControlConfigurations) au-dessus de la ressource Kubernetes avec Azure Arc (représentée par Microsoft.Kubernetes/connectedClusters) dans Azure Resource Manager.

Les propriétés des ressources de configuration permettent de déployer l’opérateur Flux sur le cluster avec les paramètres appropriés, par exemple le dépôt Git à partir duquel tirer les manifestes ainsi que la fréquence d’interrogation de leur extraction. Les données des ressources de configuration sont stockées et chiffrées au repos dans une base de données Azure Cosmos DB pour garantir leur confidentialité.

Le config-agent en cours d’exécution dans votre cluster est responsable des tâches suivantes :

  • Suivi des ressources de configuration nouvelles ou mises à jour sur la ressource Kubernetes avec Azure Arc.
  • Déploiement d’un opérateur Flux pour surveiller chaque ressource de configuration du dépôt Git.
  • Application des mises à jour apportées aux ressources de configuration.

Vous pouvez créer plusieurs ressources de configuration ayant pour étendue un espace de noms sur le même cluster Kubernetes avec Azure Arc pour obtenir une architecture multilocataire.

Remarque

  • config-agent supervise la disponibilité des ressources de configuration nouvelles ou mises à jour sur la ressource Kubernetes avec Azure Arc. Les agents ont donc besoin d’une connectivité pour que l’état souhaité soit extrait vers le cluster. Si les agents ne parviennent pas à se connecter à Azure, il se produit un retard dans la propagation de l’état souhaité vers le cluster.
  • Les entrées de clients sensibles telles que la clé privée, le contenu des hôtes connus, le nom d’utilisateur HTTPS et le jeton/mot de passe ne sont pas stockées au-delà de 48 heures dans les services Kubernetes avec Azure Arc. Si vous utilisez des entrées sensibles pour les configurations, mettez les clusters en ligne aussi régulièrement que possible.

Appliquer des configurations à grande échelle

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 Arc via Azure Policy, dans l’étendue d’un abonnement ou d’un groupe de ressources.

À travers cette mise en œuvre à grande échelle, vous avez la garantie qu’une configuration de base de référence commune (contenant des configurations telles que ClusterRoleBindings, RoleBindings et NetworkPolicy) peut être appliquée à l’ensemble d’une flotte ou d’un inventaire de clusters Kubernetes avec Azure Arc.

Étapes suivantes