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

When you deploy new versions of a microservice, you need control over how traffic shifts from the old version to the new one. Service Mesh (ASM) provides traffic management through Istio VirtualService and DestinationRule resources, so you can switch or split traffic between versions without redeploying pods. This topic walks through three progressive delivery strategies using the Bookinfo sample application: blue-green release, weight-based canary release, and content-based canary release.

Release strategies at a glance

Strategy	How it works	Best for
Blue-green release	Switches 100% of traffic from one version to another	Full cutover after the new version passes testing
Canary release (weight-based)	Splits traffic between versions by percentage (for example, 90/10 or 50/50)	Gradual rollout to limit blast radius
Canary release (content-based)	Routes traffic based on request attributes such as HTTP headers	Testing with specific users before a broader rollout

How VirtualService and DestinationRule work together: A DestinationRule defines the available versions (subsets) of a service. A VirtualService controls how traffic is distributed across those subsets. To change your release strategy, update the VirtualService -- the DestinationRule stays the same.

Prerequisites

Before you begin, make sure that 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

Step 1: Create destination rules

Define version subsets for each Bookinfo microservice. These DestinationRules register the available pod versions with ASM so that VirtualServices can route traffic to them.

For more information, see Manage destination rules.

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:
  # Three versions of the reviews service are available for traffic routing
  - 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

Step 2: Route all traffic to v1

Create VirtualServices that route all traffic to version 1 of each microservice. This establishes a stable baseline before you introduce new versions.

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          # All traffic goes to productpage v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1          # All traffic goes to reviews v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1          # All traffic goes to ratings v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: details
spec:
  hosts:
  - details
  http:
  - route:
    - destination:
        host: details
        subset: v1          # All traffic goes to details v1

At this point, reviews v2 and v3 are running in the cluster but receive no traffic. All requests go to v1.

Step 3: Perform a blue-green release to reviews v2

Switch all traffic from reviews v1 to v2 in one step. Update the reviews VirtualService:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2          # 100% of traffic now goes to reviews v2

Verify: Refresh the Bookinfo product page. The reviews section now shows ratings with black stars, which confirms that all traffic reaches reviews v2.

Tip: To roll back, update the VirtualService to route traffic back to subset v1. See the "Roll back a release" section below.

Step 4: Perform a weight-based canary release to reviews v3

Instead of switching all traffic at once, split it between v2 and v3 to limit blast radius. Update the reviews VirtualService to distribute traffic evenly:

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

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

Tip: Adjust the weights to shift traffic gradually. For example, start with 90/10, move to 70/30, then 50/50, and finally 0/100 for a full cutover to v3. The weights must add up to 100.

Recommended progressive rollout

For production workloads, increase traffic to the new version incrementally rather than jumping to a 50/50 split:

Stage	v2 weight	v3 weight	Action
1	90	10	Monitor error rates and latency
2	70	30	Verify no increase in error rates
3	50	50	Continue monitoring
4	0	100	Complete cutover to v3

At each stage, update the weight values in the VirtualService and monitor service health before proceeding.

Step 5: Perform a content-based canary release to reviews v3

Route traffic by user identity instead of weight. This lets you validate a new version with specific users while everyone else stays on the stable version.

Update the reviews VirtualService to match requests by the end-user HTTP header:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason       # Requests from user "jason" go to v3
    route:
    - destination:
        host: reviews
        subset: v3
  - route:
    - destination:
        host: reviews
        subset: v2           # All other requests go to v2

Verify:

Refresh the Bookinfo product page without signing in. The reviews section shows black stars (v2).
Click Sign in in the upper-right corner and log in with the username jason (no password required).
After sign-in, the reviews section shows red stars (v3).

Note When you sign in to Bookinfo, the productpage service adds an end-user HTTP header to requests sent to backend microservices. The VirtualService matches this header value to decide which version handles the request.

Roll back a release

To revert to a previous version, update the VirtualService to route traffic back to the desired subset. For example, to roll back reviews to v1:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1           # Route all traffic back to v1

The DestinationRule does not need to change. The rollback takes effect as soon as ASM applies the updated VirtualService.

Production considerations

When you use these release strategies in a production environment, keep the following in mind:

Monitor during rollout. Track error rates, latency, and success rates for the new version at each stage. If metrics degrade, roll back by updating the VirtualService to route traffic to the previous stable version.
Use small initial weight. Start canary traffic at a small percentage rather than 50%. This limits the number of users affected if the new version has issues.
Automate rollback criteria. Define clear thresholds for error rate and latency that trigger a rollback.
Test with internal users first. Use content-based routing to direct traffic from internal test accounts to the new version before opening it to external traffic.

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