Note that the sum of all rollout webhooks timeouts should be lower than the analysis interval.
heycommands in the background, if they are not already running. This will ensure that during the analysis, the
podinfo-canary.testservice will receive a steady stream of GET and POST requests.
heyto the public URL and use HTTP2.
heywith another CLI, you can create your own Docker image:
pre-rolloutstep, to load test a service before any traffic is sent to it:
kube-systemnamespace using the
entrypointrepresents where your test process runs in Concord. In order to authenticate to Concord, you need to set
apiKeyPathto a path of a file containing a valid Concord API key on the
flagger-helmtestercontainer. This can be done via mounting a Kubernetes secret in the tester's Deployment.
pollIntervalrepresents the interval in seconds the web-hook will call Concord to see if the process has finished (Default is 5s).
pollTimeoutrepresents the time in seconds the web-hook will try to call Concord before timing out (Default is 30s).
confirm-promotionwebhooks. The confirmation rollout hooks are executed before the pre-rollout hooks. For manually approving traffic weight increase, you can use the
confirm-traffic-increasewebhook. Flagger will halt the canary traffic shifting and analysis until the confirm webhook returns HTTP status 200.
rollbackwebhook. The rollback hook will be called during the analysis and confirmation states. If a rollback webhook returns a successful HTTP status code, Flagger will shift all traffic back to the primary instance and fail the canary.
/gate/haltreturns HTTP 403 thus blocking the rollout.
/gate/approveto start the canary analysis:
confirm-promotionhook type can be used to manually approve the canary promotion. While the promotion is paused, Flagger will continue to run the metrics checks and load tests.
rollbackhook type can be used to manually rollback the canary promotion. As with gating, rollbacks can be driven with Flagger's tester API by setting the rollback URL to