Reduce the risk of introducing a new software version in production by slowly
rolling out the change to a small subset of users. This plugin also enables rolling
back to your original upstream service, or shifting all traffic to the new version.
You can configure this plugin using the
Kong Admin API
or through declarative configuration, which involves directly editing
the Kong configuration file.
Enabling the plugin on a Service
<service> is the
name of the Service that this plugin
configuration will target.
Enabling the plugin on a Route
<route> is the
name of the Route that this plugin configuration
Enabling the plugin globally
A plugin which is not associated to any Service, Route, or Consumer is
considered global, and will be run on every request. Read the
Plugin Reference and the Plugin Precedence
sections for more information.
Here's a list of all the parameters which can be used in this plugin's configuration:
|The name of the plugin to use, in this case
|The ID of the Service the plugin targets.
|The ID of the Route the plugin targets.
|Whether this plugin will be applied.
Future time in seconds since epoch, when the canary release will start.
percentage is set, or when using
Default value: 3600
The duration of the transition in seconds. Ignored when
percentage is set, or
Fixed percentage of traffic to be routed to new target, if given overrides
value must be between 0 and 100.
Default value: 1000
Number of steps the release should be broken into.
The target hostname where traffic will be routed. Required if
upstream_port are not set.
Default value: false
Whether the plugin will fall back to the original upstream if the Canary Upstream doesn’t have at least one healthy target. (
upstream_host must point to a valid Kong Upstream entity.)
The target port where traffic will be routed. Required if
upstream_host are not set.
Must be a value between 0 and 65535.
The Upstream URI where traffic will be routed. Required if
upstream_host are not set.
Default value: consumer
Entity to be used for hashing. Options:
ip, make sure to properly set the settings for trusted IPs
real_ip_header settings in the Kong configuration file.)
Type: array of string elements
An array of strings with the group names that are allowed or denied. Set
hash to either
allow (the listed groups
go into the canary) or
deny (the listed groups will NOT go into the canary.)
The Canary Release plugin allows you to route traffic to two separate upstream
Services referred to as Service A and Service B. The location of Service A
is defined by the
service entity for the request being proxied. The location
of Service B is defined by the
configured on the plugin.
There are 3 modes of operation:
- Set a fixed percentage to be routed to Service B. See parameter
- Define an allow or deny group comprised of Consumers with allowed or denied access to Service B.
The Consumer-group association can be configured using the ACL plugin.
- Set a period (in linear time) over which the traffic will be transferred
from Service A to Service B. See parameters
Determining Where to Route a Request
(This does not apply to allowing or denying groups).
The Canary Release plugin defines a number of “buckets” (
Each of these buckets can be routed to either Service A or Service B.
For example: If you set
config.steps to 100 steps, and
percentage to 10%,
Canary will create 100 “buckets”, 10 of which will be routed to Service B,
while the other 90 will remain routed to Service A.
config.hash parameter determines which requests end up in a specific bucket.
When set to
consumer, Canary ensures each Consumer will
consistently end up in the same bucket. The effect is that once a Consumer’s bucket
switches to Service B, it will then always go to
Service B, and will not flip-flop between A and B. Alternatively, if it is set to
ip, then the same concept applies but on the basis of the originating IP address.
When using either the
ip setting, if any specific Consumer or IP
is responsible for more than the average percentage of traffic, the migration
may not be evenly distributed, e.g., if the percentage is set to 50%, then 50% of
either the Consumers or IPs will be rerouted, but not necessarily 50% of the total requests.
When set to
none, the requests will be evenly distributed; each bucket
will get the same number of requests, but a Consumer or IP might flip-flop between
Service A and Service B on consecutive requests.
Canary provides an automatic fallback if, for some reason, a Consumer or IP can
not be identified. The fallback order is
Finalizing the Canary
Once the Canary is complete, either going to 100% for a percentage-based Canary,
or when the timed Canary has reached 100%, the configuration will need to be updated.
Note: If the plugin is configured on a
route, then all routes for the current
service must have completed the Canary.
- Update the
service entity to point to Service B by matching it to the URL as
- Remove the Canary plugin with a
Removing or disabling the Canary Release plugin before the Canary is complete will
instantly switch all traffic to Service A.
The configuration item
to skip applying the Canary upstream if it does not have at least one healthy
target. For this configuration to take effect, the following conditions must be met:
- As this configuration relies on Kong’s balancer (and healthchecks),
the name specified in
config.upstream_host must point to a valid Kong Upstream
- Healthchecks are
enabled in the canary upstream, i.e., the upstream specified in
needs to have healthchecks enabled it. It works with both passive and active