Add support for Contour ingress controller

.circleci/config.yml

@@ -150,6 +150,17 @@ jobs:
  - run: test/e2e-linkerd.sh
  - run: test/e2e-linkerd-tests.sh
 
+ e2e-contour-testing:
+ machine: true
+ steps:
+ - checkout
+ - attach_workspace:
+ at: /tmp/bin
+ - run: test/container-build.sh
+ - run: test/e2e-kind.sh
+ - run: test/e2e-contour.sh
+ - run: test/e2e-contour-tests.sh
+
  push-helm-charts:
  docker:
  - image: circleci/golang:1.13
@@ -215,6 +226,9 @@ workflows:
  - e2e-linkerd-testing:
  requires:
  - build-binary
+ - e2e-contour-testing:
+ requires:
+ - build-binary
  - push-container:
  requires:
  - build-binary

README.md

@@ -7,7 +7,7 @@
 [![release](https://img.shields.io/github/release/weaveworks/flagger/all.svg)](https://github.com/weaveworks/flagger/releases)
 
 Flagger is a Kubernetes operator that automates the promotion of canary deployments
-using Istio, Linkerd, App Mesh, NGINX or Gloo routing for traffic shifting and Prometheus metrics for canary analysis.
+using Istio, Linkerd, App Mesh, NGINX, Contour or Gloo 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.
 
@@ -69,7 +69,7 @@ metadata:
  namespace: test
 spec:
  # service mesh provider (optional)
- # can be: kubernetes, istio, linkerd, appmesh, nginx, gloo, supergloo
+ # can be: kubernetes, istio, linkerd, appmesh, nginx, contour, gloo, supergloo
  provider: istio
  # deployment reference
  targetRef:
@@ -150,21 +150,21 @@ For more details on how the canary analysis and promotion works please [read the
 
 ## Features
 
-| Feature | Istio | Linkerd | App Mesh | NGINX | Gloo | Kubernetes CNI |
-| -------------------------------------------- | ------------------ | ------------------ |------------------ |------------------ |------------------ |------------------ |
-| Canary deployments (weighted traffic) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
-| A/B testing (headers and cookies routing) | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: |
-| Blue/Green deployments (traffic switch) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Webhooks (acceptance/load testing) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Manual gating (approve/pause/resume) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Request success rate check (L7 metric) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
-| Request duration check (L7 metric) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
-| Custom promql checks | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Traffic policy, CORS, retries and timeouts | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: |
+| Feature | Istio | Linkerd | App Mesh | NGINX | Gloo | Contour | CNI  |
+| -------------------------------------------- | ------------------ | ------------------ |------------------ |------------------ |------------------ |------------------ |------------------ |
+| Canary deployments (weighted traffic) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
+| A/B testing (headers and cookies routing) | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
+| Blue/Green deployments (traffic switch) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Webhooks (acceptance/load testing) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Manual gating (approve/pause/resume) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Request success rate check (L7 metric) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
+| Request duration check (L7 metric) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
+| Custom promql checks | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Traffic policy, CORS, retries and timeouts | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
 
 ## Roadmap
 
-* Integrate with other ingress controllers like Contour, HAProxy, ALB
+* Integrate with other service mesh like Consul Connect and ingress controllers like HAProxy, ALB
 * Add support for comparing the canary metrics to the primary ones and do the validation based on the derivation between the two
 
 ## Contributing
@@ -175,9 +175,9 @@ 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)
+* which Kubernetes version
+* what configuration (canary, ingress and workloads definitions)
+* what happened (Flagger and Proxy logs)
 
 ## Getting Help
 

artifacts/flagger/account.yaml

@@ -81,6 +81,11 @@ rules:
  - virtualservices
  - gateways
  verbs: ["*"]
+ - apiGroups:
+ - projectcontour.io
+ resources:
+ - httpproxies
+ verbs: ["*"]
  - nonResourceURLs:
  - /version
  verbs:

charts/flagger/templates/rbac.yaml

@@ -77,6 +77,11 @@ rules:
  - virtualservices
  - gateways
  verbs: ["*"]
+ - apiGroups:
+ - projectcontour.io
+ resources:
+ - httpproxies
+ verbs: ["*"]
  - nonResourceURLs:
  - /version
  verbs:

docs/gitbook/README.md

@@ -5,7 +5,7 @@ description: Flagger is a progressive delivery Kubernetes operator
 # Introduction
 
 [Flagger](https://github.com/weaveworks/flagger) is a **Kubernetes** operator that automates the promotion of canary 
-deployments using **Istio**, **Linkerd**, **App Mesh**, **NGINX** or **Gloo** routing for traffic shifting and **Prometheus** metrics for canary analysis.
+deployments using **Istio**, **Linkerd**, **App Mesh**, **NGINX**, **Contour** or **Gloo** routing for traffic shifting and **Prometheus** metrics for canary analysis.
 The canary analysis can be extended with webhooks for running system integration/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 
@@ -16,7 +16,7 @@ Based on analysis of the **KPIs** a canary is promoted or aborted, and the analy
 
 Flagger can be configured with Kubernetes custom resources and is compatible with 
 any CI/CD solutions made for Kubernetes. Since Flagger is declarative and reacts to Kubernetes events, 
-it can be used in **GitOps** pipelines together with Weave Flux or JenkinsX.
+it can be used in **GitOps** pipelines together with Flux CD or JenkinsX.
 
 This project is sponsored by [Weaveworks](https://www.weave.works/)
 

docs/gitbook/faq.md

@@ -6,13 +6,13 @@
 
 Flagger can run automated application analysis, promotion and rollback for the following deployment strategies:
 * Canary (progressive traffic shifting)
- * Istio, Linkerd, App Mesh, NGINX, Gloo
+ * Istio, Linkerd, App Mesh, NGINX, Contour, Gloo
 * Canary (traffic mirroring)
  * Istio
 * A/B Testing (HTTP headers and cookies traffic routing)
- * Istio, App Mesh, NGINX
+ * Istio, App Mesh, NGINX, Contour
 * Blue/Green (traffic switch)
- * Kubernetes CNI, Istio, Linkerd, App Mesh, NGINX, Gloo
+ * Kubernetes CNI, Istio, Linkerd, App Mesh, NGINX, Contour, Gloo
 
 For Canary deployments and A/B testing you'll need a Layer 7 traffic management solution like a service mesh or an ingress controller.
 For Blue/Green deployments no service mesh or ingress controller is required.
@@ -58,6 +58,21 @@ App Mesh example:
 
 Note that App Mesh supports a single condition.
 
+Contour example:
+
+```yaml
+ canaryAnalysis:
+ interval: 1m
+ threshold: 10
+ iterations: 2
+ match:
+ - headers:
+ user-agent:
+ prefix: "Chrome"
+```
+
+Note that Contour does not support regex, you can use prefix, suffix or exact.
+
 NGINX example:
 
 ```yaml

docs/gitbook/how-it-works.md

@@ -386,7 +386,7 @@ sum(
 )
 ```
 
-Envoy query (App Mesh or Gloo):
+Envoy query (App Mesh, Contour or Gloo):
 
 ```javascript
 sum(
@@ -439,7 +439,7 @@ histogram_quantile(0.99,
 )
 ```
 
-Envoy query (App Mesh or Gloo):
+Envoy query (App Mesh, Contour or Gloo):
 
 ```javascript
 histogram_quantile(0.99,