I am gonna use automatic Canary deployment so I tried to follow the process via Flagger. Here was my VirtualService file for routing:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: {{ .Values.project }}
  namespace: {{ .Values.service.namespace }}
spec:
  hosts:
    - {{ .Values.subdomain }}
  gateways:
    - mygateway.istio-system.svc.cluster.local
  http:
    {{- range $key, $value := .Values.routing.http }}
    - name: {{ $key }}
{{ toYaml $value | indent 6 }}
    {{- end }}

Which the routing part looks like this:

http:
    r1:
      match:
        - uri:
            prefix: /myservice/monitor
      route:
        - destination:
            host: myservice
            port:
              number: 9090
    r2:
      match:
        - uri:
            prefix: /myservice
      route:
        - destination:
            host: myservice
            port:
              number: 8080
      corsPolicy:
        allowCredentials: false
        allowHeaders:
        - X-Tenant-Identifier
        - Content-Type
        - Authorization
        allowMethods:
        - GET
        - POST
        - PATCH
        allowOrigin:
        - "*"
        maxAge: 24h    `

However as I found the Flagger overwites the virtualservice, I have removed this file and modified the canary.yaml file based on my requirements but I get yaml error:

{{- if .Values.canary.enabled }}
apiVersion: flagger.app/v1alpha3
kind: Canary
metadata:
  name: {{ .Values.project }}
  namespace: {{ .Values.service.namespace }}
  labels:
    app: {{ .Values.project }}
    chart: {{ template "myservice-chart.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name:  {{ .Values.project }}
  progressDeadlineSeconds: 60
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name:  {{ .Values.project }}    
  service:
    port: 8080
    portDiscovery: true
    {{- if .Values.canary.istioIngress.enabled }}
    gateways:
    -  {{ .Values.canary.istioIngress.gateway }}
    hosts:
    - {{ .Values.canary.istioIngress.host }}
    {{- end }}
    trafficPolicy:
      tls:
        # use ISTIO_MUTUAL when mTLS is enabled
        mode: DISABLE
    # HTTP match conditions (optional)
    match:
      - uri:
          prefix: /myservice
    # cross-origin resource sharing policy (optional)
      corsPolicy:
        allowOrigin:
          - "*"
        allowMethods:
          - GET
          - POST
          - PATCH
        allowCredentials: false
        allowHeaders:
          - X-Tenant-Identifier
          - Content-Type
          - Authorization
        maxAge: 24h
      - uri:
          prefix: /myservice/monitor
  canaryAnalysis:
    interval: {{ .Values.canary.analysis.interval }}
    threshold: {{ .Values.canary.analysis.threshold }}
    maxWeight: {{ .Values.canary.analysis.maxWeight }}
    stepWeight: {{ .Values.canary.analysis.stepWeight }}
    metrics:
    - name: request-success-rate
      threshold: {{ .Values.canary.thresholds.successRate }}
      interval: 1m
    - name: request-duration
      threshold: {{ .Values.canary.thresholds.latency }}
      interval: 1m
    webhooks:
      {{- if .Values.canary.loadtest.enabled }}
      - name: load-test-get
        url: {{ .Values.canary.loadtest.url }}
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 5 -c 2 http://myservice.default:8080"
      - name: load-test-post
        url: {{ .Values.canary.loadtest.url }}
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 5 -c 2 -m POST -d '{\"test\": true}' http://myservice.default:8080/echo"
      {{- end }}  
{{- end }}

Can anyone help with this issue?

@stefanprodan This is a work in progress PR looking for acceptance on the approach and feedback. This PR provides the opt-in capability for users to revert flagger mutations on deletion of a canary. If users opt-in finalizers will be utilized to revert the mutated resources before the canary and owned resources are handed over for finalizing.

Changes: Add evaluations for finalizers controller/controller Add finalizers source controller/finalizer Add interface method on deployment and daemonset controllers Add interface method on routers Add e2e tests

Work to be done: Cover mesh and ingress outside of Istio

Fix: #388 Fix: #488

I am trying to get a simple POC working with Gloo and Flagger, however the example docs don't work out-of-the-box.

I also noticed the example virtual-service is different in the docs compared to what's in the repo?

The specifics regarding mapping a virtual-service to an upstream seem to be different in both and I just want to know what I should follow to get this working.

I would make an issue on Gloo's repository, however I'm unsure if my error is stemming with Gloo or me following the wrong docs.

Right now, due to istio limitations, it is not possible to create a virtualservice with a mesh and another host name. For example:

if I have:

...
gateways:
- www.myapp.com
- mesh
http:
  - match:
    - uri:
        prefix: /api
    route:
    - destination:
        host: api.default.svc.cluster.local
        port:
          number: 80

and

...
gateways:
- www.myapp.com
- mesh
http:
  - match:
    - uri:
        prefix: /internal
    route:
    - destination:
        host: internal.default.svc.cluster.local
        port:
          number: 80

Istio will throw an error

Only unique values for domains are permitted. Duplicate entry of domain www.myapp.com"

The two ways of fixing this I see is for flagger to either:

1. Create a separate virtualservice and maintain the canary settings for each one correlated to the particular service deployed
2. Compile all virtualservices together into a singular virtualservice

Let me know what you think!

Hey guys I have configured Istio as a service mesh in my Kubernetes. I wanted to try A/B testing deployment-strategy along with Flagger.

I followed the following documentation to set up Flagger 1.) https://docs.flagger.app/usage/ab-testing 2.) https://docs.flagger.app/how-it-works#a-b-testing

It throws me a VirtualService error: virtualservice:publisher-d8t-v1 Weight sum should be 100 when i check my Kiali dashboard.

And on describing the canary the canary fails due to no traffic was generated. Although i made post call to my service and a response status of 200 was returned.

Can you please help me fix this error.

I have attached the respective screenshots .

VirtualService Error in Kiali:

Canary Status:

Traffic Generation and its status:

Can you please help me resolve this issue !!

Also according to istio documentation, to connect a VirtualService with DestinationRule we need to use subsets. But i see no subsets being created. How are you able to achieve traffic routing without a subset. I did read as note keep a label as app:deployment name, is this solving the purpose ??.

Thanks in advance :)

given following:

      metrics:
      - interval: 1m
        name: request-success-rate
        threshold: 99
      - interval: 30s
        name: request-duration
        threshold: 500
      stepWeight: 10
      threshold: 5
      webhooks:
      - metadata:
          cmd: hey -z 10m -q 10 -c 2 http://conf-day-demo-rest.conf-day-demo:8080/greeting
        name: conf-day-demo-loadtest
        timeout: 5s
        url: http://loadtester.loadtester/

Canary promotion fails with Halt advancement no values found for metric request-success-rate probably conf-day-demo-rest.conf-day-demo is not receiving traffic

querying metrics manually I see metrics for conf-day-demo-rest-primary but flagger queries for

destination_workload=~"{{ .Name }}"
``` which returns no data 

Hi all,

we have a problem with ingress admission webhook. Using podinfo as example we did a canary deployment.

Flagger created second ingress and after rollout was done it switch "canary" annotation from "true" to "false":

apiVersion:  networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx-v2
    nginx.ingress.kubernetes.io/canary: "false"

I added "test" annotation to main Ingress to trigger update:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: podinfo
  labels:
    app: podinfo
  annotations:
    kubernetes.io/ingress.class: "nginx-v2"
    test: "test"
...

Now when I try to apply main Ingress file I get admission webhook error:

Error from server (BadRequest): error when creating "podinfo.yaml": 
admission webhook "validate.nginx.ingress.kubernetes.io" 
denied the request: host "example.com" and 
path "/" is already defined in ingress develop/podinfo-canary

podinfo Ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: podinfo
  labels:
    app: podinfo
  annotations:
    kubernetes.io/ingress.class: "nginx-v2"
spec:
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              serviceName: podinfo
              servicePort: 80
  tls:
  - hosts:
    - example.com
    secretName: example.com.wildcard

Flagger version: 1.6.1 Ingress nginx version: 0.43

Hey everybody. I wanted to give you some feedback from my learning process using Flagger and ask you a couple of question on how to fix an issue I've been having with my current use case.

Here is it: I have an EKS cluster with two namespace, one for testing (called staging) and another for production. I've been trying to add Flagger to the staging namespace in order to enable Blue Green Deployments from my GitLab pipeline.

How do I do that? Well, I've set up a gitlab job that basically runs a kubectl command and applies the files that I've added below. This is a very basic application, that means I've been trying to implement Blue/Green style deployments with Kubernetes L4 networking.

Here is the order of how files get applied:

1. namespace
2. canary
3. deployment
4. service

I've also created a drawing to help you illustrate the situation a little bit better.

The problem with this is approach is that as soon as I apply the load balanacer manifest I got this error:

 The Service "my-app" is invalid: spec.ports[2].name: Duplicate value: "http"

I've tried applying this the same configuration on the production environment and it did work. My guess here is that somehow Flagger's ClusterIP services are creating a conflict with my load balancer, leading to a possible collision between them.

I hope that you can help me with this issue, I'll keep you posted if I find a solution.

namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: staging

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: staging
  labels:
    app: my-app
    environment: staging
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: my-app
      environment: staging
  template:
    metadata:
      labels:
        app: my-app
        environment: staging
      annotations:
        configHash: " "
    spec:
      containers:
        - name: my-app
          image: marcoshuck/my-app
          imagePullPolicy: Always
          ports:
            - containerPort: 8001
          envFrom:
            - configMapRef:
                name: my-app-config
      nodeSelector:
        server: "true"

load-balancer.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-app
  namespace: staging
  annotations:
    # Use HTTP to talk to the backend.
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
    # Amazon (AMC) certificate ARN
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: XXXXXXXXXXXXXXXXXXXXXXXXX
    # Only run SSL on the port named "tls" below.
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https"
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 8001
  - name: https
    port: 443
    targetPort: 8001
  selector:
    app: my-app
    environment: staging

canary.yaml

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: my-app
  namespace: staging
spec:
  provider: kubernetes
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  progressDeadlineSeconds: 60
  service:
    port: 8001
    portDiscovery: true
  analysis:
    interval: 30s
    threshold: 3
    iterations: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 30s
    webhooks:
      - name: load-test
        url: http://flagger-loadtester.test/
        timeout: 5s
        metadata:
          type: cmd
          cmd: "hey -z 1m -q 10 -c 2 http://my-app-canary.test:8001/"

Hi, In my deployment, I use progressDeadlineSeconds: 1200, and in the canary definition, I use canary deployment with buildin prometheus check. The canary app crashed, the deployment should be rolled back. but seems it isn't.

my-app-deployment-58b7ffb786-7dk4h                     1/2     CrashLoopBackOff   109        9h
my-app-deployment-primary-84f69c75c4-9d7x7             2/2     Running            0          16h

And the flagger logs always shows following messages with infinite loop.

{"level":"info","ts":"2020-03-26T01:38:32.078Z","caller":"controller/events.go:27","msg":"canary deployment my-app-deployment.test not ready with retryable true: waiting for
rollout to finish: 0 of 1 updated replicas are available","canary":"my-app-canary.test"}

The canary I use:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: my-app-canary
  namespace: test
spec:
  # deployment reference
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  # the maximum time in seconds for the canary deployment
  # to make progress before it is rollback (default 600s)
  progressDeadlineSeconds: 1200
  # HPA reference (optional)
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: my-app-hpa
  service:
    # ClusterIP port number
    port: 80
    # container port name or number (optional)
    targetPort: 8080
    # Istio virtual service host names (optional)
    trafficPolicy:
      tls:
        mode: ISTIO_MUTUAL
  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # max number of failed iterations before rollback
    threshold: 5
    # max traffic percentage routed to canary
    # percentage (0-100)
    maxWeight: 50
    # canary increment step
    # percentage (0-100)
    stepWeight: 10
    metrics:
      - name: request-success-rate
        # builtin Prometheus check
        # minimum req success rate (non 5xx responses)
        # percentage (0-100)
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        # builtin Prometheus check
        # maximum req duration P99
        # milliseconds
        thresholdRange:
          max: 500
        interval: 30s
    webhooks:
      - name: acceptance-test
        type: pre-rollout
        url: http://blueprint-test-loadtester.blueprint-test/
        timeout: 30s
        metadata:
          type: bash
          cmd: "curl http://my-app-deployment-canary.test"
      - name: load-test
        type: rollout
        url: http://blueprint-test-loadtester.blueprint-test/
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://my-app-deployment-canary.test"

Could you show an example of how to use this with the istio ingress? I can't seem to figure out how to point to the correct service!

More specifically, is it possible to tell the istio ingress to route based on certain criteria (i.e. a uri prefix, etc?)

Describe the bug

Since OSM is supported (SMI support added in #896), I did the following to create a canary deploy using OSM and Flagger. As recommended in #896, I used the MetricsTemplate CRDs to create the required Prometheus custom metrics (request-success-rate and request-duration).

I then created a canary custom resource for podinfo deployment, however it does not succeed. It says that the canary custom resource cannot create a TrafficSplit resource for the canary deployment.

Output excerpt of kubectl describe -f ./podinfo-canary.yaml:

Status:
  Canary Weight:  0
  Conditions:
    Last Transition Time:  2021-06-07T22:28:21Z
    Last Update Time:      2021-06-07T22:28:21Z
    Message:               New Deployment detected, starting initialization.
    Reason:                Initializing
    Status:                Unknown
    Type:                  Promoted
  Failed Checks:           0
  Iterations:              0
  Last Transition Time:    2021-06-07T22:28:21Z
  Phase:                   Initializing
Events:
  Type     Reason  Age                  From     Message
  ----     ------  ----                 ----     -------
  Warning  Synced  5m38s                flagger  podinfo-primary.test not ready: waiting for rollout to finish: observed deployment generation less then desired generation
  Normal   Synced  8s (x12 over 5m38s)  flagger  all the metrics providers are available!
  Warning  Synced  8s (x11 over 5m8s)   flagger  TrafficSplit podinfo.test create error: the server could not find the requested resource (post trafficsplits.split.smi-spec.io)

To Reproduce

./kustomize/osm/kustomization.yaml:

namespace: osm-system
bases:
  - ../base/flagger/
patchesStrategicMerge:
  - patch.yaml

./kustomize/osm/patch.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flagger
spec:
  template:
    spec:
      containers:
        - name: flagger
          args:
            - -log-level=info
            - -include-label-prefix=app.kubernetes.io
            - -mesh-provider=smi:v1alpha3
            - -metrics-server=http://osm-prometheus.osm-system.svc:7070

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: flagger
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: flagger
subjects:
  - kind: ServiceAccount
    name: flagger
    namespace: osm-system

Used MetricTemplate CRD to implement required custom metric (recommended in #896) - request-success-rate.yaml:

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
  name: request-success-rate
  namespace: osm-system
spec:
  provider:
    type: prometheus
    address: http://osm-prometheus.osm-system.svc:7070
  query: |
    sum(
        rate(
            osm_request_total{
              destination_namespace="{{ namespace }}",
              destination_name="{{ target }}",
              response_code!="404"
            }[{{ interval }}]
        )
    )
    /
    sum(
        rate(
            osm_request_total{
              destination_namespace="{{ namespace }}",
              destination_name="{{ target }}"
            }[{{ interval }}]
        )
    ) * 100

Used MetricTemplate CRD to implement required custom metric (recommended in #896) - request-duration.yaml:

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
  name: request-duration
  namespace: osm-system
spec:
  provider:
    type: prometheus
    address: http://osm-prometheus.osm-system.svc:7070
  query: |
    histogram_quantile(
      0.99,
      sum(
        rate(
          osm_request_duration_ms{
            destination_namespace="{{ namespace }}",
            destination_name=~"{{ target }}"
          }[{{ interval }}]
        )
      ) by (le)
    )

podinfo-canary.yaml:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  provider: "smi:v1alpha3"
  # deployment reference
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  # HPA reference (optional)
  autoscalerRef:
    apiVersion: autoscaling/v2beta2
    kind: HorizontalPodAutoscaler
    name: podinfo
  # the maximum time in seconds for the canary deployment
  # to make progress before it is rollback (default 600s)
  progressDeadlineSeconds: 60
  service:
    # ClusterIP port number
    port: 9898
    # container port number or name (optional)
    targetPort: 9898
  analysis:
    # schedule interval (default 60s)
    interval: 30s
    # max number of failed metric checks before rollback
    threshold: 5
    # max traffic percentage routed to canary
    # percentage (0-100)
    maxWeight: 50
    # canary increment step
    # percentage (0-100)
    stepWeight: 5
    # Prometheus checks
    metrics:
    - name: request-success-rate
      # minimum req success rate (non 5xx responses)
      # percentage (0-100)
      thresholdRange:
        min: 99
      interval: 1m
    - name: request-duration
      # maximum req duration P99
      # milliseconds
      thresholdRange:
        max: 500
      interval: 30s
    # testing (optional)
    webhooks:
      - name: acceptance-test
        type: pre-rollout
        url: http://flagger-loadtester.test/
        timeout: 30s
        metadata:
          type: bash
          cmd: "curl -sd 'test' http://podinfo-canary.test:9898/token | grep token"
      - name: load-test
        type: rollout
        url: http://flagger-loadtester.test/
        metadata:
          cmd: "hey -z 2m -q 10 -c 2 http://podinfo-canary.test:9898/"

Output excerpt of kubectl describe -f ./podinfo-canary.yaml:

Status:
  Canary Weight:  0
  Conditions:
    Last Transition Time:  2021-06-07T22:28:21Z
    Last Update Time:      2021-06-07T22:28:21Z
    Message:               New Deployment detected, starting initialization.
    Reason:                Initializing
    Status:                Unknown
    Type:                  Promoted
  Failed Checks:           0
  Iterations:              0
  Last Transition Time:    2021-06-07T22:28:21Z
  Phase:                   Initializing
Events:
  Type     Reason  Age                  From     Message
  ----     ------  ----                 ----     -------
  Warning  Synced  5m38s                flagger  podinfo-primary.test not ready: waiting for rollout to finish: observed deployment generation less then desired generation
  Normal   Synced  8s (x12 over 5m38s)  flagger  all the metrics providers are available!
  Warning  Synced  8s (x11 over 5m8s)   flagger  TrafficSplit podinfo.test create error: the server could not find the requested resource (post trafficsplits.split.smi-spec.io)

Full output of kubectl describe -f ./podinfo-canary.yaml: https://pastebin.ubuntu.com/p/kB9qtPxZvr/

Expected behavior

A clear and concise description of what you expected to happen.

Additional context

• Flagger version: 1.11.0
• Kubernetes version: 1.19.11
• Service Mesh provider: smi (through osm)
• Ingress provider: N/A.

Describe the feature

This might already exist, please point me in the direction if it does.

I'd like to be able to exclude (or include) specific annotation prefixes from being copied over to the primary deployments.

I noticed similar functionality exists for labels with --include-label-prefix but nothing exists for annotations.

For context, we're looking to use stakater/Reloader which allows us to reload pods when configmap and/or secrets change. This works well for us at the moment, and flagger also handles this gracefully too.

However, since Reloader is annotation based, the Reloader annotation config that we include in the original Deployment resource is then copied over to the Primary Deployment resource, meaning that when a configmap and/or secret changes, Reloader will patch both the Original and Primary Deployments at the same time as both will now include the annotation, whereas we would only want the Original Deployment to be patched (which would then trigger a Flagger rollout naturally)

I'd like to specify that Flagger should not include Reloader annotations, or similar to --include-label-prefix specify which annotations should be included.

Proposed solution

Replicate the behaviour of --include-label-prefix to a new argument --include-annotation-prefix

Happy to PR if you see value in this.

We are facing issues with MQL while trying to Integration StackDriver with Flagger to Perform Canary Analysis. We have a GKE Cluster Setup and Workload Identity Configured for the Service Account.

During the analysis, events reported are as below:

test             0s          Normal    Synced                    canary/ankit                                                 Starting canary analysis for podinfo.test
test             0s          Normal    Synced                    canary/ankit                                                 Pre-rollout check acceptance-test passed
test             0s          Normal    Synced                    canary/ankit                                                 Advance ankit.test canary weight 10
test             0s          Warning   Synced                    canary/ankit                                                 Metric query failed for error-rate: error requesting stackdriver: rpc error: code = InvalidArgument desc = Request was missing field name.
test             0s          Warning   Synced                    canary/ankit                                                 Metric query failed for error-rate: error requesting stackdriver: rpc error: code = InvalidArgument desc = Request was missing field name.
test             0s          Warning   Synced                    canary/ankit                                                 Metric query failed for error-rate: error requesting stackdriver: rpc error: code = InvalidArgument desc = Request was missing field name.
test             0s          Warning   Synced                    canary/ankit                                                 Metric query failed for error-rate: error requesting stackdriver: rpc error: code = InvalidArgument desc = Request was missing field name.
test             0s          Warning   Synced                    canary/ankit                                                 Metric query failed for error-rate: error requesting stackdriver: rpc error: code = InvalidArgument desc = Request was missing field name.

I have a metric template as below that uses the query to fetch a sample metric which in this case if limit utilization.

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
  name: error-rate
  namespace: test
spec:
  provider:
    type: stackdriver
  query: |
    fetch k8s_container
    | metric 'kubernetes.io/container/cpu/limit_utilization'
    | filter (resource.namespace_name == 'flagger-system')
    | align delta(1m)
    | every 1m
    | group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]

Could you please provide suggestions on where we might be going wrong?

Bumps actions/cache from 3.0.11 to 3.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Currently flagger supports advanced deployment strategies mainly via a service mesh or an ingress. These advanced methods are great but they also add extra complexity.

I suggest adding a new deployment method via pod readiness gate.

How it works:

1. A pod readiness gate is added to the deployment spec, for example:

  readinessGates:
    - conditionType: "flagger.io/progress"

2. Once a rollout takes place and new pods are launched, the deployment progress will stop until flagger updates the readiness gate
3. Flagger performs an analysis
4. If the analysis passes flagger updates the readiness gate field in the new pods
5. The deployment progresses according to the rollingUpdate strategy and new pods are launched
6. Repeat

Advantages:

1. Native deployment object can be used, no need to create new deployments and shift traffic between them
2. No need for special considerations for HPA and configmaps
3. Can work with daemonsets and statefulsets as well

I believe this feature will make flagger much more approachable to a wider audience who is not using service meshes and will allow for a super simple onboarding while using existing production deployment/hpa resources with no need for migration.

Describe the bug

Currently there is a feature toggle .Values.wbx3.canary.delegate in our canary resource definition to switch flagger virtual service used as delegate that will be called by another virtual service or take gateway traffic directly. Looks virtual service gateway and host can not update after delegation enable in canary.

To Reproduce

canary.yaml

  service:
    name: hello-world-flagger
    port: 8080
    portDiscovery: true
    {{ $delegateEnabled := lower $.Values.wbx3.canary.delegate}}
    {{- if eq $delegateEnabled "true" -}}
    delegation: true
    {{- else -}}
    gateways:
     - hello-world-web
    hosts:
     - hello-world.xxxx.xxxx
    {{- end }}

• Set .Values.wbx3.canary.delegate to false, then trigger helm deploy.

$kubectl get vs
NAME                   GATEWAYS                   HOSTS                                             AGE                                                                                                          
hello-world-flagger    ["hello-world-web"]        ["hello-world.xxxx.xxxx","hello-world-flagger"]   48m

• Set .Values.wbx3.canary.delegate to true, then trigger helm deploy.

$kubectl get vs
 NAME                  GATEWAYS                   HOSTS                                            AGE   
hello-world-flagger    ["hello-world-web"]        ["hello-world.xxxx.xxxx","hello-world-flagger"]   48m

Expected behavior

Gateway and host will auto removed when delegation enabled in the canary resource.

Additional context

• Flagger version: 1.20.4
• Kubernetes version: v1.21.5
• Service Mesh provider: Istio
• Ingress provider:

I have seen that during canary analysis, if we are using datadog custom metrics, we can only push data(metrics) for the canary instance into DD ! Is there any way we can enable a same logic as DD monitors? so for example when using a MetricTemplate for not-found-percentage, is there anyway we can tell flagger to stop the rollout if the provided query 100 - ( sum:istio.mesh.request.count{ reporter:destination, destination_workload_namespace:{{ namespace }}, destination_workload:{{ target }}, !response_code:404 }.as_count() / sum:istio.mesh.request.count{ reporter:destination, destination_workload_namespace:{{ namespace }}, destination_workload:{{ target }} }.as_count() ) * 100

is above a certain threshold that we set! Thanks.