Select a Release Method
Only one canary rollout can be in progress for the same service at a time. After the canary rollout is fully switched to the target version, the old version must still be cleaned up before the rollout is considered complete. You can roll back before cleanup; after cleanup, fast rollback for the current canary rollout is no longer supported.
Direct Publishing
For verified changes in a test environment or with controlled impact, click Update > Direct Release in the service list. After submitting the changes, wait for the instances to be updated and ready, then verify the endpoint, minimal requests, and required dependencies. A direct release updates the currently running version and does not support parallel validation of the target and previous versions during the canary period. For changes involving images, resource configurations, storage mounts, startup commands, environment variables, or other changes that may affect production requests, prioritize a canary release.Canary Release
1. Go to the canary release page
In the service list, click Update > Canary Release. The Version Change section is used to configure information related to the target version.Before initiating a canary release, we recommend recording the current image, version, access endpoint, target replicas, and business baseline. The service must be Running and must not have an ongoing canary release process. Refer to the page restrictions for details.
2. Configure the Target Version
The following configurations are displayed in the Cannot Be Modified During Canary Release section: Gateway Configuration, Monitor Config, Metrics Configuration, Number of Instances, and Scheduled Policy. Number of Instances and Scheduled Policy are labeled Use Direct Release. To modify these configurations, use the direct release method provided on the service page.
3. Select a Canary Release Strategy
Both modes require selecting a capacity policy:
- Start Before Stop: Start instances of the target version first, then scale down instances of the old version. This avoids capacity reduction during the transition period but requires additional resources.
- Stop Before Start: Release part of the old version’s capacity first, then start instances of the target version. This is suitable when resources are limited and a capacity reduction during the transition period is acceptable.
4. Create and Start the Canary Release
Click Create and Start Canary Release. After submission, you will be taken to the canary release details page, where you can view the target replicas, ready replicas, events, logs, monitoring, and the differences introduced by this change for the target version.Monitor and Advance the Canary Rollout
After each target adjustment, wait for the instance to become ready and monitor the error rate, latency, business results, and alarms before proceeding. The actual proportion of small-sample requests may differ from the configured weight, so assess it in conjunction with the overall metrics.
Roll Back the Current Canary Release and Clean Up the Old Version
After the full cutover to the target version, the target version handles all traffic with the current target replica count. The old version is typically retained for a period of time to enable a quick rollback. At this point, both versions may still consume resources. For example, if the old version has3 replicas and the target version has only 1 replica, after the full cutover, the 1 target-version replica handles all traffic, while the old version’s 3 replicas are retained until the old version is cleaned up.
- If the target version encounters an issue, ensure that the old version has sufficient capacity to handle the traffic, then use the rollback action provided by the current canary rollout process.
- After the target version is stable, use the old-version cleanup action provided on the page to release old-version resources.
- After the old version is cleaned up, this canary rollout is complete, and you can no longer quickly roll back through the current canary rollout process.
Roll Back to a Historical Version
Historical version rollback is used to restore service configurations that were previously in effect; it is not the same as withdrawing the current canary rollout.- In the service version history, select a version that was previously officially active, and verify the image, startup command, and dependencies.
- Confirm that no canary rollout is in progress and that the resource quota and storage permissions still meet the requirements of the earlier version’s configuration.
- Submit the rollback as prompted, and wait for the instances to be updated and become ready.
- Revalidate the access endpoint, service requests, and external dependencies.
Frequently Asked Questions
Why are other operations disabled during a canary rollout?
Why are other operations disabled during a canary rollout?
The canary rollout process is managing traffic and replicas for the target version and the previous version. To prevent direct updates, scaling, bringing services online or offline, or ingress changes from overriding the canary rollout target, some operations are disabled. To resume regular operations, first complete the cleanup of the previous version or roll back to end the canary rollout.
Why are resources from the old version still in use after a full rollout?
Why are resources from the old version still in use after a full rollout?
A full rollout only directs traffic to the target version. The old version is retained for rollback during the observation period. After confirming that the target version is stable, use the old version cleanup action provided on the page.
What should I check first if a canary rollout fails?
What should I check first if a canary rollout fails?
First, check the alarms, target replicas, and ready replicas in the canary rollout details. Then check the target version events and instance logs. If resources are insufficient, reduce the target for the target version, adjust the capacity policy, or roll back.