Partager via

Architecture avancée de microservices AKS (Azure Kubernetes Service)

Application Gateway Azure
Azure Container Registry
Azure Kubernetes Service (AKS)
Réseau virtuel Azure

Cette architecture de référence décrit plusieurs configurations à prendre en compte lorsque vous exécutez des microservices sur Azure Kubernetes Service (AKS). Cet article décrit la configuration de la stratégie réseau, la mise à l’échelle automatique des pods et le suivi distribué sur une application basée sur un microservice.

Cette architecture repose sur l’architecture de base AKS, que Microsoft recommande comme point de départ pour l’infrastructure AKS. La base de référence AKS décrit les fonctionnalités infrastructurelles telles que l’ID de charge de travail Microsoft Entra, les restrictions d’entrée et de sortie, les limites de ressources et d’autres configurations d’infrastructure AKS sécurisées. Ces fonctionnalités ne sont pas abordées dans cet article. Nous vous recommandons de vous familiariser avec l’architecture de base AKS avant de poursuivre le contenu des microservices.

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

Architecture

Diagramme réseau montrant un réseau hub-spoke qui a deux réseaux virtuels appairés et les ressources Azure utilisées par cette implémentation.

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

Si vous préférez commencer par un exemple de microservices de base sur AKS, consultez l’architecture des microservices sur AKS.

Flux de travail

Ce flux de requête implémente les modèles de conception cloud Éditeur-abonné, Consommateurs concurrents et Routage de passerelle. Le workflow suivant correspond au diagramme précédent :

  1. Une requête HTTPS est soumise pour planifier un collecte par drone. La requête passe par Azure Application Gateway dans l’application web d’ingestion, qui s’exécute en tant que microservice en cluster dans AKS.

  2. L’application web d’ingestion produit un message et l’envoie à la file d’attente de messages Azure Service Bus.

  3. Le système back-end affecte un drone et informe l’utilisateur. Le microservice de flux de travail effectue les tâches suivantes :

    • Consomme des informations de message à partir de la file d’attente de messages Service Bus
    • Envoie une requête HTTPS au microservice de remise, qui transmet des données au stockage de données externe 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 des données au stockage de données externes MongoDB

  4. L’architecture utilise une requête HTTPS GET pour retourner l’état de remise. Cette demande passe par Application Gateway dans le microservice de remise.

  5. Le microservice Livraison lit les données à partir d’Azure Cache pour Redis.

Composants

Stockage externe et autres composants

  • Key Vault stocke et gère les clés de sécurité, les valeurs secrètes et les certificats pour les services Azure. Dans cette architecture, les coffres de clés Azure stockent les informations d’identification pour Azure Cosmos DB et Azure Cache pour Redis.

  • Container Registry stocke des images conteneur privées qui peuvent être exécutées dans le cluster AKS. AKS s’authentifie auprès de Container Registry à l’aide de son identité managée Microsoft Entra. Vous pouvez utiliser d’autres registres de conteneurs, tel Docker Hub. Dans cette architecture, Container Registry stocke les images conteneur pour les microservices.

  • Azure Cosmos DB est une base de données NoSQL, relationnelle et vectorielle entièrement managée. Les microservices étant généralement sans état, ils écrivent leur état dans des magasins de données externes. Azure Cosmos DB dispose d’API open source pour MongoDB, PostgreSQL et Cassandra. Dans cette architecture, Azure Cosmos DB et Azure Cosmos DB pour MongoDB servent de magasins de données pour chaque microservice.

  • Service Bus fournit une messagerie cloud fiable en tant que service et une intégration hybride simple. Service Bus prend en charge les modèles de messagerie asynchrones courants dans les applications de microservices. Dans cette architecture, Service Bus sert de couche de mise en file d’attente asynchrone entre les microservices d’ingestion et de flux de travail.

  • Azure Cache pour Redis ajoute une couche de mise en cache à l’architecture de l’application afin d’améliorer la vitesse et les performances des charges de trafic lourd. Dans cette architecture, le microservice de remise utilise Azure Cache pour Redis comme magasin d’état et cache latéral.

  • Azure Monitor collecte et stocke des métriques et journaux, dont une télémétrie d’application et des métriques de plateforme et de service Azure. Dans cette architecture, vous pouvez utiliser ces données pour surveiller l’application, configurer des alertes et des tableaux de bord et effectuer une analyse de la cause racine des défaillances.

D’autres opérations prennent en charge les composants système

  • Helm est un gestionnaire de package pour Kubernetes qui regroupe des objets Kubernetes dans une unité unique que vous pouvez publier, déployer, version et mettre à jour. Dans cette architecture, utilisez des commandes Helm pour empaqueter et déployer des microservices sur le cluster AKS.

  • Fournisseur de pilotes CSI du magasin de secrets Key Vault Le fournisseur Key Vault pour le pilote CSI du magasin de secrets permet l’intégration d’un coffre de clés en tant que magasin de secrets à un cluster AKS via un volume CSI. Dans cette architecture, les secrets du coffre de clés sont montés en tant que volume dans des conteneurs de microservice afin que les microservices puissent récupérer des informations d’identification pour Azure Cosmos DB, Azure Cache pour Redis et Service Bus.

  • Flux est une solution de livraison continue ouverte et extensible pour Kubernetes qui active GitOps dans AKS.

Alternatives

Au lieu d’utiliser un module complémentaire de routage d’applications, vous pouvez utiliser des alternatives comme Application Gateway pour conteneurs et le module complémentaire de passerelle Istio. Pour obtenir une comparaison des options d’entrée dans AKS, consultez Entrée dans AKS. Application Gateway pour conteneurs est une évolution du contrôleur d’entrée Application Gateway et fournit des fonctionnalités supplémentaires telles que le fractionnement du trafic et l’équilibrage de charge de tourniquet pondéré.

Vous pouvez utiliser ArgoCD comme outil GitOps au lieu de Flux v2. Flux v2 et ArgoCD sont disponibles en tant qu’extensions de cluster.

Au lieu de stocker des informations d’identification pour Azure Cosmos DB et Azure Cache pour Redis dans les coffres de clés, nous vous recommandons d’utiliser des identités managées pour vous authentifier, car les mécanismes d’authentification sans mot de passe sont plus sécurisés. Pour plus d’informations, consultez Utiliser des identités managées pour vous connecter à Azure Cosmos DB à partir d’une machine virtuelle Azure et authentifier une identité managée à l’aide de l’ID Microsoft Entra pour accéder aux ressources Service Bus. Azure Cache pour Redis prend également en charge l’authentification à l’aide d’identités managées.

Détails du scénario

L’exemple d’application Fabrikam Drone Delivery Shipping présentée dans le diagramme précédent implémente les composants et pratiques architecturaux décrits par cet article. Dans cet exemple, Fabrikam, Inc., société fictive, gère une flotte de drones. 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é. Pendant que la livraison est en cours, le client peut suivre l’emplacement du drone et voir une heure estimée en continu de l’arrivée.

Recommandations

Vous pouvez appliquer les recommandations suivantes à la plupart des scénarios. Suivez ces recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.

Entrée NGINX managée avec le module complémentaire de routage des applications

Le Routage de passerelle API est un modèle de conception de microservices général. Une passerelle d’API fonctionne en tant que proxy inverse qui achemine les requêtes des clients vers les microservices. La ressource d’entrée Kubernetes et le contrôleur d’entrée gèrent la plupart des fonctionnalités de passerelle d’API en effectuant les actions suivantes :

  • Routage des demandes des clients vers les services principaux appropriés pour fournir un point de terminaison unique pour les clients et aider à dissocier les clients des services

  • Agrégation de plusieurs requêtes en une seule requête pour réduire la conversation entre le client et le serveur principal

  • Fonctionnalités de déchargement telles que l’arrêt SSL (Secure Sockets Layer), l’authentification, les restrictions d’adresse IP et la limitation du débit du client à partir des services principaux

Les contrôleurs d’entrée simplifient l’ingestion du trafic dans des clusters AKS, améliorent la sécurité et les performances, et économisent des ressources. Cette architecture utilise l’entrée NGINX managée avec le module complémentaire de routage d’application pour le contrôle d’entrée.

Nous vous recommandons d’utiliser le contrôleur d’entrée avec une adresse IP interne (privée) et un équilibreur de charge interne et d’intégrer aux zones système de noms de domaine privés Azure pour la résolution de noms d’hôte des microservices. Configurez l’adresse IP privée ou le nom d’hôte du contrôleur d’entrée en tant qu’adresse du pool principal dans Application Gateway. Application Gateway reçoit le trafic sur le point de terminaison public, effectue des inspections WAF et route le trafic vers l’adresse IP privée d’entrée.

Vous devez configurer le contrôleur d’entrée avec un nom de domaine personnalisé et un certificat SSL afin que le trafic soit chiffré de bout en bout. Application Gateway reçoit le trafic sur l’écouteur HTTPS. Après les inspections waf, Application Gateway achemine le trafic vers le point de terminaison HTTPS du contrôleur d’entrée. Tous les microservices doivent être configurés avec des noms de domaine personnalisés et des certificats SSL afin que la communication entre microservices au sein du cluster AKS soit également sécurisée à l’aide de SSL.

Les charges de travail mutualisées ou un cluster unique qui prend en charge les environnements de développement et de test peuvent nécessiter davantage de contrôleurs d’entrée. Le module complémentaire de routage des applications prend en charge les configurations et personnalisations avancées, notamment plusieurs contrôleurs d’entrée au sein du même cluster AKS et l’utilisation d’annotations pour configurer des ressources d’entrée.

Stratégies réseau confiance zéro

Les stratégies réseau spécifient la façon dont les pods AKS sont autorisés à communiquer entre eux et avec d’autres points de terminaison réseau. Par défaut, tout le trafic entrant et sortant est autorisé vers et depuis des pods. Lorsque vous concevez la façon dont vos microservices communiquent entre eux et avec d’autres points de terminaison, envisagez de suivre un principe de confiance zéro, où l’accès à n’importe quel service, appareil, application ou référentiel de données nécessite une configuration explicite.

Une stratégie d’implémentation d’une stratégie Confiance Zéro consiste à créer une stratégie réseau qui refuse tout trafic d’entrée et de sortie à tous les pods de l’espace de noms cible. L’exemple suivant montre un refus de toutes les stratégies qui s’appliquent à tous les pods situés dans l’espace backend-dev de noms.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Une fois qu’une stratégie restrictive est en place, commencez à définir des règles réseau spécifiques pour autoriser le trafic vers et hors de chaque pod du microservice. Dans l’exemple suivant, la stratégie réseau est appliquée à n’importe quel pod de l’espace backend-dev de noms qui a une étiquette qui correspond app.kubernetes.io/component: backend. La stratégie refuse tout trafic, sauf s’il est source d’un pod qui a une étiquette qui correspond app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Pour plus d’informations sur les stratégies réseau Kubernetes et d’autres exemples de stratégies par défaut potentielles, consultez la documentation sur les stratégies réseau dans la documentation Kubernetes.

Azure fournit trois moteurs de stratégie réseau pour appliquer des stratégies réseau :

  • Cilium pour les clusters AKS qui utilisent Azure CNI optimisé par Cilium
  • Gestionnaire de stratégie réseau Azure
  • Calico, une solution de sécurité réseau open source et de sécurité réseau

Nous vous recommandons d’utiliser Cilium comme moteur de stratégie réseau.

Quotas de ressources

Les administrateurs utilisent des quotas de ressources pour réserver et limiter les ressources dans une équipe de développement ou un projet. Vous pouvez définir des quotas de ressources sur un espace de noms et les utiliser pour définir des limites sur les ressources suivantes :

  • Ressources de calcul, telles que l’UC et la mémoire, ou les GPU
  • Ressources de stockage, y compris le nombre de volumes ou la quantité d’espace disque pour une classe de stockage donnée
  • Nombre d’objets, tels que le nombre maximal de secrets, de services ou de travaux qui peuvent être créés

Une fois le total cumulé des demandes de ressources ou des limites passées le quota affecté, aucun déploiement supplémentaire n’est réussi.

Les quotas de ressources garantissent que l’ensemble des pods affectés à l’espace de noms ne peut pas dépasser le quota de ressources de l’espace de noms. Le serveur frontal ne peut pas utiliser toutes les ressources pour les services principaux, et le serveur principal ne peut pas utiliser toutes les ressources pour les services frontaux.

Quand vous définissez des quotas de ressources, tous les pods créés dans l’espace de noms doivent fournir des demandes ou des limites dans leurs spécifications de pod. S’ils ne fournissent pas ces valeurs, le déploiement est rejeté.

L’exemple suivant montre une spécification de pod qui définit les demandes et limites de quota de ressources :

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Pour plus d’informations sur les quotas de ressources, consultez les articles suivants :

Mise à l’échelle automatique

Kubernetes prend en charge la mise à l’échelle automatique pour augmenter le nombre de pods alloués à un déploiement ou pour augmenter les nœuds du cluster afin d’augmenter le nombre total de ressources de calcul disponibles. La mise à l’échelle automatique est un système autonome et autocorrecteur de rétroaction. Vous pouvez mettre à l’échelle les pods et les nœuds manuellement, mais la mise à l’échelle automatique réduit les chances que les services atteignent des limites de ressources à des charges élevées. Une stratégie de mise à l’échelle automatique doit tenir compte des pods et des nœuds.

Mise à l’échelle automatique du cluster

L’autoscaler de cluster met à l’échelle le nombre de nœuds. Si les pods ne peuvent pas être planifiés en raison de contraintes de ressources, le générateur de mise à l’échelle automatique du cluster provisionne davantage de nœuds. Vous définissez un nombre minimal de nœuds pour maintenir le cluster AKS et vos charges de travail opérationnels, ainsi qu’un nombre maximal de nœuds quand le trafic est dense. L’autoscaler de cluster vérifie toutes les quelques secondes s’il y a des pods en attente ou des nœuds vides, et adapte l’échelle du cluster AKS en conséquence.

L’exemple suivant montre la configuration de l’autorité de certification à partir du modèle Bicep :

autoScalerProfile: {
  'scan-interval': '10s'
  'scale-down-delay-after-add': '10m'
  'scale-down-delay-after-delete': '20s'
  'scale-down-delay-after-failure': '3m'
  'scale-down-unneeded-time': '10m'
  'scale-down-unready-time': '20m'
  'scale-down-utilization-threshold': '0.5'
  'max-graceful-termination-sec': '600'
  'balance-similar-node-groups': 'false'
  expander: 'random'
  'skip-nodes-with-local-storage': 'true'
  'skip-nodes-with-system-pods': 'true'
  'max-empty-bulk-delete': '10'
  'max-total-unready-percentage': '45'
  'ok-total-unready-count': '3'
}

Les lignes suivantes du modèle Bicep illustrent l’exemple de nœuds minimum et maximal pour le générateur de mise à l’échelle automatique du cluster :

minCount: 2
maxCount: 5

Autoscaler de pods horizontaux

L’autoscaler de pod horizontal (HPA) met à l’échelle les pods en fonction de l’UC, de la mémoire ou des métriques personnalisées observées. Pour configurer la mise à l’échelle horizontale des pods, vous spécifiez les métriques cibles et le nombre minimal et maximal de réplicas dans la spécification du pod de déploiement Kubernetes. Testez vos services pour déterminer ces nombres.

L’autorité de certification et HPA fonctionnent ensemble. Activez donc les deux options de mise à l’échelle automatique dans votre cluster AKS. L’autoscaler de pod horizontal met à l’échelle l’application, tandis que l’autoscaler de cluster met à l’échelle l’infrastructure.

L’exemple suivant définit les métriques de ressources pour l’autoscaler de pod horizontal :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA examine les ressources réelles consommées ou d’autres métriques provenant de pods en cours d’exécution. L’autorité de certification provisionne des nœuds pour les pods qui ne sont pas encore planifiés. Par conséquent, l’autorité de certification examine les ressources demandées, comme spécifié dans la spécification du pod. Utilisez des tests de charge pour affiner ces valeurs.

Pour plus d’informations, consultez options de mise à l’échelle pour les applications dans AKS.

Mise à l’échelle automatique verticale des pods

L’autoscaler de pod vertical (VPA) ajuste automatiquement les demandes d’UC et de mémoire de vos pods pour qu’ils correspondent aux modèles d’utilisation de vos charges de travail. Lorsqu’il est configuré, l’application VPA définit automatiquement les demandes de ressources et les limites des conteneurs pour chaque charge de travail en fonction de l’utilisation passée. Le VPA rend l’UC et la mémoire disponibles pour d’autres pods et permet d’assurer une utilisation efficace de vos clusters AKS.

Dans cette architecture, VPA augmente les demandes de processeur et de mémoire et les limites des microservices en fonction de leur utilisation passée. Par exemple, si le microservice de flux de travail consomme plus d’UC que d’autres microservices, le VPA peut surveiller cette utilisation et augmenter les limites du processeur pour le microservice de flux de travail.

Mise à l’échelle automatique basée sur les événements Kubernetes

Le module complémentaire KEDA (Kubernetes Event Driven Autoscaler) permet la mise à l’échelle automatique pilotée par les événements pour mettre à l’échelle votre microservice afin de répondre à la demande de manière durable et rentable. Par exemple, KEDA peut effectuer un scale-up des microservices lorsque le nombre de messages dans la file d’attente Service Bus dépasse des seuils spécifiques.

Dans l’exemple de livraison de drone Fabrikam, KEDA effectue un scale-out du microservice de flux de travail en fonction de la profondeur de file d’attente Service Bus et en fonction de la sortie du microservice d’ingestion. Pour obtenir la liste des scalers KEDA pour les services Azure, consultez Intégrations à KEDA sur AKS.

Sondes d’intégrité

Kubernetes équilibre la charge du trafic vers les pods correspondant à un sélecteur d’étiquette pour un service. Seuls les pods qui ont correctement démarré et qui sont sains reçoivent du trafic. En cas de blocage d’un conteneur, Kubernetes supprime le pod et planifie un remplacement.

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

  • La sonde de préparation indique à Kubernetes si le pod est prêt à accepter les demandes.

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

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

Les sondes probe liveness gèrent les pods en cours d’exécution qui sont on sains et nécessitent un recyclage. Par exemple, si un conteneur servant des requêtes HTTP suspend son exécution, il ne se bloque pas, mais arrête de servir les requêtes. La sonde liveness HTTP cesse de répondre, ce qui avertit Kubernetes de redémarrer le pod.

Il peut arriver qu’un pod ne soit pas prêt à recevoir du trafic, même s’il a démarré correctement. Par exemple, il se peut que l’application en cours d’exécution dans le conteneur soit en train d’effectuer des tâches d’initialisation. La sonde probe readiness indique si le pod est prêt à recevoir du trafic.

Les microservices doivent exposer des points de terminaison dans leur code qui facilitent les sondes d’intégrité, avec un délai et un délai d’expiration adaptés spécifiquement aux vérifications qu’ils effectuent. La formule HPA repose sur la phase prête du pod. Il est donc crucial que les sondes d’intégrité existent et soient précises.

Supervision

Dans une application de microservices, la surveillance de la gestion des performances des applications (APM) est essentielle pour détecter les anomalies, diagnostiquer les problèmes et comprendre rapidement les dépendances entre les services. Application Insights, une fonctionnalité d’Azure Monitor, fournit une surveillance APM pour les applications actives écrites dans .NET Core, Node.js, Java et de nombreux autres langages d’application.

Azure fournit différents mécanismes pour la supervision des charges de travail de microservice :

  • Prometheus managé pour la collecte de métriques. Utilisez Prometheus pour surveiller et alerter sur les performances de l’infrastructure et des charges de travail.

  • Le service managé Azure Monitor pour Prometheus et container Insights fonctionnent ensemble pour une surveillance complète de votre environnement Kubernetes.

  • Grafana managé pour la visualisation de cluster et de microservice.

Pour contextualiser les données de télémétrie de service dans Kubernetes, intégrez les données de télémétrie Azure Monitor à AKS pour collecter des métriques à partir de contrôleurs, de nœuds, de conteneurs et de journaux de conteneurs et de nœuds. Vous pouvez intégrer Application Insights à AKS sans modification du code.

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 Well-Architected Framework.

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.

Tenez compte des points suivants lorsque vous planifiez la sécurité.

  • Utilisez des protections de déploiement dans le cluster AKS. Les mesures de sécurité de déploiement appliquent les meilleures pratiques Kubernetes dans votre cluster AKS via des contrôles Azure Policy.

  • Intégrez l’analyse de sécurité dans les pipelines de génération et de déploiement de microservice. Gérez votre environnement DevOps à l’aide de La sécurité Microsoft Defender pour Cloud DevOps. Utilisez l’analyse du code sans agent et exécutez des outils d’analyse de code statique dans le cadre des pipelines d’intégration continue et de déploiement continu (CI/CD) afin de pouvoir identifier et résoudre les vulnérabilités du code de microservice dans le cadre des processus de génération et de déploiement.

  • Un pod AKS s’authentifie à l’aide d’une identité de charge de travail stockée dans l’ID Microsoft Entra. Vous devez utiliser une identité de charge de travail, car elle ne nécessite pas de clé secrète client.

  • Lorsque vous utilisez des identités managées, l’application peut rapidement obtenir des jetons OAuth 2.0 Azure Resource Manager lors de son exécution. Il n’a pas besoin de mots de passe ou de chaînes de connexion. Dans AKS, vous pouvez affecter des identités à des pods individuels à l’aide de l’ID de charge de travail.

  • Chaque service de l’application de microservice doit se voir attribuer une identité de charge de travail unique pour faciliter les affectations de RBAC moins privilégié. Vous ne devez affecter des identités qu’aux services qui en ont besoin.

  • Dans les cas où un composant d’application requiert un accès API Kubernetes, assurez-vous que les pods d’application sont configurés pour utiliser un compte de service disposant d’un accès d’API d’une étendue appropriée. Pour plus d’informations, consultez Gérer les comptes de service Kubernetes.

  • Tous les services Azure ne prennent pas en charge l’utilisation de l’ID Microsoft Entra pour l’authentification du plan de données. Pour stocker des informations d’identification ou des secrets d’application pour ces services, pour les services autres que Microsoft ou pour les clés API, utilisez Key Vault. Key Vault fournit la gestion centralisée, le contrôle d’accès, le chiffrement au repos et l’audit de toutes les clés et secrets.

  • Dans AKS, vous pouvez monter un ou plusieurs secrets à partir de Key Vault en tant que volume. Le pod peut ensuite lire les secrets de Key Vault comme il lirait un volume normal. Pour plus d’informations, consultez Utiliser le fournisseur Key Vault pour le pilote CSI du magasin de secrets dans un cluster AKS. Nous vous recommandons de conserver des coffres de clés distincts pour chaque microservice. L’implémentation de référence utilise des coffres de clés distincts pour chaque microservice.

  • Si le microservice doit communiquer avec des ressources, telles que des URL externes, en dehors du cluster, contrôlez l’accès via le Pare-feu Azure. Si le microservice n’a pas besoin d’effectuer d’appels sortants, utilisez des clusters isolés réseau.

  • Permettre à Microsoft Defender pour conteneurs de fournir la gestion de la posture de sécurité, l’évaluation des vulnérabilités pour les microservices, la protection contre les menaces au moment de l’exécution et d’autres fonctionnalités de sécurité.

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.

  • La section Optimisation des coûts de l’infrastructure Well-Architected décrit les considérations relatives aux coûts.

  • Utilisez la Calculatrice de prix Azure pour estimer les coûts de votre scénario spécifique.

  • Dans le niveau Gratuit, AKS n’a aucun coût associé au déploiement, à la gestion et aux opérations du cluster Kubernetes. Vous payez uniquement pour les instances de machine virtuelle, le stockage et les ressources réseau que le cluster consomme. La mise à l’échelle automatique du cluster peut réduire sensiblement le coût de celui-ci en supprimant les nœuds vides ou inutilisés.

  • Envisagez d’utiliser le niveau Gratuit d’AKS pour les charges de travail de développement et utilisez les niveaux Standard et Premium pour les charges de travail de production.

  • Envisagez d’activer l’analyse des coûts AKS pour l’allocation granulaire des coûts de l’infrastructure de cluster par des constructions spécifiques à Kubernetes.

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.

Tenez compte des points suivants lorsque vous planifiez la facilité de gestion.

  • Gérez l’infrastructure du cluster AKS via un pipeline de déploiement automatisé. L’implémentation de référence pour cette architecture fournit un flux de travail GitHub Actions que vous pouvez référencer lorsque vous générez votre pipeline.

  • Le fichier de flux de travail déploie l’infrastructure uniquement, pas la charge de travail, dans le réseau virtuel existant et dans la configuration Microsoft Entra. Le déploiement de l’infrastructure et de la charge de travail séparément vous permet de répondre à des problèmes de cycle de vie et opérationnels distincts.

  • Considérez votre flux de travail comme un mécanisme de déploiement dans une autre région en cas de défaillance régionale. Générez le pipeline afin de pouvoir déployer un nouveau cluster dans une nouvelle région avec des modifications de paramètre et d’entrée.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

Tenez compte des points suivants lorsque vous planifiez la scalabilité.

  • Ne combinez pas la mise à l’échelle automatique et la gestion impérative ou déclarative du nombre de réplicas. Les utilisateurs et un générateur de mise à l’échelle automatique tentent de modifier le nombre de réplicas peuvent provoquer un comportement inattendu. Lorsque HPA est activé, réduisez le nombre de réplicas au nombre minimal que vous souhaitez déployer.

  • Un effet secondaire de la mise à l’échelle automatique des pods est que les pods peuvent être créés ou supprimés fréquemment à mesure que l’application est mise à l’échelle ou augmente. Pour atténuer ces effets, effectuez les actions suivantes :

    • Utilisez des probes readiness pour que Kubernetes sache quand un nouveau pod est prêt à accepter du trafic.
    • Utilisez des budgets d’interruption de pod pour limiter le nombre de pods pouvant être supprimés d’un service simultanément.

  • S’il existe un grand nombre de flux sortants à partir du microservice, envisagez d’utiliser des passerelles de traduction d’adresses réseau pour éviter l’épuisement du port de traduction d’adresses réseau source.

  • Les charges de travail multilocataire ou d’autres charges de travail avancées peuvent avoir des exigences d’isolation de pool de nœuds qui demandent plus et probablement des sous-réseaux plus petits. Pour plus d’informations, consultez Ajouter des pools de nœuds avec des sous-réseaux uniques. Les organisations adoptent des normes différentes pour leurs implémentations de type hub-and-spoke. Veillez à suivre les directives de votre organisation.

  • Envisagez d’utiliser CNI avec la mise en réseau de superposition pour conserver l’espace d’adressage réseau.

Étapes suivantes