Implement blue-green and canary release with ASM - Alibaba Cloud Service Mesh

Service Mesh (ASM) decouples traffic routing from pod scaling, giving you percentage-based control over how traffic reaches each application version -- regardless of replica count.

This guide walks through three release strategies using virtual services and destination rules, with the Bookinfo sample application:

Blue-green release -- switch all traffic from one version to another in a single step.
Weight-based canary release -- split traffic between two versions by percentage.
Header-based canary release -- route specific users to a new version based on request headers.

Prerequisites

Before you begin, make sure you have:

An ASM instance. For more information, see Create an ASM instance
At least one Container Service for Kubernetes (ACK) cluster added to the ASM instance. For more information, see Add a cluster to an ASM instance
The Bookinfo application deployed in the ACK cluster. For more information, see Deploy an application in an ASM instance
An ingress gateway deployed for the ACK cluster. For more information, see Create an ingress gateway service

How it works

Destination rules define named subsets that map to version labels on your pods. Virtual services reference those subsets to control which version receives traffic and in what proportion.

This guide follows a realistic progression:

Define subsets for all Bookinfo microservice versions (destination rules).
Route all traffic to v1 (baseline).
Blue-green release: switch the reviews service from v1 to v2.
Weight-based canary release: split traffic between reviews v2 and v3.
Header-based canary release: route a specific user to reviews v3.

Step 1: Create destination rules

Define subsets for each Bookinfo microservice so that virtual services can reference them by name. For more information, see Manage destination rules.

Apply the following destination rules to your ASM instance:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
---
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
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v2-mysql
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Verify that the destination rules are created:

kubectl get destinationrules -o name

Expected output:

destinationrule.networking.istio.io/productpage
destinationrule.networking.istio.io/reviews
destinationrule.networking.istio.io/ratings
destinationrule.networking.istio.io/details

Step 2: Route all traffic to v1 (baseline)

Create virtual services to route all traffic to the v1 subset of each Bookinfo microservice. This establishes a stable baseline before you shift traffic. For more information, see Manage virtual services.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
  - productpage
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: details
spec:
  hosts:
  - details
  http:
  - route:
    - destination:
        host: details
        subset: v1

Verify the baseline

Refresh the Bookinfo product page in your browser. The reviews section displays without star ratings, because reviews v1 does not call the ratings service.

Confirm the routing rule:

kubectl get virtualservice reviews -o yaml

The output should show subset: v1 as the only destination for the reviews service.

At this point, pods for reviews v2 and v3 are running but receive no traffic.

Step 3: Blue-green release -- switch to reviews v2

Blue-green release shifts all traffic from one version to another in a single step. Update the reviews virtual service to route 100% of traffic to the v2 subset:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2

Verify the blue-green release

Refresh the Bookinfo product page. The reviews section now displays black star ratings, confirming that all traffic reaches reviews v2.

Confirm the routing rule:

kubectl get virtualservice reviews -o yaml

The output should show subset: v2 as the only destination.

Note: To roll back, re-apply the Step 2 virtual service that routes traffic to subset v1.

Step 4: Weight-based canary release -- split traffic between v2 and v3

Instead of switching all traffic at once, gradually shift a percentage to the new version. The following virtual service splits traffic 50/50 between reviews v2 and v3:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2
      weight: 50
    - destination:
        host: reviews
        subset: v3
      weight: 50

The weight values control the traffic percentage for each version. Weights must add up to 100.

Verify the canary release

Refresh the Bookinfo product page several times. The reviews section alternates between black stars (v2) and red stars (v3) at roughly equal frequency.

Note: To roll back, set weight: 100 on the v2 destination and weight: 0 on v3, or remove the v3 destination entirely.

Step 5: Header-based canary release -- route by user identity

Route specific users to the new version based on HTTP headers while all other users remain on the current version. This approach is useful for internal testing before a broader rollout.

The Bookinfo application passes the logged-in username as the end-user HTTP header. The following virtual service routes the user jason to reviews v3 and all other users to reviews v2:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v3
  - route:
    - destination:
        host: reviews
        subset: v2

Verify the header-based release

Without signing in, refresh the Bookinfo product page. The reviews section displays black stars (v2).
Click Sign in in the upper-right corner. Enter jason as the username. No password is required.
After you sign in, refresh the page. The reviews section now displays red stars (v3).

This works because the Bookinfo product page includes an end-user header in requests to backend microservices. When end-user matches jason, the virtual service routes the request to reviews v3.

Clean up

To remove the routing rules created in this guide, delete the virtual services and destination rules:

kubectl delete virtualservice productpage reviews ratings details
kubectl delete destinationrule productpage reviews ratings details

What's next

Manage virtual services -- explore routing options such as fault injection and timeouts.
Manage destination rules -- configure load balancing policies and connection pool settings for subsets.