Alibaba Cloud Service Mesh:Use a service mesh for service-level disaster recovery

Mécanisme de basculement : basculement conscient de la localité dans un service mesh

ASM propose un mécanisme de basculement conscient de la localité. Le proxy sidecar de chaque charge de travail surveille en continu si la charge de travail de destination renvoie des erreurs de réponse consécutives dans une fenêtre de temps configurable. Lorsque le proxy sidecar détecte qu'une charge de travail est défectueuse, il la retire du pool d'équilibrage de charge et redirige le trafic vers d'autres charges de travail saines.

L'exemple suivant utilise deux clusters situés dans deux régions différentes, avec deux ensembles pairs d'une application déployés sur ces clusters. Dans chaque cluster, les charges de travail de chaque service sont réparties uniformément entre les différentes zones grâce à des contraintes de répartition topologique.

• Topologie du trafic normalLorsque tous les services sont opérationnels, le service mesh maintient le trafic au sein de la même zone afin de minimiser l'impact de l'emplacement de destination sur la latence des requêtes.

Topologies de déploiement des applications : topologies de clusters prises en charge et comparaison

Le mécanisme de basculement conscient de la localité d'ASM s'applique à plusieurs topologies de déploiement d'applications. Chaque topologie couvre une plage différente de dimensions de défaillance et varie en termes de coûts de ressources et de complexité des opérations et de la maintenance (O&M).

Déploiement en cluster unique, multi-zones

Il s'agit du mode de déploiement le plus simple pour la reprise après sinistre. Configurez un pool de nœuds multi-zones, sélectionnez des vSwitches de plusieurs zones pour le pool de nœuds et choisissez la politique de distribution équilibrée lors de la configuration de la politique de mise à l'échelle. Les instances ECS sont alors réparties uniformément entre les zones spécifiées pour le groupe de mise à l'échelle.

Déploiement en région unique, multi-zones, multi-clusters

Ce mode étend le cluster unique d'un déploiement en cluster unique, multi-zones, à plusieurs clusters, chacun ayant sa propre configuration. Lorsqu'un basculement se produit, ASM recherche d'abord d'autres charges de travail dans la même zone, puis sélectionne l'une des charges de travail saines dans une zone différente au sein de la même région que la région source comme destination de basculement. Sélectionnez des zones distinctes pour les deux clusters. Si les zones des deux clusters se chevauchent, les charges de travail de la même zone peuvent être prioritaires par rapport aux charges de travail du même cluster, ce qui peut être inattendu pour votre activité.

Déploiement multi-régions, multi-clusters

Ce mode transforme le déploiement en région unique d'une architecture multi-clusters en un déploiement multi-régions. Il maintient le déploiement de chaque service dispersé sur toutes les dimensions : zones, régions, clusters et dépendances. Ainsi, les charges de travail saines continuent de traiter le trafic lorsqu'une panne survient, quelle qu'en soit la raison.

Déploiement multi-régions, multi-clusters dans un environnement multicloud

Il s'agit de la topologie de déploiement la plus avancée. ASM prend entièrement en charge la gestion des clusters Kubernetes de n'importe quel fournisseur cloud et des centres de données sur site. Exécutez deux environnements de cluster Kubernetes across différents fournisseurs cloud, ou exécutez-en un dans le cloud et un autre sur site. Si une infrastructure tombe en panne, l'autre continue de fournir vos services.

Étape 1 : Préparer l'environnement

Suivez les sous-étapes ci-dessous afin de préparer l'environnement pour la démonstration de reprise après sinistre.

1. Créez un cluster Kubernetes dans chacune des deux régions et nommez-les cluster-1 et cluster-2. Configurez plusieurs zones pour les deux clusters et activez l'option Expose API server with EIP. Pour plus d'informations, consultez la rubrique Créer un cluster ACK managé.

2. Dans les mêmes deux régions que les clusters ACK, créez les instances ASM mesh-1 et mesh-2. Lors de la création des instances, veillez à sélectionner des vSwitches situés dans les mêmes zones que les clusters ACK. Pour plus d'informations, reportez-vous aux étapes 1, 2 et 3 de la rubrique Mettre en œuvre la reprise après sinistre multi-clusters avec une architecture de plan de contrôle multi-master ASM.

3. Dans mesh-1 et mesh-2, créez une passerelle d'entrée de type NLB nommée ingressgateway. Pour les zones NLB, sélectionnez les deux mêmes zones que celles des instances ASM et des clusters ACK. Pour plus d'informations, consultez la rubrique Utiliser une instance NLB pour une passerelle d'entrée ASM.

4. Dans mesh-1 et mesh-2, activez l'injection automatique de sidecar pour le namespace default des deux clusters. Cette configuration fait partie de la gestion globale des namespaces dans ASM. Pour plus d'informations, consultez la rubrique Gérer les namespaces globaux.

5. Déployez l'application exemple en tant que pairs dans les deux clusters ACK. Cet exemple utilise deux zones : cn-hangzhou-h et cn-hangzhou-k. Ajustez les zones dans le fichier YAML en fonction de votre environnement réel.

   Remarque

   Les images de conteneur du fichier YAML suivant sont extraites du registre Chine (Hangzhou) (registry-cn-hangzhou.ack.aliyuncs.com). Si vous effectuez un déploiement inter-régions, assurez-vous que les images sont disponibles dans toutes les régions cibles. Vous devrez peut-être configurer la synchronisation d'images inter-régions via Container Registry.

   Développer pour afficher la commande

   kubectl apply -f- <<EOF apiVersion: v1 kind: Service metadata: name: mocka labels: app: mocka service: mocka spec: ports: - port: 8000 name: http selector: app: mocka --- apiVersion: apps/v1 kind: Deployment metadata: name: mocka-cn-hangzhou-h labels: app: mocka spec: replicas: 1 selector: matchLabels: app: mocka template: metadata: labels: app: mocka locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mocka - name: upstream_url value: "http://mockb:8000/" ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mocka-cn-hangzhou-k labels: app: mocka spec: replicas: 1 selector: matchLabels: app: mocka template: metadata: labels: app: mocka locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mocka - name: upstream_url value: "http://mockb:8000/" ports: - containerPort: 8000 --- apiVersion: v1 kind: Service metadata: name: mockb labels: app: mockb service: mockb spec: ports: - port: 8000 name: http selector: app: mockb --- apiVersion: apps/v1 kind: Deployment metadata: name: mockb-cn-hangzhou-h labels: app: mockb spec: replicas: 1 selector: matchLabels: app: mockb template: metadata: labels: app: mockb locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mockb - name: upstream_url value: "http://mockc:8000/" ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mockb-cn-hangzhou-k labels: app: mockb spec: replicas: 1 selector: matchLabels: app: mockb template: metadata: labels: app: mockb locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mockb - name: upstream_url value: "http://mockc:8000/" ports: - containerPort: 8000 --- apiVersion: v1 kind: Service metadata: name: mockc labels: app: mockc service: mockc spec: ports: - port: 8000 name: http selector: app: mockc --- apiVersion: apps/v1 kind: Deployment metadata: name: mockc-cn-hangzhou-h labels: app: mockc spec: replicas: 1 selector: matchLabels: app: mockc template: metadata: labels: app: mockc locality: cn-hangzhou-h spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-h containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-h - name: app value: mockc ports: - containerPort: 8000 --- apiVersion: apps/v1 kind: Deployment metadata: name: mockc-cn-hangzhou-k labels: app: mockc spec: replicas: 1 selector: matchLabels: app: mockc template: metadata: labels: app: mockc locality: cn-hangzhou-k spec: nodeSelector: topology.kubernetes.io/zone: cn-hangzhou-k containers: - name: default image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing imagePullPolicy: IfNotPresent env: - name: version value: cn-hangzhou-k - name: app value: mockc ports: - containerPort: 8000 --- apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: mocka namespace: default spec: selector: istio: ingressgateway servers: - hosts: - '' port: name: test number: 80 protocol: HTTP --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: demoapp-vs namespace: default spec: gateways: - mocka hosts: - '' http: - name: test route: - destination: host: mocka port: number: 8000 EOFAprès avoir exécuté les commandes précédentes dans les deux clusters, les services mocka, mockb et mockc sont déployés en tant que pairs dans les deux clusters. Chaque service comprend deux déploiements sans état avec un réplica chacun. Des paramètres nodeSelector différents distribuent les déploiements sur des nœuds situés dans différentes zones, et des variables d'environnement permettent à chaque déploiement de renvoyer la zone dans laquelle il réside.

   Pour une démonstration simplifiée, cet exemple utilise le champ nodeSelector pour sélectionner manuellement la zone de chaque pod. Lorsque vous construisez un environnement de haute disponibilité réel, configurez des contraintes de répartition topologique pour distribuer les pods autant que possible sur différentes zones. Pour plus d'informations, consultez la rubrique Configurer la haute disponibilité pour les charges de travail.

6. Configurez Global Traffic Manager (GTM) avec les instances NLB pour mettre en œuvre la reprise après sinistre actif-actif pour la passerelle d'entrée. Pour plus d'informations, consultez la rubrique Comment GTM met en œuvre la reprise après sinistre actif-actif.

Étape 2 : Activer le basculement conscient de la localité

ASM active par défaut le basculement conscient de la localité, mais cette fonctionnalité ne prend effet qu'en combinaison avec des règles de disjoncteur au niveau de l'hôte configurées dans les règles de destination.

1. Déployez des règles de disjoncteur au niveau de l'hôte dans les clusters cluster-1 et cluster-2.

   kubectl apply -f- <<EOF apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: mocka spec: host: mocka trafficPolicy: outlierDetection: splitExternalLocalOriginErrors: true consecutiveLocalOriginFailures: 1 baseEjectionTime: 5m consecutive5xxErrors: 1 interval: 30s maxEjectionPercent: 100 --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: mockb spec: host: mockb trafficPolicy: outlierDetection: splitExternalLocalOriginErrors: true consecutiveLocalOriginFailures: 1 baseEjectionTime: 5m consecutive5xxErrors: 1 interval: 30s maxEjectionPercent: 100 --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: mockc spec: host: mockc trafficPolicy: outlierDetection: splitExternalLocalOriginErrors: true consecutiveLocalOriginFailures: 1 baseEjectionTime: 5m consecutive5xxErrors: 1 interval: 30s maxEjectionPercent: 100 EOFLe paramètre outlierDetection correspond au mécanisme utilisé par le maillage de services pour la détection des pannes de service et l'éjection des endpoints défaillants. Le tableau suivant décrit les éléments de configuration :

   Élément de configuration	Description
   interval	Intervalle auquel la détection des pannes est effectuée.
   baseEjectionTime	Durée d'attente avant qu'un endpoint soit éjecté du pool d'équilibrage de charge après avoir été identifié comme défaillant.
   maxEjectionPercent	Pourcentage maximal d'endpoints pouvant être éjectés.
   consecutive5xxErrors	Nombre d'erreurs 5xx consécutives renvoyées par un endpoint avant qu'il ne soit considéré comme défaillant.
   splitExternalLocalOriginErrors	Indique si les échecs de connexion et les délais d'expiration de connexion doivent être comptabilisés comme des pannes.
   consecutiveLocalOriginFailures	Nombre d'erreurs non-5xx consécutives, telles que les échecs de connexion et les délais d'expiration de connexion, générées par un endpoint avant qu'il ne soit considéré comme défaillant.

2. Vérifiez l'état du service.

   Envoyez une requête au nom de domaine du service.

   curl mock.asm-demo.work/mock -v

   Host mock.asm-demo.work:80 was resolved. IPv6: (none) IPv4: 8.xxx.xxx.47, 8.xxx.xxx.42 Trying 8.xxx.xxx.47:80... Connected to mock.asm-demo.work (8.209.XXX.XX) port 80 > GET /mock HTTP/1,1 > Host: mock.asm-demo.work > User-Agent: curl/8.7.1 > Accept: / > Request completely sent off < HTTP/1,1 200 OK < date: Wed, 11 Dec 2024 12:10:56 GMT < content-length: 153 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 3 < server: istio-envoy < * Connection #0 to host mock.asm-demo.work left intact -> mocka(version: cn-hangzhou-k, ip: 10.1.225.40)-> mockb(version: cn-hangzhou-k, ip: 10.1.225.31)-> mockc(version: cn-hangzhou-k, ip: 10.1.225.32)%

   La chaîne d'appel de service reste sur les charges de travail situées dans la même zone.

Étape 3 : Effectuer un test de panne

L'exemple suivant simule une défaillance d'une charge de travail en remplaçant manuellement l'image de conteneur du service mockb dans une zone.

1. Remplacez l'image de mockb-cn-hangzhou-h dans cluster-2 pour simuler une panne.

   1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

   2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Workloads > Deployments.

   3. Dans la liste, repérez la charge de travail mockb-cn-hangzhou-h . Dans la colonne Actions à droite, cliquez sur Edit. Modifiez l'image pour utiliser registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2 et ajoutez ["sleep","3600"] à la commande dans le champ Start afin que le conteneur puisse démarrer correctement. Cliquez sur Update.

2. Accédez continuellement au nom de domaine de l'application pour afficher le chemin de la requête après la survenue de la panne.

   curl mock.asm-demo.work/mock -vRésultat attendu 1 : La requête est envoyée vers une zone autre que cn-hangzhou-h.

   Host mock.asm-demo.work:80 was resolved. IPv6: (none) IPv4: 8.209.XXX.XX, 8.221.XXX.XX Trying 8.209.247.47:80... Connected to mock.asm-demo.work (8.209.247.47) port 80 > GET /mock HTTP/1,1 > Host: mock.asm-demo.work > User-Agent: curl/8.7.1 > Accept: / > Request completely sent off < HTTP/1,1 200 OK < date: Wed, 11 Dec 2024 12:10:56 GMT < content-length: 153 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 3 < server: istio-envoy < * Connection #0 to host mock.asm-demo.work left intact -> mocka(version: cn-hangzhou-k, ip: 10.1.225.40)-> mockb(version: cn-hangzhou-k, ip: 10.1.225.31)-> mockc(version: cn-hangzhou-k, ip: 10.1.225.32)%

   La requête reste dans une zone saine.

   Résultat attendu 2 : La requête est envoyée vers la zone cn-hangzhou-h lors de la première tentative.

   Host mock.asm-demo.work:80 was resolved. IPv6: (none) IPv4: 112.124.XX.XXX, 121.41.XXX.XXX Trying 112.124.65.120:80... Connected to mock.asm-demo.work (112.124.65.120) port 80 > GET /mock HTTP/1,1 > Host: mock.asm-demo.work > User-Agent: curl/8.7.1 > Accept: / > Request completely sent off < HTTP/1,1 200 OK < date: Wed, 11 Dec 2024 12:08:45 GMT < content-length: 220 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 48 < server: istio-envoy < * Connection #0 to host mock.asm-demo.work left intact -> mocka(version: cn-hangzhou-h, ip: 192.168.122.135)upstream connect error or disconnect/reset before headers. reset reason: remote connection failure, transport failure reason: delayed connect error: Connection refused%La connexion est refusée lorsque la requête atteint le service mockb .

   Résultat attendu 3 : La requête est envoyée à nouveau vers la zone cn-hangzhou-h après que le proxy sidecar a détecté la panne.

   Host mock.asm-demo.work:80 was resolved. IPv6: (none) IPv4: 8.209.XXX.XX, 8.221.XXX.XX Trying 8.209.247.47:80... Connected to mock.asm-demo.work (8.209.247.47) port 80 > GET /mock HTTP/1,1 > Host: mock.asm-demo.work > User-Agent: curl/8.7.1 > Accept: / > Request completely sent off < HTTP/1,1 200 OK < date: Wed, 11 Dec 2024 12:10:59 GMT < content-length: 154 < content-type: text/plain; charset=utf-8 < x-envoy-upstream-service-time: 4 < server: istio-envoy < * Connection #0 to host mock.asm-demo.work left intact -> mocka(version: cn-hangzhou-h, ip: 10.0.239.141)-> mockb(version: cn-hangzhou-k, ip: 10.1.225.31)-> mockc(version: cn-hangzhou-k, ip: 10.1.225.32)%Le trafic mockb est redirigé vers cn-hangzhou-k, une autre zone de la même région.

(Facultatif) Étape 4 : Configurer des alertes pour les pannes au niveau des services

1. Configurez le proxy sidecar pour qu'il rapporte les métriques de disjoncteur via proxyStatsMatcher. Lors de la configuration de proxyStatsMatcher, sélectionnez Regular Expression Match et définissez la valeur sur .*outlier_detection.*. Pour plus d'informations, consultez proxyStatsMatcher.

   Le tableau suivant décrit certaines des métriques de disjoncteur :

   Metric	Metric type	Description
   envoy_cluster_outlier_detection_ejections_active	Gauge	Le nombre d'hôtes actuellement éjectés.
   envoy_cluster_outlier_detection_ejections_enforced_total	Counter	Le nombre d'événements d'éjection d'hôte.
   envoy_cluster_outlier_detection_ejections_overflow	Counter	Le nombre de fois où une éjection d'hôte a été ignorée car le pourcentage maximal d'éjection a été dépassé.
   ejections_detected_consecutive_5xx	Counter	Le nombre de fois où un hôte a été détecté comme renvoyant des erreurs 5xx consécutives.

2. Redéployez les charges de travail sans état (mocka, mockb et mockc) pour appliquer la configuration mise à jour de proxyStatsMatcher. Pour plus d'informations, consultez Redeploy the workload.

3. Créez une règle d'alerte pour le disjoncteur au niveau de l'hôte.

   1. Intégrez le composant Alibaba Cloud ASM au cluster du plan de données ou mettez à jour le composant vers la dernière version, afin que Managed Service for Prometheus puisse collecter les métriques de disjoncteur exposées. Pour plus d'informations sur la mise à jour du composant d'intégration, consultez Manage integrations. (Si vous collectez déjà les métriques du maillage de services avec une instance Prometheus gérée par vos soins, comme décrit dans Integrate a self-managed Prometheus instance for mesh monitoring, ignorez cette étape.)

   2. Créez une règle d'alerte pour le disjoncteur au niveau de l'hôte. Pour plus d'informations, consultez Create an alert rule for a Prometheus instance.Le tableau suivant fournit des exemples pour les paramètres clés de la règle d'alerte : Configurez les autres paramètres selon vos besoins en vous référant aux documents précédents.

   Parameter	Example	Description
   Custom PromQL statement	(sum (envoy_cluster_outlier_detection_ejections_active) by (cluster_name, namespace)) > 0	L'exemple interroge la métrique envoy_cluster_outlier_detection_ejections_active pour déterminer si des hôtes sont actuellement éjectés dans le cluster, et regroupe les résultats de la requête par namespace et par nom de service.
   Alert content	Host-level circuit breaking is triggered. A workload returned consecutive errors and was ejected from the service load balancing pool! Namespace: {{$labels.namespace}}. Service where the ejection occurred: {{$labels.cluster_name}}. Number of ejections: {{ $value }}	Le message d'alerte d'exemple affiche le namespace et le nom du service qui a déclenché le disjoncteur, ainsi que le nombre d'hôtes actuellement éjectés pour ce service.