podinfo
:podinfo
deployment and uses Prometheus as a trigger:podinfo
deployment:podinfo-canary.yaml
and then apply it:.spec.autoscalerRef
. Flagger will use this to generate a ScaledObject which will scale the primary deployment. By default, Flagger will try to guess the query to use for the primary ScaledObject, by replacing all mentions of .spec.targetRef.Name
and {.spec.targetRef.Name}-canary
with {.spec.targetRef.Name}-primary
, for all triggers. For eg, if your ScaledObject has a trigger query defined as: sum(rate(http_requests_total{ app="podinfo" }[30s]))
or sum(rate(http_requests_total{ app="podinfo-primary" }[30s]))
, then the primary ScaledObject will have the same trigger with a query defined as sum(rate(http_requests_total{ app="podinfo-primary" }[30s]))
..spec.autoscalerRef.primaryScalerQueries
, which lets you define a query for each trigger. Please note that, your ScaledObject's .spec.triggers[@].name
must not be blank, as Flagger needs that to identify each trigger uniquely.podinfo.test
will be routed to the primary pods. To keep the podinfo deployment at 0 replicas and pause auto scaling, Flagger will add an annotation to your ScaledObject: autoscaling.keda.sh/paused-replicas: 0
. During the canary analysis, the annotation is removed, to enable auto scaling for the podinfo deployment. The podinfo-canary.test
address can be used to target directly the canary pods. When the canary analysis starts, Flagger will call the pre-rollout webhooks before routing traffic to the canary. The Blue/Green deployment will run for five iterations while validating the HTTP metrics and rollout hooks every 15 seconds.