Skip to content
Istio and App Mesh progressive delivery Kubernetes operator
Branch: master
Clone or download
stefanprodan Merge pull request #156 from weaveworks/docs-fix
Fix Tiller-less install command
Latest commit 57f1b63 Apr 22, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci Exclude docs branches from CI Apr 13, 2019
.github Add maintainers Mar 21, 2019
artifacts Disable bats in load tester artifacts Apr 19, 2019
charts Release v0.11.1 Apr 18, 2019
cmd Update deps to Kubernetes 1.13.1 Apr 18, 2019
docs Fix Tiller-less install command Apr 22, 2019
hack Update App Mesh to v1beta1 Mar 26, 2019
test Add A/B testing and hooks to e2e readme Apr 16, 2019
vendor Make codegen work with the klog shim Apr 18, 2019
.gitignore update .gitignore Mar 5, 2019
.goreleaser.yml Move to weaveworks org Mar 20, 2019
.travis.yml Switch to Docker Hub from Quay Apr 17, 2019 Update changelog for v0.11.1 Apr 18, 2019 Add contributing and code of conduct docs Oct 11, 2018
Dockerfile Update go to 1.12 Mar 27, 2019
Dockerfile.loadtester Add bash bats task runner Apr 17, 2019
Gopkg.lock Make codegen work with the klog shim Apr 18, 2019
LICENSE Copyright Weaveworks Jan 3, 2019
Makefile Update deps to Kubernetes 1.13.1 Apr 18, 2019 Use the builtin metrics in artifacts Apr 18, 2019 Add contributing and code of conduct docs Oct 11, 2018


build report codecov license release

Flagger is a Kubernetes operator that automates the promotion of canary deployments using Istio or App Mesh routing for traffic shifting and Prometheus metrics for canary analysis. The canary analysis can be extended with webhooks for running acceptance tests, load tests or any other custom validation.

Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pods health. Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack.



Flagger documentation can be found at

Canary CRD

Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler (HPA), then creates a series of objects (Kubernetes deployments, ClusterIP services and Istio or App Mesh virtual services). These objects expose the application on the mesh and drive the canary analysis and promotion.

Flagger keeps track of ConfigMaps and Secrets referenced by a Kubernetes Deployment and triggers a canary analysis if any of those objects change. When promoting a workload in production, both code (container images) and configuration (config maps and secrets) are being synchronised.

For a deployment named podinfo, a canary promotion can be defined using Flagger's custom resource:

kind: Canary
  name: podinfo
  namespace: test
  # deployment reference
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  # the maximum time in seconds for the canary deployment
  # to make progress before it is rollback (default 600s)
  progressDeadlineSeconds: 60
  # HPA reference (optional)
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: podinfo
    # container port
    port: 9898
    # Istio gateways (optional)
    - public-gateway.istio-system.svc.cluster.local
    - mesh
    # Istio virtual service host names (optional)
    # HTTP match conditions (optional)
      - uri:
          prefix: /
    # HTTP rewrite (optional)
      uri: /
    # Envoy timeout and retry policy (optional)
          x-envoy-upstream-rq-timeout-ms: "15000"
          x-envoy-max-retries: "10"
          x-envoy-retry-on: "gateway-error,connect-failure,refused-stream"
    # cross-origin resource sharing policy (optional)
  # promote the canary without analysing it (default false)
  skipAnalysis: false
  # define the canary analysis timing and KPIs
    # schedule interval (default 60s)
    interval: 1m
    # max number of failed metric checks before rollback
    threshold: 10
    # max traffic percentage routed to canary
    # percentage (0-100)
    maxWeight: 50
    # canary increment step
    # percentage (0-100)
    stepWeight: 5
    # Istio Prometheus checks
    # builtin checks
    - name: request-success-rate
      # minimum req success rate (non 5xx responses)
      # percentage (0-100)
      threshold: 99
      interval: 1m
    - name: request-duration
      # maximum req duration P99
      # milliseconds
      threshold: 500
      interval: 30s
    # custom check
    - name: "kafka lag"
      threshold: 100
      query: |
    # external checks (optional)
      - name: load-test
        url: http://flagger-loadtester.test/
        timeout: 5s
          cmd: "hey -z 1m -q 10 -c 2 http://podinfo.test:9898/"

For more details on how the canary analysis and promotion works please read the docs.


Feature Istio App Mesh
Canary deployments (weighted traffic) ✔️ ✔️
A/B testing (headers and cookies filters) ✔️
Load testing ✔️ ✔️
Webhooks (custom acceptance tests) ✔️ ✔️
Request success rate check (Envoy metric) ✔️ ✔️
Request duration check (Envoy metric) ✔️
Custom promql checks ✔️ ✔️
Ingress gateway (CORS, retries and timeouts) ✔️


  • Integrate with other service mesh technologies like Linkerd v2, Super Gloo or Consul Mesh
  • Add support for comparing the canary metrics to the primary ones and do the validation based on the derivation between the two


Flagger is Apache 2.0 licensed and accepts contributions via GitHub pull requests.

When submitting bug reports please include as much details as possible:

  • which Flagger version
  • which Flagger CRD version
  • which Kubernetes/Istio version
  • what configuration (canary, virtual service and workloads definitions)
  • what happened (Flagger, Istio Pilot and Proxy logs)

Getting Help

If you have any questions about Flagger and progressive delivery:

Your feedback is always welcome!

You can’t perform that action at this time.