La topologie de maillage en mode managé vous permet de surveiller la topologie du trafic sur plusieurs clusters. Dans ce mode, une instance de service de topologie de maillage est déployée en tant qu'instance de conteneur élastique afin d'améliorer la fiabilité et la facilité d'utilisation du service. Vous n'avez besoin de déployer qu'une seule instance de service de topologie de maillage pour l'ensemble de l'instance Service Mesh (ASM), ce qui réduit la charge de configuration.
Prérequis
Un cluster Kubernetes a été créé. Pour plus d'informations, consultez la page Créer un cluster ACK managé.
Le cluster Kubernetes a été ajouté à une instance ASM de version 1.18.2.112 ou ultérieure. Pour plus d'informations, consultez la page Ajouter un cluster à une instance ASM.
Une instance Prometheus autogérée a été créée ou Managed Service for Prometheus a été intégré pour surveiller les instances ASM. Pour plus d'informations, consultez les pages Intégrer une instance Prometheus autogérée pour la surveillance du maillage ou Intégrer Managed Service for Prometheus pour la surveillance du maillage de services.
Description de la fonctionnalité
En tant qu'outil d'observabilité d'ASM, la topologie de maillage met à votre disposition une interface visuelle permettant de consulter les services et configurations associés. Cela facilite l'évaluation rapide de l'état de santé des services. La topologie de maillage offre une visualisation puissante du trafic ASM. Elle combine le trafic de requêtes en temps réel avec les informations de configuration d'ASM pour fournir des aperçus instantanés du comportement d'ASM et vous aider à identifier rapidement les problèmes.
Les instances ASM de version 1.18.2.112 et ultérieures prennent en charge la topologie de maillage en mode managé. Dans les versions antérieures, la topologie de maillage ne pouvait être déployée que dans les clusters Kubernetes du plan de données. Le mode managé présente des avantages significatifs en matière d'observation unifiée sur plusieurs clusters, de simplicité de configuration et de fiabilité du service.
La topologie de maillage peut être déployée selon deux modes. Ces derniers diffèrent par leur complexité de configuration et la fiabilité du service.
Mode intra-cluster Kubernetes
Dans ce mode, une instance de service de topologie de maillage doit être déployée dans chaque cluster du plan de données d'une instance ASM. Ce mode de déploiement présente les caractéristiques suivantes :
Une instance de service de topologie de maillage est déployée dans chaque cluster du plan de données. Chaque instance se connecte à l'instance Prometheus du cluster d'hébergement pour observer la topologie du trafic des services au sein de ce cluster.
L'instance de service de topologie de maillage de chaque cluster du plan de données doit être configurée individuellement. En présence de plusieurs clusters, plusieurs adresses IP doivent être configurées, ce qui complexifie la procédure.
La disponibilité d'une instance de service de topologie de maillage dépend de son cluster du plan de données. L'instance peut devenir indisponible en cas de ressources insuffisantes au sein du cluster.
Mode managé
Les instances ASM de version 1.18.2.112 et ultérieures prennent en charge la topologie de maillage en mode managé. Dans ce mode, une instance de service de topologie de maillage est déployée en tant qu'instance de conteneur élastique, offrant ainsi une meilleure fiabilité et une plus grande facilité d'utilisation. Le mode managé présente les caractéristiques suivantes :
Une seule instance de service de topologie de maillage est déployée au sein d'une instance ASM et observe uniformément la topologie du trafic de plusieurs clusters.
Il n'est pas nécessaire de configurer séparément l'instance de service de topologie de maillage pour chaque cluster, ce qui allège la charge de configuration.
Les charges de travail de l'instance de service de topologie de maillage sont déployées sous forme d'instances ECI (Elastic Container Instance), garantissant une fiabilité accrue du service.
Étape 1 : Activer la topologie de maillage en mode managé
Le mode managé est sélectionnable uniquement lors de l'activation de la topologie de maillage. Si le service Mesh Topology est déjà activé, désactivez-le puis réactivez-le.
Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez .
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez .
Sur la page Mesh Topology, cliquez sur Managed Mode puis sur To enable.
-
Dans la boîte de dialogue Enable Mesh Topology in Managed Mode, configurez les paramètres requis et cliquez sur OK.
Paramètre
Description
Clusters to observe
Sélectionnez les clusters du plan de données dont le trafic doit être observé par le service de topologie de maillage. Plusieurs clusters peuvent être sélectionnés. En mode managé, une instance ASM ne dispose que d'une seule instance de service de topologie de maillage.
ImportantAprès avoir configuré les clusters du plan de données à observer, les charges de travail de l'instance de service de topologie de maillage obtiennent des autorisations en lecture seule sur les ressources Service, Pod, Namespace, Deployment, Replicaset, Endpoints et Node dans ces clusters. De plus, elles disposent d'autorisations en lecture seule sur les ressources ConfigMap Istio et Istio-sidecar-injector dans les namespaces istio-system des clusters du plan de données.
Les charges de travail de l'instance de service de topologie de maillage sont déployées en tant qu'instances de conteneurs élastiques sur le plan de contrôle. Cela signifie que ces instances peuvent avoir des autorisations en lecture seule sur les ressources précédentes de plusieurs clusters. Sélectionnez les clusters à observer avec prudence après avoir pris connaissance de cet avertissement.
Configure Prometheus address
Configurez l'adresse HTTP API de l'instance Prometheus dont dépend l'instance de service de topologie de maillage.
Si vous choisissez d'observer un seul cluster, vous pouvez utiliser l'adresse HTTP API de l'instance Prometheus intégrée à ce cluster. Si vous utilisez une instance Managed Service for Prometheus, vous pouvez obtenir l'adresse HTTP API de l'instance en suivant les étapes décrites dans Accéder aux données Prometheus via des URL d'API HTTP.
Si vous choisissez d'observer plusieurs clusters, assurez-vous que l'instance Prometheus dépendante a collecté les métriques Envoy de ces clusters. Vous pouvez créer une instance Prometheus d'agrégation pour les instances Managed Service for Prometheus de plusieurs clusters et obtenir l'adresse HTTP API de cette instance d'agrégation. Pour plus d'informations, consultez la page Créer une instance d'agrégation globale à l'aide de Managed Service for Prometheus.
Access
En mode managé, vous pouvez créer une instance Classic Load Balancer (CLB) pour accéder au service de topologie de maillage. Vous pouvez également utiliser une passerelle ASM pour y accéder. Vous avez la possibilité de créer ou non une instance CLB pour cet accès.
Si vous n'activez pas l'option Create a CLB Instance to Access ASM Mesh Topology,
vous devez finaliser la configuration de l'accès au service de topologie de maillage via une passerelle ASM avant d'activer la topologie de maillage dans la console ASM. Pour plus d'informations, consultez la section Méthode 2 : Utiliser une passerelle ASM pour accéder à la topologie de maillage de l'Étape 2 : Ouvrir la page de connexion de la topologie de maillage dans la rubrique Activer la topologie de maillage pour améliorer l'observabilité. Notez ensuite l'adresse IP de la passerelle ASM.
Authentication
La connexion à la topologie de maillage en mode managé est possible uniquement via un compte Alibaba Cloud ou via OpenID Connect (OIDC).
To log on by using an Alibaba Cloud account, vous devez spécifier The address to access Mesh Topology si vous n'avez pas activé l'option Create a CLB Instance to Access ASM Mesh Topology à l'étape Access de l'assistant de configuration. Cette adresse correspond à l'adresse IP de la passerelle ASM configurée à l'étape Access de l'assistant.
To log on by using OIDC, vous devez configurer les champs ClientID, ClientSecret et IssuerUri du fournisseur d'identité (IdP). Pour plus d'informations sur la configuration d'un IdP, consultez l'Étape 2 : Ajouter et configurer une application OIDC de la rubrique Intégrer Alibaba Cloud IDaaS à ASM pour mettre en œuvre l'authentification unique.
Étape 2 : Accéder au service de topologie de maillage
En mode managé, vous pouvez accéder au service de topologie de maillage via une instance CLB ou une passerelle ASM. Pour plus d'informations, consultez les sections Méthode 1 : Accéder directement à la topologie de maillage et Méthode 2 : Utiliser une passerelle ASM pour accéder à la topologie de maillage de l'Étape 2 : Ouvrir la page de connexion de la topologie de maillage dans la rubrique Activer la topologie de maillage pour améliorer l'observabilité.
Références
Si vous constatez une latence de réponse élevée pour certaines requêtes, utilisez les journaux d'accès pour en identifier la cause. Pour plus d'informations, consultez la page Résoudre les problèmes de latence de réponse élevée à l'aide des journaux d'accès.
Pour obtenir la latence d'appel de service la plus faible, utilisez la fonctionnalité de routage conscient de la zone afin qu'un client appelle en priorité un service de destination déployé dans la même zone. Pour plus d'informations, consultez la page Observer le routage conscient de la zone à l'aide de la topologie de maillage.
Consultez les informations d'appel et la topologie générée à partir de ces données dans la console Managed Service for OpenTelemetry. Ces éléments facilitent l'analyse et le diagnostic rapides des goulots d'étranglement de performance, améliorant ainsi l'efficacité du diagnostic. Pour plus d'informations, consultez la page Configurer l'exportation des données de traçage depuis ASM.
Activez la fonctionnalité d'audit du maillage pour enregistrer ou tracer les opérations quotidiennes des différents utilisateurs. Configurez également des alertes d'audit pour les opérations sur les ressources ASM afin d'envoyer rapidement des notifications aux contacts d'alerte en cas de modification des ressources importantes. Pour plus d'informations, consultez les pages Audit des opérations KubeAPI et Configurer des alertes d'audit pour les opérations sur les ressources du maillage.
ASM réduit la surface d'attaque dans l'environnement cloud-native et fournit un cadre de base pour la construction d'un réseau d'applications zero trust. ASM adopte le chiffrement de bout en bout, l'authentification d'identité au niveau du service et des politiques d'autorisation granulaires pour sécuriser la communication entre services. Pour plus d'informations, consultez la page Présentation de la sécurité zero trust.