Partager via

Architecture de microservices sur Azure Kubernetes Service

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Équilibrage de charge Azure
Azure Pipelines
Azure Monitor

Cette architecture de référence présente une application de microservices déployée sur AKS (Azure Kubernetes Service). Il décrit une configuration AKS de base que vous pouvez utiliser comme point de départ pour la plupart des déploiements. Cet article part du principe que vous avez une compréhension de base de Kubernetes. L’article met principalement en évidence l’infrastructure et les aspects DevOps de la gestion des microservices sur AKS. Pour plus d’informations sur la conception de microservices, consultez conception de l’architecture microservices.

logo GitHub. Une implémentation de référence de cette architecture est disponible sur GitHub .

Architecture

Diagramme montrant les microservices sur l’architecture de référence AKS.

Helm est une marque de la Cloud Native Computing Foundation (CNCF). L’utilisation de cette marque n’implique aucune approbation de sa part.

Téléchargez un fichier Visio de cette architecture.

Si vous souhaitez voir un exemple de microservice plus avancé basé sur l’architecture de base de référence AKS , consultez l’architecture de microservices AKS avancée avancée.

Flux de travail

Ce flux de requête implémente les d’abonnéséditeur, les consommateurs concurrentset modèles de routage de passerelle cloud.

Le flux de données suivant correspond au diagramme précédent :

  1. L’application cliente envoie une charge utile JSON sur HTTPS au nom de domaine complet public de l’équilibreur de charge (contrôleur d’entrée managé) pour planifier un enlèvement de drone.

    • Le contrôleur d’entrée managé achemine la requête vers le microservice d’ingestion.

    • Le microservice d’ingestion traite les demandes de remise des demandes et des files d’attente dans une file d’attente Azure Service Bus.

  2. Microservice de flux de travail :

    • Utilise les informations de message de la file d’attente de messages Service Bus.

    • Envoie une requête HTTPS au microservice de remise, qui transmet les données au stockage de données externe dans Azure Cache pour Redis.

    • Envoie une requête HTTPS au microservice du planificateur de drone.

    • Envoie une requête HTTPS au microservice de package, qui transmet les données au stockage de données externe dans MongoDB.

  3. Une requête HTTPS GET retourne l’état de remise. Cette requête passe par le contrôleur d’entrée managé dans le microservice de remise. Ensuite, le microservice de remise lit les données à partir d’Azure Cache pour Redis.

Pour plus d’informations sur l’exemple d’application de microservices, consultez exemple d’implémentation de référence de microservices.

Composants

  • AKS est un cluster Kubernetes managé hébergé dans le cloud Azure. AKS permet de réduire la complexité et la surcharge opérationnelle de la gestion d’un cluster Kubernetes en déléguant une grande partie de cette responsabilité à Azure.

  • Un serveur d’entrée expose des itinéraires HTTP(S) vers des services à l’intérieur du cluster. L’implémentation de référence utilise un contrôleur d’entrée basé sur NGINX managé via un module complémentaire de routage d’application. Le contrôleur d’entrée implémente le modèle de passerelle d’API pour les microservices.

  • magasins de données externes, tels que Azure SQL Database ou Azure Cosmos DB, sont utilisés par des microservices sans état pour écrire leurs données et d’autres informations d’état. L’implémentation de référence utilise Azure Cosmos DB, Cache Azure pour Redis, Azure Cosmos DB pour MongoDB et Service Bus en tant que magasins de données ou emplacements pour stocker l’état.

  • 'ID Microsoft Entra est nécessaire pour le cluster AKS. Il fournit une identité managée utilisée pour accéder à Azure Container Registry et pour accéder et approvisionner des ressources Azure telles que des équilibreurs de charge et des disques managés. Les charges de travail déployées sur un cluster AKS nécessitent également une identité dans Microsoft Entra pour accéder aux ressources protégées par Microsoft Entra, telles qu’Azure Key Vault et Microsoft Graph. Dans cette architecture de référence, ID de charge de travail Microsoft Entra s’intègre à Kubernetes et fournit des charges de travail avec des identités. Vous pouvez également utiliser des identités managées ou des informations d’identification d’application pour chaque charge de travail.

  • container Registry pouvez être utilisé pour stocker des images conteneur privées, qui sont déployées sur le cluster. AKS peut s’authentifier auprès de Container Registry à l’aide de son identité Microsoft Entra. Dans l’implémentation de référence, les images conteneur de microservice sont générées et envoyées (push) à Container Registry.

  • azure Pipelines fait partie de la suite Azure DevOps et exécute des builds, des tests et des déploiements automatisés. Une approche 'intégration continue et de déploiement continu (CI/CD) est fortement encouragée dans les environnements de microservice. Différentes équipes peuvent créer et déployer des microservices sur AKS indépendamment à l’aide d’Azure Pipelines.

  • Helm est un gestionnaire de package pour Kubernetes qui fournit un mécanisme permettant de regrouper et de normaliser les objets Kubernetes en une seule unité qui peut être publiée, déployée, versionnée et mise à jour.

  • Azure Monitor collecte et stocke les métriques et les journaux d’activité, la télémétrie des applications et les métriques de plateforme pour les services Azure. Azure Monitor s'intègre à AKS pour collecter des métriques à partir des contrôleurs, nœuds et conteneurs.

  • Application Insights surveille les microservices et les conteneurs. Il peut être utilisé pour fournir une observabilité aux microservices, notamment le flux de trafic, la latence de bout en bout et le pourcentage d’erreurs. L’intégrité des microservices et les relations entre eux peuvent être affichées sur une seule carte d’application.

Alternatives

Azure Container Apps offre une expérience Kubernetes serverless managée. Il sert d’alternative plus simple à AKS pour l’hébergement de microservices lorsque vous n’avez pas besoin d’un accès direct à Kubernetes ou à ses API et ne nécessitent pas de contrôle sur l’infrastructure de cluster.

Au lieu de la passerelle d’entrée managée dans AKS, vous pouvez utiliser des alternatives comme Application Gateway pour conteneurs, la passerelle d’entrée Istio ou les solutions non-Microsoft. Pour plus d’informations, consultez Entrée dans AKS.

Vous pouvez stocker des images conteneur dans des registres de conteneurs non-Microsoft tels que Docker Hub.

Pour les microservices qui doivent conserver les informations d’état, Dapr fournit une couche d’abstraction pour gérer l’état du microservice.

Vous pouvez utiliser GitHub Actions pour générer et déployer des microservices, ou choisir des solutions CI/CD non-Microsoft telles que Jenkins.

L’observabilité du microservice peut être obtenue avec d’autres outils comme Kiali.

Détails du scénario

L’exemple implémentation de référence de microservice implémente les composants et pratiques architecturaux décrits dans cet article. Dans cet exemple, une société fictive appelée Fabrikam, Inc., gère une flotte d’avions de drone. Les entreprises souscrivent au service, et les utilisateurs peuvent demander à ce qu’un drone vienne récupérer les marchandises à livrer. Lorsqu’un client planifie un enlèvement, le système back-end affecte un drone et avertit l’utilisateur avec un délai de livraison estimé. Lorsque la livraison est en cours, le client peut suivre l’emplacement du drone avec un délai de livraison estimé en continu.

Le scénario vise à illustrer les meilleures pratiques en matière d’architecture et de déploiement de microservices dans AKS.

Cas d’usage potentiels

Adoptez les meilleures pratiques suivantes du scénario pour concevoir des applications complexes basées sur des microservices dans AKS :

  • Applications web complexes
  • Logique métier développée à l’aide de principes de conception de microservice

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Conception

Cette architecture de référence est axée sur les microservices, mais la plupart des pratiques recommandées s’appliquent à d’autres charges de travail qui s’exécutent sur AKS.

Microservices

Un microservice est une unité faiblement couplée, pouvant être déployée indépendamment du code. Les microservices communiquent généralement par le biais d'API bien définies et peuvent être détectés par une forme de fonctionnalité de détection de services. L’objet de service Kubernetes est un moyen classique de modéliser des microservices dans Kubernetes.

Stockage des données

Dans une architecture de microservices, les services ne doivent pas partager de solutions de stockage de données. Chaque service doit gérer son propre jeu de données pour éviter les dépendances masquées entre les services. La séparation des données permet d’éviter le couplage involontaire entre les services. Ce processus peut se produire lorsque les services partagent les mêmes schémas de données sous-jacents. Lorsque les services gèrent leurs propres magasins de données, ils peuvent utiliser le magasin de données approprié pour leurs besoins particuliers. Pour plus d’informations, consultez considérations relatives aux données pour les microservices.

Évitez de stocker des données persistantes dans le stockage de cluster local, car cette méthode lie les données au nœud. Utilisez plutôt un service externe tel que SQL Database ou Azure Cosmos DB. Une autre option consiste à monter un volume de données persistant dans une solution à l’aide du Stockage disque Azure ou d’Azure Files. Pour plus d’informations, consultez Options de stockage pour les applications dans AKS.

Passerelle API

Les passerelles API sont un modèle de conception de microservices général. Une passerelle d’API se trouve entre les clients externes et les microservices. La passerelle sert de proxy inverse et achemine les demandes des clients vers les microservices. Une passerelle d’API peut également effectuer différentes tâches croisées telles que l’authentification, l’arrêt SSL (Secure Sockets Layer) et la limitation du débit. Pour plus d’informations, consultez les ressources suivantes :

Dans Kubernetes, un contrôleur d’entrée gère principalement les fonctionnalités d’une passerelle d’API. L’entrée et le contrôleur d’entrée fonctionnent conjointement avec :

  • Acheminer les demandes du client vers les microservices principaux appropriés. Ce routage fournit un point de terminaison unique pour les clients et permet de dissocier les clients des services.

  • Agréger plusieurs requêtes en une seule requête pour réduire les conversationtines entre le client et le serveur principal.

  • Décharger les fonctionnalités des services principaux, telles que l’arrêt SSL, l’authentification, les restrictions d’adresse IP ou la limitation du débit client (appelée limitation).

Il existe des contrôleurs d’entrée pour les proxys inverses, notamment NGINX, HAProxy, Traefik et Azure Application Gateway. AKS fournit plusieurs options d’entrée managées. Vous pouvez choisir parmi un contrôleur d’entrée managé basé sur NGINX via le module complémentaire de routage d’application, Application Gateway pour conteneurs. Vous pouvez également choisir la passerelle d’entrée Istio comme contrôleur d’entrée. Pour plus d’informations, consultez Entrée dans AKS.

Les ressources d’entrée des objets Kubernetes ont été remplacées par l’API de passerelle Kubernetes plus avancée et polyvalente. Le contrôleur d’entrée et l’API de passerelle sont tous deux des objets Kubernetes utilisés pour le routage de gestion du trafic et l’équilibrage de charge. Conçu pour être générique, expressif, extensible et orienté rôle, l’API de passerelle est un ensemble moderne d’API permettant de définir des règles de routage L4 et L7 dans Kubernetes.

Le contrôleur d’entrée fonctionne en tant que routeur de périphérie ou proxy inverse. Un serveur proxy inverse est un goulot d’étranglement potentiel ou un point de défaillance unique. Nous vous recommandons donc de déployer au moins deux réplicas pour garantir une haute disponibilité.

Quand choisir des contrôleurs d’entrée ou une API de passerelle

Les ressources d’entrée conviennent aux cas d’usage suivants :

  • Les contrôleurs d’entrée sont faciles à configurer et conviennent aux déploiements Kubernetes plus petits et moins complexes qui hiérarchisent la configuration facile.

  • Si vous avez actuellement des contrôleurs d’entrée configurés dans votre cluster Kubernetes et qu’ils répondent efficacement à vos besoins, il se peut qu’il n’y ait pas besoin immédiatement de passer à l’API de passerelle Kubernetes.

Vous devez utiliser l’API de passerelle :

  • Lorsque vous gérez des configurations de routage complexes, le fractionnement du trafic et des stratégies avancées de gestion du trafic. La flexibilité fournie par les ressources route de l’API De passerelle Kubernetes est essentielle.

  • Si les exigences de mise en réseau nécessitent des solutions personnalisées ou l’intégration de plug-ins non-Microsoft. L’approche de l’API de passerelle Kubernetes, basée sur des définitions de ressources personnalisées, peut fournir une extensibilité améliorée.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Partitionnement de microservices

Utilisez des espaces de noms pour organiser les services au sein du cluster. Chaque objet dans un cluster Kubernetes appartient à un espace de noms. Il est recommandé d’utiliser des espaces de noms pour organiser les ressources dans le cluster.

Les espaces de noms permettent d’empêcher les collisions d’affectation de noms. Quand plusieurs équipes déploient des microservices sur le même cluster, opération pouvant impliquer des centaines de microservices, il devient difficile de savoir s’ils peuvent tous être placés dans le même espace de noms. Les espaces de noms vous permettent également de :

  • Appliquez des contraintes de ressources à un espace de noms afin que l’ensemble total de pods attribués à cet espace de noms ne puisse pas dépasser le quota de ressources de l’espace de noms.

  • Appliquez des stratégies au niveau de l’espace de noms, notamment le contrôle d’accès en fonction du rôle (RBAC) et les stratégies de sécurité.

Lorsque plusieurs équipes développent et déploient des microservices, vous pouvez utiliser des espaces de noms comme mécanisme pratique pour contrôler les zones à déployer par chaque équipe. Par exemple, l’équipe de développement A peut avoir accès uniquement à l’espace de noms A, et l’équipe de développement B ne peut accéder qu’à l’espace de noms B via kubernetes stratégies RBAC.

Pour une architecture de microservices, envisagez d’organiser les microservices dans des contextes délimités et de créer des espaces de noms pour chaque contexte délimité. Par exemple, tous les microservices liés au contexte limité « Traitement des commandes » peuvent accéder au même espace de noms. Vous pouvez également créer un espace de noms pour chaque équipe de développement.

Placez les services d’utilitaire dans leur propre espace de noms. Par exemple, vous pouvez déployer des outils de surveillance de cluster tels qu’Elasticsearch et Prometheus dans un espace de noms de surveillance.

Sondes d’intégrité

Kubernetes définit trois types de sondes d’intégrité qu’un pod peut exposer :

  • sonde Readiness : indique à Kubernetes si le pod est prêt à accepter les demandes.

  • sonde Liveness : indique à Kubernetes si un pod doit être supprimé et qu’une nouvelle instance a démarré.

  • sonde de démarrage : indique à Kubernetes si le pod est démarré.

Lorsque vous pensez à des sondes, il est important de mémoriser le fonctionnement d’un service dans Kubernetes. Un service a un sélecteur d’étiquette qui correspond à un ensemble de zéro ou plusieurs pods. Kubernetes équilibre la charge du trafic vers les pods qui correspondent au sélecteur. Seuls les pods qui démarrent correctement et sont en bonne santé reçoivent le trafic. Si un conteneur se bloque, Kubernetes met fin au pod et planifie un remplacement.

Parfois, un pod peut ne pas être prêt à recevoir le trafic, même s’il a démarré avec succès. Par exemple, il peut y avoir des tâches d’initialisation en cours, par exemple lorsque l’application s’exécutant dans le conteneur charge des données en mémoire ou lit des fichiers de configuration. Vous pouvez utiliser une sonde de démarrage pour ces conteneurs à démarrage lent. Cette approche permet d’empêcher Kubernetes de les terminer avant qu’ils aient la possibilité d’initialiser entièrement.

Les sondes Liveness sont utilisées pour vérifier si un pod est en cours d’exécution, mais ne fonctionne pas correctement et doit être redémarré. Par exemple, si un conteneur gère les requêtes HTTP, mais cesse soudainement de répondre sans se bloquer, la sonde liveness détecte cet événement et déclenche un redémarrage du pod. Si vous configurez une sonde liveness, elle remarque quand un conteneur ne répond pas et invite Kubernetes à redémarrer le pod si le conteneur échoue à plusieurs reprises la sonde.

Tenez compte des points suivants lorsque vous concevez des sondes pour les microservices.

  • Si votre code a une longue durée de démarrage, il existe un danger qu’une sonde liveness signale un échec avant la fin du démarrage. Pour retarder le début d’une sonde liveness, utilisez la sonde de démarrage ou utilisez le paramètre initialDelaySeconds avec la sonde liveness.

  • Une sonde liveness permet uniquement si le redémarrage du pod est susceptible de le restaurer à un état sain. Vous pouvez utiliser une sonde liveness pour atténuer les fuites de mémoire ou les blocages inattendus, mais il n’y a aucune raison de redémarrer un pod qui échouera immédiatement.

  • Parfois, les probes readiness peuvent servir à vérifier les services dépendants. Par exemple, si un pod dépend d'une base de données, la probe peut vérifier la connexion à la base de données. Toutefois, cette approche peut engendrer des problèmes inattendus. Un service externe peut être temporairement indisponible. Cette indisponibilité entraîne l’échec de la sonde de préparation pour tous les pods de votre service, ce qui entraîne leur suppression de l’équilibrage de charge. Cette suppression crée des défaillances en cascade en amont.

    Une meilleure approche consiste à implémenter la gestion des nouvelles tentatives au sein de votre service afin que votre service puisse récupérer correctement à partir d’échecs temporaires. En guise d’alternative, la gestion des nouvelles tentatives, la tolérance d’erreur et les disjoncteurs peuvent être implémentés par le maillage de service Istio istio pour créer une architecture résiliente capable de gérer les défaillances de microservice.

Contraintes de ressources

La contention de ressources peut affecter la disponibilité d’un service. Définissez contraintes de ressources pour les conteneurs afin qu’un seul conteneur ne puisse pas submerger les ressources du cluster, telles que la mémoire et le processeur. Pour les ressources autres que conteneur, telles que les threads ou les connexions réseau, envisagez d’utiliser le modèle de bulkhead pour isoler les ressources.

Utilisez quotas de ressources pour limiter le nombre total de ressources autorisées pour un espace de noms. Cette limitation garantit que le serveur frontal ne peut pas priver les services principaux pour les ressources ou inversement. Les quotas de ressources peuvent aider à allouer des ressources au sein du même cluster à plusieurs équipes de développement de microservice.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

Chiffrement TLS et SSL

Dans de nombreuses implémentations, le contrôleur d’entrée est utilisé pour l’arrêt SSL. Dans le cadre du déploiement du contrôleur d’entrée, vous devez créer ou importer un certificat TLS (Transport Layer Security). Utilisez uniquement des certificats auto-signés à des fins de développement et de test. Pour plus d’informations, consultez Configurer un nom de domaine personnalisé et un certificat SSL avec le module complémentaire de routage d’application.

Pour les charges de travail de production, obtenez des certificats signés auprès des autorités de certification approuvées.

Vous devrez peut-être également faire pivoter vos certificats en fonction des stratégies de l’organisation. Vous pouvez utiliser Key Vault pour faire pivoter les certificats que les microservices utilisent. Pour plus d’informations, consultez Configurer la rotation automatique des certificats dans Key Vault.

RBAC

Lorsque plusieurs équipes développent et déploient des microservices en même temps, les mécanismes RBAC AKS peuvent fournir un contrôle granulaire et un filtrage des actions utilisateur. Vous pouvez utiliser RBAC Kubernetes ou Azure RBAC avec l’ID Microsoft Entra pour contrôler l’accès aux ressources du cluster. Pour plus d’informations, consultez Options d’accès et d’identité pour AKS.

Authentification et autorisation

Les microservices peuvent exiger que les services ou utilisateurs consommants authentifient et autorisent l’accès au microservice à l’aide de certificats, d’informations d’identification et de mécanismes RBAC. Microsoft Entra ID peut être utilisé pour implémenter jetons OAuth 2.0 pour l’autorisation. Les maillages de service tels que Istio fournissent également des mécanismes d’autorisation et d’authentification pour les microservices, qui incluent la validation des jetons OAuth et le routage basé sur les jetons. L’implémentation de référence ne couvre pas les scénarios d’authentification et d’autorisation de microservice.

Gestion des secrets et informations d’identification d’application

Les applications et services ont souvent besoin d’informations d’identification leur permettant de se connecter à des services externes tels que Stockage Azure ou SQL Database. Le défi consiste à assurer la sécurité de ces informations d’identification et à les protéger de toute fuite.

Pour les ressources Azure, utilisez des identités managées lorsque cela est possible. Une identité managée est comme un ID unique pour une application ou un service stocké dans l’ID Microsoft Entra. Il utilise cette identité pour s’authentifier auprès d’un service Azure. L’application ou le service a un principal de service créé pour celui-ci dans Microsoft Entra ID et s’authentifie à l’aide de jetons OAuth 2.0. Le code en cours d’exécution dans le processus peut obtenir de manière transparente le jeton. Cette approche vous permet de vous assurer que vous n’avez pas besoin de stocker de mots de passe ou de chaînes de connexion. Pour utiliser des identités managées, vous pouvez affecter des identités Microsoft Entra à des pods individuels dans AKS à l’aide de 'ID de charge de travail Microsoft Entra.

Même lorsque vous utilisez des identités managées, vous devrez peut-être toujours stocker des informations d’identification ou d’autres secrets d’application. Ce stockage est nécessaire pour les services Azure qui ne prennent pas en charge les identités managées, les services non-Microsoft ou les clés API. Vous pouvez utiliser les options suivantes pour stocker les secrets de manière plus sécurisée :

L’utilisation d’une solution telle que Key Vault offre plusieurs avantages, notamment :

  • Contrôle centralisé des secrets
  • Aider à s’assurer que tous les secrets sont chiffrés au repos.
  • Gestion centralisée des clés
  • Contrôle d’accès des secrets
  • Gestion du cycle de vie des clés.
  • Audit.

L’implémentation de référence stocke les chaînes de connexion Azure Cosmos DB et d’autres secrets dans Key Vault. L’implémentation de référence utilise une identité managée pour les microservices pour s’authentifier auprès de Key Vault et accéder aux secrets.

Sécurité du conteneur et de l’orchestrateur

Les pratiques recommandées suivantes peuvent vous aider à sécuriser vos pods et conteneurs.

  • Surveillez les menaces. Surveillez les menaces à l’aide de Microsoft Defender pour conteneurs ou d’une fonctionnalité non-Microsoft. Si vous hébergez des conteneurs sur une machine virtuelle, utilisez Microsoft Defender pour serveurs ou une fonctionnalité autre que Microsoft. En outre, vous pouvez intégrer des journaux d’activité de solution de supervision de conteneur dans Azure Monitor à Microsoft Sentinel ou à une solution SIEM (Security Information and Event Management) existante.

  • Surveillez les vulnérabilités. Surveillez en permanence les images et les conteneurs en cours d’exécution pour connaître les vulnérabilités connues à l’aide de Microsoft Defender pour Cloud ou d’une solution non-Microsoft.

  • Automatisez la mise à jour corrective des images. Utilisez tâches Azure Container Registry, une fonctionnalité de Container Registry, pour automatiser la mise à jour corrective des images. Une image conteneur est développée à partir de couches. Les couches de base incluent l’image de système d’exploitation et les images de framework d’application, par exemple ASP.NET Core ou Node.js. Les images de base sont généralement créées en amont à partir des développeurs d’applications, et d’autres maintenances de projet les gèrent. Lorsque ces images sont corrigées en amont, il est important de mettre à jour, de tester et de redéployer vos propres images afin de ne pas laisser de vulnérabilités de sécurité connues. Les tâches Azure Container Registry peuvent aider à automatiser ce processus.

  • Stockez des images dans un registre privé approuvé. Utilisez un registre privé approuvé tel que Container Registry ou Docker Trusted Registry pour stocker des images. Utilisez un webhook d’admission de validation dans Kubernetes pour vous assurer que les pods peuvent uniquement récupérer des images à partir du registre approuvé.

  • Appliquez le principe du privilège minimum. N’exécutez pas les conteneurs en mode privilégié. Le mode privilégié donne à un conteneur l’accès à tous les appareils sur l’hôte. Dans la mesure du possible, évitez d’exécuter des processus en tant qu’utilisateur root à l’intérieur des conteneurs. Les conteneurs ne fournissent pas une isolation complète du point de vue de la sécurité. Il est donc préférable d’exécuter un processus de conteneur en tant qu’utilisateur non privilégié.

Considérations relatives à l’INTÉGRATION/CD de déploiement

Tenez compte des objectifs suivants d’un processus CI/CD robuste pour une architecture de microservices :

  • Chaque équipe peut générer et déployer ses propres services de manière indépendante, sans affecter ou interrompre d’autres équipes.

  • Avant qu’une nouvelle version d’un service soit déployée en production, elle est déployée pour le développement, le test et les environnements Q&A pour validation. Des critères de qualité sont appliqués à chaque étape.

  • Une nouvelle version d'un service peut être déployée aux côtés de la version précédente.

  • Des stratégies de contrôle d’accès suffisantes sont en place.

  • Pour les charges de travail conteneurisées, vous pouvez approuver les images conteneur déployées en production.

Pour en savoir plus sur les défis, consultez Intégration continue/livraison continue (CI/CD) pour les architectures de microservices.

L’utilisation d’un maillage de service comme Istio peut vous aider à utiliser des processus CI/CD, tels que les déploiements canary, les tests A/B des microservices et les déploiements intermédiaires avec des fractionnements de trafic basés sur des pourcentages.

Pour plus d’informations sur des recommandations et des bonnes pratiques spécifiques, consultez Créer un pipeline CI/CD pour les microservices sur Kubernetes avec Azure DevOps et Helm.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

Utiliser la calculatrice de prix Azure pour estimer les coûts. D’autres considérations sont décrites dans la section Coût dans Microsoft Azure Well-Architected Framework.

Tenez compte des points suivants pour certains des services utilisés dans cette architecture.

AKS

  • Dans le niveau gratuit, aucun coût n’est associé à AKS dans le déploiement, la gestion et les opérations du cluster Kubernetes. Vous payez uniquement pour les instances de machine virtuelle, le stockage et les ressources réseau que votre cluster Kubernetes consomme.

  • Envisagez d’utiliser autoscaler de pod horizontal pour mettre automatiquement à l’échelle les microservices dans ou les mettre à l’échelle en fonction de la charge.

  • Configurez mise à l’échelle automatique du cluster pour mettre à l’échelle les nœuds ou les mettre à l’échelle en fonction de la charge.

  • Envisagez d’utiliser nœuds spot pour héberger des microservices non critiques.

  • Passez en revue les bonnes pratiques d’optimisation des coûts pour AKS.

  • Pour estimer le coût des ressources requises, utilisez la calculatrice AKS .

Équilibrage de charge Azure

Vous n'êtes facturé que pour le nombre de règles de trafic sortant et d'équilibrage de la charge configurées. Les règles de traduction d’adresses réseau entrantes sont gratuites. Il n'y a pas de frais horaires pour l'équilibreur de charge Standard Load Balancer lorsqu'aucune règle n'est configurée. Pour plus d’informations, consultez tarification d’Azure Load Balancer.

Azure Pipelines

Cette architecture de référence utilise uniquement Azure Pipelines. Azure fournit le pipeline en tant que service individuel. Vous êtes autorisé à effectuer un travail gratuit hébergé par Microsoft avec 1 800 minutes pour chaque mois pour CI/CD et un travail auto-hébergé avec des minutes illimitées pour chaque mois. Des travaux supplémentaires entraînent davantage de coûts. Pour plus d’informations, consultez tarification des services Azure DevOps.

Azure Monitor

Concernant Azure Monitor Log Analytics, vous êtes facturé pour l'ingestion et la conservation des données. Pour en savoir plus, consultez Tarification d’Azure Monitor.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

Cette architecture de référence inclut fichiers Bicep pour approvisionner des ressources cloud et leurs dépendances. Vous pouvez utiliser azure Pipelines pour déployer ces fichiers Bicep et configurer rapidement différents environnements, tels que la réplication de scénarios de production. Cette approche vous permet d’économiser des coûts en approvisionnant des environnements de test de charge uniquement si nécessaire.

Envisagez de suivre les critères d’isolation de la charge de travail pour structurer votre fichier Bicep. Une charge de travail est généralement définie comme une unité arbitraire de fonctionnalités. Par exemple, vous pouvez avoir un fichier Bicep distinct pour le cluster, puis un autre fichier pour les services dépendants. Vous pouvez utiliser Azure DevOps pour effectuer l’isolation CI/CD avec une isolation de charge de travail, car chaque charge de travail est associée et gérée par sa propre équipe.

Déployer ce scénario

Pour déployer l'implémentation de référence de cette architecture, suivez la procédure décrite dans le référentiel GitHub. Pour plus d’informations, consultez implémentation de référence des microservices AKS.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

Autres contributeurs :

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

Étapes suivantes