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

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, qui sert de 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.

Architecture

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 afin de planifier une 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 messages à partir de la file de messages Service Bus.

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

   • 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 Azure DocumentDB.

   • Les politiques Advanced Container Networking Services (Cilium NetworkPolicy) régissent le trafic entre services au sein du cluster, et le plan de contrôle applique de manière transparente le chiffrement facultatif pour les pods entre les nœuds (WireGuard). Advanced Container Networking Services n’est pas activé par défaut. Il extrait les données au niveau du nœud et de pod et les ingère dans Azure Monitor pour une visibilité de bout en bout.

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 de remise lit les données d’Azure Managed Redis.

Composants

• AKS est une plateforme Kubernetes managée qui fournit des clusters managés pour le déploiement et la mise à l’échelle d’applications conteneurisées. Quand vous utilisez AKS, Azure gère le serveur d’API Kubernetes. L’opérateur de cluster peut accéder aux nœuds Kubernetes ou aux pools de nœuds et les gérer. Cette architecture utilise les fonctionnalités d’infrastructure AKS suivantes :

  • L’ID Microsoft Entra géré par AKS pour le contrôle d’accès en fonction du rôle Azure (Azure RBAC) est une fonctionnalité qui intègre Microsoft Entra ID à AKS pour appliquer le contrôle d’accès basé sur l’identité. Dans cette architecture, elle garantit une authentification et une autorisation sécurisées, centralisées pour les utilisateurs et les charges de travail du cluster.

  • 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 tout en fournissant des fonctionnalités de stratégie réseau intégrées et une visibilité du trafic.

  • Advanced Container Networking Services est une suite de fonctionnalités de mise en réseau managées pour AKS qui fournit une observabilité réseau et une sécurité améliorée en cluster :

    • L’observabilité du réseau de conteneurs utilise des outils basés sur le filtre de paquets eBPF (Extended Berkeley Packet Filter), comme Hubble et Retina, pour collecter des requêtes DNS (Domain Name System), des flux pod-à-pod et pod-à-service, des suppressions de paquets et d’autres métriques. Il fonctionne sur les plans de données Cilium et non-Cilium Linux. Il s’intègre également au service managé Azure Monitor pour Prometheus et Azure Managed Grafana pour la visualisation et les alertes. Dans cette architecture, Container Network Observability diagnostique les configurations incorrectes de stratégie, la latence DNS ou les erreurs et les déséquilibres du trafic entre les microservices.

    • Container Network Security s’applique aux clusters qui utilisent Azure CNI alimenté par Cilium. Il applique les ressources Cilium NetworkPolicy, y compris le filtrage de sortie complet (FQDN) basé sur le nom de domaine complet, pour implémenter la segmentation du réseau de confiance zéro et réduire la surcharge opérationnelle. Dans cette architecture, les politiques de FQDN en cluster fonctionnent avec Pare-feu Azure ou Azure NAT Gateway pour appliquer la sortie sous le principe du moindre privilège tout en simplifiant la gestion des politiques.

  • Le module complémentaire Azure Policy pour AKS est une extension intégrée qui apporte des contrôles de gouvernance et de conformité directement dans vos clusters AKS. Il applique des règles de gouvernance sur les ressources AKS à l’aide d’Azure Policy. Dans cette architecture, elle applique la conformité en validant les configurations et en limitant les déploiements non autorisés.

  • L’entrée NGINX gérée avec le module complémentaire de routage des applications est une fonctionnalité d’AKS qui vous permet d’exposer vos applications à Internet à l’aide du trafic HTTP ou HTTPS. Il fournit un contrôleur d’entrée NGINX préconfiguré pour AKS. Dans cette architecture, elle gère le routage du trafic vers les services et permet l’exposition de pods à Application Gateway.

  • La séparation du pool de nœuds système et utilisateur est une pratique architecturale qui divise les nœuds de cluster en deux types distincts de pools de nœuds et isole les composants d’infrastructure AKS des charges de travail d’application. Dans cette architecture, la sécurité et l’efficacité des ressources sont améliorées en dédicant des pools de nœuds à des rôles opérationnels spécifiques.

  • L’ID de charge de travail est un moyen sécurisé et évolutif pour les charges de travail Kubernetes d’accéder aux ressources Azure à l’aide de l’ID Microsoft Entra sans avoir besoin de secrets ou d’informations d’identification stockés dans le cluster. L’ID de charge de travail permet aux charges de travail AKS d’accéder en toute sécurité aux ressources Azure à l’aide de l’identité fédérée. Dans cette architecture, elle élimine le besoin de secrets et améliore la posture de sécurité par le biais d’un accès basé sur l’identité.

• Application Gateway est un service géré par Azure qui fournit des fonctionnalités d’équilibrage de charge de couche 7 et de pare-feu d’applications web (WAF). Dans cette architecture, elle expose le microservice d’ingestion en tant que point de terminaison public et équilibre le trafic web entrant vers l’application.

• Le Pare-feu Azure est un service géré par Azure qui fournit une sécurité réseau intelligente et native cloud et une protection contre les menaces. Dans cette architecture, elle contrôle les communications sortantes des microservices vers des ressources externes, ce qui autorise uniquement les noms de domaine complets approuvés comme trafic de sortie. Le pare-feu effectue également une traduction d’adresses réseau source (SNAT) sur les flux de sortie, de sorte que ses adresses IP publiques deviennent l’identité de sortie du cluster pour les listes d’autorisation des partenaires.

• Azure Private Link est un service géré par Azure qui permet une connectivité privée aux offres PaaS (Platform as a Service) Azure via le réseau principal Microsoft. Dans cette architecture, il affecte des adresses IP privées pour accéder à Azure Container Registry et Azure Key Vault à partir de pools de nœuds AKS via des points de terminaison privés.

• Le réseau virtuel Azure est un service géré par Azure qui fournit des environnements isolés et sécurisés pour exécuter des applications et des machines virtuelles. Dans cette architecture, on utilise une topologie hub-spoke appairée. Le réseau hub héberge le Pare-feu Azure et Azure Bastion. Le réseau spoke contient des sous-réseaux de pool de nœuds utilisateur et système AKS, ainsi que le sous-réseau Application Gateway.

Stockage externe et autres composants

• Azure Managed Redis est un service géré par Azure qui fournit un magasin de données en mémoire hautes performances pour la mise en cache, le stockage de session et l’accès aux données en temps réel. Au-delà de la mise en cache traditionnelle, il inclut la prise en charge des types de données et fonctionnalités avancés tels que le stockage de documents JSON, la recherche en texte intégral et la recherche vectorielle et le traitement de flux. Dans cette architecture, le microservice de livraison utilise Azure Managed Redis comme magasin d’état et cache latéral pour améliorer la vitesse et la réactivité pendant le trafic lourd.

• Container Registry est un service géré par Azure qui stocke des images conteneur privées pour le déploiement dans AKS. Dans cette architecture, elle contient les images conteneur pour les microservices et AKS s’authentifie avec elle à l’aide de son identité managée Microsoft Entra. Vous pouvez également utiliser d’autres registres, comme Docker Hub.

• Azure Cosmos DB est un service de base de données noSQL distribué à l’échelle mondiale, relationnelle et vectorielle géré par Azure. Dans cette architecture, Azure Cosmos DB et Azure DocumentDB servent de magasins de données externes pour chaque microservice.

• Key Vault est un service géré par Azure qui stocke et gère en toute sécurité les secrets, les clés et les certificats. Dans cette architecture, Key Vault stocke les informations d’identification utilisées par les microservices pour accéder à Azure Cosmos DB et à Azure Managed Redis.

• Azure Monitor est une plateforme d’observabilité gérée par Azure qui collecte des métriques, des journaux et des données de télémétrie entre les services. Dans cette architecture, elle permet de surveiller l’application, les alertes, les tableaux de bord et l’analyse de la cause racine des défaillances dans AKS et les services intégrés.

  L’observabilité du réseau de conteneurs pour Advanced Container Networking Services utilise Hubble pour la visibilité des flux et Retina pour la télémétrie réseau organisée. Ces outils s’intègrent aux back-ends d’observabilité managée, comme le service managé Azure Monitor pour Prometheus et Azure Managed Grafana, pour la résolution des problèmes et la création de rapports d’objectif de niveau de service (SLO).

• Service Bus est un service de messagerie géré par Azure qui prend en charge la communication fiable et asynchrone entre les applications distribuées. Dans cette architecture, Service Bus sert de couche de mise en file d’attente entre les microservices d’ingestion et de flux de travail, ce qui permet d’échanger des messages découplés et évolutifs.

D'autres composants du système support des opérations

• Flux est une solution de livraison continue extensible et open source prise en charge par Azure pour Kubernetes qui active GitOps dans AKS. Dans cette architecture, Flux automatise les déploiements en synchronisant les fichiers manifeste d’application à partir d’un référentiel Git, ce qui garantit une livraison cohérente et déclarative des microservices au cluster AKS.

• Helm est un gestionnaire de package natif Kubernetes qui regroupe des objets Kubernetes dans une unité unique pour la publication, le déploiement, le contrôle de version et la mise à jour. Dans cette architecture, Helm est utilisé pour empaqueter et déployer des microservices sur le cluster AKS.

• Le fournisseur de pilotes CSI du magasin de secrets Key Vault est un pilote intégré à Azure qui permet aux clusters AKS de monter des secrets à partir de Key Vault à l’aide de volumes CSI. Dans cette architecture, les secrets sont montés directement dans des conteneurs de microservice, ce qui permet une récupération sécurisée des informations d’identification pour Azure Cosmos DB et Azure Managed Redis.

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. Flux et ArgoCD sont disponibles en tant qu’extensions de cluster.

Au lieu de stocker les informations d’identification pour Azure Cosmos DB et Azure Managed 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 Managed Redis prend également en charge l’authentification à l’aide d’identités managées.

Détails du scénario

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é. Le client peut suivre l’emplacement du drone et voir une heure d’arrivée estimée en continu pendant que la livraison est en cours.

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

• Le déchargement de fonctionnalités telles que la terminaison SSL (Secure Sockets Layer), l’authentification, les restrictions d’adresse IP et la limitation ou le contrôle du débit du client à partir des services de back-end

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 des zones DNS privées 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.

Configurez 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. Configurez tous les microservices pour utiliser des noms de domaine personnalisés et des certificats SSL, qui sécurisent la communication entre microservices au sein du cluster AKS.

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.

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

Utilisez Azure CNI optimisé par Cilium. Le plan de données eBPF offre des performances de routage appropriées et prend en charge n’importe quelle taille de cluster. Cilium applique en mode natif Kubernetes NetworkPolicy et fournit une observabilité du trafic riche. Pour plus d’informations, consultez Configurer Azure CNI alimenté par Cilium dans AKS.

Pour des besoins spécifiques en matière de gestion des adresses IP, Azure CNI alimenté par Cilium prend en charge les modèles d'adresses IP pour les pods, tant ceux routés par le réseau virtuel que ceux en superposition. Pour en savoir plus, consultez Azure CNI optimisé par Cilium.

Stratégies réseau confiance zéro

Les stratégies réseau spécifient la façon dont les pods AKS communiquent 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. Définissez et appliquez Kubernetes NetworkPolicy (implémenté par Advanced Container Networking Services/Cilium) pour segmenter le trafic entre les microservices et restreindre les sorties aux noms de domaine complets autorisés uniquement.

Une stratégie d’implémentation d’une stratégie d’approbation 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 une politique de refus total qui s’applique à tous les pods situés dans le namespace backend-dev.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: backend-dev
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  ingress:
  - fromEntities: []
  egress:
  - toEntities: []

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 Cilium est appliquée à tout pod dans l’espace backend-dev de noms qui possède un label correspondant à app.kubernetes.io/component: backend. La politique refuse tout trafic, à moins qu'il provienne d'un pod avec une étiquette qui correspond à app.kubernetes.io/part-of: dronedelivery.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/part-of: dronedelivery
    toPorts:
    - 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. Pour connaître les meilleures pratiques pour les stratégies réseau dans AKS, consultez Utiliser des stratégies réseau dans AKS.

Lorsque vous utilisez Azure CNI alimenté par Cilium, Kubernetes NetworkPolicy est appliqué par Cilium. Pour les exigences spécialisées, Azure fournit d’autres moteurs de stratégie réseau, notamment le gestionnaire de stratégies réseau Azure et Calico. Nous vous recommandons Cilium comme moteur de stratégie réseau par défaut.

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 les unités de traitement centralisées (UC), la mémoire et les unités de traitement graphique (GPU)

• Ressources de stockage, y compris le nombre de volumes ou la quantité d’espace disque pour une classe de stockage spécifique

• Nombre d’objets, comme 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 :

• Appliquer des quotas de ressources
• Quotas de ressources

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 leurs limites de ressources lors de charges élevées. Une stratégie de mise à l’échelle automatique doit tenir compte des pods et des nœuds.

Mise à l’échelle automatique des clusters

L’autoscaler du cluster met à l’échelle le nombre de nœuds. Si les pods ne peuvent pas être planifiés en raison de contraintes de ressources, l’autorité de certification 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 (CA) vérifie toutes les quelques secondes la présence de pods en attente ou de nœuds vides, et ajuste le dimensionnement du cluster AKS en conséquence.

L’exemple suivant montre la configuration du CA à partir du modèle Bicep du cluster :

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 définissent des exemples de nœuds minimum et maximal pour l’autorité de certification :

minCount: 2
maxCount: 5

Mise à l'échelle automatique horizontale des pods

L’autoscaler de pod horizontal (HPA) met à l’échelle les pods en fonction des CPU, 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. Effectuez un test de charge de vos services pour déterminer ces nombres.

Le CA et le HPA travaillent ensemble, alors activez les deux options d'autoscaler dans votre cluster AKS. Le HPA met à l’échelle l’application, tandis que le CA met à l’échelle l’infrastructure.

L’exemple suivant définit les métriques de ressource pour hpA :

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

Le HPA examine les ressources réelles consommées ou d’autres métriques lors de l'exécution des pods. 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 réglages de processeur et de mémoire de vos pods pour qu’ils correspondent aux schémas 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 le processeur et la mémoire disponibles pour d’autres pods et permet d’assurer une utilisation efficace de vos clusters AKS.

Dans cette architecture, le 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 événementielle de Kubernetes

Le module complémentaire Kubernetes Event-Driven Autoscaling (KEDA) permet une mise à l'échelle automatique pilotée par les événements, ce qui permet d'adapter votre microservice pour répondre durablement et de manière rentable à la demande. Par exemple, KEDA peut augmenter la capacité des microservices lorsque le nombre de messages dans la file d'attente de bus de services dépasse des seuils spécifiques.

Dans le scénario 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 de santé

Kubernetes répartit le trafic vers les pods correspondant à un sélecteur de labels pour un service. Seuls les pods qui démarrent avec succès et qui sont en bonne santé reçoivent le trafic. En cas de crash d’un conteneur, Kubernetes supprime le pod et planifie un remplacement. Kubernetes définit trois types de sondes de santé qu’un pod peut exposer :

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

• Le liveness probe indique à Kubernetes si un pod doit être supprimé et qu'une nouvelle instance doit être démarrée.

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

Les sondes liveness gèrent les pods en cours d'exécution qui sont non sains et doivent être recyclés. Par exemple, si un conteneur qui traite les requêtes HTTP se bloque, le conteneur ne se bloque pas, mais il cesse de traiter les requêtes. La sonde liveness HTTP cesse de répondre, ce qui avertit Kubernetes de redémarrer le pod.

Parfois, un pod peut ne pas être prêt à recevoir le trafic, même si le pod démarre correctement. Par exemple, l’application qui s’exécute dans le conteneur peut effectuer des tâches d’initialisation. La sonde d'état de préparation 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 de santé, avec un délai et un temps d'attente spécifiquement adaptés aux vérifications qu’ils effectuent. La formule HPA repose sur la phase de disponibilité du pod, il est donc essentiel que les sondes de santé existent et soient précises.

Supervision

La surveillance est essentielle dans une architecture de microservices pour détecter les anomalies, diagnostiquer les problèmes et comprendre les dépendances de service. Application Insights, qui fait partie d’Azure Monitor, fournit une analyse des performances des applications (APM) pour les applications écrites dans .NET, Node.js, Java et de nombreux autres langages. Azure offre plusieurs fonctionnalités intégrées pour une visibilité de bout en bout :

• Le service managé Azure Monitor pour Prometheus collecte et alerte les métriques d’infrastructure et de charge de travail.

• La fonctionnalité Live Data dans Container Insights surveille l’intégrité et l’utilisation des ressources des clusters, nœuds et conteneurs AKS.

• Azure Managed Grafana visualise les métriques et les tableaux de bord pour les clusters et les microservices.

L'observabilité des services avancés de mise en réseau de conteneurs complète ces outils en fournissant une visibilité approfondie basée sur eBPF concernant le comportement réseau des clusters AKS. Il capture la latence DNS, les flux de pod à pod et de service, les baisses de stratégie réseau et les métriques de protocole de niveau 7, telles que les codes d’état HTTP et les temps de réponse. Cette télémétrie s’intègre au service managé Azure Monitor pour Prometheus pour les métriques et Azure Managed Grafana pour les tableaux de bord. Le plan de données Cilium eBPF fournit une visibilité et une résolution des problèmes au niveau du flux. Lorsqu’elle est combinée avec Advanced Container Networking Services et Azure Monitor, cette fonctionnalité offre une observabilité réseau de bout en bout. Cette intégration permet de détecter les goulots d’étranglement réseau, les mauvaises configurations de stratégie et les problèmes de communication que l’APM traditionnel risque de manquer.

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

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 workload, car elle ne nécessite pas de secret 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 recevoir une identité de charge de travail unique pour faciliter les affectations RBAC Azure à privilèges minimum. Affectez uniquement des identités 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’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. Il 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.

Advanced Container Networking Services fournit une segmentation réseau en cluster et des contrôles d’approbation zéro pour les clusters AKS. Utilisez des stratégies réseau Cilium sur Azure CNI alimenté par Cilium pour implémenter la segmentation des couches 3 et 4 au sein du cluster. La sécurité avancée de Container Networking Services étend cette base en ajoutant des fonctionnalités avancées :

• Filtrage de sortie basé sur le nom de domaine complet pour restreindre le trafic sortant aux domaines approuvés.

• Stratégies prenant en charge les niveaux 7 pour les protocoles tels que HTTP et gRPC Remote Procedure Call (gRPC) pour valider et contrôler la communication au niveau de l’application.

• Chiffrement WireGuard pour sécuriser le trafic d'un pod à l'autre et protéger les données sensibles en transit.

  Ces fonctionnalités fonctionnent en même temps que les défenses de périmètre telles que les groupes de sécurité réseau (NSG) et le Pare-feu Azure pour fournir une approche de sécurité en couches qui applique le contrôle du trafic à partir du cluster.

• Si le microservice doit communiquer avec des ressources, comme 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 une gestion de la posture de sécurité, une évaluation des vulnérabilités pour les microservices, la protection contre les menaces d’exécution et d’autres fonctionnalités de sécurité.

Plan de données réseau et moteurs de stratégie

Cilium sur AKS est actuellement pris en charge pour les nœuds Linux et applique NetworkPolicy dans le plan de données. Tenez compte des mises en garde de la politique, telles que l'utilisation de ipBlock avec des adresses IP de nœud, des adresses IP de pod, et des pods en réseau hôte qui utilisent une identité d’hôte. Les politiques au niveau du pod ne s’appliquent pas. Alignez les versions AKS et Cilium avec la matrice de version prise en charge. Pour plus d’informations, consultez les limitations d’Azure CNI propulsées par Cilium.

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 dans le cadre 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 de cluster AKS via un pipeline de déploiement automatisé, comme les workflows GitHub Actions .

• 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. Si les utilisateurs et un générateur de mise à l’échelle automatique tentent de modifier le nombre de réplicas, un comportement inattendu peut se produire. 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 évincés fréquemment quand l'application réduit ou augmente sa capacité. 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 (NAT) pour éviter l’épuisement des ports SNAT (Source Network Address Translation).

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

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

Étapes suivantes

• Présentation d’AKS
• Qu’est-ce que le réseau virtuel ?
• Qu’est-ce que Private Link ?
• Qu’est-ce qu’Application Gateway ?
• Qu’est-ce qu’Azure Bastion ?
• Présentation de Key Vault
• Présentation de Container Registry
• Vue d’ensemble d’Azure Monitor
• Advanced Container Networking Services

Ressources associées

• Architecture de base pour un cluster AKS
• Concevoir, générer et exploiter des microservices sur Azure avec Kubernetes
• Architecture de microservices sur AKS
• Créer un pipeline CI/CD pour les microservices sur Kubernetes