À propos des maillages de services
Un maillage de services offre des fonctionnalités axées sur les aspects suivants : gestion du trafic, résilience, stratégie, sécurité, identité forte et observabilité des charges de travail. Votre application est dissociée de ces fonctionnalités opérationnelles, lesquelles sont déplacées par le maillage de services hors de la couche Application, au niveau de la couche d’infrastructure.
Scénarios
Voici quelques-uns des scénarios que vous pouvez mettre en œuvre avec vos charges de travail quand vous utilisez un maillage de services :
Chiffrer tout le trafic dans le cluster : activez le protocole TLS mutuel entre services spécifiés dans le cluster. Cela peut être étendu à l’entrée et à la sortie au niveau du périmètre du réseau, et fournit une option sécurisée par défaut sans aucune modification nécessaire pour le code et l’infrastructure de l’application.
Lancements de versions canary et par phases : spécifiez les conditions de routage d’un sous-ensemble de trafic vers un ensemble de nouveaux services dans le cluster. En cas de test réussi d’une version canary, supprimez le routage conditionnel et augmentez progressivement le pourcentage du trafic vers le nouveau service. Au final, tout le trafic doit être dirigé vers le nouveau service.
Gestion et manipulation du trafic : créez une stratégie sur un service qui va limiter tout le trafic à une version d’un service à partir d’une origine spécifique, ou une stratégie qui applique une stratégie de nouvelle tentative aux classes d’échecs entre les services spécifiés. Mettez en miroir le trafic en direct vers les nouvelles versions des services pendant une migration ou pour déboguer des problèmes. Injectez des erreurs entre les services dans un environnement de test pour tester la résilience.
Observabilité : obtenez des insights sur le mode de connexion de vos services et le trafic qui transite entre eux. Obtenez des métriques, des journaux et des traces pour l’ensemble du trafic dans le cluster y compris pour les entrées/sorties. Ajoutez des fonctionnalités de traçage distribué à vos applications.
Critères de sélection
Avant de sélectionner un maillage de services, veillez à bien comprendre vos exigences et les raisons pour lesquelles vous souhaitez en installer un. Posez les questions suivantes :
Un contrôleur d’entrée est-il suffisant pour mes besoins ? Parfois, la mise en place d’une fonctionnalité telle qu’un test A/B ou une répartition du trafic à l’entrée est suffisante pour prendre en charge le scénario requis. N’augmentez pas le niveau de complexité de votre environnement si cela n’en vaut pas la peine.
Mes charges de travail et mon environnement peuvent-ils tolérer les surcharges supplémentaires ? Tous les composants supplémentaires requis pour prendre en charge le maillage de services nécessitent davantage de ressources, notamment en termes de processeur et de mémoire. De plus, tous les proxys et les vérifications de stratégie associées ajoutent de la latence à votre trafic. Si vous avez des charges de travail très sensibles à la latence ou êtes dans l’impossibilité de fournir des ressources supplémentaires pour répondre aux besoins des composants du maillage de services, reconsidérez votre décision.
Cela ajoute-t-il une complexité supplémentaire inutile ? Si vous installez un maillage de services dans le but d’obtenir une fonctionnalité non critique pour l’entreprise ou les équipes opérationnelles, déterminez si l’accroissement de la complexité résultant des tâches d’installation, de maintenance et de configuration en vaut la peine.
Est-il possible de suivre une approche incrémentielle ? Vous pouvez adopter certains maillages de services proposant un grand nombre de fonctionnalités de manière plus incrémentielle. Dans ce cas, vous installez uniquement les composants nécessaires à votre réussite. Une fois que vous avez gagné en confiance, explorez d’autres fonctionnalités à mesure que de nouveaux besoins émergent. Résistez à l’envie d’installer tout dès le début.
Étapes suivantes
Open Service Mesh (OSM) est un maillage de service pris en charge qui exécute Azure Kubernetes Service (AKS) :
Il existe également des maillages de service fournis par des projets open source et des tiers qui sont couramment utilisés avec AKS. Ces maillages de service open source et de tiers ne sont pas couverts par la stratégie de support d’AKS.
Pour plus d’informations sur le panorama des maillages de service, consultez Panorama des maillages de service de couche 5.
Pour plus d’informations sur les travaux de standardisation des maillages de service :