use the EDAS console to implement canary releases of applications in Kubernetes clusters - Enterprise Distributed Application Service

When you deploy a new version of a microservice, pushing changes to all instances at once risks widespread failures if defects surface. A canary release mitigates this risk by deploying the new version to a small subset of instances first. After you verify that the canary instances are healthy, you promote the release to the remaining instances in controlled batches. If issues arise, you roll back before the change reaches your full fleet.

The following sections describe how to configure and run a canary release for Spring Cloud or Dubbo microservices in a Kubernetes cluster through the EDAS console.

How a canary release works

A canary release in EDAS follows this sequence:

EDAS creates a canary instance group and deploys the new version to a specified number of instances.
Traffic routes to the canary group based on your chosen rule -- content-based matching, percentage-based splitting, or lane-based routing.
You verify the canary group by checking whether traffic is distributed as expected.
After verification, you promote the release by deploying the new version to the remaining instances in one or more batches.
If issues arise at any point, you roll back to the previous version.

The following table summarizes the three traffic routing strategies so you can choose the one that fits your use case:

Strategy	Best for	How it works
Canary Release by Content	Testing with specific users, requests, or parameters	Routes traffic based on request attributes (headers, cookies, or parameters) that match your conditions
Canary Release by Ratio	Gradual percentage-based rollout	Sends a fixed percentage of all traffic to the canary group
Canary Release By Lane	End-to-end traffic isolation across a microservices call chain	Routes traffic through a predefined lane to isolate the call chain

Limitations

High-Speed Service Framework (HSF) applications: Canary release is not supported.
Dubbo applications: Fully supported without restrictions.
Spring Cloud applications: Do not use canary release if your application relies on Deployment.Metadata.Name or Deployment.Metadata.Uid to configure features. Otherwise, the native features of the application may be abnormal after the canary release.
Ingress applications: If a Server Load Balancer (SLB) instance forwards traffic directly to your ingress application, the SLB routing policy does not follow the canary release rules.
Note
To use canary release with an ingress application, create a client application and a server application with multiple replicas. Implement canary release on the server application, and associate the SLB instance with the client application.

Prerequisites

Before you begin, make sure that you have:

A Spring Cloud or Dubbo application deployed in a Kubernetes cluster on EDAS
The deployment package (JAR or WAR) or container image for the new version
(For Container Registry) The aliyun-acr-credential-helper component installed in your cluster. See Use the aliyun-acr-credential-helper component to pull images without using a secret
(For Container Registry Enterprise Edition) Virtual Private Cloud (VPC) access configured. See Configure a VPC ACL

Start a canary release

Log on to the EDAS console.
In the left-side navigation pane, choose Application Management > Applications.
In the top navigation bar, select a region. In the upper part of the page, select a microservices namespace from the Microservices Namespace drop-down list.
From the Cluster Type drop-down list, select Kubernetes Cluster, then click the name of the target application.
In the upper-right corner of the Application Overview page, choose Deploy > Deploy.
On the Set Deployment Mode page, find the Canary Release (Phased) section and click Start Deployment.
On the Canary Release (Phased) page, configure the following three areas, then click OK:
- Deployment method
- Release policy
- Canary release rule

Configure the deployment method

Specify the application package or image for the new version.

Parameter	Description
Application Runtime Environment	Must match the runtime used in the previous deployment. JAR packages use Standard Java Application Runtime Environment. WAR packages use Apache Tomcat (version changeable).
Java Environment	Select a JDK version from the drop-down list.
File Uploading Method	The package type must match the previous deployment. Options: Upload JAR Package / Upload WAR Package (upload directly), or JAR Package Address / WAR Package Address (provide a URL).
Container Registry Repository Type	Available only for Java, Tomcat, or EDAS-Container (HSF) applications in ACK clusters. Not available for ACK Serverless clusters. Select Container Registry Personal Edition or Container Registry Enterprise Edition.
Region of Container Registry	Required only for Container Registry Enterprise Edition. Select the region where your image resides.
Container Registry	Required only for Container Registry Enterprise Edition. Select the container image.
Image Repository Namespace	Select the namespace for your image repository, or click + Create Namespace to create one.
Version	Version number for the deployment package. A timestamp is a common choice.
Time Zone	Select the time zone for the application.
Single-pod Resource Quota	CPU, memory, and ephemeral storage reserved per pod. The default value `0` means no limit. If you do not configure ephemeral storage, the cluster determines the maximum quota.

Note

Image build tasks run inside your cluster and consume cluster resources. The default resource limit for a single build task is 1 GB per core. To adjust this limit, see How do I adjust resource limits for image building?

Image build scheduling rules

When using Container Registry Personal Edition or Enterprise Edition, EDAS applies the following scheduling rules for image build tasks:

Rule	Behavior
Anti-affinity	Build tasks are not scheduled to nodes labeled `edas.image.build=disable`.
Preferred affinity	Build tasks prefer nodes labeled `edas.image.build=enable`, but can run on unlabeled nodes.
Toleration	Build tasks tolerate nodes with the taint `key=edas.image.build, effect=NoSchedule`.

To prevent build tasks from running on specific nodes, add the edas.image.build=disable label to those nodes.

To create a dedicated build node, add both the edas.image.build=enable label and the key=edas.image.build, effect=NoSchedule taint to the node. This prevents non-build pods from being scheduled to it.

Configure the release policy

Control how instances are updated across batches.

Parameter	Description
Number of Instances for Canary Release	Number of instances in the first (canary) batch. Set this to less than half the total instance count to maintain stability during verification.
Remaining Batches	Number of batches for deploying to the remaining instances after the canary batch.
Batch Mode	Required when Remaining Batches is greater than 1. Automatic: releases batches at a fixed interval (in minutes). Manual: requires you to trigger each batch.
Deployment Interval Between Batches	Time in seconds between deploying to individual instances within a single batch, when the batch contains more than one instance.

Note

After the canary batch completes, you must manually verify and then trigger the remaining batches. The Publish Policy Configuration panel on the right side of the page shows a visual summary of your release plan.

Configure a canary release rule

Select one of the three traffic routing strategies described in the overview above.

Content-based routing

Use content-based routing to test the new version with specific users or request types before exposing it to all traffic. Traffic is matched by request attributes such as headers, cookies, or parameters.

Click Add Policy.
In the Add a canary release by content policy panel, enter a Policy Name and click Create Inbound Traffic Rule to define one or more matching rules. Click OK.
From the Select Policy drop-down list, select the policy you created.

Configure the inbound traffic rule based on your framework:

Parameter	Spring Cloud	Dubbo
Protocol Type	HTTP path (relative path)	Select Service and Method from the drop-down lists
Conditional Mode	Meet All Following Conditions or Meet Any of Following Conditions	Same
Conditions	Match by Cookie, Header, or Parameter	Set Parameter and Expression for Getting Parameter Values

Ratio-based routing

Use ratio-based routing for a gradual percentage-based rollout without filtering by specific request attributes.

Set the Traffic Ratio to specify the percentage of traffic forwarded to the canary group.

Lane-based routing

Use lane-based routing to isolate traffic end-to-end across a full microservices call chain.

Click +Add Policy.
In the Add Lane Canary Release Policy panel, enter a Policy Name, select a Lane Group and Lane, then click OK.
From the Select Policy drop-down list, select the lane policy you created.

For information about creating lane groups and lanes, see Create a lane group and Create a lane.

(Optional) Configure advanced settings

Expand the advanced settings to configure additional options:

Verify and promote the release

After the canary batch deploys, the deployment progress and status appear on the Upgrade History page. Verify the new version before promoting it to the remaining instances.

Check whether the traffic is distributed as expected. For more information, see Monitor canary traffic.
After verification, go to the Change List page and click Start the Next Batch to deploy the next batch.
Repeat until all batches complete.

Roll back a release

If you find issues during verification, roll back the canary release:

On the Change List page, click RollBack in the upper-right corner.
In the confirmation dialog box, click OK.

Verify completion

After all batches finish, go to the Application Overview page and check the Deployment specifications section. Confirm that the deployment package version matches the new version.