Alibaba Cloud Service Mesh (ASM) uses Envoy proxies to ensure global load balancing among application services in an ASM instance. Envoy proxies can route traffic to the optimal instances deployed in different regions. This topic describes how to use ASM to implement global load balancing for an application that is deployed in two clusters across regions. In this topic, the Bookinfo application is used as an example.

Prerequisites

  • An ASM instance is created. For more information, see Create an ASM instance. In this topic, the ASM instance is mesh1.
  • The IPv4 CIDR blocks of the vSwitches to be used by the clusters do not overlap, and the pod and service CIDR blocks do not overlap.
  • A Container Service for Kubernetes (ACK) cluster is created in two different virtual private clouds (VPCs). For more information, see Create a dedicated Kubernetes cluster. In this topic, the clusters are m1c1 and m1c2.
  • Cloud Enterprise Network is activated.
  • The VPCs are connected to each other by using Cloud Enterprise Network. For more information, see Overview.
  • All CIDR blocks are advertised to Cloud Enterprise Network to ensure that they do not overlap. For more information, see Publish a route to CEN.

Background information

  • The following table describes the CIDR blocks used in this topic.
    Object Cluster m1c1 Cluster m1c2
    IPv4 CIDR block of the VPC or vSwitch 192.168.0.0/24 192.168.1.0/24
    Pod CIDR block 172.22.0.0/16 172.30.0.0/16
    Service CIDR 172.23.0.0/20 172.31.0.0/20
  • In an ACK cluster, the location of a pod is determined by the region and zone labels of the node where the pod resides. For more information, see Well-Known Labels, Annotations and Taints. The location of a pod is set by default in an ACK cluster.

Step 1: Deploy an application in clusters across regions

Deploy the Bookinfo application in multiple clusters in VPCs across regions.

To detect abnormal service instances of the Bookinfo application at the earliest opportunity, you must use Envoy proxies to configure exception detection in the destination rule for each service. For more information, see Destination Rule. When an Envoy proxy sends a request, ASM prioritizes the workload instances of the application service based on the location of the Envoy proxy. If you enable the nearby access feature and all workload instances work as expected, requests from Envoy proxies are preferentially sent to the nearest instances.

No destination rule with exception detection is configured for the reviews service. You can refresh the product page to view the effect of the three versions of the reviews service in turn.
  • Version v1 does not call the Ratings microservice.
  • Version v2 calls the Ratings microservice and displays each rating as one to five black stars.
  • Version v3 calls the Ratings microservice and displays each rating as one to five red stars.

Step 2: Configure exception detection

Requests are sent to the workload instance that is nearest to the source Envoy proxy only when the workload instance runs as expected. Therefore, you must configure exception detection in the destination rule for the service so that Envoy proxies can check whether the nearest workload instance works as expected.

  1. Log on to the ASM console.
  2. In the left-side navigation pane, choose Service Mesh > Mesh Management.
  3. On the Mesh Management page, find the ASM instance that you want to configure. Click the name of the ASM instance or click Manage in the Actions column of the ASM instance.
  4. On the details page of the ASM instance, choose Traffic Management > DestinationRule in the left-side navigation pane. On the DestinationRule page, click Create.
  5. In the Create panel, set the parameters for a destination rule and click OK.
    1. In the Namespace drop-down list, select the namespace where you want to create a destination rule.
    2. In the text editor, enter the configuration of the destination rule.
      The following code provides a sample YAML file for the destination rule:
      apiVersion: networking.istio.io/v1alpha3
      kind: DestinationRule
      metadata:
        name: reviews
      spec:
        host: reviews
        trafficPolicy:
          outlierDetection:
            consecutiveErrors: 5
            interval: 2m
            baseEjectionTime: 5m

Result

The productpage service and the v1 and v2 versions of the reviews service are deployed in the same cluster. The v3 version of the reviews service is deployed in another cluster in a different region. After you enable the nearby access feature and the v1 and v2 versions of the reviews service work as expected, network traffic destined for the reviews service is not routed to the v3 version. You can refresh the product page to view the effect of the v1 and v2 versions of the reviews service in turn.
  • Version v1 does not call the Ratings microservice.
  • Version v2 calls the Ratings microservice and displays each rating as one to five black stars.
Note You can reduce the number of pods to 0 to disable the v1 and v2 versions of the reviews service deployed in the m1c1 cluster. After you refresh the product page again, you can find that ratings on the page are displayed as one to five red stars. This indicates that the v3 version of the reviews service takes effect.