Partager via

Migrer votre charge de travail de Service Fabric vers AKS

  • Article

De nombreuses organisations se déplacent vers des applications conteneurisées dans le cadre d’une poussée vers l’adoption des meilleures pratiques de développement d’applications modernes, de meilleures pratiques de maintenance et d’architectures natives cloud. Étant donné que les technologies continuent d’évoluer, les organisations doivent évaluer les nombreuses plateformes d’application conteneurisées disponibles dans le cloud public.

Il n’existe pas de solution universelle pour les applications, mais les organisations constatent souvent que Azure Kubernetes Service (AKS) répond aux exigences de la plupart de leurs applications en conteneur. AKS est un service Kubernetes managé qui simplifie les déploiements d’applications via Kubernetes en gérant le plan de contrôle pour fournir des services de base pour les charges de travail d’application. De nombreuses organisations utilisent AKS comme plateforme d’infrastructure principale et les charges de travail de transition hébergées sur d’autres plateformes vers AKS.

Cet article explique comment migrer des applications en conteneur d’Azure Service Fabric vers AKS. L’article suppose que vous êtes familiarisé avec Service Fabric, mais que vous souhaitez découvrir comment ses fonctionnalités et ses fonctionnalités se comparent à celles d’AKS. L’article fournit également les meilleures pratiques à prendre en compte lors de la migration.

Comparaison d’AKS à Service Fabric

Pour commencer, passez en revue Choisir un service de calcul Azure, ainsi que d’autres services de calcul Azure. Cette section met en évidence les similitudes et les différences notables qui concernent la migration.

Service Fabric et AKS sont des orchestrateurs de conteneurs. Service Fabric prend en charge plusieurs modèles de programmation, mais AKS prend uniquement en charge les conteneurs.

  • Modèles de programmation : Service Fabric prend en charge plusieurs façons d’écrire et de gérer vos services, notamment les conteneurs Linux et Windows, Reliable Services, Reliable Actors, ASP.NET Core et les exécutables invités.

  • Conteneurs sur AKS : AKS prend uniquement en charge la conteneurisation avec des conteneurs Windows et Linux qui s’exécutent sur le conteneur d’exécution de conteneur, qui est géré automatiquement.

Service Fabric et AKS fournissent des intégrations avec d’autres services Azure, notamment Azure Pipelines, Azure Monitor, Azure Key Vault et Microsoft Entra ID.

Différences clés

Lorsque vous déployez un cluster Service Fabric traditionnel, au lieu d’un cluster managé, vous devez définir explicitement une ressource de cluster avec de nombreuses ressources de prise en charge dans vos modèles Azure Resource Manager (modèles ARM) ou les modules Bicep. Ces ressources incluent un groupe de machines virtuelles identiques pour chaque type de nœud de cluster, groupes de sécurité réseau et équilibreurs de charge. Il est de votre responsabilité de vous assurer que ces ressources sont correctement configurées. En revanche, le modèle d’encapsulation pour les clusters managés Service Fabric se compose d’une seule ressource de cluster managée. Toutes les ressources sous-jacentes pour le cluster sont extraites et managées par Azure en votre nom.

AKS simplifie le déploiement d’un cluster Kubernetes managé dans Azure en déchargeant la surcharge opérationnelle sur Azure. AKS étant un service Kubernetes hébergé, Azure gère des tâches critiques telles que l’analyse de l’intégrité et la maintenance de l’infrastructure. Azure gère les nœuds principaux Kubernetes. Vous devez donc gérer et gérer les nœuds de l’agent uniquement.

Pour déplacer votre charge de travail de Service Fabric vers AKS, vous devez comprendre les différences dans l’infrastructure sous-jacente afin de pouvoir migrer en toute confiance vos applications conteneurisées. Le tableau suivant compare les fonctionnalités des deux plateformes d’hébergement.

Fonctionnalité ou composant Service Fabric AKS
Applications non conteneurisées Oui Non
Conteneurs Windows et Linux Oui Oui
Plan de contrôle géré par Azure Non Oui
Prise en charge des charges de travail sans état et avec état Oui Oui
Emplacement du nœud Worker Virtual Machine Scale Sets, client configuré Virtual Machine Scale Sets, géré par Azure
Manifeste de configuration XML YAML
Intégration d’Azure Monitor Oui Oui
Prise en charge native du modèle Reliable Services et Reliable Actor Oui Non
Pile de communication WCF pour Reliable Services Oui Non
Stockage persistant Pilote de volume Azure Files Prise en charge de différents systèmes de stockage, tels que les disques managés, les Azure Files et les Stockage Blob Azure via des classes de stockage CSI, des revendications de volume persistant et de volume persistant
Modes réseau Intégration du Réseau virtuel Azure Prise en charge de plusieurs plug-ins réseau (Azure CNI, Kubenet, BYOCNI), de stratégies réseau (Azure, Calico) et de contrôleurs d’entrée (Application Gateway contrôleur d’entrée, NGINX, etc.)
Contrôleurs d’entrée Proxy inverse intégré à Service Fabric. Le proxy inverse Service Fabric permet aux microservices exécutés dans un cluster Service Fabric de découvrir d’autres services dotés de points de terminaison http et de communiquer avec ces services. Vous pouvez également utiliser Traefik sur Service Fabric Contrôleur d’entrée NGINX managé, entrée BYO code source ouvert et contrôleurs commerciaux qui utilisent des équilibreurs de charge publics ou internes gérés par la plateforme, comme le contrôleur d’entrée NGINX et le contrôleur d’entrée Application Gateway

Remarque

Si vous utilisez des conteneurs Windows sur Service Fabric, nous vous recommandons de les utiliser sur AKS pour faciliter votre migration.

Étapes de la migration

En général, les étapes de migration de Service Fabric vers AKS sont les suivantes.

Diagramme montrant les étapes de migration de Service Fabric vers AKS.

  1. Établissez l’architecture de déploiement et créez le cluster AKS. AKS fournit différentes options pour configurer l’accès au cluster, l’extensibilité des nœuds et des pods, l’accès réseau et la configuration, etc. Pour plus d’informations sur une architecture de déploiement classique, consultez Exemple d’architecture. L’architecture de base AKS fournit également des instructions de déploiement et de surveillance de cluster. La construction AKS fournit des modèles de démarrage rapide pour déployer votre cluster AKS en fonction des exigences métier et techniques.

  2. Réarchitecte l’application Service Fabric. Si vous utilisez des modèles de programmation tels que Reliable Services ou Reliable Actors, ou si vous utilisez d’autres constructions spécifiques à Service Fabric, vous devrez peut-être réorganiser votre application. Pour implémenter la gestion de l’état lorsque vous migrez à partir de Reliable Services, utilisez Distributed Application Runtime (Dapr). Kubernetes fournit des modèles et des exemples pour la migration à partir de Reliable Actors.

  3. Empaqueter l’application en tant que conteneurs. Visual Studio fournit des options pour générer le fichier Dockerfile et empaqueter l’application en tant que conteneurs. Envoyez (push) les images conteneur que vous créez vers Azure Container Registry.

  4. Réécrire les fichiers XML de configuration Service Fabric en tant que fichiers YAML Kubernetes. Vous déployez l’application sur AKS à l’aide de fichiers YAML ou en tant que package à l’aide de graphiques Helm. Pour plus d’informations, consultez le manifeste d’application et de service.

  5. Déployez l’application sur un cluster AKS.

  6. Déplacez le trafic vers le cluster AKS en fonction de vos stratégies de déploiement et surveillez le comportement, la disponibilité et les performances de l’application.

Exemple d'architecture

AKS et Azure offrent la flexibilité nécessaire pour configurer votre environnement en fonction des besoins de votre entreprise. AKS s’intègre parfaitement aux autres services Azure. L’architecture de base AKS est un exemple.

Diagramme montrant une architecture de base AKS.

En guise de point de départ, familiarisez-vous avec certains concepts Kubernetes clés, puis passez en revue quelques exemples d’architectures :

Notes

Lorsque vous migrez une charge de travail de Service Fabric vers AKS, vous pouvez remplacer Service Fabric Reliable Actors par le bloc de construction Acteurs Dapr. Vous pouvez remplacer Service Fabric Reliable Collections par le bloc de gestion de l’état Dapr.

Dapr fournit des API qui simplifient la connectivité de microservice. Pour plus d’informations, consultez Présentation de Dapr. Nous vous recommandons d’installer Dapr en tant qu’extension AKS.

Manifeste d’application et de service

Service Fabric et AKS ont différents types et constructions de fichiers manifeste d’application et de service. Service Fabric utilise des fichiers XML pour la définition d’application et de service. AKS utilise le manifeste de fichier YAML Kubernetes pour définir des objets Kubernetes. Il n’existe aucun outil spécifiquement destiné à migrer un fichier XML Service Fabric vers un fichier YAML Kubernetes. Toutefois, vous pouvez en savoir plus sur le fonctionnement des fichiers YAML sur Kubernetes en examinant les ressources suivantes.

Vous pouvez utiliser Helm pour définir des manifestes YAML paramétrés et créer des modèles génériques en remplaçant les valeurs statiques, codées en dur par des espaces réservés que vous pouvez remplacer par des valeurs personnalisées fournies au moment du déploiement. Les modèles résultants qui contiennent les valeurs personnalisées sont rendus sous forme de manifestes valides pour Kubernetes.

Kustomize introduit un moyen sans modèle de personnaliser la configuration de l’application qui simplifie l’utilisation d’applications prêtes à l’emploi. Vous pouvez utiliser Kustomize avec Helm ou comme alternative à Helm.

Pour plus d’informations sur Helm et Kustomize, consultez les ressources suivantes :

Mise en réseau

AKS fournit deux options pour le réseau sous-jacent :

  • Apportez votre propre réseau virtuel Azure pour approvisionner les nœuds de cluster AKS dans un sous-réseau à partir d’un réseau virtuel que vous fournissez.

  • Laissez le fournisseur de ressources AKS créer un réseau virtuel Azure pour vous dans le groupe de ressources de nœud qui contient toutes les ressources Azure qu’un cluster utilise.

Si vous choisissez la deuxième option, Azure gère le réseau virtuel.

Service Fabric ne propose pas de plug-ins réseau. Si vous utilisez AKS, vous devez choisir l’une des options suivantes :

  • Kubenet. Avec Kubenet, les nœuds obtiennent une adresse IP du sous-réseau du réseau virtuel Azure. Les pods reçoivent une adresse IP à partir d’un espace d’adressage qui est logiquement différent de celui du sous-réseau de réseau virtuel Azure des nœuds. La traduction d’adresses réseau (NAT) est ensuite configurée afin que les pods puissent accéder aux ressources sur le réseau virtuel Azure. L’adresse IP source du trafic est traduite en adresse IP principale du nœud. Cette approche réduit considérablement le nombre d’adresses IP que vous devez réserver dans votre espace réseau pour que les pods les utilisent.

  • Azure CNI. Si vous utilisez l’interface CNI (Container Networking Interface), chaque pod obtient une adresse IP à partir du sous-réseau et est accessible directement. Ces adresses IP doivent être uniques dans votre espace réseau et doivent être planifiées à l’avance. Chaque nœud possède un paramètre de configuration pour le nombre maximal de pods qu’il prend en charge. Vous réservez ensuite le nombre équivalent d’adresses IP pour chaque nœud. Cette approche nécessite davantage de planification. De plus, elle conduit souvent à l’épuisement des adresses IP ou à la nécessité de regénérer les clusters dans un sous-réseau plus vaste à mesure que vos demandes d’applications augmentent. Vous pouvez configurer le nombre maximal de pods pouvant être déployés sur un nœud lorsque vous créez le cluster ou lorsque vous créez des pools de nœuds.

  • Réseau de superposition Azure CNI. Si vous utilisez la superposition Azure CNI, les nœuds de cluster sont déployés dans un sous-réseau Azure Réseau virtuel. Les pods reçoivent des adresses IP attribuées à partir d’un CIDR privé qui sont logiquement différentes de l’adresse du réseau virtuel qui héberge les nœuds. Le trafic de pod et de nœud au sein du cluster utilise un réseau de superposition. NAT utilise l’adresse IP du nœud pour atteindre les ressources en dehors du cluster. Cette solution enregistre un nombre important d’adresses IP de réseau virtuel et vous aide à mettre à l’échelle votre cluster en toute transparence à de grandes tailles. Un avantage supplémentaire est que le CIDR privé peut être réutilisé dans différents clusters AKS, étendant réellement l’espace IP disponible pour les applications conteneurisées dans AKS.

  • Azure CNI avec Cilium. Azure CNI optimisé par Cilium combine le plan de contrôle robuste d’Azure CNI avec le plan de données de Cilium pour fournir une mise en réseau haute performance et une sécurité renforcée.

  • Utiliser votre propre plug-in CNI. Kubernetes ne fournit pas de système d’interface réseau par défaut. Cette fonctionnalité est fournie par les plug-ins réseau. AKS fournit plusieurs plug-ins CNI pris en charge. Pour plus d’informations sur les plug-ins pris en charge, consultez Concepts réseau pour les applications dans AKS.

Actuellement, les conteneurs Windows prennent uniquement en charge le plug-in Azure CNI. Différents choix pour les stratégies réseau et les contrôleurs d’entrée sont disponibles.

Dans AKS, vous pouvez utiliser des stratégies réseau pour séparer et sécuriser les communications intra-service en contrôlant les composants qui peuvent communiquer entre eux. Par défaut, tous les pods d’un cluster Kubernetes peuvent envoyer et recevoir du trafic sans aucune limite. Pour améliorer la sécurité, vous pouvez utiliser les stratégies réseau Azure ou les stratégies réseau Calico pour définir des règles qui contrôlent le flux de trafic entre les différents microservices.

Pour utiliser Azure Network Policy Manager, vous devez utiliser le plug-in Azure CNI. Vous pouvez utiliser des stratégies réseau Calico avec le plug-in Azure CNI ou le plug-in kubenet CNI. L’utilisation d’Azure Network Policy Manager pour les nœuds Windows est prise en charge uniquement sur Windows Server 2022. Pour plus d’informations, consultez Sécuriser le trafic entre les pods avec des stratégies réseau dans AKS. Pour plus d’informations sur la mise en réseau AKS, consultez Mise en réseau dans AKS.

Dans Kubernetes, un contrôleur d’entrée fait office de proxy de service et d’intermédiaire entre un service et le monde extérieur, ce qui permet au trafic externe d’accéder au service. Le proxy de service fournit généralement diverses fonctionnalités telles que l’arrêt TLS, le routage des requêtes basée sur le chemin d’accès, l’équilibrage de charge et les fonctionnalités de sécurité telles que l’authentification et l’autorisation. Les contrôleurs d’entrée fournissent également une autre couche d’abstraction et de contrôle pour le routage du trafic externe vers les services Kubernetes en fonction des règles HTTP et HTTPS. Cette couche fournit un contrôle plus précis sur le flux de trafic et la gestion du trafic.

Dans AKS, il existe plusieurs options de déploiement, d’exécution et d’exploitation d’un contrôleur d’entrée. L’une des options est le contrôleur d’entrée Application Gateway, qui vous permet d’utiliser Azure Application Gateway comme contrôleur d’entrée pour l’arrêt TLS, le routage basé sur le chemin et en tant que pare-feu d’accès web. Une autre option est le contrôleur d’entrée NGINX managé, qui fournit l’option gérée par Azure pour le contrôleur d’entrée NGINX largement utilisé. Le contrôleur d’entrée Traefik est un autre contrôleur d’entrée populaire pour Kubernetes.

Chacun de ces contrôleurs d’entrée présente des forces et des faiblesses. Pour déterminer celui à utiliser, tenez compte des exigences de l’application et de l’environnement. Veillez à utiliser la dernière version de Helm et à avoir accès au référentiel Helm approprié lorsque vous installez un contrôleur d’entrée non managé.

Stockage persistant

Service Fabric et AKS ont tous deux des mécanismes pour fournir un stockage persistant aux applications conteneurisées. Dans Service Fabric, le pilote de volume Azure Files, qui est un plug-in de volume Docker, fournit des volumes Azure Files pour les conteneurs Linux et Windows. Il se trouve dans un package en tant qu’application Service Fabric pouvant être déployée sur un cluster Service Fabric pour fournir des volumes pour d’autres applications de conteneur Service Fabric au sein du cluster. Pour plus d’informations, consultez Pilote de volume Azure Files pour Service Fabric.

Les applications qui s’exécutent dans AKS peuvent avoir besoin de stocker et de récupérer des données à partir d’un système de stockage de fichiers persistant. AKS s’intègre aux services de stockage Azure tels que les disques managés Azure, Azure Files, Stockage Blob et Azure NetApp Storage (ANF). Il s’intègre également à des systèmes de stockage non Microsoft tels que Rook et GlusterFS via des pilotes CSI (Container Storage Interface).

CSI est une norme pour exposer des systèmes de stockage de blocs et de fichiers à des charges de travail en conteneur sur Kubernetes. Les fournisseurs de stockage non-Microsoft qui utilisent CSI peuvent écrire, déployer et mettre à jour des plug-ins pour exposer de nouveaux systèmes de stockage dans Kubernetes, ou pour améliorer ceux existants, sans avoir à modifier le code Kubernetes principal et attendre ses cycles de publication.

La prise en charge du pilote de stockage CSI sur AKS vous permet d’utiliser en mode natif ces services de stockage Azure :

  • Disques Azure. Utilisez Disques Azure pour créer une ressource DataDisk Kubernetes. Les disques peuvent utiliser le stockage Premium Azure soutenu par des disques SSD hautes performances ou un stockage Standard Azure soutenu par des disques DURS ou des DISQUES SSD standard standard. Pour la plupart des charges de travail de production et de développement, utilisez le Stockage Premium. Les disques Azure sont montés avec le mode ReadWriteOnce et ne sont disponibles que pour un seul nœud dans AKS. Pour les volumes de stockage auxquels plusieurs pods peuvent accéder simultanément, utilisez Azure Files.

    En revanche, Service Fabric prend en charge la création d’un cluster ou d’un type de nœud qui utilise des disques managés, mais pas les applications qui créent dynamiquement des disques managés attachés via une approche déclarative. Pour plus d’informations, consultez Déployer un type de nœud de cluster Service Fabric avec des disques de données managés.

  • Azure Files. Vous pouvez utiliser Azure Files pour monter un partage SMB 3.0 ou 3.1 pris en charge par un compte Stockage Azure sur des pods. Avec Azure Files, vous pouvez partager des données entre plusieurs nœuds et pods. Azure Files peut utiliser un Stockage Standard Azure, assorti de disques HDD standard, ou un Stockage Premium Azure, assorti de disques SSD haute performance.

    Service Fabric fournit un pilote de volume Azure Files en tant que plug-in de volume Docker qui fournit des volumes Azure Files pour les conteneurs Docker. Service Fabric fournit une version du pilote pour les clusters Windows et une version pour les clusters Linux.

  • Stockage d'objets blob. Le stockage Blob Azure peut être utilisé pour monter le stockage blob (ou le stockage d’objets) en tant que système de fichiers dans un conteneur ou un pod. L’utilisation du stockage Blob permet à un cluster AKS de prendre en charge les applications qui fonctionnent avec de grands jeux de données non structurés, tels que des données de fichier journal, des images ou des documents, le HPC et d’autres. Si vous ingérez des données dans Azure Data Lake Storage, vous pouvez le monter le stockage et l’utiliser directement dans AKS sans configurer un autre système de fichiers intermédiaire. Service Fabric ne prend en charge aucun mécanisme de montage du stockage d’objets blob en mode déclaratif.

Pour plus d’informations sur les options de stockage, consultez Stockage Azure dans AKS.

Surveillance des applications et des clusters

Service Fabric et AKS fournissent une intégration native à Azure Monitor et à ses services, comme Log Analytics. La surveillance et les diagnostics sont essentiels pour développer, tester et déployer des charges de travail dans n’importe quel environnement cloud. La supervision inclut la surveillance de l’infrastructure et des applications.

Par exemple, vous pouvez suivre la façon dont vos applications sont utilisées, les actions effectuées par la plateforme Service Fabric, votre utilisation des ressources avec des compteurs de performances et l’intégrité globale de votre cluster. Vous pouvez utiliser ces informations pour diagnostiquer et corriger les problèmes, et éviter qu’ils ne se reproduisent. Pour plus d’informations, consultez Monitoring et diagnostics pour Service Fabric. Lorsque vous hébergez et utilisez des applications conteneurisées dans un cluster Service Fabric, vous devez configurer la solution de supervision de conteneur pour afficher les événements et journaux de conteneur.

Toutefois, AKS a une intégration intégrée à Azure Monitor et Container Insights, qui est conçue pour surveiller les performances des charges de travail conteneurisées déployées dans le cloud. Container Insights vous permet de visualiser les performances en collectant des métriques sur la mémoire et le processeur à partir des contrôleurs, des nœuds et des conteneurs qui sont disponibles dans Kubernetes via l’API Metrics.

Une fois que vous avez activé la supervision des clusters Kubernetes, les métriques et les journaux de conteneur sont automatiquement collectés à l’aide d’une version conteneurisée de l’agent Log Analytics pour Linux. Les métriques sont envoyées à la base de données de métriques dans Azure Monitor. Les données du journal sont envoyées à votre espace de travail Log Analytics. Cela vous permet d’obtenir des données de surveillance et de télémétrie pour le cluster AKS et les applications conteneurisées qui s’exécutent dessus. Pour plus d’informations, consultez Monitor AKS avec Azure Monitor.

En guise de solution alternative ou complémentaire à Container Insights, vous pouvez configurer votre cluster AKS pour collecter des métriques dans le service managé Azure Monitor pour Prometheus. Vous pouvez utiliser cette configuration pour collecter et analyser des métriques à grande échelle à l’aide d’une solution de supervision compatible Prometheus, basée sur le projet Prometheus . Le service entièrement managé vous permet d’utiliser le langage de requête Prometheus (PromQL) pour analyser les performances de l’infrastructure et des charges de travail surveillées. Il vous permet également de recevoir des alertes sans avoir à utiliser l’infrastructure sous-jacente.

Le service managé Azure Monitor pour Prometheus est un composant des métriques Azure Monitor. Il offre une plus grande flexibilité dans les types de données de métriques que vous pouvez collecter et analyser à l’aide d’Azure Monitor. Les métriques Prometheus partagent certaines fonctionnalités avec des métriques de plateforme et personnalisées, mais elles ont des fonctionnalités supplémentaires pour mieux prendre en charge les outils open source tels que PromQLet Grafana.

Vous pouvez configurer le service managé Azure Monitor pour Prometheus en tant que source de données pour Azure Managed Grafana et Grafana auto-hébergé dans une machine virtuelle Azure. Pour plus d’informations, consultez Utiliser le service managé Azure Monitor pour Prometheus comme source de données pour Grafana avec l’identité système managée.

Modules complémentaires pour AKS

Lorsque vous migrez de Service Fabric vers AKS, vous devez envisager d’utiliser des modules complémentaires et des extensions. AKS fournit des fonctionnalités supplémentaires prises en charge pour vos clusters via des extensions et des extensions telles que la mise à l’échelle automatique basée sur les événements Kubernetes (KEDA) et GitOps Flux v2. De nombreuses autres intégrations fournies par des projets open source et des tiers qui sont couramment utilisées avec AKS. La stratégie de support AKS ne couvre pas les intégrations open source et non-Microsoft. Pour plus d’informations, consultez Modules complémentaires, extensions et autres intégrations avec AKS.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes