Perform a canary release for a Kubernetes application by using the console - Enterprise Distributed Application Service

When deploying new versions of microservices, a full rollout risks exposing all users to potential issues. A canary release mitigates this by deploying the new version to a small subset of instances first. After you verify that the canary instances are healthy, you promote the new version to the remaining instances in batches.

This topic describes how to perform a canary release for Spring Cloud and Dubbo microservices in Kubernetes clusters through the Enterprise Distributed Application Service (EDAS) console.

How it works

A canary release in EDAS follows this lifecycle:

EDAS creates a canary instance group and deploys the new version to the number of instances you specify.
Traffic routes to the canary group based on a rule you configure: content-based matching, percentage-based splitting, or lane-based routing.
You monitor the canary traffic to verify that the new version behaves as expected.
After verification passes, you manually approve promotion -- deploying the new version to the remaining instances in one or more batches.
If issues arise, you can roll back the canary group to the previous version.

Note

The canary batch requires manual approval before the remaining batches begin. EDAS does not automatically promote the canary to full rollout.

Limits

Application type	Canary release support
High-Speed Service Framework (HSF)	Not supported.
Dubbo	Supported without restrictions.
Spring Cloud	Supported. Do not use canary release if the 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	Supported with limitations. If a Server Load Balancer (SLB) instance forwards traffic directly to the application, SLB traffic forwarding does not follow the canary release policy.

Note

To use canary release with an ingress application, create a client application and a server application with multiple replicas. Run the canary release on the server application, then associate the SLB instance with the client application for external traffic.

Start a canary release

Before you begin

Make sure that you have:

A Spring Cloud or Dubbo application deployed in a Kubernetes cluster managed by EDAS
Access to the EDAS console
(If using Container Registry Enterprise Edition) The aliyun-acr-credential-helper component installed in the cluster. For details, see Use the aliyun-acr-credential-helper component to pull images without using a secret.
(If using Container Registry Enterprise Edition) VPC access configured for the image repository. For details, see Configure a VPC ACL.

Procedure

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.
On the Applications page, select Kubernetes Cluster from the Cluster Type drop-down list. Click the name of the application for which you want to perform a canary release.
In the upper-right corner of the Application Overview page, choose Deploy > Deploy. On the Set Deployment Mode page, click Start Deployment in the Canary Release (Phased) section.
On the Canary Release (Phased) page, configure the deployment method, release policy, and canary release rule, then click OK. The following sections describe each configuration area.

Step 1: Configure the deployment method

The deployment parameters depend on how the application was originally deployed: JAR/WAR package or container image.

JAR/WAR package deployments

Parameter	Description
Application Runtime Environment	Must match the previous deployment. JAR packages use Standard Java Application Runtime Environment. WAR packages use Apache Tomcat. You can change the Tomcat version but not the runtime type.
Java Environment	Select a JDK version.
File Uploading Method	The package type must match the previous deployment (JAR or WAR). Upload the package directly or specify a package URL.
Version	Version number of the deployment package. A timestamp works well.
Time Zone	Select the time zone for the application.

Container image deployments

Parameter	Description
Container Registry Repository Type	Available only for Java, Tomcat, or EDAS-Container (HSF) applications in Container Service for Kubernetes (ACK) clusters. Not supported in ACK Serverless clusters.
Region of Container Registry	Required only for Container Registry Enterprise Edition. Select the region where the image resides.
Container Registry	Required only for Container Registry Enterprise Edition. Select the image to deploy.
Image Repository Namespace	Select a namespace, or click + Create Namespace to create one.

Note

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

Image build scheduling rules

If you use a repository of Container Registry Personal Edition or Container Registry Enterprise Edition to store the created image, EDAS schedules image build tasks based on node labels and taints:

Behavior	Node configuration
EDAS rejects scheduling build tasks to the node	Node has the `edas.image.build=disable` label
EDAS prefers scheduling build tasks to the node	Node has the `edas.image.build=enable` label
Build tasks tolerate the node	Node has the `key=edas.image.build, effect=NoSchedule` taint

Note

To dedicate a node for build tasks, add both the edas.image.build=enable label and the key=edas.image.build, effect=NoSchedule taint. This prevents pods that do not tolerate the taint from being scheduled to the node while allowing build tasks to run on it.

Resource quota (all deployment types)

Parameter	Description
Single-pod Resource Quota	CPU, memory, and ephemeral storage reserved for each pod. A value of `0` (default) means no limit. If ephemeral storage is not specified, the maximum depends on the cluster capacity.

Step 2: Configure the release policy

The release policy controls how many instances receive the new version in the initial canary batch and how the remaining instances are updated afterward.

Parameter	Description
Number of Instances for Canary Release	Number of instances in the first (canary) batch. The total instance count is displayed next to this field. For stability, set this to less than half the total.
Remaining Batches	Number of batches for updating the remaining instances after the canary batch.
Batch Mode	Required when Remaining Batches is greater than 1. Automatic: releases batches at the specified Interval (in minutes). Manual: requires you to trigger each batch.
Deployment Interval Between Batches	When a batch contains multiple instances, this is the delay (in seconds) between deploying to each instance within that batch.

Note

After the canary batch is deployed, you must manually approve the promotion to start the remaining batches.

The Publish Policy Configuration panel on the right side of the page shows a visual summary of the release flow based on your settings.

Step 3: Configure the canary release rule

The canary release rule determines how traffic reaches the canary instance group. EDAS supports three routing strategies: Canary Release by Content, Canary Release by Ratio, and Canary Release By Lane.

Strategy	When to use
Canary Release by Content	Route requests that match specific headers, cookies, or parameters to the canary group. Best for targeted testing with specific users or request types.
Canary Release by Ratio	Route a fixed percentage of all traffic to the canary group. Best for broad validation with a representative sample of traffic.
Canary Release By Lane	Route traffic through a predefined lane for end-to-end canary validation across a chain of microservices. Best for validating changes that span multiple services in a call chain.

Content-based routing

Route traffic to the canary group when requests match specific attributes.

Click Add Policy. In the Add a canary release by content policy panel, specify a Policy Name and click Create Inbound Traffic Rule, then click OK.
Select the created policy from the Select Policy drop-down list.

Note

Create multiple inbound traffic rules within a single policy. All rules take effect simultaneously.

Parameter	Description
Protocol Type	For Spring Cloud: specify a relative HTTP path. For Dubbo: select a service and method.
Conditional Mode	Meet All Following Conditions (AND logic) or Meet Any of Following Conditions (OR logic).
Conditions	For Spring Cloud: match on Cookie, Header, or Parameter. For Dubbo: set Parameter and Expression for Getting Parameter Values to match your application.

Percentage-based routing

Route a fixed percentage of traffic to the canary group.

Parameter	Description
Traffic Ratio	The percentage of traffic forwarded to the canary group.

Lane-based routing

Route traffic through a predefined lane for end-to-end canary validation across multiple services in a call chain.

Click +Add Policy. In the Add Lane Canary Release Policy panel, specify Policy Name, Lane Group, and Lane, then click OK.
Select the created policy from the Select Policy drop-down list.

Parameter	Description
Lane Group	Select an existing lane group. To create one, see Create a lane group.
Lane	Select an existing lane. To create one, see Create a lane.

Note

A lane isolates a set of application instances for traffic routing. Set up lane groups and lanes before using this routing strategy.

Step 4: (Optional) Configure advanced settings

Configure additional deployment options as needed:

Monitor and promote the release

After the canary batch is deployed, EDAS displays the deployment progress and status on the Upgrade History page.

Verify that traffic is distributed as expected. For details, see Monitor canary traffic.
If the canary instances are healthy, go to the Change List page and click Start the Next Batch to promote the release to subsequent batches.
Repeat until all batches are complete.

Roll back a release

If issues arise during canary verification:

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

Verify the release

After all batches complete, confirm the application runs the new version:

Go to the Application Overview page of the application.
In the Deployment specifications section, check that the deployment package version matches the newly deployed version.