Modifier

Architecture de microservices sur Azure Kubernetes Service

Azure Active Directory
Container Registry
Kubernetes Service
Load Balancer
Pipelines

Cette architecture de référence présente une application de microservices déployée sur AKS (Azure Kubernetes Service). Elle décrit une configuration AKS de base qui peut être le point de départ de la plupart des déploiements. Cet article suppose une connaissance élémentaire de Kubernetes. Il se concentre principalement sur l’infrastructure et les considérations DevOps liées à l’exécution d’une architecture de microservices sur AKS. Pour obtenir des conseils sur la conception de microservices, consultez Création de microservices sur Azure.

Logo GitHubUne implémentation de référence de cette architecture est disponible sur GitHub.

Architecture

Diagramme illustrant l’architecture de référence AKS.

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

Si vous préférez voir un exemple de microservices plus avancé, basé sur l'architecture de référence AKS, consultez Architecture avancée de microservices AKS (Azure Kubernetes Service).

Workflow

L’architecture est constituée des composants suivants.

Azure Kubernetes Service (AKS). AKS est un cluster Kubernetes managé hébergé dans le cloud Azure. Azure gère le service d'API Kubernetes et seule la gestion des nœuds d'agent vous incombe.

Réseau virtuel. Par défaut, AKS crée un réseau virtuel dans lequel les nœuds d'agent sont connectés. Pour les scénarios plus avancés, vous pouvez commencer par créer le réseau virtuel et contrôler ainsi la configuration des sous-réseaux, la connectivité locale et l'adressage IP, entre autres éléments. Pour plus d’informations, consultez Configurer la mise en réseau avancée dans AKS (Azure Kubernetes Service).

Entrée. Un serveur d'entrée expose des itinéraires HTTP(S) aux services à l'intérieur du cluster. Pour plus d’informations, consultez la section Passerelle API ci-dessous.

Équilibreur de charge Azure. Dès qu'un cluster AKS est créé, il est prêt à utiliser l'équilibreur de charge. Ensuite, une fois le service NGINX déployé, l'équilibreur de charge est configuré avec une nouvelle adresse IP publique qui fait face à votre contrôleur d'entrée. L'équilibreur de charge achemine ainsi le trafic Internet vers l'entrée.

Magasins de données externes. Les microservices sont généralement sans état et écrivent l’état dans des magasins de données externes, tels qu’Azure SQL Database ou Azure Cosmos DB.

Azure Active Directory. AKS utilise une identité Azure Active Directory (Azure AD) pour créer et gérer d’autres ressources Azure telles que les équilibreurs de charge Azure. Azure AD est également recommandé pour l’authentification de l’utilisateur dans les applications clientes.

Azure Container Registry. Utilisez Container Registry pour stocker les images Docker privées, qui sont déployées sur le cluster. AKS peut s’authentifier auprès de Container Registry à l’aide de son identité Azure AD. AKS ne nécessite pas Azure Container Registry. Vous pouvez utiliser d’autres registres de conteneurs, tels que Docker Hub. Assurez-vous simplement que votre registre de conteneurs correspond ou dépasse le contrat de niveau de service (SLA) pour votre charge de travail.

Azure Pipelines. Azure Pipelines fait partie des services Azure DevOps et permet d'exécuter des builds, des tests et des déploiements automatisés. Vous pouvez également utiliser des solutions CI/CD tierces telles que Jenkins.

Helm. Helm est un gestionnaire de package pour Kubernetes qui permet de regrouper et de généraliser les objets Kubernetes en une seule unité qui peut être publiée, déployée et mise à jour, et dont la version peut être contrôlée.

Azure Monitor. Azure Monitor collecte et stocke les métriques et les journaux, les données de télémétrie des applications et les métriques de plateforme pour les services Azure. Utilisez ces données pour superviser l'application, définir des alertes, configurer des tableaux de bord et effectuer une analyse de la cause racine des échecs. Azure Monitor s'intègre à AKS pour collecter des métriques à partir des contrôleurs, nœuds et conteneurs.

Considérations

Conception

Cette architecture de référence se concentre sur les architectures de microservices, bien que la plupart des pratiques recommandées s'appliquent à d'autres charges de travail exécutées 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. Le service doit toujours être joignable, même lorsque les pods se déplacent. L'objet Kubernetes Service permet de modéliser naturellement les microservices dans Kubernetes.

Passerelle API

Les passerelles API sont un modèle de conception de microservices général. Une passerelle API se trouve entre les clients externes et les microservices. Elle fait office de proxy inverse, acheminant les demandes des clients vers les microservices. Elle peut également effectuer diverses tâches transversales telles que l'authentification, l'arrêt SSL et la limitation du débit. Pour plus d'informations, consultez les pages suivantes :

Dans Kubernetes, le fonctionnement d'une passerelle API repose principalement sur un contrôleur d'entrée. Les considérations sont décrites dans la section Entrée.

Stockage des données

Dans une architecture microservices, les services ne doivent pas partager les solutions de stockage de données. Chaque service doit gérer ses propres jeux de données afin d'éviter les dépendances cachées entre services. La séparation des données permet d'éviter tout couplage non intentionnel entre les services, problème qui peut se produire dans les cas de figure où les services partagent des schémas de données sous-jacents. En outre, quand les services gèrent leurs propres magasins de données, ils peuvent utiliser le magasin de données adapté à leurs besoins.

Pour plus d’informations, consultez Conception des microservices : Considérations relatives aux données.

Évitez de stocker des données persistantes dans l'espace de stockage en cluster local, car celui-ci lie les données au nœud. Utilisez plutôt un service externe tel qu’Azure SQL Database ou Azure Cosmos DB. Une autre option consiste à monter un volume de données persistant sur une solution à l'aide de disques Azure ou d'Azure Files.

Pour plus d'informations, consultez Options de stockage pour les applications dans Azure Kubernetes Service.

Objet Service

L'objet Kubernetes Service fournit un ensemble de fonctionnalités qui correspondent aux exigences des microservices en termes de détectabilité des services :

  • Adresse IP. L’objet Service fournit une adresse IP interne statique pour un groupe de pods (ReplicaSet). Quand des pods sont créés ou déplacés, le service est toujours accessible à cette adresse IP interne.

  • Équilibrage de charge : Le trafic envoyé à l’adresse IP du service fait l’objet d’un équilibrage de charge sur les pods.

  • Découverte des services. Les services se voient assigner des entrées DNS internes par le service DNS Kubernetes. Cela signifie que la passerelle API peut appeler un service back-end en utilisant le nom DNS. Le même mécanisme peut être utilisé pour la communication de service à service. Les entrées DNS étant organisées par espace de noms, si vos espaces de noms correspondent à des contextes délimités, le nom DNS pour un service est naturellement mappé au domaine d’application.

Le diagramme suivant illustre la relation conceptuelle entre les services et les pods. Le mappage réel aux ports et adresses IP de point de terminaison est effectué par kube-proxy, proxy de réseau Kubernetes.

Diagramme illustrant les services et pods.

Entrée

Dans Kubernetes, le contrôleur d'entrée peut implémenter le modèle de passerelle API. Dans ce cas, Entrée et Contrôleur d'entrée fonctionnent conjointement pour fournir les fonctionnalités suivantes :

  • Routage des requêtes client vers les services back-end appropriés. Ce routage fournit un point de terminaison unique pour les clients et permet de découpler ces derniers des services.

  • Agrégation de plusieurs requêtes en une seule, pour réduire les échanges excessifs entre le client et le back-end.

  • Déchargement de fonctionnalités à partir des services back-end, comme l'arrêt SSL, l'authentification, la restriction d'adresses IP ou la limitation du débit client.

Entrée abstrait les paramètres de configuration d'un serveur proxy. Il vous faut également un contrôleur d'entrée, qui fournit l'implémentation sous-jacente de l'entrée. Il existe des contrôleurs d'entrée pour Nginx, HAProxy, Traefik et Azure Application Gateway, entre autres.

La ressource Entrée peut être fournie par différentes technologies. Pour fonctionner conjointement, elles doivent être déployées en tant que contrôleur d'entrée dans le cluster. Celui-ci fait office de routeur de périphérie ou de proxy inverse. Un serveur proxy inverse est un point de défaillance unique ou un goulot d’étranglement potentiel. Déployez donc toujours au moins deux réplicas pour une haute disponibilité.

Souvent, la configuration du serveur proxy nécessite des fichiers complexes, qui peuvent être difficiles à paramétrer si vous n'êtes pas un expert. Le contrôleur d'entrée fournit donc une abstraction intéressante. Le contrôleur d'entrée a également accès à l'API Kubernetes, ce qui lui permet de prendre des décisions intelligentes sur le routage et l'équilibrage de charge. Par exemple, le contrôleur d’entrée Nginx contourne le proxy réseau kube-proxy.

En revanche, si vous avez besoin de contrôler totalement les paramètres, vous pouvez passer outre cette abstraction et configurer le serveur proxy manuellement. Pour plus d'informations, consultez Déployer Nginx ou HAProxy sur Kubernetes.

Pour AKS, vous pouvez également utiliser Azure Application Gateway, à l'aide du Contrôleur d'entrée Application Gateway (AGIC). Azure Application Gateway peut exécuter un routage de couche 7 et un arrêt SSL. Il offre également une prise en charge intégrée du pare-feu d'applications web (WAF). Si votre cluster AKS utilise la mise en réseau CNI, Application Gateway peut être déployé dans un sous-réseau du réseau virtuel du cluster ou peut être déployé dans un réseau virtuel différent du réseau virtuel AKS, toutefois, les deux réseaux virtuels doivent être appairés. AGIC prend également en charge le plug-in réseau Kubenet. Lorsque vous utilisez le mode Kubenet, le contrôleur d’entrée doit gérer une table de routage dans le sous-réseau du Application Gateway pour diriger le trafic vers les adresses IP de pod. Pour plus d’informations, consultez Comment configurer la mise en réseau entre Application Gateway et AKS.

Pour plus d'informations sur les services d'équilibrage de charge Azure, consultez Vue d'ensemble des options d'équilibrage de charge dans Azure.

Chiffrement TLS/SSL

Dans les implémentations courantes, le contrôleur d'entrée est utilisé pour l'arrêt SSL. Ainsi, dans le cadre du déploiement du contrôleur d'entrée, vous devez créer un certificat TLS. Utilisez uniquement des certificats auto-signés à des fins de développement/test. Pour plus d'informations, consultez Créer un contrôleur d'entrée HTTPS et utiliser vos propres certificats TLS sur Azure Kubernetes Service (AKS).

Pour les charges de travail de production, procurez-vous des certificats signés auprès d'autorités de certification approuvées. Pour plus d'informations sur la génération et la configuration des certificats Let's Encrypt, consultez Créer un contrôleur d'entrée avec une adresse IP publique statique dans Azure Kubernetes Service (AKS).

Vous devrez peut-être aussi effectuer une rotation de vos certificats conformément aux stratégies de l'organisation. Pour plus d'informations, consultez Effectuer une rotation des certificats dans Azure Kubernetes Service (AKS).

Espaces de noms

Utilisez des espaces de noms pour organiser les services au sein du cluster. Chaque objet dans un cluster Kubernetes appartient à un espace de noms. Par défaut, quand vous créez un objet, il est placé dans l’espace de noms default. Nous vous conseillons toutefois de créer des espaces de noms plus descriptifs afin d’organiser aisément les ressources dans le cluster.

Tout d’abord, les espaces de noms vous aident à empêcher les collisions 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. En outre, les espaces de noms vous permettent d’effectuer les opérations suivantes :

  • Appliquer des contraintes de ressources à un espace de noms, afin que l’ensemble total de pods assignés à cet espace de noms ne dépasse pas le quota de ressources de l’espace de noms

  • Appliquer des stratégies au niveau de l’espace de noms, notamment des stratégies RBAC et de sécurité

Pour une architecture de microservices, envisagez d’organiser les microservices en 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 délimité « Traitement des commandes » peuvent être placés dans le 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 Elasticsearch ou Prometheus pour la supervision des clusters ou Tiller pour Helm.

Sondes d’intégrité

Kubernetes définit deux types de probe d’intégrité qu’un pod peut exposer :

  • Probe readiness : indique à Kubernetes si le pod est prêt à accepter des demandes.

  • Probe liveness : indique à Kubernetes si un pod doit être supprimé et une nouvelle instance démarrée.

Quand vous vous penchez sur les probes, pensez à la façon dont fonctionne un service dans Kubernetes. Un service a un sélecteur d’étiquette qui correspond à un ensemble de pods (zéro ou plus). Kubernetes équilibre la charge du trafic vers les pods qui correspondent au sélecteur. Seuls les pods qui ont correctement démarré et qui sont sains reçoivent du trafic. Si un conteneur plante, Kubernetes supprime le pod et planifie un remplacement.

Il peut arriver qu’un pod ne soit pas prêt à recevoir du trafic, même s’il a démarré correctement. Ce peut être le cas à l’occasion de tâches d’initialisation pendant lesquelles l’application en cours d’exécution dans le conteneur charge des éléments en mémoire ou lit des données de configuration. Pour indiquer qu’un pod est sain mais qu’il n’est pas prêt à recevoir du trafic, définissez une probe readiness.

Les probes liveness traitent le cas où un pod, bien qu’en cours d’exécution, doit être recyclé, car il n’est pas sain. Par exemple, supposons qu’un conteneur sert des requêtes HTTP, mais se bloque pour une raison quelconque. Le conteneur ne plante pas, mais il a arrêté de servir les requêtes. Si vous définissez une probe liveness HTTP, celle-ci ne répond plus et indique à Kubernetes de redémarrer le pod.

Voici quelques considérations liées à la conception des probes :

  • Si votre code met du temps à démarrer, il existe un risque que la probe liveness signale un échec avant la fin du démarrage. Pour éviter cet échec de la sonde d'intégrité, utilisez le paramètre initialDelaySeconds, qui retarde le démarrage de la sonde d'intégrité.

  • Une probe liveness n’est utile que si le redémarrage du pod est susceptible de restaurer celui-ci dans un état sain. Vous pouvez utiliser une probe liveness pour éviter les fuites de mémoire ou les blocages inattendus, mais il est inutile de redémarrer un pod susceptible de rééchouer 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 pour une raison quelconque. Cette situation entraîne l’échec de la probe readiness pour tous les pods dans votre service, puis la suppression de ces derniers de l’équilibrage de charge, suivie de défaillances en cascade en amont. Une meilleure approche consiste à implémenter la gestion de nouvelle tentative au sein de votre service, afin que celui-ci puisse récupérer correctement après des défaillances temporaires.

Contraintes de ressources

La contention de ressources peut affecter la disponibilité d’un service. Définissez des contraintes de ressources pour les conteneurs, afin qu’un seul conteneur ne puisse pas surcharger les ressources de cluster (UC et mémoire). Pour les ressources non-conteneur, telles que les threads ou les connexions réseau, envisagez d’utiliser le modèle de cloisonnement pour les isoler.

Utilisez des quotas de ressources afin de limiter les ressources totales autorisées pour un espace de noms. De cette façon, le front-end ne peut pas priver les services back-end de ressources ou vice versa.

Sécurité

Contrôle d’accès en fonction du rôle

Kubernetes et Azure disposent de mécanismes de contrôle d’accès en fonction du rôle (RBAC) :

  • RBAC Azure contrôle l’accès aux ressources dans Azure, y compris la possibilité de créer des ressources Azure. Ces autorisations peuvent être assignées aux utilisateurs, groupes ou principaux de service. (Un principal de service est une identité de sécurité utilisée par les applications.)

  • Kubernetes RBAC contrôle les autorisations sur l’API Kubernetes. Par exemple, la création de pods et le listage de pods sont des actions qui peuvent être accordées (ou refusées) à un utilisateur au moyen de Kubernetes RBAC. Pour assigner des autorisations Kubernetes à des utilisateurs, vous créez des rôles et des liaisons de rôle :

    • Un rôle est un jeu d’autorisations qui s’appliquent au sein d’un espace de noms. Les autorisations sont définies sous forme de verbes (obtenir, mettre à jour, créer, supprimer) appliqués à des ressources (pods, déploiements, etc.).

    • Une liaison de rôle (RoleBinding) assigne des utilisateurs ou groupes à un rôle.

    • Il existe également un objet ClusterRole, qui est similaire à un rôle, mais s’applique à l’ensemble du cluster, sur tous les espaces de noms. Pour assigner des utilisateurs ou des groupes à un rôle de cluster (ClusterRole), créez une liaison de rôle de cluster (ClusterRoleBinding).

AKS intègre ces deux mécanismes RBAC. Quand vous créez un cluster AKS, vous pouvez le configurer afin d’utiliser Azure AD pour l’authentification utilisateur. Pour plus d’informations sur la façon d’effectuer cette configuration, consultez Intégrer Azure Active Directory dans Azure Kubernetes Service.

Une fois cette configuration effectuée, un utilisateur qui souhaite accéder à l’API Kubernetes (par exemple, via kubectl) doit se connecter à l’aide de ses informations d’identification Azure AD.

Par défaut, un utilisateur Azure AD n’a pas accès au cluster. Pour accorder l’accès, l’administrateur de cluster crée des liaisons de rôle qui font référence à des utilisateurs ou groupes Azure AD. Si un utilisateur ne dispose pas d’autorisations pour une opération particulière, celle-ci échoue.

Si les utilisateurs n’ont par défaut aucun accès, comment l’administrateur de cluster peut-il créer les liaisons de rôle initialement ? Un cluster AKS a en fait deux types d’informations d’identification pour appeler le serveur d’API Kubernetes : utilisateur de cluster et administrateur de cluster. Les informations d’identification d’administrateur de cluster accordent un accès complet au cluster. La commande Azure CLI az aks get-credentials --admin télécharge les informations d’identification d’administrateur de cluster et les enregistre dans votre fichier kubeconfig. L’administrateur de cluster peut utiliser ce fichier kubeconfig pour créer des rôles et des liaisons de rôle.

Au lieu de gérer en mode natif des objets de cluster Kuernetes et RoleBinding dans Kubernetes, il est préférable d’utiliser Azure RBAC pour l’autorisation Kubernetes. Cela permet d’unifier la gestion et le contrôle d’accès entre les ressources Azure, AKS et les ressources Kubernetes. Ces attributions de rôles RBAC Azure peuvent cibler le cluster ou les espaces de noms au sein du cluster pour un contrôle d’accès plus précis. Azure RBAC prend en charge un ensemble limité d’autorisations par défaut et vous pouvez le combiner avec le mécanisme Kubernetes natif de gestion des rôles et des roleBindings pour prendre en charge des modèles d’accès avancés ou plus précis. Quand cette option est activée, les principaux Azure AD sont validés exclusivement par Azure RBAC, tandis que les comptes de service et utilisateurs Kubernetes standard sont validés exclusivement par Kubernetes RBAC.

Les informations d’identification d’administrateur de cluster étant particulièrement puissantes, utilisez RBAC Azure pour restreindre l’accès à ces dernières :

  • Le « Rôle administrateur de cluster du service Azure Kubernetes » est autorisé à télécharger les informations d’identification d’administrateur de cluster. Seuls les administrateurs de cluster doivent être assignés à ce rôle.

  • Le « Rôle utilisateur de cluster du service Azure Kubernetes » est autorisé à télécharger les informations d’identification d’utilisateur de cluster. Les utilisateurs non-administrateurs peuvent être assignés à ce rôle. Ce rôle ne donne pas d’autorisations spécifiques sur les ressources Kubernetes à l’intérieur du cluster. Il permet simplement à un utilisateur de se connecter au serveur d’API.

Quand vous définissez vos stratégies RBAC (Kubernetes et Azure), pensez aux rôles dans votre organisation :

  • Qui peut créer ou supprimer un cluster AKS et télécharger les informations d’identification d’administrateur ?
  • Qui peut administrer un cluster ?
  • Qui peut créer ou mettre à jour des ressources au sein d’un espace de noms ?

Nous vous conseillons de définir les autorisations RBAC Kubernetes à l’échelle des espaces de noms, en utilisant des rôles et liaisons de rôle, plutôt que des rôles de cluster (ClusterRoles) et des liaisons de rôle de cluster (ClusterRoleBindings).

Enfin, vous devez déterminer les autorisations dont dispose le cluster AKS pour créer et gérer des ressources Azure, telles que les équilibreurs de charge, le réseau ou le stockage. Pour s’authentifier auprès des API Azure, le cluster utilise un principal de service Azure AD. Si vous ne spécifiez pas de principal de service quand vous créez le cluster, un principal de service est créé automatiquement. Toutefois, pour des raisons de sécurité, nous vous recommandons de créer le principal de service dès le départ, puis de lui assigner les autorisations RBAC minimales. Pour plus d’informations, consultez Principaux de service avec Azure Kubernetes Service.

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, vous pouvez utiliser des identités managées. Une identité managée repose sur l’idée qu’une application ou un service a une identité stockée dans Azure AD et utilise cette identité auprès d’un service Azure. Un principal de service est créé dans Azure AD pour l’application ou le service, qui s’authentifie à l’aide de jetons OAuth 2.0. Le code de processus en cours d’exécution peut obtenir de manière transparente le jeton à utiliser. Ainsi, vous n’avez pas besoin de stocker de mots de passe ou de chaînes de connexion. Vous pouvez utiliser des identités managées dans AKS en affectant des identités Azure AD à des pods individuels, à l’aide d’identités de charge de travail Azure AD (préversion).

Tous les services Azure ne prennent pas en charge l’authentification à l’aide d’identités managées. Pour obtenir une liste, consultez Services Azure qui prennent en charge l’authentification Azure AD.

Même avec des identités managées, vous devrez probablement stocker certaines informations d’identification ou d’autres secrets d’application, que ce soit pour des services Azure qui ne prennent pas en charge les identités managées, des services tiers, des clés API, etc. Voici quelques options pour stocker des secrets de manière sécurisée :

L’utilisation d’un système comme HashiCorp Vault ou Azure Key Vault offre plusieurs avantages, tels que les suivants :

  • Contrôle centralisé des secrets
  • Garantie que tous les secrets sont chiffrés au repos
  • Gestion centralisée des clés
  • Contrôle d’accès des secrets
  • Audit

Sécurité des conteneurs et des orchestrateurs

Voici des pratiques recommandées pour sécuriser vos pods et conteneurs :

  • Monitoring des menaces : Monitorez les menaces à l’aide de Microsoft Defender pour les conteneurs (ou de fonctionnalités tierces). Si vous hébergez des conteneurs sur une machine virtuelle, utilisez Microsoft Defender pour les serveurs ou une capacité tierce. Vous pouvez également intégrer des journaux provenant d’une solution de monitoring de conteneurs dans Azure Monitor à Microsoft Sentinel ou à une solution SIEM existante.

  • Surveillance des vulnérabilités : Surveillez en continu les images et les conteneurs en cours d’exécution pour identifier les vulnérabilités connues en utilisant Microsoft Defender pour le cloud ou une solution tierce disponible via Place de marché Azure.

  • Automatisez la mise à jour corrective des images à l’aide d’ACR Tasks, fonctionnalité d’Azure Container Registry. 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 des développeurs d’applications et sont gérées par d’autres mainteneurs du projet. Quand ces images sont corrigées en amont, il est important que vous mettiez à jour, testiez et redéployiez vos propres images, afin qu’elles soient exemptes de vulnérabilités de sécurité connues. ACR Tasks peut aider à automatiser ce processus.

  • Stockez les images dans un registre privé approuvé, tel qu’Azure Container Registry ou Docker Trusted Registry. Utilisez un webhook d’admission de validation dans Kubernetes pour vous assurer que les pods ne peuvent extraire des images que du registre approuvé.

  • Appliquer 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 n’offrent 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é.

DevOps

Cette architecture de référence fournit un modèle Azure Resource Manager pour l'approvisionnement des ressources cloud et de leurs dépendances. Grâce aux [modèles Azure Resource Manager][arm-template], vous pouvez utiliser les services Azure DevOps pour approvisionner différents environnements en quelques minutes, par exemple pour reproduire des scénarios de production. Cela vous permet de réduire les coûts et de n'utiliser l'environnement de test de charge que lorsque cela est nécessaire.

Suivez les critères d'isolement de la charge de travail pour structurer votre modèle ARM. Une charge de travail est généralement définie comme une fonctionnalité arbitraire ; vous pouvez, par exemple, disposer d'un modèle distinct pour le cluster et d'un autre pour les services qui en dépendent. L'isolement de la charge de travail permet à DevOps d'effectuer une intégration et une livraison continues (CI/CD), car chaque charge de travail est associée et gérée par l'équipe DevOps correspondante.

Points à prendre en considération pour le déploiement (CI/CD)

Voici certains objectifs 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 d’être déployée en production, une nouvelle version d’un service est déployée sur les environnements de développement/test/assurance qualité à des fins de 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.

Pour obtenir des recommandations spécifiques et accéder aux meilleures pratiques, consultez Intégration continue/livraison continue (CI/CD) pour les microservices.

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ûts de Microsoft Azure Well-Architected Framework.

Voici quelques points à prendre en compte pour certains des services utilisés dans cette architecture.

Azure Kubernetes Service (AKS)

Aucun coût n'est associé à AKS au niveau du déploiement, de la gestion et des opérations du cluster Kubernetes. Vous payez uniquement pour les instances de machines virtuelles, le stockage et les ressources réseau consommées par votre cluster Kubernetes.

Pour estimer le coût des ressources requises, reportez-vous à la Calculatrice de services conteneurs.

Azure Load balancer

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 NAT 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 propose Azure Pipelines en tant que service individuel. Vous bénéficiez d'une tâche gratuite hébergée par Microsoft, avec 1 800 minutes par mois pour l'intégration et la livraison continues (CI/CD), et d'un travail auto-hébergé, avec un nombre de minutes mensuelles illimité. Les travaux supplémentaires sont facturés. Pour plus d'informations, consultez Tarification d'Azure DevOps Services.

Azure Monitor

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

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.

Implémentation de référence des microservices AKS

Étapes suivantes