Découvrez les deux scénarios de gestion multi-cluster pris en charge par Service Mesh (ASM) et consultez la documentation associée à chacun d'eux.
Concepts préalables
Unité de reprise après sinistre
Dans les scénarios de reprise après sinistre, un système complet et autonome est déployé dans plusieurs emplacements géographiques indépendants afin d'éviter les points de défaillance uniques. Chacun de ces systèmes constitue une unité de reprise après sinistre.
Réseau plat
Prenons l'exemple de deux sous-réseaux indépendants (par exemple, différents VPC ou vSwitch Alibaba Cloud). Si les adresses IP d'un sous-réseau sont directement accessibles depuis l'autre, ces deux sous-réseaux forment un réseau plat. L'accès direct signifie que le routage de couche 3 (couche IP) peut atteindre l'autre sous-réseau sans intermédiaire. Dans le cas contraire, ils constituent un réseau non plat.
Scénarios multi-cluster typiques
Les fonctionnalités multi-cluster de Service Mesh (ASM) prennent en charge diverses solutions de déploiement multi-cluster.
Scénario 1 : Reprise après sinistre multi-cluster
Lorsque vous créez plusieurs clusters à des fins de reprise après sinistre, déployez-les dans plusieurs emplacements géographiques. Créez également une instance ASM dédiée pour chaque cluster, située dans le même emplacement géographique que ce dernier. Dans les scénarios multi-cloud, si vous utilisez des clusters provenant d'autres fournisseurs cloud et qu'Alibaba Cloud n'est pas disponible dans la région correspondante, sélectionnez l'emplacement géographique le plus proche. Pour plus d'informations, consultez la rubrique Reprise après sinistre multi-cluster.
Scénario 2 : Découverte de services partagée multi-cluster
Supposons que vos charges de travail soient déployées de manière asymétrique (c'est-à-dire que différentes charges de travail sont déployées dans chaque cluster) sur plusieurs clusters au sein d'une même unité de reprise après sinistre (par exemple, dans la même zone ou la même région). Si les applications de ces clusters peuvent s'appeler mutuellement, ajoutez ces clusters à la même instance ASM. Les clusters partagent alors les informations de découverte de services, et les applications peuvent s'appeler directement entre elles via les noms de domaine de service Kubernetes, sans avoir besoin d'exposer les services hors des clusters via des passerelles.
Connectivité réseau multi-cluster
Dans les scénarios multi-cluster décrits précédemment, un accès inter-cluster peut s'avérer nécessaire. Par exemple, dans les scénarios de reprise après sinistre, lorsque le cluster local devient indisponible, des appels inter-cluster sont tentés. Les clusters peuvent résider dans des réseaux différents, par exemple across VPC, across régions, ou dans des environnements cloud hybrides où les réseaux ne sont pas interconnectés. Dans ce cas, établissez d'abord des connexions réseau entre les clusters. Les méthodes suivantes sont disponibles :
|
Type de déploiement |
Description |
Méthode de connexion |
|
Cross VPC sur Alibaba Cloud |
Tous les clusters sont des clusters Alibaba Cloud, mais ils résident dans différents VPC |
|
|
Alibaba Cloud + cloud tiers ou clusters auto-gérés |
Le déploiement inclut des clusters Alibaba Cloud et des clusters cloud tiers ou auto-gérés |
|
Gestion du trafic multi-cluster
Utiliser un proxy DNS pour la découverte de services multi-cluster
Reprise après sinistre multi-cluster
Reprise après sinistre au niveau de la région avec ASM et GTM
Utiliser un service mesh pour la reprise après sinistre au niveau de la zone de disponibilité
Utiliser un service mesh pour la reprise après sinistre au niveau du service