Canary Deployment Strategy

The version 3.5 pipeline introduces support for the deployment of applications using one of two available strategies for each target Kubernetes environment:

• runOnce
• canary

The runOnce strategy is the default and is the simplest form of deployment, deploying the application in a straightforward manner to the appropriate namespace.

The canary deployment strategy is intended for version upgrades of applications as a method to shift traffic from the old version to the newer version in a controlled manner, allowing the application team to ensure healthy behavior before committing 100% of transaction traffic to the upgraded version. It is important to note that a canary deployment expects a prior version to exist in a target environment since the purpose is to split traffic between old and new versions, therefore a runOnce deployment must have executed at least once previously in a given environment before a canary deployment would be configured.

Configuration of Canary Deployment

In order to configure an environment to use the canary strategy, a canary: YAML block should be included in the appropriate hostspace YAML object. The canary: YAML object would look like the following example:

        canary:
          increments: [25,50]
          promote: "auto"
          pauseInMinutes: 60

In the above example, the increments value is a YAML list of percentages. Each percentage represents a stage of progression in the canary deployment, where the specified percentage of traffic will be shifted to the new version of the application, with the remaining traffic continuing to flow to the previously deployed version.

The promote value above means that the pipeline will continue automatically after the amount of time in minutes specified by the pauseInMinutes value has passed (*note that in this version of the pipeline, auto is the only supported value for promote*).

Canary Deployment Flow

In a canary deployment, a copy of the already previously deployed version of the application will first be deployed as a "baseline" deployment. After this is deployed, the canary deployment will be released. All deployed versions of the application, the original, the baseline and the canary version, will have distinct ingress routes mapped through the Ambassador Edge Stack, but each will share the same URL.

As the deployment progresses through the traffic increments (listed in the YAML list canary.increments), the percentage of traffic represented by the increment will be assigned to the canary route mapping and an identical percentage will be assigned to the baseline route. By default, after the percentge of traffic is assigned, the pipeline will pause for a given number of minutes (configured in the YAML value canary.pauseInMinutes) during which time the application team can compare results of traffic as it is split between the canary version and the baseline version (with any remaining apportionment of traffic going to the original deployment, which should match the baseline version).

Once the pause has expired, the next traffic increment will be assigned the canary and baseline route mappings until the end of the canary.increments list. Once completed, the pipeline will pass through a 100% traffic increment and then update the original deployment to the new version and clean up and remove the baseline and canary deployments, leaving only the newly updated deployment with all traffic flowing to it.