Enterprise Distributed Application Service (EDAS) provides three strategies for upgrading applications in Kubernetes clusters: release to all at once, phased release, and canary release. Each strategy offers a different balance between deployment speed and risk control. If the new version causes issues, you can roll back to a previous version -- either automatically or manually.
Why different upgrade strategies matter
A direct upgrade deploys the new version to all instances simultaneously. This works for small-scale applications, but in production environments with many instances or complex service dependencies, a failed upgrade can affect all traffic at once. Phased and canary releases reduce this blast radius by limiting the scope of each deployment step, so you can detect and contain issues before they reach all instances.
Choose an upgrade strategy
| Strategy | When to use | How it works | Available methods |
|---|---|---|---|
| Release to all at once | Few instances or simple architecture | Deploys the new version to all instances simultaneously. Fast, but no gradual validation. | Console, API, plug-in or tool |
| Phased release | Many instances or complex architecture | Deploys the new version in batches. Each batch is verified before the next one starts. | Console, API, plug-in or tool |
| Canary release | New version needs validation before full rollout | Deploys the new version to a small subset of instances first. After verification, promotes it to all instances. | Console |
Release to all at once
Deploys the new version to every instance at once. Use this strategy when the application has few instances or a straightforward architecture, and you have already validated the new version in a test environment.
Phased release
Deploys the new version in multiple batches. Only some instances are upgraded in each batch, and the release is complete when all instances run the new version. If an error occurs during any batch, terminate the process and roll back. Fix the issue, then release again.
Canary release
Deploys the new version to a small number of instances for verification. If the new version passes validation, promote it to all remaining instances. This limits the blast radius of potential issues to a controlled subset before committing to a full rollout.
| Method | Reference |
|---|---|
| Console | Use the EDAS console to implement canary releases of applications in Kubernetes clusters |
Roll back an application
EDAS supports both automatic and manual rollback, depending on when and how an issue is detected.
Automatic rollback
During an upgrade, EDAS monitors the process for failures. If an error occurs, such as an unavailable deployment package or a health check failure, the upgrade is automatically terminated and the application is rolled back to the previous version. No manual action is required.
Manual rollback
If the new version introduces issues that are not caught automatically, roll back manually. Two scenarios apply:
During the upgrade -- Terminate the in-progress upgrade and roll back immediately.
After the upgrade -- Roll back by redeploying a historical version of the application.
Rollback methods
| Scenario | Method | Reference |
|---|---|---|
| Roll back in the console | Console | Roll back an application in a Kubernetes cluster in the EDAS console |
| Terminate an upgrade and roll back | API | AbortAndRollbackChangeOrder |
| Roll back to a historical version | API | RollbackApplication |
What to do next
To release to all at once, see Use the EDAS console to release an application to all instances in a Kubernetes cluster at a time.
To perform a phased release, see Use the EDAS console to implement phased releases of applications in Kubernetes clusters.
To perform a canary release, see Use the EDAS console to implement canary releases of applications in Kubernetes clusters.
To roll back an application, see Roll back an application in a Kubernetes cluster in the EDAS console.