Alibaba Cloud Service Mesh:Configure fallback routing in ASM

How fallback differs from retries and circuit breakers

ASM provides several resilience mechanisms. Choose the right one based on the failure mode you need to handle:

Fallback operates at the routing level: the sidecar proxy checks whether the target subset has healthy endpoints before forwarding the request. If no healthy endpoints exist, it routes to the fallback target instead.

Prerequisites

Bookinfo reviews service versions

The Bookinfo reviews service has three versions, each identifiable by its star rating on the product page:

The productpage service calls reviews. A VirtualService routes all traffic to reviews-v3. When v3 becomes unavailable, the fallback rule redirects requests to reviews-v2 instead of returning a 503 error.

Download the configuration files used in this topic.

Step 1: Create the destination rule for the reviews service

Define a DestinationRule with subsets for each version of the reviews service.

1. Create a file named reviews.yaml with the following content:

      apiVersion: networking.istio.io/v1alpha3
      kind: DestinationRule
      metadata:
        name: reviews
      spec:
        host: reviews
        subsets:
        - name: v1
          labels:
            version: v1
        - name: v2
          labels:
            version: v2
        - name: v3
          labels:
            version: v3

2. Connect to the ASM instance using kubectl and the KubeConfig file, then apply the rule:

      kubectl apply -f reviews.yaml

3. Get the ingress gateway IP address using either method:

   • Run the following command:

     kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

   • Find the IP on the Ingress Gateway page in the ASM console. See Query the IP address of the ASM instance's ingress gateway.

4. Open http://<gateway-ip>/productpage in a browser. The Reviews served by field and the star rating identify the version serving each request. Refresh the page several times -- requests are distributed across v1, v2, and v3. For example, reviews-v2 displays black stars:

   

Step 2: Configure a basic fallback rule

Route all traffic to reviews-v3 and set reviews-v2 as the fallback target.

1. Create a file named reviews-route-fallback-sample1.yaml: The fallback.target field tells the sidecar proxy to forward requests to reviews-v2 when reviews-v3 is unreachable.

      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: reviews-route
        namespace: default
      spec:
        hosts:
          - reviews
        http:
          - route:
              - destination:
                  host: reviews
                  subset: v3
                fallback:
                  target:
                    host: reviews
                    subset: v2

2. Apply the VirtualService:

      kubectl apply -f reviews-route-fallback-sample1.yaml

3. Open http://<gateway-ip>/productpage and refresh. All requests now route to v3 (red stars).

   

4. Simulate a v3 failure by scaling its deployment to zero replicas:

      kubectl scale deployment reviews-v3 --replicas=0

5. Refresh the page. Requests now fall back to v2 (black stars).

Verify fallback through access logs

Add fallback-related fields to the custom access log format to confirm the fallback triggered. See Customize access log fields for setup instructions.

Field	Value	Description
fallback_path	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-path)%	Fallback chain. A:B means A fell back to B. A:B:C means A fell back to B, then B to C.
fallback_final_cluster_name	%DYNAMIC_METADATA(com.aliyun.fallback:final-cluster)%	Cluster that ultimately handled the request after a successful fallback.
fallback_result	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-result)%	Fallback outcome. If the fallback failed, the request goes to the original route's cluster.

Check the productpage-v1 istio-proxy logs. A successful fallback from v3 to v2 produces a log entry similar to the following:

{
    "authority": "reviews:9080",
    "authority_for": "reviews:9080",
    "bytes_received": "0",
    "bytes_sent": "442",
    "downstream_local_address": "192.168.255.46:9080",
    "downstream_remote_address": "172.16.0.252:57238",
    "duration": "10",
    "fallback_path": "outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_final_cluster_name": "outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_result": "fallback successful",
    "istio_policy_status": "-",
    "method": "GET",
    "path": "/reviews/0",
    "protocol": "HTTP/1.1",
    "request_id": "15b2dffc-5f3f-4060-b9fa-898eab08****",
    "requested_server_name": "-",
    "response_code": "200",
    "response_flags": "-",
    "route_name": "-",
    "start_time": "2023-05-30T07:02:26.990Z",
    "trace_id": "18b3aed8af41****",
    "upstream_cluster": "outbound|9080|v2|reviews.default.svc.cluster.local",
    "upstream_host": "172.16.0.11:9080",
    "upstream_local_address": "172.16.0.252:44448",
    "upstream_service_time": "9",
    "upstream_transport_failure_reason": "-",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for": "-"
}

The three fallback-specific fields confirm the behavior:

• fallback_path shows the chain: v3 cluster to v2 cluster.

• fallback_final_cluster_name identifies v2 as the cluster that served the request.

• fallback_result is "fallback successful".

Step 3: Combine fallback with weighted routing

Fallback rules work alongside weighted routing. In this scenario, traffic splits 50/50 between v3 and v2, and each version has its own fallback target.

1. Restore v3:

      kubectl scale deployment reviews-v3 --replicas=1

2. Create a file named reviews-route-fallback-sample2.yaml: Two independent fallback chains are defined: Retries are disabled (attempts: 0) to isolate fallback behavior from retry behavior during testing.

   • v3 traffic (50%): falls back to v2 if v3 is unavailable

   • v2 traffic (50%): falls back to v1 if v2 is unavailable

      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: reviews-route
        namespace: default
      spec:
        hosts:
          - reviews
        http:
          - route:
              - destination:
                  host: reviews
                  subset: v3
                fallback:
                  target:
                    host: reviews
                    subset: v2
                weight: 50
              - destination:
                  host: reviews
                  subset: v2
                fallback:
                  target:
                    host: reviews
                    subset: v1
                weight: 50
            retries:
              attempts: 0

3. Apply the updated VirtualService:

      kubectl apply -f reviews-route-fallback-sample2.yaml

4. Refresh the product page. Requests are distributed evenly between v3 (red stars) and v2 (black stars).

Use fallback in production

Fallback routing masks service failures, which is valuable for availability but requires careful planning in production environments.

Related topics

• Create an ASM instance

• Customize access logs of clusters on the data plane

• Update an ASM instance