Master Canary Releases for Spring Cloud on Kubernetes with EDAS

When launching a new version, directly upgrading an existing application can jeopardize stability and user experience; therefore, keeping both old and new versions online and gradually shifting traffic is recommended. EDAS provides a canary (gray) release feature that enables multiple versions to run simultaneously with flexible traffic allocation rules.

Canary Release Configuration

Navigate to the EDAS application deployment page, select the target application, and choose Canary (Gray) Release . This mode only applies to non‑entry Dubbo and Spring Cloud services; entry services or applications using native Kubernetes features such as HPA, Rancher, Istio, or Deployment metadata should not use gray release to avoid conflicts.

Upload the new JAR package or provide its URL, then proceed to define the release strategy.

Publish Strategy Settings

The strategy consists of two parts: batch deployment settings and traffic gray rules.

Batch Deployment Settings

First‑batch gray count : Number of instances to upgrade in the initial batch; must not exceed 50% of total instances (e.g., with 7 pods, at most 3 can be selected).

Remaining batches : After the first batch, the rest of the instances are released in the specified number of batches.

Inter‑batch handling : Choose manual or automatic progression; automatic mode can set a fixed interval (e.g., 30 minutes) between batches.

Batch internal deployment interval : If a batch contains multiple instances, configure the pause between deploying each instance (e.g., 60 seconds).

Example: With 7 pods, set the first batch to 2 instances. After those finish, the remaining 5 instances are released in three batches, each auto‑triggered 30 minutes after the previous batch, and the second batch uses a 60‑second internal interval.

Gray Traffic Rules

Two rule types are supported:

Content‑based gray : Select protocol (Spring Cloud or Dubbo; here we focus on Spring Cloud). Configure request path, condition mode (all conditions must match or any condition matches), and a list of conditions on Cookie, Header, or Parameter. Example: route requests where userId % 100 <= 40 to the gray version.

Ratio‑based gray : Define a traffic percentage (e.g., 40%) that will be directed to the gray version regardless of request content.

Executing and Monitoring the Canary Release

After saving the strategy, start the release. EDAS first deploys the new version to the designated gray group; progress can be viewed on the Change Details page. If issues arise, the release can be terminated and the application rolled back.

During the gray rollout, monitor traffic and application health to verify that the new version behaves as expected. Once a batch’s traffic validation succeeds, click Start Next Batch on the Change Details page. If a problem is detected, use the Rollback button to revert immediately.

For detailed monitoring instructions, refer to the EDAS documentation “Monitoring Gray Traffic”.

Post‑Release Verification

After the gray release completes, confirm on the basic information page that the deployed package version matches the new release, and check the instance status page to ensure all pods are running normally.

Conclusion and Next Steps

This article demonstrated how to perform a gray (canary) release of Spring Cloud applications on an EDAS‑managed Kubernetes cluster, covering strategy configuration, gray rules, monitoring, and rollback to achieve smooth version upgrades. Future articles will explore detailed monitoring techniques during the release process.