Architecture de microservices sur Azure Kubernetes Service

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Redis géré
Azure Pipelines
Azure Monitor

Cette architecture montre une application de microservices déployée sur Azure Kubernetes Service (AKS). 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. Il met en évidence les aspects des opérations d’infrastructure et de développement (DevOps) de la gestion des microservices sur AKS. Pour les déploiements de production, cette architecture vous recommande d’utiliser Azure CNI alimenté par Cilium comme solution de mise en réseau. Ce service offre des performances améliorées, une application de stratégie réseau intégrée et une observabilité améliorée par le biais de son plan de données basé sur eBPF (Extended Berkeley Packet Filter). Pour plus d’informations sur la conception de microservices, consultez conception de l’architecture microservices.

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.

Pour obtenir un exemple de microservice plus avancé basé sur l’architecture de référence AKS, consultez l’architecture avancée des microservices AKS.

Flux de données

Ce flux de requête implémente les modèles de conception cloud Éditeur-abonné, Consommateurs concurrents et Routage de passerelle.

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

  1. L'application cliente envoie une charge utile JSON via HTTPS au nom de domaine complet public (FQDN) du répartiteur de charge (contrôleur d'entrée géré) pour programmer un enlèvement par drone.

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

    • Le microservice d’ingestion traite les requêtes et place les demandes de livraison dans une file d'attente Azure Service Bus.

  2. Le microservice de flux de travail effectue les actions suivantes :

    • Consomme les informations de message depuis la file d’attente de messages du Service Bus

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

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

    • Envoie une requête HTTPS au microservice de package, qui transmet des 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 livraison lit les données d'Azure Redis géré.

Components

  • AKS est un service Kubernetes managé qui héberge et orchestre les conteneurs de microservices. Dans cette architecture, AKS fournit la plateforme d’exécution pour le déploiement, la mise à l’échelle et la gestion des microservices de l’application de livraison de drone.

  • Azure CNI alimenté par Cilium est la solution réseau recommandée pour se connecter directement à un réseau virtuel Azure. Dans cette architecture, elle affecte des adresses IP du réseau virtuel aux pods et fournit des fonctionnalités de stratégie réseau intégrées et une visibilité du trafic.

  • Un serveur d’entrée expose des itinéraires HTTP et HTTPS vers des services à l’intérieur d’un cluster. Dans cette architecture, un contrôleur d’entrée basé sur NGINX managé est utilisé 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.

  • Les magasins de données externes, tels que Azure SQL Database ou Azure Cosmos DB, sont utilisés par les microservices sans état pour écrire leurs données et d’autres informations d’état. Dans cette architecture, Azure Cosmos DB, Azure Redis managé, Azure DocumentDB et Service Bus servent de magasins de données ou d’emplacements pour stocker l’état.

  • Microsoft Entra ID est un service de gestion des identités et des accès cloud qui fournit des fonctionnalités d’authentification et d’autorisation pour le cluster AKS et les charges de travail déployées. AKS nécessite une intégration Microsoft Entra ID pour fournir une identité managée pour accéder à Azure Container Registry et pour approvisionner des ressources Azure telles que les équilibreurs de charge et les disques managés. Chaque charge de travail déployée sur le cluster AKS nécessite une identité pour accéder aux ressources protégées par Microsoft Entra, telles que Azure Key Vault et Microsoft Graph. Cette architecture utilise Microsoft Entra Workload ID pour s’intégrer à Kubernetes et fournir des identités sécurisées pour les charges de travail. Vous pouvez également utiliser des identités managées ou des informations d’identification d’application pour l’authentification de la charge de travail.

  • Container Registry est un service managé qui peut stocker des images conteneur privées, qui sont déployées sur un cluster. AKS peut s’authentifier auprès de Container Registry à l’aide de son identité Microsoft Entra. Les images de conteneurs de microservices sont générées et envoyées au registre de conteneurs. Dans cette architecture, Container Registry stocke les images conteneur privées pour les microservices déployés sur le cluster AKS.

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

  • Helm est un gestionnaire de package pour Kubernetes qui fournit un mécanisme pour regrouper et normaliser les objets Kubernetes en une seule unité que vous pouvez publier, déployer, version et mettre à jour. Dans cette architecture, Helm empaquette les microservices de livraison de drone pour le déploiement sur AKS.

  • Azure Monitor est une plateforme de surveillance qui collecte et stocke des métriques et des journaux, des données de télémétrie d’application et des métriques de plateforme pour les services Azure. Dans cette architecture, Azure Monitor s’intègre à AKS pour collecter des métriques à partir de contrôleurs, de nœuds et de conteneurs.

  • Application Insights est un outil de supervision des performances qui surveille les microservices et les conteneurs. Il peut fournir une observabilité dans les microservices, notamment le flux de trafic, la latence de bout en bout et le pourcentage d’erreurs. Il peut afficher l’intégrité des microservices et les relations entre eux sur une seule carte d’application. Dans cette architecture, Application Insights surveille l’intégrité et les performances des microservices de livraison de drone et affiche leurs relations sur une carte d’application.

Alternatives

Azure Container Apps est une plateforme serverless managée qui offre une expérience basée sur Kubernetes sans nécessiter de gestion de l’infrastructure. 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, une passerelle d’entrée Istio ou des 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 comme Docker Hub.

Pour la mise en réseau, bien que cette architecture recommande Azure CNI alimentée par Cilium pour ses performances et son application de stratégie intégrée, vous pouvez utiliser d’autres solutions de mise en réseau telles que Azure superposition CNI pour des scénarios spécifiques.

Important

Si vous avez besoin de nœuds Windows dans votre architecture de microservices, examinez la limitation actuelle de Cilium, qui ne supporte que Linux, et planifiez en conséquence pour des pools de systèmes d'exploitation mixtes. Pour plus d’informations, consultez les limitations d'Azure CNI propulsé par Cilium.

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 comme Jenkins.

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

Détails du scénario

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.

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

Considerations

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

Design

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 de 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 comme SQL Database ou Azure Cosmos DB. Une autre option consiste à monter un volume de données persistant dans une solution à l’aide de Azure Disk Storage ou de Azure Files. Pour plus d’informations, consultez Options de stockage pour les applications dans AKS.

Mise en réseau et stratégie réseau

Pour les déploiements de microservices de production sur AKS, utilisez Azure CNI alimenté par Cilium comme solution réseau. Cette approche offre plusieurs avantages pour les architectures de microservices :

  • Performances et scalabilité : Le plan de données basé sur eBPF améliore les performances de routage des services et prend en charge les clusters plus volumineux qui ont une latence inférieure par rapport aux solutions réseau traditionnelles.

  • Application de la stratégie de réseau : Cilium applique les ressources Kubernetes NetworkPolicy sans nécessiter de moteur de stratégie réseau distinct comme Azure Gestionnaire de stratégie réseau ou Calico. Cette intégration simplifie la configuration du cluster et réduit la surcharge opérationnelle.

  • Observabilité: Le plan de données eBPF offre une visibilité du trafic réseau, notamment les requêtes DNS (Domain Name System), les flux pod-à-pod et la communication de service à service. Cette visibilité permet de dépanner les interactions de microservice et d’identifier les goulots d’étranglement des performances.

  • Gestion des adresses IP flexibles : Azure CNI, avec Cilium, prend en charge les modèles d'attribution des adresses IP des pods routés et overlay, en fonction des exigences de l'architecture réseau de votre charge de travail.

Lorsque vous implémentez des stratégies réseau pour les microservices, suivez un principe d’architecture Confiance Zéro en définissant explicitement les services qui peuvent communiquer entre eux. Commencez par refuser toutes les stratégies et autorisez de manière sélective uniquement le trafic nécessaire entre les microservices. Pour plus d’informations, consultez Les meilleures pratiques pour les stratégies réseau dans AKS.

API gateway

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 pour effectuer les actions suivantes :

  • 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 interactions entre le client et le serveur.

  • Décharger les fonctionnalités des services back-end, telles que la terminaison SSL, l’authentification, les restrictions d’adresse IP ou la restriction 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 basé sur NGINX géré via le module complémentaire de routage d’application ou Application Gateway pour conteneurs. Vous pouvez également choisir une passerelle d’entrée Istio comme contrôleur d’entrée. Pour plus d’informations, consultez Entrée dans AKS.

Kubernetes a remplacé les ressources d’entrée par l’API de passerelle plus avancée et polyvalente. Les contrôleurs d’entrée et l’API de passerelle sont des objets Kubernetes qui gèrent le routage 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 de niveau 4 et de niveau 7 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 l’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, vous n’avez pas besoin de passer immédiatement à l’API de passerelle Kubernetes.

Utilisez l’API de passerelle lorsque les facteurs suivants s’appliquent :

  • Lorsque vous gérez des configurations de routage complexes, le fractionnement du trafic et des stratégies avancées de gestion du trafic. Les ressources d’itinéraire de l’API de passerelle Kubernetes offrent la flexibilité requise dans ces cas.

  • Si les exigences 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.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.

Partitionner des 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 aident à éviter les collisions de noms. Lorsque plusieurs équipes déploient des microservices dans le même cluster, avec éventuellement des centaines de microservices, la gestion dans un espace de noms unique devient difficile. Les espaces de noms vous permettent également d’effectuer les actions suivantes :

  • 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, les espaces de noms fournissent un mécanisme pratique pour contrôler les zones auxquelles chaque équipe peut effectuer le déploiement. Par exemple, les stratégies RBAC Kubernetes accordent à l’équipe de développement un accès uniquement à l’espace de noms A, et l’équipe de développement B n’a accès qu’à l’espace de noms B.

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 lié au 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 comme Elasticsearch et Prometheus dans un espace de noms de surveillance.

Sondes d’intégrité

Kubernetes définit trois types de sondes de contrôle de l'état de santé qu’un pod peut exposer :

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

  • Sonde de vivacité : Indique à Kubernetes si un pod doit être supprimé et qu'une nouvelle instance doit être démarrée.

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

Pour comprendre les sondes, commencez par examiner le fonctionnement d’un service dans Kubernetes. Un service a un sélecteur d’étiquette qui correspond à un ensemble de zéro ou plus de pods. Kubernetes répartit le trafic de manière équilibrée vers les pods qui correspondent à la sélection. Seuls les pods qui réussissent à démarrer 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 n’est pas prêt à recevoir le trafic, même s’il démarre correctement. Par exemple, il peut y avoir des tâches d’initialisation en cours, comme lorsque l’application qui s’exécute 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 de vivacité vérifient si un pod est actif mais ne fonctionne pas correctement et nécessite un redémarrage. 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 liveness probe, elle détecte quand un conteneur ne répond pas et demande à Kubernetes de redémarrer le pod si le conteneur échoue à la sonde à plusieurs reprises.

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

  • Si votre code a une longue durée de démarrage, une sonde liveness peut signaler 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 de vivacité n'est utile que si le redémarrage du Pod est susceptible de le ramener à un état sain. Vous pouvez utiliser une sonde d'activité pour atténuer les fuites de mémoire ou les blocages inattendus, mais ne redémarrez pas immédiatement un pod dont vous anticipez qu'il échouera à nouveau.

  • Parfois, les sondes de préparation contrôlent 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. Mais cette approche peut créer des problèmes inattendus. Un service externe peut être temporairement indisponible. Cette indisponibilité provoque l’échec de la sonde de préparation pour tous les pods de votre service, ce qui entraîne leur exclusion 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, le maillage de service Istio peut implémenter la gestion des nouvelles tentatives, la tolérance d’erreur et les disjoncteurs. Cette approche crée une architecture résiliente qui peut gérer les défaillances de microservice.

Pour résoudre les problèmes de santé du microservice, utilisez les fonctionnalités d’observabilité réseau dans Advanced Container Networking Services. Le plan de données eBPF capture des informations détaillées sur le flux réseau entre les microservices, ce qui vous aide à identifier les problèmes de connectivité, les problèmes de résolution DNS ou les mauvaises configurations de stratégie réseau susceptibles d’affecter l’intégrité du service.

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 cloisonnement 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 les services frontaux ne consomment pas de ressources dont les services back-end ont besoin, et que les services back-end n’utilisent pas les ressources dont les services frontaux ont besoin. Les quotas de ressources peuvent aider à allouer des ressources au sein du même cluster à plusieurs équipes de développement de microservice.

Security

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 pour la révision de conception concernant la sécurité.

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 renouveler vos certificats en fonction des politiques de votre organisation. Vous pouvez utiliser Key Vault pour faire pivoter des certificats que les microservices utilisent. Pour plus d’informations, consultez Configurer la rotation automatique des certificats dans Key Vault.

Segmentation et stratégies réseau

Implémentez la segmentation réseau entre les microservices à l’aide de ressources Kubernetes NetworkPolicy. Lorsque vous utilisez Azure CNI alimenté par Cilium, le plan de données eBPF applique des stratégies réseau.

Suivez ces bonnes pratiques pour les stratégies réseau dans les architectures de microservices :

  • Appliquez les principes de confiance zéro. Commencez par refuser toutes les stratégies réseau au niveau de l’espace de noms et autorisez explicitement le trafic requis entre les microservices.

  • Segment par contexte délimité. Créez des espaces de noms pour chaque contexte limité dans votre architecture de microservices et appliquez des stratégies réseau pour contrôler le trafic entre ces contextes.

  • Contrôlez le trafic sortant. Utilisez des stratégies réseau pour restreindre le trafic sortant des microservices aux services et points de terminaison externes approuvés uniquement.

  • Surveillez l’efficacité de la stratégie. Utilisez les fonctionnalités d’observabilité du plan de données Cilium eBPF pour surveiller l’application de la stratégie réseau et identifier le trafic bloqué susceptible d’indiquer des configurations incorrectes ou des problèmes de sécurité.

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 Microsoft Entra ID 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. Vous pouvez utiliser Microsoft Entra ID pour implémenter des jetons OAuth 2.0 pour l’autorisation. Les maillages de service comme le maillage de service 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.

Gestion des secrets et identifiants d’application

Les applications et services ont souvent besoin d’informations d’identification qui leur permettent de se connecter à des services externes tels que Azure Storage ou SQL Database. Le défi est de maintenir ces informations d’identification en sécurité et d’éviter les fuites.

Pour Azure ressources, utilisez des identités managées si possible. Une identité managée est comme un ID unique pour une application ou un service stocké dans Microsoft Entra ID. 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 qui s’exécute dans le processus peut obtenir le jeton de manière transparente. 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 Microsoft Entra Workload ID.

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 :

Utilisez une solution comme Key Vault pour obtenir les avantages suivants :

  • Contrôle centralisé des secrets
  • Chiffrement des secrets au repos
  • Gestion centralisée des clés
  • Contrôle d’accès des secrets
  • Gestion du cycle de vie clé
  • Auditing

Cette architecture utilise une identité managée pour les microservices afin de s’authentifier auprès de Key Vault et d’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 les serveurs ou une fonctionnalité non-Microsoft. Vous pouvez également intégrer des journaux d’activité de la solution Container Monitoring 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 conteneurs ou d’une solution non-Microsoft.

  • Automatisez la mise à jour corrective des images. Utilisez les tâches 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 du système d’exploitation et les images d’infrastructure d’application, telles que ASP.NET Core ou Node.js. Les images de base sont généralement créées en amont des développeurs d'applications, et d'autres mainteneurs de projet les gèrent. Lorsque ces images sont corrigées en amont, vous devez mettre à jour, tester et redéployer vos propres images afin de ne pas laisser de failles de sécurité connues. Les tâches de Registre de conteneurs peuvent vous aider à automatiser ce processus.

  • Stockez des images dans un registre privé approuvé. Utilisez un registre privé approuvé comme 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 totale 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 au CI/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. Les garde-fous 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 en conteneur, vous pouvez faire confiance aux images de conteneur déployées en production.

Pour plus d’informations sur les défis, consultez CI/CD pour les architectures de microservices.

L’utilisation d’un maillage de service comme Istio peut vous aider dans les processus CI/CD, tels que les déploiements en canari, les tests A/B des microservices et les déploiements par étapes avec une répartition du trafic en fonction de pourcentages.

Pour plus d'informations sur les recommandations et les meilleures 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 la liste de vérification de conception pour l’optimisation des coûts.

Utilisez la calculatrice de prix Azure pour estimer les coûts.

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 le Horizontal Pod Autoscaler (HPA) pour ajuster automatiquement l'échelle des microservices, soit en réduisant leur nombre, soit en l'augmentant, en fonction de la charge.

  • Configurez l'Autoscaler de cluster (CA) pour faire évoluer les nœuds, soit en les ajoutant, soit en les supprimant, 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 .

Azure Répartiteur de charge

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 Load Balancer quand aucune règle n'est configurée. Pour plus d’informations, consultez Azure Load Balancer tarification.

Azure Pipelines

Cette architecture de référence utilise Azure Pipelines pour les tâches CI/CD. 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 Azure DevOps tarification des services.

Azure Monitor

Pour Log Analytics, vous êtes facturé pour l'ingestion et la rétention des données. Pour plus d’informations, consultez Azure Monitor tarification.

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 conception pour l'excellence opérationnelle.

Cette architecture de référence inclut des 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, comme 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 des tâches CI/CD avec isolation de charge de travail, car chaque charge de travail est associée et gérée par son équipe dédiée.

Contributors

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

Auteur principal :

Autres contributeurs :

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

Étapes suivantes