A canary resource can target a Kubernetes Deployment or DaemonSet.
Kubernetes Deployment example:
Based on the above configuration, Flagger generates the following Kubernetes objects:
Flagger will detect changes to the target deployment (including secrets and configmaps) and will perform a canary analysis before promoting the new version as primary.
If the target deployment uses secrets and/or configmaps, Flagger will create a copy of each object using the
-primary prefix and will reference these objects in the primary deployment、
Note that the target deployment must have a single label selector in the format
A canary analysis is triggered by changes in any of the following objects:
Deployment PodSpec (container image, command, ports, env, resources, etc)
ConfigMaps mounted as volumes or mapped to environment variables
Secrets mounted as volumes or mapped to environment variables
Flagger comes with two builtin metric checks: HTTP request success rate and duration.
The canary analysis can be extended with webhooks. Flagger will call each webhook URL and determine from the response status code (HTTP 2xx) if the canary is failing or not.
There are several types of hooks:
confirm-rollout hooks are executed before scaling up the canary deployment and can be used for manual approval.
The rollout is paused until the hook returns a successful HTTP status code.
pre-rollout hooks are executed before routing traffic to canary.
The canary advancement is paused if a pre-rollout hook fails and if the number of failures reach the
threshold the canary will be rollback.
rollout hooks are executed during the analysis on each iteration before the metric checks.
If a rollout hook call fails the canary advancement is paused and eventfully rolled back.
confirm-promotion hooks are executed before the promotion step.
The canary promotion is paused until the hooks return HTTP 200.
While the promotion is paused, Flagger will continue to run the metrics checks and rollout hooks.
post-rollout hooks are executed after the canary has been promoted or rolled back.
If a post rollout hook fails the error is logged.
rollback hooks are executed while a canary deployment is in either Progressing or Waiting status.
This provides the ability to rollback during analysis or while waiting for a confirmation. If a rollback hook
returns a successful HTTP status code, Flagger will stop the analysis and mark the canary release as failed.
event hooks are executed every time Flagger emits a Kubernetes event. When configured,
every action that Flagger takes during a canary deployment will be sent as JSON via an HTTP POST request.